Re: Problems with 64-bit numbers

[acken@informatik.uni-kl.de]

>  Date: Thu, 18 Apr 96 11:38:34 EDT
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  ...
>  > >  PS. Would you please include a hexadecimal output to Oakout and possibly
>  > >  a hexadecimal input to Oakin.
>  > 
>  > Now, if we add hex input/output to them they aren't `Oak' anymore.  I
>  > don't like this at all.
>  
>  Well, this could be an "extension" to the Oakwood standard in the same
>  spirit as OakMath has several "non-standard" procedures included.

I didn't know that.  Would you please remove all functions that aren't
part of the Oakwood spec from those modules?  

>  Assuming, that we add a non-standard LLONGINT (64-bit integer), then
>  the interpretation of 80000000H will always be 2^31.  Of course I think
>  this is the wrong way to go about adding 64-bits but it is the easiest
>  way to remain compatible with existing 32-bit compilers and the data
>  that they produce.  As long as you insist on supporting the various
>  8-, 16-, 32-bit output routines which are inherently non-portable to
>  a 64-bit compiler.

Compability is a mayor concern.  I definitely want to avoid to have
two seperate systems, one for 32 and one for 64 bit architectures.
Therefore I suggest to keep the transition 32-->64 as smooth as
possible.  There are some rough edges that prevent all modules from
being portable, but for most modules this shouldn't be a problem.

>  The best solution (in my opinion) is to uniformly change the type
>  definitions for a 64-bit compiler so that:
>  
>  	SHORTINT range is the previous INTEGER range
>          INTEGER  range is the previous LONGINT range
>          LONGINT  range becomes -8000000000000000H to 7FFFFFFFFFFFFFFFH 

This has also the advantage that it follows the Oberon-2 report to the
letter (but not in the spirit).  The sole purpose of the different
integer types is memory efficiency.  Doubling the size of all types
doesn't make sense.  And should the sizes be halved for 16 bit
architectures?  Confusion! Chaos! Anarchie!  :-)

There are several noteworthy disadvantages:
o You lose the compability between BYTE and CHAR/SHORTINT (this
  e.g. wreaks havoc on the fingerprint function used by o2c/ooc to
  hash symbol files)
o Doubles memory requirements (in the worst case)
o Users cannot rely on storage layout/value range of standard types
  (the first shouldn't be relied upon anyway, but MIN/MAX can be used
  in nonportable ways)
o Interfaces to foreign languages have to be rewritten completely (the
  C `int' is a 4 byte value on 32 and 64 bits systems AFAIK)
o Binary data exchange between programs is severely restricted (see below)

>  Any data files (e.g., symbol files) intended to be portable should only use 
>  the compressed integer format for storing the binary representation of 
>  integers (something which I didn't see in the Files modules BTW).

That will be part of the BinaryRiders module.  Sander, will you add
this?  The specs are in the Oakwood text AFAIK.

The portability issue doesn't just apply to (Oberon) data files.  It
also applies to data exchange
  o between different programs
  o coded in different languages
  o with specified protocols (without the option to change the
    protocol to WriteNum/ReadNum)
  o over different channels (file, internet, etc).

Just to decree that any `portable' data exchange should do it the
Oberon way doesn't solve these problems at all.  How would you write
your XCOFF object file format if you cannot be sure how large your
LONGINT is?  It's possible to do it, but it'd be very, very awkward
IMHO. 

>  With this definition of the types, all existing programs can just be
>  recompiled (assuming careful coding style which uses MAX(LONGINT) etc)
>  and will automatically work with the 64-bit compiler.  As well, this
>  integer interpretation will continue to work with LONGINTs as substitutes
>  for addresses.

It's not that `automatical'.  Although the LONGINT=ADDRESS is a
definite plus, the disadvantages have greater weight IMO.

-- mva