Re: 64-bit extensions

[Michael van Acken <mvacken@t-online.de>]

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

Adding a compiler switch to change properties of data types is a new
dialect.  A pretty bad kind of new dialect.  

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

Porting the Oberon System to OOC is no problem whatsoever.  Even if
the target is a 64 bit architecture.  Only modules depending on SYSTEM
have to be adjusted.  This is exactly how it was intended to be since
ancient Modula-2 times.

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

FYI: oo2c_64 bombed on an Alpha with a completely nonsence floating
point exception in LowReal.c or the like.  This has nothing to do with
data type concepts.  

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

And my point is: adding a compiler switch to change data types is no
solution.  It's a problem.  On the other hand leaving the existing
data types as they are allows to use "old" software as it is.  Across
all platforms.  

-- mva