RISC load-store verses x86 Add from memory.
|
From: Andrew Reilly on 24 Jun 2010 18:14 On Thu, 24 Jun 2010 23:04:00 +0200, Terje Mathisen wrote: > Using an INTO handler avoids the JNO, making the macro shorter, but it > also increases the cost of handling overflows very significantly. :-( Particularly if your code wants to be able to do different fix-ups for overflows from different-sized arguments... Cheers, -- Andrew
From: Chris Gray on 24 Jun 2010 23:51 Andy 'Krazy' Glew <ag-news(a)patten-glew.net> writes: > It will be fun to collect a list of idioms for overflow detection in > not-really-portable C assuming 2's complement signed and/or normal > binary unsigned. What the heck, I'll bite. These are from my current Zed byteCode engine (uses gcc's computed goto thing, hence the CASE/BREAK): CASE(bc_uadd) { z_word_t ul1, ul2; ul2 = *sp++; ul1 = *sp; ul2 += ul1; #if CHECK_ARITH if (ul2 < ul1) { ex->ex_PC = pc; runError(ex, "run-time uint add overflow"); return; } #endif *sp = ul2; BREAK; } CASE(bc_sadd) { z_sint_t sl1, sl2, sl3; sl2 = *sp++; sl1 = *sp; sl3 = sl1 + sl2; #if CHECK_ARITH if (((sl1 ^ sl2) & SIGN_BIT) == Z_ZERO) { /* Augends have same sign. Does sum? */ if (((sl2 ^ sl3) & SIGN_BIT) != Z_ZERO) { /* Sum has different sign - overflow. */ ex->ex_PC = pc; runError(ex, "run-time sint add overflow"); return; } } #endif *sp = sl3; BREAK; } (Arithmetic details are by my friend, not me.) -- Experience should guide us, not rule us. Chris Gray cg(a)GraySage.COM
From: Chris Gray on 24 Jun 2010 23:54 Andrew Reilly <areilly---(a)bigpond.net.au> writes: > On Thu, 24 Jun 2010 23:04:00 +0200, Terje Mathisen wrote: > >> Using an INTO handler avoids the JNO, making the macro shorter, but it >> also increases the cost of handling overflows very significantly. :-( > Particularly if your code wants to be able to do different fix-ups for > overflows from different-sized arguments... But, if all you want to do is essentially abort, INTO is great. But, we discovered a couple of days ago that INTO and BOUND have been removed from the 64 bit mode! ARGHHH! -- Experience should guide us, not rule us. Chris Gray cg(a)GraySage.COM
From: Terje Mathisen "terje.mathisen at on 25 Jun 2010 01:52 MitchAlsup wrote: > But back on topic: Can anyone show me a piece of code that depends on > integer overflow to create a buffer overrun? (Note: not integer > underflow) That seems almost trivial: An integer overflow turns a too-large positive result into a negative value instead, right? In that case buffer[a+b] turns out to really address buffer[-8] which is where the virtual method pointer (or some other interesting data item) happens to be located... Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen "terje.mathisen at on 25 Jun 2010 01:56
Andrew Reilly wrote: > On Thu, 24 Jun 2010 23:04:00 +0200, Terje Mathisen wrote: > >> Using an INTO handler avoids the JNO, making the macro shorter, but it >> also increases the cost of handling overflows very significantly. :-( > > Particularly if your code wants to be able to do different fix-ups for > overflows from different-sized arguments... Ouch indeed: Reach back and disassemble the ADD/SUB/whatever instruction that generated the INTO, figure out the operand size and target register, and then fix it all: Neither easy nor fast. :-( Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" |