|[20 earlier articles]|
|Re: Integers on 64-bit machines email@example.com (Marco van de Voort) (2007-07-10)|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-13)|
|Re: Integers on 64-bit machines cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-13)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (napi) (2007-07-13)|
|Re: Integers on 64-bit machines email@example.com (Stefan Monnier) (2007-07-14)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (George Neuner) (2007-07-16)|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-19)|
|Re: Integers on 64-bit machines email@example.com (George Neuner) (2007-07-19)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||Thu, 19 Jul 2007 08:29:15 +0200|
|References:||07-07-007 07-07-014 07-07-017 07-07-026 07-07-037 07-07-050 07-07-064|
George Neuner wrote:
> What compare generally tells you that subtract may not is whether the
> corresponding arithmetic result is valid. Offhand, I can't think of
> any example of an HLL where the semantics of comparison depend on that
> particular difference. Anybody?
A HLL comparison can return a perfectly valid True/False result,
without an extra overflow case. That's different for a subtraction,
where overflows can occur, and the language specification or
implementation must specify the handling of this case.
IMO you missed my point. On machines with a single compare
instruction, different conditional jumps must be used for signed or
unsigned compares, i.e. HLL ">" becomes either BHI or BGT. No such
instructions or condition code settings exist for mixed sign
operands. The same restrictions apply to other machine architectures,
and to subtraction instead of comparison instructions.
That's why a comparison or other arithmetic on mixed sign operands
becomes more expensive than comparisons of operands of the same
signedness, on every machine.
In the case of true subranges (less bits required than a machine word
can hold), the values can be stored as either signed or unsigned
words, according to their signedness. Then all such values can be
retrieved and interpreted as signed words, preventing mixed mode
arithmetic. Otherwise, with packed bitfields, different instructions
had to be used, to signed/unsigned extend the values to the full word
size, when loading the values into the ALU.
If you or somebody else disagrees, we better discuss the topic
privately, and present the results to the group.
Return to the
Search the comp.compilers archives again.