Re: 64-bit extensions

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

Hallo!

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

I don't care compability if oo2c needs to have two copies of each
module.

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

Sorry, this datatypes will then spread all over my source code. I will
never use INTEGER and LONGINT again, since every part that interfaces
with VO has then to do some type conversion depending of 32 or 64 bit.
That is not a solution.

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

Interfacing 64/32 bit maybe rather common on a 64 machine?

>  >Compability is good, compability for all cost not.

> Breaking compatibility because of short-sight is even worse!

The question if if the oberon language definition is short-sight or our
view.

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

This is only true if one does not need to access the OS directly.

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

The whole handling of addresses is wrng in my view. An address is not
something nummerical in the oberon language. It is an abstract id or
something like an handle. Despite of C it is not defined that
any modification (pointer++) on pointer will result in something value.
There is no incrementation no adding, substracting defined for
pointers. It can't, since that will break garbage collection or at
least will make it difficult. Also no size for addresses are imposed.
There is no need for it since you do not need to store it or hold place
for it. F.e. pointers are not valid if you store them to disk and then
reload them later. Persistance works different than that. This results
in two conclusions: There is no need to assign addresses to any other
type exspecially LONGINT since mathematical operations are not defined.
There is no need to define the size of an address since you can't use
that information anywhere. This is a major difference to other
languages as f.e. C. Oberon(System) needs assignment compability
between address and pointer since it does not have its own datatype for
(typeless) addresses. That is the only reason. Changing all the address
operations in SYSTEM to deal with ADDRESS (which should be part of
SYSTEM and not a regular type since handling with addresses is a no no)
will fix a problem, a flaw in the language design. It wouldn't break
the huge majority of programs. There maybe some esoteric low level
stuff that needs some arithmetic on pointers, too (gc could use the
lower bits of an address as flags since pointers are normaly aligned to
2 or 4 bytes). If this is necessary one could enhance the allowed
operations on ADDRESS to include arithmetic operations with restricted
usage as such that the minimum and maximum bounds are not defined.
However, using operations on pointers (incrementing) that result in
overflow are very likely the result of an coding error since one has
interpreted the pointer as a pointer to something that is not valid.

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

That's why we disscuss it.

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

There weels for cars would be enough, too. But somehow four are a
little bit safer ;-)

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

You will have problems with persistance. How do you exchange data when
LONGINT has different sizes on different systems. Will will end with
defining your own types which is *very* ugly.

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

I doubt it can.

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

Why? One would use ADDRESS where addresses are used.

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

Hmm, I have no problem to change that half dozend lines.

> 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*

Most languages have developed. The comming C++ specs will break a lot
of programs  when acessing the standrad C++ library, f.e. because of
the extensive use of namespaces. Howver the change are ok since they
solve a lot of problems (overrun of the global name space). Only Oberon
people will stick to their design flaws :-|

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

As far as I understood it, ooc is not a real compiler. It's just a
fontend with clearly defined backend. oo2c is a "real" compiler. It
uses the fontend of ooc and implements a special backend for generating
C code. Another compiler could be ooc86(fictious name), directly generating
intel x86 machine code. It is *very* that all versions of ooc instances
will share the same interface for pratical reason.

-- 
Gru...
       Tim.