Re: 64-bit extensions

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

Hallo!

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

Yes.

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

A clear proposal ws posted in my second answer. The proposal will work
as long as all pointers to data will have the same size.

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

But ii is a needed consequence of your own proposal!?

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

Then the language definition must be changed.

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

As proposed in my other language a void (untyped) pointer as no
arithmetical apperance.

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

Your only  argument is compability. Also portability but only narrowed
down to porting the oberon system. Is there something else I have
overlooked?

-- 
Gru...
       Tim.