On 6 April 2014 15:13, Michael Tokarev <m...@tls.msk.ru> wrote: > It is not correct either way because there's just no correct way, > because the end behavour is undefined in hardware, and we _are_ emulating > hardware here.
Incidentally, I'd disagree with that statement on two grounds: * in hardware, integer overflow is well defined (at least for all the things we emulate) -- the 99% case is "it's 2s complement" and we might have a few cases of "exception on overflow", as with x86 MININT/-1 and IIRC SPARC or MIPS have some "exception on overflow" add/subtract insns. I don't know of any h/w daft enough to make signed integer arithmetic actually undefined-behaviour. * in QEMU we're not actually using Int128 in QEMU for h/w emulation -- we just use it for doing address arithmetic in the memory subsystem so we don't run into problems with overflow and insufficient range in 64 bit integer types. In any case we can freely define the semantics of this type in any way we find convenient for ourselves. I think it's much easier to reason about things if you don't have to deal with undefined-behaviour cases (if C compilers had a "behave like a sane 2s complement system for signed arithmetic" option I'd be advocating for us using it...) thanks -- PMM