Re: Integers on 64-bit machines

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Fri, 06 Jul 2007 08:10:29 +0200

          From comp.compilers

Related articles
[5 earlier articles]
Re: Integers on 64-bit machines anton@mips.complang.tuwien.ac.at (2007-07-05)
Re: Integers on 64-bit machines mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2007-07-05)
Re: Integers on 64-bit machines gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-07-05)
Re: Integers on 64-bit machines bobduff@shell01.TheWorld.com (Robert A Duff) (2007-07-05)
Re: Integers on 64-bit machines marcov@stack.nl (Marco van de Voort) (2007-07-06)
Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-06)
Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-06)
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)
[10 later articles]
| List of all articles for this month |
From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Fri, 06 Jul 2007 08:10:29 +0200
Organization: Compilers Central
References: 07-07-007 07-07-021
Keywords: design, arithmetic
Posted-Date: 08 Jul 2007 18:59:24 EDT

Anton Ertl wrote:


> For a C-like language (i.e., where integers have some connection to
> pointers, e.g., pointer arithmetic), the main integer type should have
> the same size as a pointer; for your 64-bit machines, it should be 64
> bits.


I dare to decline. Even in C, pointers and computational values should
be kept separated. The pointer size is of little interest in pointer
arithmetic, it only dictates the required precision of the computations
and results.


Of course it's convenient to have an integer type, that can hold an
pointer (FILE, HANDLE...), but this also can be a long int, or simply a
void*. For portability reasons, a language should provide an according
type name in the standard library. Along with precisely sized integer
types...


With regards to pointer differences, what's IMO the only case where 2
pointers are involved in pointer arithmetic, there exists a need for an
*bigger* integer type, or for a convention that valid pointer (address!)
values are a subrange of ptrdiff_t.




In the current migration from 32 to 64 bit code we should keep in mind,
that we move from a memory model with a somewhat "saturated" address
range, to a model where the available address space is a fraction of the
addressable space. The same consideration applies to smaller
(embedded...) systems, where it IMO were fine to have at least two
distinct models, for dealing with machines with little or much memory.


The "an pointer is an int" paradigm applies to the little memory
category, where pointer differences don't exceed the typical integer
value range. Following this model, one should use 64 bit integers on 64
bit machines. But many people will be happy with 32 bit (or even less)
integers, because their computations either do not require bigger
values, or still require an wider range (floating point values!).


IMO the *application* should be considered, to determine which data
types to use in computations, not the machine. Consider files: it's
stupid to load huge files into memory, only because the file size is
lower than the addressing capabilites. Consider arrays: word-size
indices are overkill, when the element size prevents the allocation of
so much physical memory. The requirements for applications stay the
same, regardless of the evolution of the machines: the resources
(RAM...) are limited and require careful data management, based on
reasonable assumptions about a minimum equipment of the target machines.


DoDi



Post a followup to this message

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