| stekern | so there seems to be a lot to wish for in the lf.sf descriptions in the arch man, what is the result of the comparison if one of the operands is a qNaN? | 06:51 |
|---|---|---|
| jeremybennett | stekern: Doesn't IEEE 754 have something to say about how FP comparisons should work? | 10:32 |
| stekern | jeremybennett: I haven't read the actual standard, but reading from the net this is what it seems to roughly say: "Under the IEEE-754 standard there are four possible relationships between two floating point values. They can be equal, the first can be less than the second, the first can be greater than the second, and they can be unordered. If any NaNs are involved, the two values are unordered. Further, any comparison that involves a NaN raises an invalid operation exception." | 12:31 |
| stekern | from this page: http://www.petebecker.com/js/js200012.html | 12:31 |
| stekern | so, most likely the lf.sf comparisons are ordered, but this isn't clear in the arch spec | 12:34 |
| stekern | and it is also not clear if performing an lf.sf on a qNaN will set the qNaN flag in FPSR | 12:35 |
| stekern | ...now, I'll got check our implementations and see what they actually do ;) | 12:36 |
| stekern | apart from that, it sucks that we don't have separate ordered and unordered compares | 12:38 |
| jeremybennett | stekern: If it helps, Or1ksim uses a third party FP implementation, softfloat, which is supposed to be quite rigorous in its implementation of IEEE-754 | 13:00 |
| jeremybennett | Might be a useful reference point. | 13:01 |
| stekern | thanks, will do | 13:06 |
| stekern | although, that will not really answer the real question, are lf.sf ordered or unordered, since even if softfloat is rigorously implementing IEEE-754, or1ksim will need to make a decision from the result that softfloat returns | 13:10 |
| stekern | but given that it's the golden reference, that decision should give a hint what ought to be said in the arch spec ;) | 13:11 |
| stekern | some runtime tests with or1ksim shows that at least an exception rises on lf.sf with a nan (this is contrary to what the arch spec specifies, it says: "Exceptions: None" | 13:40 |
| jeremybennett | That's useful to know. One of the things about using softfloat was we hoped it would give us some guidance about things like this. | 14:03 |
| jeremybennett | Credit to juliusb who actually did the work. | 14:03 |
| juliusb | stekern: good question on the unordered stuff | 17:41 |
| juliusb | (or, at least, testing if one is NaN or not...) | 17:41 |
| juliusb | it looks like in the OR1200 FPU that I put together, we only set the QNAN flag in the FPCSR on arithmetic ops only | 17:48 |
| juliusb | so not on comparisons or converions | 17:48 |
| juliusb | softfloat, I dunno | 17:48 |
| juliusb | many dark, murky corners to test for this floating point stuff, it seems :( | 17:49 |
| juliusb | but, if you're looking, what flags get set during what ops int he OR1200 is in the or1200_fpu.v file, just look for the synchronous block doing all of the assigns to the fpcsr_r register | 17:50 |
| juliusb | shoudl be clear enough | 17:50 |
| juliusb | the softfloat stuff in or1ksim looks like it checks for NaN (exponent == 0xff and fractional part != 0) and if so raises an exception | 17:52 |
| juliusb | so.... yes | 17:54 |
| juliusb | perhaps a difference in implementations here | 17:54 |
| juliusb | the softfloat comparison functions call float_raise() if either operands are NaN, that then sets a global flags value called float_exception_flags and that is checked in the float_set_flags() function in cpu/or32/execut.c | 17:56 |
| juliusb | and float_set_flags() is called "running" each floating point instruction (calling the softfloat emulation function for that instruction) | 17:57 |
| juliusb | and that is done on eeach of the comparison insns | 17:57 |
| juliusb | so... yep, we will be seeing exceptions for NaNs in comparisons in or1ksim, but not on or1200 | 17:58 |
| juliusb | another thing to note on the wiki, perhaps, that we need to sort thato ut | 17:58 |
| juliusb | in the architecture manual, I mean | 17:58 |
| juliusb | actually, the flag getting set by or1ksim will be the invalid flag, not the qnan flag | 18:01 |
| juliusb | so guess who's been staring at a cortex m3 doing its thing lately | 18:03 |
| juliusb | at least, looking at it do its thing on the bus | 18:03 |
| juliusb | it's quite impressive, every cycle is used somehow, to fetch something useful or speculative | 18:04 |
| juliusb | it's a bit odd, though, they basically have two bus interfaces, one for "code" area (so ROM basically, both instruction and data via same bus infterface) then a "system" interface | 18:04 |
| juliusb | which goes to everything outside the ROM area | 18:05 |
| juliusb | which means, I guess, to an extent the data RAM manipulation stuff can be done in parallel to code and data fetches from ROM | 18:05 |
| juliusb | well, data RAM and peripheral register manipulation | 18:06 |
| stekern | (difference in implementations) yes, that's why the spec has to be much more clear on this kind of stuff, otherwise it's just guessing | 18:50 |
| stekern | ah, and the exception I saw was an illegal instruction... I hadn't turned on hardfloat support in the config | 19:13 |
| stekern | interesting about the two busses btw, I guess it's pretty much assumed that you will most of the time run from some kind of ROM/FLASH | 19:15 |
| juliusb | (busses) yes, on the embedded ASIC implementations this thing has been designed for, that's almost a given | 19:37 |
| stekern | cpu/or32/insnet.c gives the definite answer wether the lf.sf operations are ordered or unordered at least | 21:01 |
| stekern | if((!float32_lt((unsigned int)PARAM0, (unsigned int)PARAM1) & | 21:01 |
| stekern | !float32_is_nan( (unsigned int)PARAM0) & | 21:01 |
| stekern | !float32_is_nan( (unsigned int)PARAM1) ) ) | 21:01 |
| stekern | cpu_state.sprs[SPR_SR] |= SPR_SR_F; | 21:01 |
| stekern | so, ordered | 21:02 |
| stekern | I wonder why LLVM is so keen on infering unordered compares though | 21:03 |
| stekern | I think I have been silly all day, ordered gt == unordered !le, right? | 21:31 |
| stekern | i.e.: (!a_qnan && !b_qnan && a > b) == !(a_qnan || b_qnan || a <= b) | 21:32 |
| juliusb | hmm, should be noted in the arch spec then | 23:54 |
| juliusb | so i'm wondering if you really need the set-flag-if-*not*-equal | 23:55 |
| juliusb | if you then have the option to do things if either flag or no flag | 23:55 |
| juliusb | so could sfne be dropped, essentially | 23:55 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!