Re: Integers on 64-bit machines

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Thu, 19 Jul 2007 08:29:15 +0200

          From comp.compilers

Related articles
[20 earlier articles]
Re: Integers on 64-bit machines marcov@stack.nl (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 napi@axiomsol.com (napi) (2007-07-13)
Re: Integers on 64-bit machines monnier@iro.umontreal.ca (Stefan Monnier) (2007-07-14)
Re: Integers on 64-bit machines gneuner2@comcast.net (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 gneuner2@comcast.net (George Neuner) (2007-07-19)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Thu, 19 Jul 2007 08:29:15 +0200
Organization: Compilers Central
References: 07-07-007 07-07-014 07-07-017 07-07-026 07-07-037 07-07-050 07-07-064
Keywords: arithmetic, storage

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.


DoDi



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.