| stekern | finally some progress with the immu... | 06:10 |
|---|---|---|
| stekern | it's a bit of a weird setup right now though, I've got VIPT on the immu and PIPT on dmmu | 06:11 |
| juliusb | stekern: nice to hear | 09:38 |
| juliusb | I'm back inthe UK (snowy, malfunctioning), hacked on some mor1kx in transit | 09:38 |
| juliusb | writing software tests for overflow | 09:39 |
| juliusb | I'm a bit confused as to its usefulness to be honest | 09:39 |
| juliusb | in terms of creating exceptions | 09:39 |
| juliusb | without explicit signed or unsigned add, it's a bit silly that you're going to get an exception on the addition of an unsigned number | 09:40 |
| juliusb | subtact, too, i'm a bit confused, mainly about the use of the carry bit | 09:40 |
| juliusb | what 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 me | 09:40 |
| juliusb | (haha, literally, a single bit I can't figure out how to use properly :P) | 09:41 |
| juliusb | in some cases it makes sense | 09:41 |
| juliusb | but I think fundamentally the whole carry overflow stuff is a bit flawed in terms of its actual use to make computing faster | 09:42 |
| juliusb | because 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 subtract | 09:42 |
| juliusb | anyway, 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 it | 09:44 |
| juliusb | anyway, I think, if you really care about putting overflow detection in, you want explicit signed add/subtract | 09:46 |
| juliusb | otherwise you'll get all sorts of false alarms | 09:46 |
| juliusb | maybe something indicating that you only trigger an exception on that instruction alone | 09:47 |
| juliusb | because at present, a range exception is level-sensitive to SR[OV], it's not edge-triggered if you get what i mean | 09:47 |
| juliusb | and it's been a massive pain trying to test overflow because of that | 09:48 |
| LoneTech | good morning | 09:49 |
| stekern | (carry) we have an add with carry instruction, right? | 09:52 |
| LoneTech | yes. they're all specified as signed | 09:53 |
| LoneTech | which is a bit funny as the lower adds in a carry chain are better regarded as unsigned | 09:53 |
| LoneTech | i.e. if you do want to check overflow on a wide add, you only want it checked on the last add | 09:53 |
| LoneTech | juliusb: 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 ~inverted | 10:17 |
| LoneTech | the easy way to invert on openrisc is to have a register hold -1, and l.xor with it | 10:19 |
| LoneTech | oh, l.xori is sign extended, no need for the register then | 10:20 |
| juliusb | LoneTech: precisely (on lower words being treated as unsigned) | 10:28 |
| juliusb | I don't get why you invert the upper words of the second value? | 10:30 |
| juliusb | you're talking about turning a-b into a + (~b) + 1? | 10:31 |
| juliusb | the hardware for OR1200 and mor1kx already does this by default for subtract | 10:31 |
| juliusb | but i'm looking for a foolproof way of doing the 'borrow' efficiently | 10:32 |
| juliusb | just say you have a-b and both a>0 and b>0, then it's easy | 10:32 |
| juliusb | if 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) + 1 | 10:33 |
| juliusb | because 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 |
| juliusb | so 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 numbers | 10:35 |
| juliusb | oh but this also fails for 0 | 10:35 |
| juliusb | :P | 10:35 |
| juliusb | oh wait, no it works I think | 10:35 |
| juliusb | anyway, it fails for subtracting negative numbers | 10:36 |
| juliusb | 0xfffe (-2) if inverted without doing the + 1 is just positive 1 | 10:37 |
| juliusb | so for negative numbers you do need another step | 10:37 |
| juliusb | you could try to detect sign or something | 10:37 |
| juliusb | and have an additional entire 32-bit incrementer for those cases | 10:37 |
| juliusb | but I guess it seems silly | 10:38 |
| juliusb | and... this whole thing sort-of does seem silly, GCC does it pretty efficiently, and I'm not sure how much we could improve on that | 10:38 |
| juliusb | unless there's a trick I'm missing (ha ha) | 10:39 |
| juliusb | which there could well be | 10:39 |
| juliusb | but it's confusing to keep in mind that in hardware our subtractions are a + (~b) + 1 | 10:40 |
| juliusb | l.sub causes b's inversion in hardwae and the carry-in bit to be set | 10:40 |
| juliusb | .. and then it's a straightfoward add | 10:40 |
| LoneTech | right | 10:40 |
| juliusb | so, considering the case of unsigned, perhaps you could use the borrow trick of inverting the carry-in | 10:41 |
| juliusb | when it's signed you can't do it for negative values | 10:42 |
| juliusb | but for unsigned (ie. most significant word is unsigned) I thikn that might work? | 10:42 |
| LoneTech | what borrow trick? | 10:42 |
| * LoneTech is a little distracted, sorry | 10:42 | |
| juliusb | so, 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 words | 10:43 |
| juliusb | nps | 10:43 |
| LoneTech | I translate that to {a1,a0}-{~b1,~b0} with intial carry in 1. afaicr the carry chain works as usual | 10:45 |
| juliusb | so 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 wrapped | 10:45 |
| juliusb | so you can either subtract 1 from a[1] or add 1 to b[1] to implement the borrow | 10:46 |
| stekern | LoneTech: you mean {a1,a0}+{~b1,~b0} with intial carry in 1, or have I completely fell of the wagon? | 10:47 |
| juliusb | to 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 value | 10:47 |
| LoneTech | well, assume b=0. then carry out=1 all the way, doesn't mean borrow | 10:48 |
| juliusb | yes this fails for b=0 I think | 10:48 |
| juliusb | well, no you would get, for your initial word no carry-out | 10:48 |
| juliusb | you do a normal subtract for a[0] - b[0] and you'll get a[0] as the result with no carry-out | 10:49 |
| juliusb | this all falls apart when b is signed, I think | 10:49 |
| LoneTech | but ~0+1 already overflows (produces carry). doesn't matter what a is. | 10:50 |
| juliusb | LoneTech: no, that process of (~b) + 1 is separate | 10:50 |
| LoneTech | not with the trick to put that +1 into carry in | 10:51 |
| juliusb | it's not what is regarded as the actual operation, it's just modification of the operand so we can use adder hardware | 10:51 |
| juliusb | mmmm | 10:51 |
| juliusb | no it still is I tthnk, you're just preparing the operand | 10:51 |
| juliusb | but can take advantage of the unusual property that if you don't add 1, you get a value 1 greater in two's complement format | 10:52 |
| juliusb | so 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-in | 10:52 |
| juliusb | and get a value of b which is 1 greater in absolute terms | 10:53 |
| juliusb | ... I think! | 10:53 |
| juliusb | :) | 10:53 |
| juliusb | for unsigned only | 10:53 |
| juliusb | but prove me wrong | 10:53 |
| LoneTech | we're looking specifically at unsigned now? | 10:55 |
| juliusb | so, 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 |
| juliusb | LoneTech: yes, we are, this fails for signed-negative numbers I believe | 10:55 |
| juliusb | I'm just saying, I observed this during my look at if we have any efficient ways of implementing borrow for OR1K | 10:56 |
| juliusb | given the current instructinos | 10:56 |
| LoneTech | hang on a moment | 10:56 |
| juliusb | I'm still stumped for handling borrow on signed subtract | 10:56 |
| LoneTech | I think the neat thing of two's complement is you don't; it all boils down to a plain add chain | 10:57 |
| juliusb | which, I guess, is only important for the most-significant word | 10:57 |
| juliusb | LoneTech: explain further?? | 10:58 |
| LoneTech | if 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 |
| juliusb | ah, the 6:45 Kings Cross to Cambridge is finally arriving (at 9PM) | 11:00 |
| LoneTech | punctual as ever, I hear | 11:00 |
| juliusb | LoneTech: can we continue this later... althought he carry-bit indicating not-borrow seems right | 11:00 |
| juliusb | it's the snow here today, anda bridge strike on the line | 11:00 |
| juliusb | must run | 11:00 |
| juliusb | ttyl | 11:00 |
| LoneTech | see you | 11:00 |
| LoneTech | s/overflow/underflow/ | 11:21 |
| blueCmd | l.sw 0(r2),r2 | 21:52 |
| blueCmd | that just doesn't make sense. it must be a bug | 21:53 |
| LoneTech | it all depends on context. Storing a pointer to the location it is stored is a bit circular, but might be sensible | 22:18 |
| blueCmd | yes, well it crashes so something is broken :) | 22:31 |
| blueCmd | _franck_: how do you build gdb? | 22:42 |
| blueCmd | is 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 |
| hno | Yes. Finally managed to compile orpsocv2 for ordb2a.. Still have no clue what I am doing, but at least something working as reference. | 23:17 |
| blueCmd | hno: I recognize myself all too well :P | 23: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#L8791 | 23:32 |
| blueCmd | _franck_: hah sorry about that. could have sworn it said "no such function" | 23:35 |
| _franck_ | fix pushed | 23:37 |
| blueCmd | _franck_: hah, sorry - i wasn't even compiling your fork | 23:38 |
| * blueCmd is a bit tired | 23:38 | |
| blueCmd | forgot to change which directory it used | 23: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_versions | 23:41 |
| _franck_ | # NOTE: on 32-bit machines --disable-werror is needed due to an enum acting as bit mask is considered signed | 23:41 |
| blueCmd | aw man - I want Werror :( | 23:42 |
| _franck_ | the code causing the warning is autogenerated so the fix isn't trivial for me | 23:42 |
| blueCmd | hm I'm using 64 bit machine though | 23:42 |
| blueCmd | _franck_: anyway, next error http://pastebin.com/HACutp15 :) | 23:49 |
| blueCmd | sorry if I'm being troublesome, my guess is that you have seen these before and know a quick fix for them | 23:49 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!