[M3devel] INTEGER

[Tony Hosking]

On 20 Apr 2010, at 13:12, Mika Nystrom wrote:

> "Rodney M. Bates" writes:
>> The designers of Modula-3 gave use not one but three floating point types.
>> They explicitly justified this as matching the range of hardware arithmetic
>> provided by set of common processors of the day.
>> 
>> They didn't say this (to my knowledge), but one integer type also matched
>> the hardware of the day.  But the period when practically all processors
>> had the same word size was a historical anomaly.  It was a nice halcyon
>> time in that respect, and it allowed us to avoid some messy problems.
>> 
>> But it never was true prior to that era, and it is no longer true.
>> I doubt it will be again.  Despite the proliferation of 64-bit
>> machines, there will be useful 32-bit ones around for a years.
>> Not everybody buys the newest every three years, and 32 bits is
>> still capable of a lot.  I don't see them being retired at anything
>> like the rate 16-bit machines were, because they don't suffer the
>> limitations.  And then we have the proliferation of embedded and
>> hand-held devices, which as I am hearing, are already well out ahead
>> of server and desktop computers in raw processor count.
>> 
>> So I think keeping two integer sizes in the language removes what
>> many people would consider a serious obstacle.  Moreover, the way
>> the two integer sizes is are now defined is cleaner than I have
>> seen in any other language.  It also somewhat follows the way the
>> three floating types were done in the original language in that
>> it preserves the type-uniqueness of every expression.  It further
>> makes the static legality and semantics of code as close to
>> implementation-independent as it was in the unmodified language.
>> And it does not change the legality or static semantics of any
>> old code.
> 
> I agree LONGINT isn't horrible.  However, I am not sure I agree
> with your description above.
> 
> 1. Modula-3 provides three floating-point formats because *each* common
> processor architecture provided (and provides) support for generally at
> least three floating-point formats.  The point was to give programmers
> easy access to the hardware in their own machines, not really so that IBM
> programmers could have an extra format for VAX compatibility.  Note that
> I don't believe that it was intended that EXTENDED would be emulated by
> the compiler either: the point was really to give programmers access to
> the formats provided efficiently by their hardware.

In the current implementation EXTENDED=LONGREAL.

> 2. 64-bit machines don't actually get two different integer formats
> with the way LONGINT works.  INTEGER and LONGINT are both 64 bits.
> That was not the intention with the floating-point formats either.

Current implementation, yes, but this is not fixed.

> 3. 64-bit machines were hardly unforeseen by DEC's research people,
> given that their company introduced Alpha just after Modula-3 and that
> DECWRL across town was working on 64-bit ECL machines.  In fact I think
> Modula-3 had versions with 64-bit INTEGERs already in 1992?  (To use
> Jay's expression, it's now 18 years later, and many C environments still
> haven't caught up---int is still 32 bits in many of them!)  People at
> SRC surely had a lot of 64-bit machines with Modula-3 programs running
> on them in the early 90s.  Somehow the problem of representing 64-bit
> integers on older VAX, MIPS, i386 systems just didn't arise for them?

Yep.  Love my Alpha so much I can't bear to throw it away.

> 4. I still haven't seen any really convincing use cases.  What's it for?
> The lack of LONGINT was an obstacle to what, precisely?

I think the only one we have is file sizes...

> 5. Finally, is it the intention that LONGINT be fixed at 64 bits
> forevermore?  (See point 2.)  This seems to completely fly in the face
> of M3's philosophy.  (See Hendrik's arguments.)

The only constraint imposed is BITSIZE(LONGINT) >= BITSIZE(INTEGER).

> 
>    Mika
> 
> 
>