Re: 64-bit extensions

[Michael van Acken <mvacken@t-online.de>]

> >Type size for 32 bit compilers:
>  >  C type        size in bytes   OOC type
>  >  ===========   =============   =========
>  >  signed char   1               SHORTINT
>  >  short int     2               INTEGER
>  >  int           4               LONGINT
>  >  long int      4               ---
>  >  void*         4               LONGINT (aka SYSTEM.ADDRESS)
>  >
>  >For a 64 bit compiler the last two lines change to
>  >  long int      8               HUGEINT
>  >  void*         8               HUGEINT (aka SYSTEM.ADDRESS)
>  >
>  >This way proper code, i.e. all FOREIGN and INTERFACE modules and all
>  >modules using them, should work without changing a single byte both on
>  >32 _and_ 64 bit systems.  Breaking this compability on a whim is _not_
>  >an option.
> 
> No, this would not work! LONGINT must have the same size as SYSTEM.PTR:
> 1) SYSTEM.ADR(): LONGINT
> 2) SYSTEM.PUT(somewhere, my_LongInt_which_should_be_an_address)

It works fine.  The language doesn't require SIZE(LONGINT)=SIZE(PTR).
Module SYSTEM isn't part of the language proper, it is a system
dependent pseudo module to help interfacing with the underlying
operating system or hardware.

>  >A back-end can choose to provide a 64 bit integer type called HUGEINT.
> 
> As I've shown above (and will show more verbose in my diploma thesis),
> LONGING must have the same size as SYS.PTR. So either both are 8 Byte (then
> there is no need for a pervasive tpye HUGEINT) or both are 4 byte (then there
> is no need for HUGINT to be pervasive instead of beeing a SYSTEM-type).

I don't see how you have shown such a thing.  In fact I'm very
surprised that you use the SYSTEM module to derive required properties
of a standard integer type.  The language report doesn't impose any
size restrictions on the standard types beyond type inclusion.

>  >For machines with 64 address bits this isn't an option, but a
>  >requirement.  As far as OOC is concerned (with the possible exception
> 
> No! In this case, LONGINT must be 64 bitt, too. Everything else would bring
> too much trouble. Imagine porting a huge application like the Oberon System
> to 64 bit.

Unlike the language report OOC specifies fixed sizes for all standard
data types.  We have to do this if we want programs to be portable
across platforms, most notably across 32 and 64 bit architectures.  So
we set LONGINT to 4 bytes since most compilers/system use this
convention.  Having OOC compilers with differently sized LONGINT types
is not an option.

While such programs would be correct for themselves, all form of
communication to the "outside world" would have to be rewritten.  This
includes access to external C libraries, binary data in files, and
communication across things like pipes or TCP/IP streams.  This would
introduce effectively two versions of all system dependent OOC libs
and all programs that exchange binary data.  

You have the choice between two kinds of portability: portable modules
which use SYSTEM, and portable programs that interact with other
software.  Your proposal covers the former, while OOC and especially
oo2c need the latter.

>  >Unfortunately all SYSTEM procedures working with addresses (MOVE, ADR,
>  >etc) will operate with LONGINT on 32 bit systems and with HUGEINT on
>  >64 bit ones.  To allow portable modules using those procs a type alias
>  >SYSTEM.ADDRESS is introduced.  It is an alias to LONGINT (32 bit) or
>  >HUGEINT (64 bit).
> 
> Brrrr! *shiver* That's not "simple" but confusing! Short dialog: "Quick, tell
> me what's the difference between SYSTEN.PTR and SYSTEM.ADDRESS?" - "hhhh,
> ...."

This should be obvious ;-) ADDRESS is an alias for an integer type.
It lessens the impact of the unforunate specification of some of the
SYSTEM procedures.  I don't know what PTR is used for.  I don't think
it appears anywhere in OOC beyond the Types module.

> This problem can be avoided completely by _not_ introducing HUGEINT. Sure, we
> need Intergers, where the size is know; but thatfor we can use some
> SYSTEM-type, eg. SIGNED_32, SIGNED_64.

I considered this, too.  But this doesn't solve the problems I have to
deal with.

>  >All of the above is implemented.  The only missing piece is that the
>  >compiler doesn't support 64 bit _constants_ yet.  Constants in O2 code
>  >are restricted to the range of LONGINT values.  Implementing this
>  >would mean to add a second HUGEINT version of all code pieces dealing
>  >with integer constants.  But we can't do this without a working 64 bit
>  >compiler.
> 
> I've implemented full 64 bit Integers in AOS. No need for a second version of
> all fields, just a change in the Scanner to accept larger numbers and some
> minor chages to allow both incarnations of LONGINT at some places (e.g.
> MOVE).

Beside superficial resemblence to the SYSTEM appendix of the language
report this is the only true benefit of your solution.  Otherwise I
see a huge potential to make many people very unhappy, in particular
all people working on or with oo2c.  If you send me a copy of your
detailed argumentation we might discuss things further.

-- mva