🚀 go-pugleaf

Hello everyone

	Proposed 64-bit Extensions to Modula-2 (for gpm at least)

forgive me if I raise a technical issue in a newsgroup apparently given
over to people ranting on about why language X is better than language Y  ;-)

The topic which I wish to raise is one of operand size.   Most language
gurus have argued that basic types such as INTEGER should be abstractions
which have implementation-defined size.  Well, that is a nice idea, but
we live in an increasingly networked age and a heterogeneous one at that.
So if you want to interwork, or even be relatively portable, you better
agree in what to call the type for values in the 2*10^9 value range.
It should now be clear to all that although abstractions such as INTEGER
are useful _within_ a module, only types of physically pinned size can
be used for interchange across implementations.

Ok, so now the ISO committe has decided that another "clean abstraction"
is to insist (paraphrasing) that _all_ signed whole number types must be
subranges of _THE_ integer type.  Subranges may have a smaller storage size,
but all arithmetic is done at the full width.  A very nice concept, 
particularly for us gpm folks who have never have (and never will) produce 
compilers for 16-bit machines.  But what about the folks with 16-bit machines 
(or rather, 32-bit machines which run 16-bit OSs).  The problem is that if 
you want a conforming compiler to offer 32-bit integers, then all arithmetic 
must be 32-bit, with a very large performance penalty on your favourite 16-bit 
toy machine.  This is one of the reasons that the compilers for toy machines 
will never be ISO conformant.

In our case here at Gardens Point, we happen to still think that Modula is
an ideal language for systems programming, and we need support for 64-bit 
integers.  Of course, on our alpha version INTEGER already _is_ 64-bits, but 
we want 64-bit support for i486, SGI, Sparc, Power as well.  So what to do?
It is the same problem as for the toy brigade.  If we make INTEGER=64bits
on 32-bit machines, then we lose lots of performance.  

So, to cut a long story short (or is that a long long story long  ;-) 
we have added 64-bit integer support as an unauthorized extension to the 
standard, in a way that will not break any conformant program.  We have 
modified our intermediate form, adding 21 new opcodes, and are gradually 
implementing on all platforms.  All of our native code stuff from Q1 1996 
will have these extensions.  So far SPARC and Intel have been implemented, 
with others to follow RSN.

In essence we have a new type HUGEINT which is 64-bit and signed.  You
don't see it unless you say FROM HugeInts IMPORT HUGEINT;  However, once
you do import it you get infix operators, INT, and a new conversion HUGE().
Consistent with Modula's usual rules, there are no automatic coercions.
Thus you must say ---

	intVar := INT(huge-expr); 

or equivalently

	intVar := VAL(INTEGER,huge-expr); 

In terms of the underlying semantics HUGEINTs are not classified as ordinal 
types, so you can't use them as for loop controls, or take subranges of them. 
Thus MIN and MAX apply but ORD, INC and DEC don't.  

As usual numeric literals are of abstract type ZZ, which happens to be
compatible with all the whole number types.  So there is no special marker
for huge constants.

We provide FLOAT, HTRUNC HROUND and HENTIER for REAL <--> HUGEINT 
conversion, but only to and from REALs which in all gpm versions are IEEE
double.  All the normal infix operators work, including MOD REM DIV /
and *, as do the full range of comparison operators.  We will also propose
a library HugeInOut which provides formatted input an output to files and
open arrays of char.

One unusual feature is that MOD DIV REM and / all have 4-quadrant semantics
which are the continuations of the standard M2 semantics to negative divisors.
Of course the semantics of INTEGER operations are unchanged.  If you get to
hack the assembler code for the huge operations you will find that on every
architecture known to humankind it is just as easy to do the extended 
semantics as to do the 2-quadrant ones.

If anyone has a particular point of view on any of this, you should mail
us.  It isn't quite too late for us to incorporate other good ideas. However
we will be pressing ahead pretty quickly, as we need 64-bit support so that
our code generators will support java language.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
K John Gough			  Internet:	j.gough@qut.edu.au
Professor of Computer Science     VOX: 		+61 7 3864-2781
Queensland University of Tech.    Fax: 		+61 7 3864-1507
				  http://www.dstc.qut.edu.au/~gough/

Automata      _--_|\              Faculty of Information Technology
rules OK     /      QUT           Queensland University of Technology
             \_.--._/             Box 2434  Brisbane 4001  AUSTRALIA 
                   v              Phone: +61 7 864-2111  

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-