Re: [Qemu-trivial] [PATCH 2/3] int128.h: Avoid undefined behaviours involving signed arithmetic

[Peter Maydell]

On 6 April 2014 15:13, Michael Tokarev <address@hidden> 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