Re: Integers on 64-bit machines

Torben Fgidius Mogensen wrote:


>>[I would make my int type the natural word size of the machine. If people
>>want a particular size, they can certainly say so. -John]
>
> I never really liked C's machine-dependent integer type. I prefer
> integer types to have explicit fixed sizes (and a selection of those)
> or be unbounded. However, I'm happy to allow the implementation to
> use more bits than required, so an int16 could be implemented as a
> 32-bit integer on machines where operating on 16-bit entities is
> difficult or costly.


Just some thoughts:


Computations can use any appropriate size internally, which typically
will be the (biggest) natural machine word size. As long as only one
size is used in computations, this is the natural size of the default
integer type.


IMO users are not very pleased with multiple fixed-size integer types,
which require a careful selection for every local variable. Not to
mention the documentation for every decision... ;-)


Sized types primarily are required for processing data, which are
stored in legacy formats (like API function arguments). Portability is
another key, when sized/ranged data types again come into play. As
long as only 32 and 64 bit machines are involved, 32 bit integers are
a meaningful default (guaranteed) size, which AFAIK also is used for
int's in 64 bit programs. AFAIR Integer*4 was the most frequently used
data type in scientific Fortran libraries (IMSL...), since decades.


File sizes, however, already require more than 32 bits, so this may be
another mandatory type, to be implemented for every target machine.


> Even better than a small fixed number of sizes (such as int8, int16,
> int32 and int64) is to (like in Pascal) explicitly state the required
> minimum and maximum values, so you have types like -10..10 or 0..255.


Another model is the digit count, as known from COBOL, and occuring in
formatted output in most programming languages. These approaches are
quite self-documenting :-)


OTOH a specified range of values doesn't restrict the compiler to use
any decent storage format for such numbers. Range checks are required
only for assignments to such variables, integrating neatly into the
inevitable code for reading and writing variables of different byte
count. A single option can be used to enable/disable such checks, for
optimization purposes.




Another aspect is the scope of the project. In an
experimental/self-educational lanuguage project I'd use a Fortran-like
notation, which can be implemented and extended in multiple steps:


1) machine specific "Integer"
2) with a global option to specify a minimum size
3) explicitly typed "Integer*n"
4) unbounded "Integer**"


Unsigned, scaled, and true fixed-size integer types are independent
options, e.g. for binary data exchange, monetary calculations etc.
For binary compatiblity a notation like "Integer!n" could be used, to
indicate a mandatory bit or byte size. And to complete confusion,
another "Integer#i.f" notation could be used, indicating scaled integers
with i integral and f fractional *digits*.


For practical reasons I'd also implement type aliases (C/Pascal style
typedefs), which allow the user to specify type names for specific
variables/purposes, in a distinct place. For educational reasons the use
of "styled" data types could be restricted to type declarations, whereas
in the remaining code only type names are acceptable.


DoDi
[Defining the range for each variable is one of those ideas that seems
like a good idea but in practice, programmers don't do it. In Multics
PL/I programs, all the variables were FIXED INT(35) because everyone
knew that was how you got a word variable. On IBM mainframes, they
were all FIXED INT(31). -John]

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