Re: 64-bit extensions

[hartmut Goebel <hartmut@oberon.noris.de>]

Tim Teulings (tim@edge.ping.de) schrieb:

 >Hmm, this does not allow mixing VO with OberonSystem.

Yes, but not for the reason, you may think! It's the reason that (as we've
implemented it) 64-bit OberonSystem may not be mixed with 32-bit modules
_and_ (now comes the problem) X11 is not 64-bit enabeled, even on
OpenVMS 7.0.

 >Or do you propose
 >a compiler switch which works for different modules of a application
 >different? *That* would be crazy.

The switch works on all modules the same way: it specifies the size of
pointers.

 >How do you want such modules to communicate.

Like every other module. Do you worry about the interface? No problem: just
dont' write "LONGINT" there, but SIGNED_32/SIGNED_64. For pointers the
compiler needs two different ones internally.

 >How sould the author handle that, even understand that?

The auther is not bothered except when interfacing 64->32 bit. But normally
only some low-level stuff would be 32-bit.

 >Compability is good, compability for all cost not.

Breaking compatibility because of short-sight is even worse!

 >The type design of
 >the OberonSystem is not adaquate for the huge variity of systems.

It is! One just have to stop fixing the size of Integer types to 8/16/32 bit.

 >the problem only arises when you try to handle void adresses by assigning
 >them to them LONGINT. This is bad (my personal opinion) and is
 >occurence should be very rare. It only likely to occure in the system

a) SYSTEM.ADR() does not (only) handle void pointers
b) SYSTEM.ADR() does no assignement, just delivers LONGINT (you may call me
   beans-counter)
c) SYSTEM.ADR() often occurs in module I would call "high level"
   (don't ask for an example, I can't remember yet).

 >collectors. Both need special care while porting. Fixing address stuff
 >should be no problem.

Shure, but you can increase the number of changes necessary a lot if you
don't think early.

 >Reaal world applications shouldn't have problems with pointer and
 >LONGINT having equal size or not. As told this is more likely for

Real word apps shouldn't have problem with 64-bit LONGINT, either :-)

 >See above, how much application writers will have problems with pointer
 >and LONGINT having different sizes.

How much would have problems with 64-bit LONGINT? And even if this would be
more: does this justify breaking the languagedefinition?

 >Isn't it more likely that they will
 >have more problems with the different interface modules?

I dont' think so: Must will not be bothered about, since the module lib hides
it away.

 >VisualOberon is not interested in the size of pointers. This is
 >inrrelevant for it. There are in fact some places where adresses are
 >casted to LONGINT but that are problems of the interfacing to C. It is
 >very likely that X11.Mod will improve and such problems will disapear.

Are you taking about Oberon System's X11.Mod? In this case I'm afaid I must
tell you, that (taking you proposal pointersize=64, longintsize=32, leaving
out SYSTEM.ADDRESS here) you would break all applications not running in
32-bit memory.

 >And it is no problem to switch to SYSTEM.ADDRESS which will solve such
 >problems, too.

But a) it's a change to be made b) SYSTEM.ADDRESS is proprietery for ooc.

 >Every aproach is problematic. But the current one is easier for ooc, it

So the compiler writers concenience is more important than the langauge
specs? Please tell me this is not true! It can't be true! *grabbing for some
Baldrian*

 >is more adaquate because of more interfacing to the underlying OS than
 >OberonSystem does and the different aproaches are unproblematic in 98%

Are you taking about oo2c or ooc? If the later: this would have to be shown,
I doubt any significant difference (not taking VO into account). BTW: ooc
does not interface (significantly) to the OS, but the module lib (Okay, I'm
Mr. Bean-Count).

+++hartmut