🚀 go-pugleaf

In <45aanm$2s9@stork.qut.edu.au>, John Gough <gough@dstc.qut.edu.au> writes:
>
>	Proposed 64-bit Extensions to Modula-2 (for gpm at least)
>
> [...]
>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.  

For systems programming there's often a need to work with the
basic types defined by the machine architecture.  I do a lot of
systems-level stuff on 80x86 processors, and luckily the compiler
I use supports 8-bit integers (SHORTCARD, SHORTINT), 16-bit integers
(CARDINAL, INTEGER), and 32-bit integers (LONGCARD, LONGINT).
In practice I find that I use CARDINAL (16-bit) most of the time,
SHORTCARD and INTEGER some of the time, and LONGCARD only in
some special cases.

The essential point is: I really do need all of those types.  Consider
for example the implementation of a module which looks after
low-level screen graphics.  A lot of that (on the machines I use)
involves the manipulation of 8-bit quantities.  If SHORTCARD were
not available, then the arithmetic would have to be done by
copying BYTE variables into CARDINAL variables, performing the
arithmetic, and then copying the low-order part of the answer
back to a BYTE variable.  There's a performance hit caused by
the copying, and in addition the code is ugly because of issues
like type-casting.

Likewise, there are some situations (e.g. in a random number
generator, or when manipulating disk block numbers in a device
driver) where double-width integers are needed.  If they're not
available, then the calculations have to be done in a slow and
roundabout way.  If double-length is used as the default integer
type, then there's a big performance hit for the majority of
operations that don't need the double width.

A less obvious issue: if the machine architecture supports something
that can be done in assembly language, but the high-level language
has no scope for using that feature, then in effect there's a
performance hit caused by failing to realise the potential of the
hardware.  Many processors do have machine level support for
more than one size of integer, and I don't see why we shouldn't
be allowed to take advantage of that.  (As an aside, most
processors have efficient support for both signed and unsigned
arithmetic, which is one reason why I believe that dropping unsigned
types from Oberon was a big mistake.)  In fact, I'd go further: I've
long held that multiplying two single-length integers should give a
product whose type is that of a double-length integer; it's the way
a lot of hardware works, and in my experience it's closer to the
behaviour that programmers need.  It's a real pity that none of the
popular high-level languages support something that's really
easy to do in assembly language.

>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.

I'm completely in favour of this.  If Modula-2 is to be taken seriously
as a systems programming language, then there will always be the
need for unauthorised extensions of this kind.  If I had to work with
an M2 compiler that conformed precisely with the standard, I'd
give up and search for a language that was more suited for
systems programming.

Peter Moylan