Re: Integers on 64-bit machines

George Neuner <gneuner2@comcast.net>
Mon, 09 Jul 2007 06:28:16 -0400

          From comp.compilers

Related articles
[12 earlier articles]
Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-06)
Re: Integers on 64-bit machines anton@mips.complang.tuwien.ac.at (2007-07-06)
Re: Integers on 64-bit machines marcov@stack.nl (Marco van de Voort) (2007-07-08)
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)
[3 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Mon, 09 Jul 2007 06:28:16 -0400
Organization: Compilers Central
References: 07-07-007 07-07-014 07-07-017 07-07-026
Keywords: arithmetic, storage, design

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



Post a followup to this message

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