Re: 64-bit extensions

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

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

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

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.

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

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.

 >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

That's what I'm afraid of! I seams as some genious guys implementing some
"cool" stuff while ignoring other important factors.

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.

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

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.

ooc does a great job for building stand-alone applications! But it must not
ignore those using embetted apps and porting them to stand-alone (for what
reasons ever). And one of the biggest apps around there simply is the Oberon
System. You may say it's not an app, but for me it is as much as any module
library is.

Much of our decisions are based on real-time problems. The Oberon System will
be our test wether our desicions are right or not. Perhaps some have to be
corrected, but I doubt that. The only "test" of mva's proposal was his try
porting ooc to 64 bit - which failed. Shouldn't this make one think?

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

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.

+++hartmut