Re: 64-bit extensions

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

Hallo!

> No, this would not work! LONGINT must have the same size as SYSTEM.PTR:
> 1) SYSTEM.ADR(): LONGINT
> 2) SYSTEM.PUT(somewhere, my_LongInt_which_should_be_an_address)

As far as I know the oberon system at many places uses LONGINT for
pointer where one would use void* in C. I always found this irretating.
A type-sfae languae like Oberon is, should make such a connection
between pointers an nummerical types. A opaque type ADDRESS buried in
SYSTEM, which you can do mathematical operations on will sove the
problem in handling with typless pointers, will mark such handling as
sytsem dependend by using stuff from SYSTEM and will work well in all
cases where more flexible pointer manipulation is necessary, like f.e.
acessing or mapping foreign (exspcially C) interfaces. This is the
fudamental differnece between the oberon system which was build at the
beginng for a special machine and the ooc compiler system which need to
be adaptable and portable and thus must be much closer to the C type
and size system like the oberon system needs to be.

An example: It is likely that when handling type size the way you
propose we will for example break most of the interfaces of VO to the
outer worl, exspecially X11 in this case. Nothing will work when
LONGINT suddenly changes the size. Fixing will make this *much* more
difficult.

> As I've shown above (and will show more verbose in my diploma thesis),

As stated above the port of an oberon system and the adaption of ooc
are very different things with a very different background and a very
different focus.

> LONGING must have the same size as SYS.PTR. So either both are 8 Byte (then

s.o.

> No! In this case, LONGINT must be 64 bitt, too. Everything else would bring
> too much trouble. Imagine porting a huge application like the Oberon System
> to 64 bit.

Reading comp.lang.oberon I have the feeling that the ooc users and the
oberon sytsem users live in two different worlds. One can doubt that
the oberon system will be porting in the next time using ooc, but of
course this is only my personal opinion.

> AOS-64 will be tested by porting the Alpha Oberon System to 64 bit soon.
> First small tests didn't show up any problems.

Much of your decision are based on portability to the oberon system and
reuse of code. There is no deeper need for oo2c to be fully complicant
to the oberon system nor does oo2c build itself havily on oberon system code.

-- 
Gru...
       Tim.