IRC logs for #openrisc Thursday, 2012-08-02

stekernso 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
jeremybennettstekern: Doesn't IEEE 754 have something to say about how FP comparisons should work?10:32
stekernjeremybennett: 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
stekernfrom this page:
stekernso, most likely the lf.sf comparisons are ordered, but this isn't clear in the arch spec12:34
stekernand it is also not clear if performing an lf.sf on a qNaN will set the qNaN flag in FPSR12:35, I'll got check our implementations and see what they actually do ;)12:36
stekernapart from that, it sucks that we don't have separate ordered and unordered compares12:38
jeremybennettstekern: If it helps, Or1ksim uses a third party FP implementation, softfloat, which is supposed to be quite rigorous in its implementation of IEEE-75413:00
jeremybennettMight be a useful reference point.13:01
stekernthanks, will do13:06
stekernalthough, 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 returns13:10
stekernbut given that it's the golden reference, that decision should give a hint what ought to be said in the arch spec ;)13:11
stekernsome 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
jeremybennettThat'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
jeremybennettCredit to juliusb who actually did the work.14:03
juliusbstekern: good question on the unordered stuff17:41
juliusb(or, at least, testing if one is NaN or not...)17:41
juliusbit looks like in the OR1200 FPU that I put together, we only set the QNAN flag in the FPCSR on arithmetic ops only17:48
juliusbso not on comparisons or converions17:48
juliusbsoftfloat, I dunno17:48
juliusbmany dark, murky corners to test for this floating point stuff, it seems :(17:49
juliusbbut, 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 register17:50
juliusbshoudl be clear enough17:50
juliusbthe softfloat stuff in or1ksim looks like it checks for NaN (exponent == 0xff and fractional part != 0) and if so raises an exception17:52
juliusbso.... yes17:54
juliusbperhaps a difference in implementations here17:54
juliusbthe 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.c17:56
juliusband float_set_flags() is called "running" each floating point instruction (calling the softfloat emulation function for that instruction)17:57
juliusband that is done on eeach of the comparison insns17:57
juliusbso... yep, we will be seeing exceptions for NaNs in comparisons in or1ksim, but not on or120017:58
juliusbanother thing to note on the wiki, perhaps, that we need to sort thato ut17:58
juliusbin the architecture manual, I mean17:58
juliusbactually, the flag getting set by or1ksim will be the invalid flag, not the qnan flag18:01
juliusbso guess who's been staring at a cortex m3 doing its thing lately18:03
juliusbat least, looking at it do its thing on the bus18:03
juliusbit's quite impressive, every cycle is used somehow, to fetch something useful or speculative18:04
juliusbit'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" interface18:04
juliusbwhich goes to everything outside the ROM area18:05
juliusbwhich means, I guess, to an extent the data RAM manipulation stuff can be done in parallel to code and data fetches from ROM18:05
juliusbwell, data RAM and peripheral register manipulation18: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 guessing18:50
stekernah, and the exception I saw was an illegal instruction... I hadn't turned on hardfloat support in the config19:13
stekerninteresting 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/FLASH19:15
juliusb(busses) yes, on the embedded ASIC implementations this thing has been designed for, that's almost a given19:37
stekerncpu/or32/insnet.c gives the definite answer wether the lf.sf operations are ordered or unordered at least21: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
stekernso, ordered21:02
stekernI wonder why LLVM is so keen on infering unordered compares though21:03
stekernI think I have been silly all day, ordered gt == unordered !le, right?21:31
stekerni.e.: (!a_qnan && !b_qnan && a > b) == !(a_qnan || b_qnan || a <= b)21:32
juliusbhmm, should be noted in the arch spec then23:54
juliusbso i'm wondering if you really need the set-flag-if-*not*-equal23:55
juliusbif you then have the option to do things if either flag or no flag23:55
juliusbso could sfne be dropped, essentially23:55

Generated by 2.15.2 by Marius Gedminas - find it at!