Re: 64-bit extensions

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

Hallo!

> Oh, seams I've forgotten one point: size of LONGINT can be switched by a
> compiler option. Thus modules relying on SIZE(LONGINT)=4 still can be
> compiled. Thus your problems aren't :-) Only thing to worry about is not
> writing "LONGINT" to the symbol-file but something more specific.

Hmm, this does not allow mixing VO with OberonSystem. Or do you propose
a compiler switch which works for different modules of a application
different? *That* would be crazy. How do you want such modules to
communicate. How sould the author handle that, even understand that?

> Are you sure? Please reconsider this point! You can't change a language
> ignoring it' usage. Should ooc be an Oberon compiler or not? This is the
> key-question.

Compability is good, compability for all cost not. The type design of
the OberonSystem is not adaquate for the huge variity of systems.
Should that is a point to break compability (a little bit). Not that
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
kernel or in heavy pointer jugling applications like garbage
collectors. Both need special care while porting. Fixing address stuff
should be no problem.

> For my point of view - as software author - I'm interested in porting my
> software to may plattforms, eiher stand-alone or Oberon-System-embetted. But
> that for I need _one_ common language, not several dialects.

Reaal world applications shouldn't have problems with pointer and
LONGINT having equal size or not. As told this is more likely for
kernel stuff and that like. So you shouldn't have problems with
software in nearly all cases.

> So you think, there is no "deeper need" for compatiblity, too? What about
> guys porting stuff from the Oberon System to ooc or visa-versa? Wether ooc
> builds on the Oberon System is irrelevant for this discussion.

See above, how much application writers will have problems with pointer
and LONGINT having different sizes. Isn't it more likely that they will
have more problems with the different interface modules?

> ooc does a great job for building stand-alone applications! But it must not

definitely :-)

> Tim, do you want to restict usage of your VO System to users of ooc only? Or
> should it be used as wide-spread as possible? As far as I kown you you've
> been in the "reusage fraction", too?!

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.
And it is no problem to switch to SYSTEM.ADDRESS which will solve such
problems, too.

Of course VisualOberon should be wide spread as possible, but fact is,
that it is still a one man job. There are some interested people and it
is likely that there will be more third party stuff in the future. But
all that people come from the ooc side, none of the OberonSystem people
has been interested (at least no one contacted me). Despite the fact
that VisualOberon could make Oberon more wide spread. Seeing what I had
realized in the past year in free time I sure comparisons with Java,
Tcl/Tk by combining it with current oberon compilers and stuff like Juice
are legal when at least 10 more people would help. But OberonSytsem people
do not seem to be interested :-|

(So I use this mail to ask for support from the ooc community (again). I'll
offer as much help and support as possible and there are a lot of problems
to be solved and there is a lot of work to be done. You do not need to
be a heavy hacker, there are also a lot of things which are easy to
implement, but for which I had no time to).

> Pleaae not: I'm not tring to bash mva'a proposal. I'm simply trying to show
> some problems and deficites I see from my very point of view and from my
> experience programming stand-alone _and_ embetted.

Every aproach is problematic. But the current one is easier for ooc, it
is more adaquate because of more interfacing to the underlying OS than
OberonSystem does and the different aproaches are unproblematic in 98%
of all applications when porting between ooc and OberonSystem.

-- 
Gru...
       Tim.