Re: Problems with 64-bit numbers

[Mike Griebling <grieblm@trt.allied.com>]

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

I just looked and it appears that MathL has the non-standard function:
"modf" not OakMath, OakMathL. (mea culpa)
 
> >  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!  :-)

I had another thought which would still give the advantage of LONGINT/ADDRESS
identity and allow efficient representation of integers: Just introduce a new
integer type called WORDINT which takes on the former range of LONGINTs.  The
LONGINT type would then be promoted to a 64-bit type.

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

The same way I do right now, check out the sizes of the file types and
output the correspondingly-sized integer type.  BTW, given the padding
with records, I can't just output records for the XCOFF object file so
I do have to write integer by integer.  It wouldn't really be any more
awkward than it is now.  As you say, though, the XCOFF writer would not
be portable.
 
> -- mva
> 

Hmmm, I wonder if anyone at ETH has addressed this 64-bit issue?  It would be
interesting to see their solution.

Michael G.