develooper Front page | perl.perl6.internals | Postings from October 2002

Re: 64-bit ints and non-capable hardware

Thread Previous | Thread Next
Martin D Kealey
October 22, 2002 04:54
Re: 64-bit ints and non-capable hardware
Message ID:
Dan Sugalski <> wrote:
> Okay, I'm about ready to just bite the bullet and declare that 
> INTVALs have to be 64 bit integers.
> Does anyone know of a platform that has neither native nor emulated 
> 64 bit integers? (One we're likely to run on, rather)

I'm fairly new to Parrot, but I've spent a while following standards tracks
for languages such as C and C++, and also using Perl, so hopefully I'm not
too far off the mark here...

I was wondering if anyone else followed the discussion in comp.std.c about
integer types, prior to the adoption of the C99 standard? There was a
substantial paper put out by Frank Farance, entitled "specification based
extended integer range" or SBEIR for short; see It wasn't
adopted at the time, mostly because it was too big a lump to swallow, too
late in the standardisation process, but it looks like it might be timely
for Parrot to consider the concepts involved.

The basic idea is to express the requirements that a program has for its 
integers, and let the compiler choose the best option;

 minimum size
 exactness of size (for modulus operation),

There were objections that this was too complex, and that some combinations
didn't make sense.  To address the complexity, I proposed that integers
should be subcategorised as "classical" versus "logical".

"Classical" integers included all the existing C integer types, while
"logical" integers were those based on usage specification rather than
storage specification. In practice a logical specification would be
something like an exact range of values with trap-on-overflow, whereas a
classical or low level specification would be something like the range held
by a CPU register, with host-specific handling of overflows.

The relevance to Parrot is that, rather than opting for a short-list of
integer sizes like [8, 16, 32 and 64 bit], we should if possible allow an
extensible type system, possibly including optional automatic promotion to a
library-implemented integer type (BigNum, Complex, or whatever).


(I find it quiet disappointing that "modern" languages like Java and C# rely
entirely on storage-based integer specifications "64 bit", when languages
like Pascal and Algol had range-specified integers 20 years ago.)

CAUTION: The information contained in this message is consequential and
subject to legacy provenance. If you are the intended recipient you are
hereby notified that reading this message is permitted. If you have not
received this message please notarise the sender and destroy the

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About