Re: 64-bit extensions

[acken@informatik.uni-kl.de]

[The quotes below are taken from Mike's, Hartmut's, and Tim's
postings.] 

> It has never made much sense to not have any operations defined on
> BYTEs since they are a basic data type all computers support.  I
> don't see any advantage to defining an arbitrary SYSTEM entity the
> same size as a BYTE.

There _are_ operations on SYSTEM.BYTE: you can assign SHORTINT and
CHAR values to it.  And then there is the generic VAR parameter ARRAY
OF SYSTEM.BYTE.  The _only_ purpose of this type is to circumvent the
type system.  This is an unsafe operation, as the SYSTEM prefix nicely
points out.  I'll never understand why the CP people chose BYTE as the
name of a plain and simple integer type.

> Of course, the argument might be made that this will break the type
> safeness of Oberon-2.  But it's already broken.  My response would
> be to close this loophole and not allow the concept of any type
> being compatible with an ARRAY OF BYTE.  I don't know of any
> functions which couldn't be performed in a type-safe way without
> this loophole.

Yes, O2 has no true type safety as long as ARRAY OF BYTE is around.
But you'll be hard pressed to implement Files.ReadBytes & friends
without it.  Unless you turn the language into something that isn't O2
anymore.

> > Yes, if you can't kill your enemy, join him ;-) However I [don't?] see support
> > for the java engine at the horizon :-| And there is not only the bytecode
> > interpreter, but the whole jave engine, and I doubt we can totaly map
> > everything to that (GUI, IO etc...), so this can't be really done...?
> 
> Well, I think we could simulate the Java libs in OOC and then put native
> calls to those libs in place when targetting Java output.

A Java back-end isn't really an option.  You can't efficiently
translate O2 to Java byte-code because there are lots of differences
in the type and class concepts of the languages, and Java byte-code
includes lots of Java type information.  It's (maybe) possible to
conceive a back-end translating to Java, but it would be clumsy beyond
measure and most likely slightly incompatible with standard O2.

[changing LONGINT to 64 bit]
> > But wouldn't that break compatibility between the 32bit and the 64bit
> > version. Can files (ascci, binary) writen by the first loaded by the
> > second and the other way round?
> 
> It was never intended to have the two binary compatible.  [...] If
> an application takes care, it would be possible to have binary files
> produced which are compatible on both systems but I don't see any
> advantage to that.  Of course, the C-object/library files would be
> useable on both systems.

I'll never accept a change to the type system in such a way that a
module will read/write different data depending on the OOC compiler it
was compiled under.  

As for usability of "C-object/library files": Assuming Mike refers to
foreign modules implemented in C, like Files, SysClock, etc., changing
the range of the types would break all of them.  Every module
interfacing with C code (libc, X11, foreign implementations, etc)
would have to be rewritten.  Keeping 2 versions of each would be a
true maintenance nightmare.

> > But if I thing about it again... wouldn't be mapping LONGINT to
> > 64bit excatly that what happens with C.long if you port a C compiler
> > to a 64 OS (not porcessor!)?. And arn't our two opinions regarding
> > LONGINT as a result the same?
> 
> Yes, I would agree.  But it is possible to encapsulate the C type definitions
> as OOC has done and then changing to a different OS is a fairly simple
> matter of just adjusting these type definitions.  As long as all C interfaces
> refer to these types, the mapping should be fairly simple.

C compiler implementors take a fairly pragmatic approach when moving
to a 64 bit platform: except for `long int' all types have the same
size as on 32 bit architectures.

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.

> Almost everyone is also talking about using a Unicode character
> set which are basically 16-bit characters.  I noticed the Component
> Pascal has defined the following:
> 
>   SHORTCHAR = 0X - 0FFX    (perhaps in SYSTEM)
>   CHAR      = 0X - 0FFFFX
> 
> What are people's thought's about extending the CHAR type as
> well?  Personally, this is not a big deal for me, but our
> Asian colleagues might definitely be interested in something
> like this.

This isn't an extension since you are changing something that already
exists.  Adding a new character type (WCHAR, HUGECHAR, UNICHAR,
LONGCHAR?) would be an option.

But: All support OOC could give is a new data type, conversion
functions between standard CHAR and this type, and a set of library
modules like Strings & friends.  But no Unicode IO.  I doubt that
anyone would gain something with these changes.

> Some advantages I see to these additions are that:
> 
> 1) Our data types would be much closer to the Java virtual
>    machine; perhaps making an Oberon-2 to Java byte code
>    back end simpler.

Why should we ever try to make O2 closer to the Java VM??? 

> 2) The compiler would be ready for 64-bit machines.

There are better ways to do this.

> 3) OOC would be compatible (sort of) with the Component
>    Pascal compiler.

Why should we ever try to make O2 compatible with CP??? 

------------------------------------------------------------------------

This discussion is really interesting.  But the fact is that the OOC
implementation of 64 bit integer types is already done.  Here are the
specs: 

A back-end can choose to provide a 64 bit integer type called HUGEINT.
For machines with 64 address bits this isn't an option, but a
requirement.  As far as OOC is concerned (with the possible exception
of compilers for very strange architectures like DSP chips) the size
of all integer types is fixed:

  SHORINT  8 bits
  INTEGER  16 bits
  LONGINT  32 bits
  HUGEINT  64 bits

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


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.

Of course oo2c_64 was only tested once, and the test failed.  If
someone wants to try 64 bit oo2c on an Alpha or the like and is
prepared to do some low level C debugging I'll be happy to put
together a 64 bit distrib.  Just drop me a note.

-- mva