Re: Integers on 64-bit machines

On Fri, 06 Jul 2007 06:22:49 +0200, Hans-Peter Diettrich
<DrDiettrich1@aol.com> wrote:


>Consider a common situation: the difference between two n-bit values
>requires n+1 bits, or overflows can occur when less bits are used for
>the result. Using an subrange type of wordsize-n bits, both the user and
>the compiler can be sure that a sum or difference cannot produce an
>overflow, in computations with full wordsize registers or variables.
>
>A common situation, found in many open source C codes, are comparisons
>of signed and unsigned values. The Delphi compiler warns the user, that
>the comparison requires to extend the values to the next higher type. I
>dunno what a C compiler will do in such cases, but in Delphi I can use
>appropriate subrange types to eliminate such conversions.


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.


Actually, the integer compare instructions on many CPUs correctly
handles the n+1 bit result, but a compiler may choose instead to use
subtraction and not catch the over/underflow.


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. C doesn't catch integer
over/underflows and it won't warn you about the possibility.




>Now tell me please, how one can prevent overflows or inappropriate or
>bloated comparison code, when e.g. only a single integer type is available.


You either have to catch the overflow (possibly using assembler) or
change the data representation - e.g., by scaling or offsetting - to
make sure an overflow can't happen.




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).


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). And the
compiler still won't warn you if you screw up using them - they obey
the same rules as normal C integers. But with an appropriate variable
naming scheme you could at least look at an expression and be able to
tell whether it might bust.


George
--
for email reply remove "/" from address

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