Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!RRZ.Uni-Koeln.DE!news.duesseldorf.ecrc.net!news.ecrc.de!blackbush.xlink.net!news-kar1.dfn.de!news-fra1.dfn.de!news-koe1.dfn.de!main.Germany.EU.net!EU.net!howland.erols.net!ix.netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: Inform .z8 question
Message-ID: <erkyrathE4LGML.Kon@netcom.com>
Organization: Netcom On-Line Services
X-Newsreader: TIN [version 1.2 PL2]
References: <rbram-ya023580002201971617040001@news.concentric.net> <erkyrathE4For8.6DD@netcom.com> <32E9A189.31A0F5C6@post.rwth-aachen.de>
Date: Sun, 26 Jan 1997 02:37:33 GMT
Lines: 30
Sender: erkyrath@netcom15.netcom.com

Linards Ticmanis (Linards.Ticmanis@post.rwth-aachen.de) wrote:
> Andrew Plotkin wrote:

> > No. The writable memory area is still limited to 64K.
> ...
> > Increasing the writable memory area beyond 64K would take major surgery
> > to the Z-machine; you'd have to change everything to allow 32-bit
> > addresses.

> Well... Can't we modify loadb/loadw/storeb/storew to use a segmented
> scheme (stolen from dos), so that instead of simply adding their two
> parameters together they would first shift the former four bits to the
> left? Of course the object tree (minus Inform's private properties,
> these are not really a part of the tree as seen from the Z-Machine)
> would still have to sit in the first 64k, but we'd have considerably
> more space for arrays, which is what's really wanted, I guess.

Arrgh. No. If you're going to make a non-backwards-compatible change, go 
whole hog and make it all 32-bit. Half measures are stupid.

> And yes, Andrew, I _know_ the Java VM is better ;)

Dunno if it's better in general, but it already exists. 

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
