IRC logs for #openrisc Monday, 2013-01-21

stekernfinally some progress with the immu...06:10
stekernit's a bit of a weird setup right now though, I've got VIPT on the immu and PIPT on dmmu06:11
juliusbstekern: nice to hear09:38
juliusbI'm back inthe UK (snowy, malfunctioning), hacked on some mor1kx in transit09:38
juliusbwriting software tests for overflow09:39
juliusbI'm a bit confused as to its usefulness to be honest09:39
juliusbin terms of creating exceptions09:39
juliusbwithout explicit signed or unsigned add, it's a bit silly that you're going to get an exception on the addition of an unsigned number09:40
juliusbsubtact, too, i'm a bit confused, mainly about the use of the carry bit09:40
juliusbwhat the point of that is - I get you can use it to indicate borrowing from the next word along, but how to use that efficiently is a bit beyond me09:40
juliusb(haha, literally, a single bit I can't figure out how to use properly :P)09:41
juliusbin some cases it makes sense09:41
juliusbbut I think fundamentally the whole carry overflow stuff is a bit flawed in terms of its actual use to make computing faster09:42
juliusbbecause obviously GCC knows how to do all this stuff now, and it does it with comparisons and branching to do carry for adds and borrow for subtract09:42
juliusbanyway, have been a bit scattered in my efforts, had some heavy work stuff lately, and been on holiday which didn't give me much time to hack on stuff acutally (no rainy days, just blue skies and beach, dammit) and have been meaning to do an email to the list to ask about it09:44
juliusbanyway, I think, if you really care about putting overflow detection in, you want explicit signed add/subtract09:46
juliusbotherwise you'll get all sorts of false alarms09:46
juliusbmaybe something indicating that you only trigger an exception on that instruction alone09:47
juliusbbecause at present, a range exception is level-sensitive to SR[OV], it's not edge-triggered if you get what i mean09:47
juliusband it's been a massive pain trying to test overflow because of that09:48
LoneTechgood morning09:49
stekern(carry) we have an add with carry instruction, right?09:52
LoneTechyes. they're all specified as signed09:53
LoneTechwhich is a bit funny as the lower adds in a carry chain are better regarded as unsigned09:53
LoneTechi.e. if you do want to check overflow on a wide add, you only want it checked on the last add09:53
LoneTechjuliusb: regarding subtract with carry, you can invert the upper words of the second value and use add with carry. In essence a 2 complement subtract is an add with carry in=1 and the second word ~inverted10:17
LoneTechthe easy way to invert on openrisc is to have a register hold -1, and l.xor with it10:19
LoneTechoh, l.xori is sign extended, no need for the register then10:20
juliusbLoneTech: precisely (on lower words being treated as unsigned)10:28
juliusbI don't get why you invert the upper words of the second value?10:30
juliusbyou're talking about turning a-b into a + (~b) + 1?10:31
juliusbthe hardware for OR1200 and mor1kx already does this by default for subtract10:31
juliusbbut i'm looking for a foolproof way of doing the 'borrow' efficiently10:32
juliusbjust say you have a-b and both a>0 and b>0, then it's easy10:32
juliusbif the carry bit is set from the lower word's subtract then when doing upper words, you _don't_ set the carry-in bit for a + (~b) + 110:33
juliusbbecause if you do ~b of b>0 then you'll end up with a 2s complement value which is one larger than the positive value (ie 0x1 inverted is 0xfffe which is -2)10:34
juliusbso for b>0 only then you can do a trick where carry-in is negated for a + (~b) + 1, bu that's only useful if you have a subtract-with-borrow instruction to know to do that, and only good for b>0, or unsigned numbers10:35
juliusboh but this also fails for 010:35
juliusb:P10:35
juliusboh wait, no it works I think10:35
juliusbanyway, it fails for subtracting negative numbers10:36
juliusb0xfffe (-2) if inverted without doing the + 1 is just positive 110:37
juliusbso for negative numbers you do need another step10:37
juliusbyou could try to detect sign or something10:37
juliusband have an additional entire 32-bit incrementer for those cases10:37
juliusbbut I guess it seems silly10:38
juliusband... this whole thing sort-of does seem silly, GCC does it pretty efficiently, and I'm not sure how much we could improve on that10:38
juliusbunless there's a trick I'm missing (ha ha)10:39
juliusbwhich there could well be10:39
juliusbbut it's confusing to keep in mind that in hardware our subtractions are a + (~b) + 110:40
juliusbl.sub causes b's inversion in hardwae and the carry-in bit to be set10:40
juliusb.. and then it's a straightfoward add10:40
LoneTechright10:40
juliusbso, considering the case of unsigned, perhaps you could use the borrow trick of inverting the carry-in10:41
juliusbwhen it's signed you can't do it for negative values10:42
juliusbbut for unsigned (ie. most significant word is unsigned) I thikn that might work?10:42
LoneTechwhat borrow trick?10:42
* LoneTech is a little distracted, sorry10:42
juliusbso, say you do {a[1],a[0]} - {b[1],b[0]} where a and b are 64-bit values and you can index them in 32-bit words10:43
juliusbnps10:43
LoneTechI translate that to {a1,a0}-{~b1,~b0} with intial carry in 1. afaicr the carry chain works as usual10:45
juliusbso first of all you do a[0] - b[0], if you do a + (~b) + 1 and you get carry-out, then that means we had to borrow a bit from the next word as the resulting word > a[1] and wrapped10:45
juliusbso you can either subtract 1 from a[1] or add 1 to b[1] to implement the borrow10:46
stekernLoneTech: you mean {a1,a0}+{~b1,~b0} with intial carry in 1, or have I completely fell of the wagon?10:47
juliusbto add 1 to b[1] you can do (due to the 2's complement trick I showed above) the inversion and not do the carry in and you'll get a "signed" value which is one greater in absolute terms than the positive value10:47
LoneTechwell, assume b=0. then carry out=1 all the way, doesn't mean borrow10:48
juliusbyes this fails for b=0 I think10:48
juliusbwell, no you would get, for your initial word no carry-out10:48
juliusbyou do a normal subtract for a[0] - b[0] and you'll get a[0] as the result with no carry-out10:49
juliusbthis all falls apart when b is signed, I think10:49
LoneTechbut ~0+1 already overflows (produces carry). doesn't matter what a is.10:50
juliusbLoneTech: no, that process of (~b)  + 1 is separate10:50
LoneTechnot with the trick to put that +1 into carry in10:51
juliusbit's not what is regarded as the actual operation, it's just modification of the operand so we can use adder hardware10:51
juliusbmmmm10:51
juliusbno it still is I tthnk, you're just preparing the operand10:51
juliusbbut can take advantage of the unusual property that if you don't add 1, you get a value 1 greater in two's complement format10:52
juliusbso if you need to borrow from the next word of a, you can just invert the carry-bit's meaning for the a + (~b) + carry-in10:52
juliusband get a value of b which is 1 greater in absolute terms10:53
juliusb... I think!10:53
juliusb:)10:53
juliusbfor unsigned only10:53
juliusbbut prove me wrong10:53
LoneTechwe're looking specifically at unsigned now?10:55
juliusbso, I think if we have an unsigned subtract instruction (which we don't in OR1K) and an unsigned-subtract-with-borrow instruction (which we don't) then this could be used as a trick :)10:55
juliusbLoneTech: yes, we are, this fails for signed-negative numbers I believe10:55
juliusbI'm just saying, I observed this during my look at if we have any efficient ways of implementing borrow for OR1K10:56
juliusbgiven the current instructinos10:56
LoneTechhang on a moment10:56
juliusbI'm still stumped for handling borrow on signed subtract10:56
LoneTechI think the neat thing of two's complement is you don't; it all boils down to a plain add chain10:57
juliusbwhich, I guess, is only important for the most-significant word10:57
juliusbLoneTech: explain further??10:58
LoneTechif I do unsigned subtract with a+~b+1, I expect carry to be set. let's boil it down to one bit: 0+~0+1=10, 0+~1+1=01 (overflow), 1+~0+1=11, 1+~1+1=10. so the carry bit becomes a not-borrow?10:59
juliusbah, the 6:45 Kings Cross to Cambridge is finally arriving (at 9PM)11:00
LoneTechpunctual as ever, I hear11:00
juliusbLoneTech: can we continue this later... althought he carry-bit indicating not-borrow seems right11:00
juliusbit's the snow here today, anda  bridge strike on the line11:00
juliusbmust run11:00
juliusbttyl11:00
LoneTechsee you11:00
LoneTechs/overflow/underflow/11:21
blueCmd l.sw            0(r2),r221:52
blueCmdthat just doesn't make sense. it must be a bug21:53
LoneTechit all depends on context. Storing a pointer to the location it is stored is a bit circular, but might be sensible22:18
blueCmdyes, well it crashes so something is broken :)22:31
blueCmd_franck_: how do you build gdb?22:42
blueCmdis it just --enable-gdb to configure?22:42
blueCmd_franck_: I get ../../or1k-src/gdb/or1k-tdep.c:568:3: error: implicit declaration of function ‘insn_decode’ [-Werror=implicit-function-declaration]22:43
hnoYes. Finally managed to compile orpsocv2 for ordb2a.. Still have no clue what I am doing, but at least something working as reference.23:17
blueCmdhno: I recognize myself all too well :P23:23
_franck_blueCmd: don't use -Werror :) Need to add extern initialize_file_ftype _initialize_or1k_tdep; /* -Wmissing-prototypes */23:32
_franck_like here: https://github.com/Franck79/or1k-src/blob/or1k/gdb/mips-tdep.c#L879123:32
blueCmd_franck_: hah sorry about that. could have sworn it said "no such function"23:35
_franck_fix pushed23:37
blueCmd_franck_: hah, sorry - i wasn't even compiling your fork23:38
* blueCmd is a bit tired23:38
blueCmdforgot to change which directory it used23:38
_franck_:)23:38
blueCmd_franck_: ../../gdb-src/gdb/or1k-tdep.c:1796:3: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Werror=format] ;)23:40
_franck_http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Installation_of_development_versions23:41
_franck_# NOTE: on 32-bit machines --disable-werror is needed due to an enum acting as bit mask is considered signed23:41
blueCmdaw man - I want Werror :(23:42
_franck_the code causing the warning is autogenerated so the fix isn't trivial for me23:42
blueCmdhm I'm using 64 bit machine though23:42
blueCmd_franck_: anyway, next error http://pastebin.com/HACutp15 :)23:49
blueCmdsorry if I'm being troublesome, my guess is that you have seen these before and know a quick fix for them23:49

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!