Re: Integers on 64-bit machines

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Fri, 13 Jul 2007 11:57:04 +0200

          From comp.compilers

Related articles
[15 earlier articles]
Re: Integers on 64-bit machines cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-08)
Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-09)
Re: Integers on 64-bit machines torbenm@app-6.diku.dk (2007-07-09)
Re: Integers on 64-bit machines gneuner2@comcast.net (George Neuner) (2007-07-09)
Re: Integers on 64-bit machines dot@dotat.at (Tony Finch) (2007-07-09)
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: Fri, 13 Jul 2007 11:57:04 +0200
Organization: Compilers Central
References: 07-07-007 07-07-014 07-07-017 07-07-026 07-07-037
Keywords: arithmetic, design, storage
Posted-Date: 15 Jul 2007 16:26:57 EDT

George Neuner wrote:


> Subranges are mapped into an appropriately sized integral type. So
> depending on where you make your range declaration(s), you are either
> using a larger data type everywhere or performing a local conversion
> anyway.


Right, the *storage* format must match the container (memory, register).
Local conversions occur just like for other variables, when a smaller
operand must be extended to the size of the bigger one.




> Actually, the integer compare instructions on many CPUs correctly
> handles the n+1 bit result,


You mean the overflow and carry flags? These flags contain meaninful
values only after a comparison of arguments of the same signedness.
Typically the *following* instructions determine the *interpretation* of
the comparison result, as either a comparison of two signed or two
unsigned values.




> but a compiler may choose instead to use
> subtraction and not catch the over/underflow.


When the language allows for such behaviour...




> Most C compilers warn about mixing signed and unsigned values in an
> expression - at least if the programmer doesn't turn off the warning.
> Comparing them is usually a stupid mistake, but it works except at the
> corner case where the unsigned value exceeds the largest positive
> value of the corresponding signed type.


Right. With subrange types one can make sure that the corner case never
will occur, without assembly code hacks.




> If the data cooperates, one trick you can use in C is to define
> reduced range integer types using structures and bit fields. For
> example, if you define a 20-bit signed type and a 19-bit unsigned
> type, you know that these can be compared cleanly (even if the
> compiler warns) and that an unsigned value could be safely assigned to
> a signed type (though not the reverse).


Right, C bitfields define subranges. But I never saw code that used
bitfields for exactly that purpose, only for packing multiple values
into one container.




> Bit field integers must fit into a machine register (so no 37-bit
> integers on a 32-bit machine :) and they require masking or shifting
> so they are slower to use than plain integers (though the hit is
> generally minor if you limit one bit field to a structure).


Right, packing multiple bitfields into one container results in more
code and slower computations. It's the designer's choice, as appropriate
or acceptable in a concrete application.


DoDi


Post a followup to this message

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