Various unclear floating point semantics

[alexrp]

While implementing simulation for the various floating point instructions, I came across several things that are not entirely clear.

1. For FMADD/FMSUB, should a NaN result have the sign bit of RD ^ RN ^ RM, or just RN ^ RM?
2. Do FMADD/FMSUB not actually check for RD == NAN in Operation?
3. When an FPU exception is raised, should instructions still yield useful/well-defined results?
4. Some Operation descriptions for floating point instructions set some kind of N flag. What is this?

[timpart]

[aolofsson]

Thanks Tim! It will be fixed!

[aolofsson]

Missed the first three questions...

Q: For FMADD/FMSUB, should a NaN result have the sign bit of RD ^ RN ^ RM, or just RN ^ RM?
A: It follows this exact logic:
nan_result_flag= rn_is_nan ? rn[31] :
rm_is_nan ? rm[31] : rd[31];

Q: Do FMADD/FMSUB not actually check for RD == NAN in Operation?
A: Yes they do.

Q: When an FPU exception is raised, should instructions still yield useful/well-defined results?
A: quiet NAN is returned

[alexrp]

Regarding the first question:

1. Is this the same logic used for other floating point operations than FMADD/FMSUB? Or is that logic more like `nan_result_flag = rn_is_nan ? rn[31] : rm[31]`?
2. This logic isn't actually exactly equivalent to XORing the sign bits, is it?

[alexrp]

@aolofsson ping - did you see my two extra questions?

[aolofsson]

[alexrp]

Should I implement the XOR behavior or the chained-?: behavior? Which is more likely to be future-proof?

[alexrp]

@aolofsson - ping in case you didn't see this :)

[aolofsson]

I recommend implementing the chained logic that I provided, since this covers the current two versions of the chip (Epiphany-III and Epiphany-IV).
I suspect there will be more than one interesting corner case popping up once we start running validation software comparing the simulator to the cgen model.
Andreas