Problems with 64-bit numbers

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

> >  Thanks, that sounds fine.  There's probably a lot more that can be cleaned
> >  up in both Oakin and Oakout since I didn't spend much time on these
> >  modules.
> 
> When the specs of the `official' OOC IO lib exists I'll add Oakwood
> conformant versions of In and Out.  I don't see much reason to put
> time into this beyond the modules you provided.
> 
> >  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.

Another possibility might be to include this in your File Streams.
 
> If you want hex IO in the OOC lib, you'll have to tell Sander about
> it.  We had a short discussion on this topic when Sander added hex IO
> for _all_ types and shortly afterwards dropped _all_ of them.

Ok, I'll mention it to Sander. Sander, are you listening?  Please give
us the ability to output (as a minimum) hexadecimal numbers.
 
> There is a tiny problem when writing/reading negative LONGINT values.
> Should they be signed or not?  The o2c convention to wrap values
> >=2^31 to negative numbers works only as long as you don't have a
> larger--say 64 bit--LLONGINT type; such a type will probably be
> necessary for 64 bit target architectures.  With this a type included
> in the language the value 8000000H is 2^31, without it it's -2^31.
> Note that this will also effect the parsing of huge hex numbers in the
> source code for 64 bit versions of OOC.

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.

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 

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

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

Michael G.