representable in single format?
**
-exactly the same thing as if `fld` were used to load an "unrepresentable"
-value: nothing. if `fld` raised flags or exceptions then so would (should)
-`fmvis`. these are immediates, statically-compiled. if the developer
-wants "invalid" data, statically-compiled into a binary, it is reasonable
-to assume they have good reasons for doing so.
+I'm assuming you're asking what happens if something like `f3 = 0x0080_0000_0000_0001` and `fishmv f3, 0xABCD` is executed:
+Exactly the same thing as if the FPR value isn't representable in f32 format for stfs -- the value stored is defined by the `SINGLE` pseudo-code function, no fp status bits are set. Likewise, the input f32 value for fishmv is determined by the `SINGLE` pseudo-code function, no fp status bits are set, fishmv then replaces the lower 16 bits of the f32 value with the immediate, then converts the resulting f32 back to f64 using `DOUBLE` and stores it in FRT.
**
3. The first clause of the verbal description of fishmv seems to assume
the fact that they bypass D-Cache and correspondingly raise no flags or
exceptions is the connection to `ld`. despite that i like (a) as well
-although for purely non-technical reasons (more "memorable") i do love
+although for purely non-technical reasons (more "memorable") i (Luke) do love
the two mnemonics `flis fishmv` :)
we picked "s" on the end of `fmvis` (`flis`) because it is "shifted"
-(like `oris`)
+(like `oris`), not "single". this was accidentally left out of the initial RFC submission.
+
+An alternative suggestion by Jacob Lifshay is to name them: `flis` (fp load immediate shifted) and `fli2` (fp load immediate 2nd-part), with possible (though unlikely) `fli3`/`fli4` to load the rest of the bits needed for a f64.
Other:
remaining mantissa and high exponent bits to complete a full FP64,
the cost of doing so is:
-* 1x32 flis
-* 1x32 fishmv
+* 1x64 pflis
* 1x64 pfishmv
-which is QTY 8 bytes which is actually *more* than just `fld`,
-which is only QTY 6 bytes. the only technical reason therefore is
+which totals to 16 bytes loaded which is actually *more* than just `lfd`,
+which is only 4 + 8 bytes. the only technical reason therefore is
to avoid D-Cache entirely, just like the 5-instruction sequence
that writes a 64-bit GPR only from immediates
(li, oris, rldicl, li, oris) although that is justifiable
What about fsub FRT,FRA,FRA?
**
-didn't know about it! although technically that reads registers
-(unless micro-code-redirected to an internal zeroing operation)
+That doesn't actually clear FRT to zero because NaN - NaN = Inf - Inf = NaN, not zero. Also, with round to -inf, 0 - 0 produces -0, not 0.
**
5. "FRS" for both instructions should be changed to "FRT". ("FRS" normally
integer is to use pli (extended mnemonic for paddi).)
**
-it is extremely unlikely that we (Libre-SOC) will implement any of v3.1
+it is unlikely that we (Libre-SOC) will initially implement any of v3.1
64-bit prefixing (it cannot be Vectorised, resulting unacceptably in
-96-bit instructions so what is the point). that said the LD
-addressing immediate extended range is extremely useful.
+96-bit instructions which we decided is too much). that said, the LD
+addressing immediate extended range is extremely useful (along with the PC-relative modes and also other instructions such as paddi).
-bottom line we have given almost no thought to using any v3.1 Scalar
-Prefixed instructions, at all, so don't even know 99% of what they do.
+bottom line we have not yet given much thought to using any v3.1 Scalar
+Prefixed instructions, at all, so don't even know most of what they do.
projects / libreriscv.git / commitdiff