Re: Integers on 64-bit machines

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

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