Re: 64-bit extensions

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

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

Preface: Tim, I hope you didn't get me wrong, since I'm not suggesting the
posibilities I meantioned (except for no. 3).

 >> You have some posibilities here, which one would you prefere?
 >> 1) leave pointers 32 bit -> can't use 64-bit mem
 >
 >This is nonsense and is likely not to work.

Sure!

 >> 2) make all pointers 64 bit -> how to interface to system-stuff?
 >
 >Where do you see problems that connot be handled by a opaque pointertype
 >adress?

You mean ADDRESS as an ident in this sentence? Otherwise I don't understand
it.

What sice should your ADDRESS have then? 32 bit? 64 bit? Since it's untyped:
how to assign from/to typed pointers?

So I think you agree with me: this posibility is nonsense, too.

 >> 4) add another reserved word POINTER64 and change all modules which should
 >>    use 64 bit pointers.
 >>    Please note: in this case you will get a) maintenenace problems (big,
 >> big
 >>    ones), b) have to change _all_ of e.g. the Oberon Systems modules (incl.
 >>    pure applications) if Oberon System should support 64 bit pointers.
 >
 >Why should one differentiate between POINTER,POINTER32 or POINTER64?

I don't know! I personally think this would be bullshit, too. I just
meantioned it for completness.

 >Where in the OberonSystem is code that must handle POINTERs and
 >LONGINT, e.g. where is the code that depends on nummerical operations
 >specialy bound to LONGINT, that fores us to resize LONGINT?

It's not the Oberon System that forces to resize LONGINT, bur the language
definition: SYSTEM.ADR() is defined to deliver LONGINT, thus LONGINT mut be
big enough to repersent all valid addresses. Remember: we are talking about a
64-bit address machine, not about 64-bit arithmetics on a 32-bit address
machine!

Futher: The language report does in no way specify the number range of
LONGINT. Neither does it suggest a range.

 >Isn't it ok
 >to use SIZE(ADDRESS) and just just check against minimal and maximal
 >bounds when adding or subtraction (a small value) from an address to
 >f.e. index some annonymous datapointer etc...?

This is the problem of overflow which is a different topic.

 >I don't see reasons for
 >ADDRESS beeing LONGINT that or not based on compability and missuse of
 >LONGINT as C-like void-pointer.

Parton me? (in German: Bahnhof?)

 >> IC!
 >
 >IC, what?

IC means I understood mva's explanation about why this try failed.

 >As questioned before, give arguments, tell us detailed resons for that
 >besides history and compability.

See above. If you don't beleave me: read the Oberon Report. Sorry for the
rough words, but I'm too bored for repeating my arguments once again.
And remember: 64 bit address machine!

+++hartmut