Re: 64-bit extensions

[Tim Teulings <tim@edge.ping.de>]

Hallo!

> A byte is possibly _the_ most portable construct around.  Every micro
> and computer that I know of has a byte data type.  So putting it into
> system really has no basis in reality -- it's just a whim of the language
> designer since no operations were defined on a byte (well they were on
> SHORTINTs which is essentially what BYTE would become).

Its not its size, which makes as a "near hardware" type its is name. If
you want 8Bits use SHORTINT, if you do memcopy and need a datatype that
stands for void instead of numercial data, use BYTE.

> There are some advantages to having this support in the language:
> 
> 1) Automatic support for UNICODE strings and conversion from standard
>    constant strings to UNICOCDE strings.
> 2) Standard comparison and other operators would work on UNICHAR strings
>    just as they do on ordinary strings.

I value that advantages.

> As far as interface to existing OSes, that would still be possible
> with the final conversion consisting of a simple SHORT() on the
> UNICODE string.  Eventually, OSes will start using Unicode and the
> interface will be a non-issue.

That not that good, I don't like puting SHORT around every string and I
don't like implcit conversions either. However at least under linux
implementation of unicode is not that easy, see "man unicode" and "man
utf-8" and much internal performance will be lost.

> Of course, I don't see mva changing the current definition.  He has
> already indicated that a HUGEINT 64-bit type is the way he would go
> in the existing compiler.  I don't think a 16-bit character type would
> be implemented either.

I don't see any problems with implementing UNICHAR like he will implement
HUGEINT.

> In my original proposal I was thinking more of a language change,
> which, to be accurate, could no longer be called Oberon-2. 

I have no problem with designing a new language on top of oberon-2.

> I believe these are stop-gap measures.  Eventually OSes will speak
> Unicode and that will drive the languages of the future.

There are not that many new OSs around and I doubt the existing ones
(Window, diverse Unixes, Max OS) will fully switch to unicode. The simply
cannot because of portability reasons. The will support Unicode by
implementing a strings-library for wchar_t and add functionality for the
GUI to print 16bit strings and leave everything else to the programmer.

> Juice runs on two targets (Mac OS and Windows 95).  That leaves a lot of
> operating systems which aren't supported.  Java byte code VMs can be found
> almost everywhere or will be very soon -- even the BeOS has a Java VM.
> If we want Oberon-2 to have a place in the future, eventually there will

Yes, if you can't kill your enemy, join him ;-) However I 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...?

> Of course, they have some silly extensions too such as keywords added
> just to use as pragmas.  OOC's method is better IMHO.

There may bew some good points, some of them I like to have in ooc, too,
but they made changes, that made their language incompatible to oberon.
You can't compile an oberon programm under CP as far as I understood.
That's mainly because of silly keywords the *must* be added in most cases,
which make me type as much as I do in C++ and which, as I staed, break
compatibility. This changes have nothing to do with the intended simlicity
of oberon.

> No need to use the 64-bit compiler on such systems.  There still would
> be the 32-bit compiler.  Eventually everyone will have 64-bit processors
> so then the switch is painless.  By that time memory will be even cheaper
> than today so that will a non-issue as well.  Besides, after removing
> Windows 2000, you'll have an extra couple of Gigabytes of RAM to play
> with. :-)

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?

> I don't understand this point.  An Oberon-2 INTEGER gets mapped to a
> C.long.

Can be done, also you can map SHORTINT to int and by that loose a TYPE for
displaying BYTES (of caus without using SYSTEM.BYTE!).

> 64-bit compiler, interfacing to a 32-bit OS can be done optimally by
> selecting the appropriate data type for the interface.  IMHO this
> interface has nothing to do with the integer representation.

But the type ed in that interfaces may than differ between the 32bit and the
64bit version, making work harder for the portable programmer. 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?

> I think the Java data types were designed for future OSes.  Oberon-2's
> data types were designed for current OSes.

Thats what I wanted to say. 

-- 
Gru...
       Tim.