Re: 64-bit extensions

[hartmut Goebel <hartmut@oberon.noris.de>]

acken (acken@informatik.uni-kl.de) schrieb:

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

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

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

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

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

 >Of course oo2c_64 was only tested once, and the test failed.  If

AOS-64 will be tested by porting the Alpha Oberon System to 64 bit soon.
First small tests didn't show up any problems.

+++hartmut