Re: 64-bit extensions

["Eric W. Nikitin" <enikitin@apk.net>]

Mike Griebling (MG) wrote:

> and Michael van Acken (MVA) wrote:

MG > > It has never made much sense to not have any operations defined on
MG > > BYTEs since they are a basic data type all computers support.  

Bytes are computer specific entities; *not* a data abstraction like
the other basic types.  You could, of course, argue that SHORTINT,
LONGINT, etc. are also computer specific entities, but you have to
strike a balance somewhere between the abstraction and the
respresentation.  

MVA > I'll never understand why the CP people chose BYTE as the
MVA > name of a plain and simple integer type.

Because that's what the Java folks did... 

MG > Why Wirth choose to allow a
MG > way to break the type system is beyond me.
[snip]
MG > There _are_ other ways to do I/O without relying on ARRAY OF SYSTEM.BYTE.
MG > For example in Oberon/F there is no concept of such a thing.  Lowest
MG > level I/O is done with the CHAR and ARRAY OF CHAR types.  Of course,
MG > you need the VAL() function to do the type casts. 

If CHAR becomes a 2-byte entity as you have suggested, then lowest
level I/O wouldn't be done with CHAR; you'd have to use SHORTCHAR (or,
as in Java, BYTE).

I'm confused as to why you complain about Wirth allowing "a way to
break the type system," but then go on to say that using SYSTEM.VAL()
is ok.

MVA > A Java back-end isn't really an option.  You can't efficiently
MVA > translate O2 to Java byte-code because there are lots of differences
MVA > in the type and class concepts of the languages, and Java byte-code
MVA > includes lots of Java type information.  

Maybe I'm reading more into this than is actually there, but I'm
interpreting this to mean that, with OOC as it is now, implementing a
Java byte-code backend would be very difficult.  I can understand
that.  

At this point, I'd actually be more interested in a backend that
produced Juice slim binaries.  Has anyone looked into what the
barriers to such a thing would be?

I haven't heard much out of the Juice folks, does anyone know what
directions they're taking?  I mean, how are they dealing with Java
compatibility?  

MG > As far as I can see the class concepts are part
MG > of Java but have nothing to do with the Java VM.

You still need class concepts for the runtime type info.  Maybe
investigation needs to be done into how type info is handled by the
JVM, and what needs to be done to OOC to support this level of type
info.  This seems to me to be more important than name compatibility
between basic types.

MG > I agree it would be a nightmare and once again I stress that the
MG > changes I was proposing would be for a different language -- it would
MG > not be Oberon-2 anymore, obviously.

Again I'm confused, what language do you want it to be?  Java with
Oberon-like syntax?  Component Pascal?  Or ???

MVA > C compiler implementors take a fairly pragmatic approach when moving
MVA > to a 64 bit platform: except for `long int' all types have the same
MVA > size as on 32 bit architectures.
MVA > 
MVA > Type size for 32 bit compilers:
[snip]
MVA > This way proper code, i.e. all FOREIGN and INTERFACE modules and all
MVA > modules using them, should work without changing a single byte both on
MVA > 32 _and_ 64 bit systems.  Breaking this compability on a whim is _not_
MVA > an option.
MG > 
MG > I never said it was -- at least not for OOC.  Given your constraints about
MG > not "changing a single byte" there is no other solution for OOC.  But you
MG > will see the base C types make more sense since they define the SHORTINT
MG > to be 16 bits.  

The *names* make more sense?  Why?  

MG > I believe that's why the CP designers went the way they did.

I think they named the way they did so they could market as Java
compatible.  

MG > > Almost everyone is also talking about using a Unicode character
MG > > set which are basically 16-bit characters.  

Support for Unicode would be a good thing.

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

I think I like LONGCHAR best, with UNICHAR a close second. 

MG > Very well, I'm not tied to the particular name.  I'm more concerned
MG > with getting language support for an extended character range.  

In the current state of things, Java (the actual language) doesn't
really do much to help, and in some cases actually hinders because
much of what's really going on is hidden.  The Java *libraries* (the
so-called Core API) provide some cool stuff that have made my life
easier (I'm working on a application that supports Korean Hangul
characters).  I don't see why OOC couldn't provide similar library
support, especially if a LONGCHAR type (and related operations) is
added.

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

Java stream I/0 is all done by reading bytes; just like OOC.  Unicode
I/0 (and other multi-byte I/O) is done with Readers and Writers which
interpret single bytes as multi-byte characters.  I can't see any
reason why OOC couldn't do this as well by providing one, or more,
multi-byte character mapper modules.

MVA > Why should we ever try to make O2 closer to the Java VM??? 
MG > 
MG > Because it's designer's clearly planned for the future OSes.  We
MG > should be ready for the same.  As I said, it will make a Java
MG > byte-code back end simpler.

My (perhaps paranoid) impression is that Sun intends the JVM to become
*the* future OS.  Would we even need a JVM if all Unix variants were
binary compatible (with each other, and MS-Windows)?  

MG > > 3) OOC would be compatible (sort of) with the Component
MG > >    Pascal compiler.
MVA > 
MVA > Why should we ever try to make O2 compatible with CP??? 
MG > 
MG > Because it is the most mainstream of the Oberon-2 systems. 

Mainstream where?  I certainly don't use it anymore.  Have sales
skyrocketed when I wasn't looking? :)

MG > (Ignoring the misnomer CP -- it should be called Oberon-3.)

I don't agree.  For one thing, it's not backwards compatible with O2,
so it can't honestly be called Oberon-3.  And besides, there are other
Oberon variants vying for the title of Oberon-3. :)

Eric