[Announce] makemaze for Inform

9 views
Skip to first unread message

Ricardo Dague

unread,
Sep 27, 1998, 3:00:00 AM9/27/98
to
I know how all of you LOOOOVE mazes in adventure games, so I've uploaded
"makemaze.zip" to ftp.gmd.de/incoming/if-archive.

In it is "makemaze.inf", a program which generates random mazes and
outputs (via scripting) Inform source files for them. It's a program that
writes programs! Also included is "mazeclas.h" which defines an example
class MazeClass which the maze rooms are instances of.

A short tutorial is shown when it's run.

Could anyone interested please download and test it? Send bug reports
and/or comments to tri...@hotmail.com.

Thanks,
-- Ricardo

Todd Baumann-Fern

unread,
Sep 27, 1998, 3:00:00 AM9/27/98
to

Ricardo Dague wrote:

> I know how all of you LOOOOVE mazes in adventure games, so I've uploaded
> "makemaze.zip" to ftp.gmd.de/incoming/if-archive.

Great! I'll can go and buy seed for my corn-maze now. :-} Hehe.

--
--Bud tf...@midstate.tds.net

David "Inky" Scott

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
Ricardo Dague wrote:

> In it is "makemaze.inf", a program which generates random mazes and
> outputs (via scripting) Inform source files for them. It's a program
> that writes programs! Also included is "mazeclas.h" which defines an

I believe (trying to remember my days as a CS major) that Knuth once
said that the two tests of a "valid" programming language were:

1) Can the language be used to write its own compiler?

2) Can the output of programs be used as valid input to the compiler (in
other words, can you write programs that write programs)?

Well, we have #2 now, anybody care to write an Inform compiler in
Inform? :-)
--
David "Inky" Scott Member of the Bermuda Triangle
da...@interoz.com Expedition Force: 1997-1951
InterCity Oz Web Architect Yes, my actions represent the typical
http://chimera.acs.ttu.edu/~z5d31 student at Texas Tech University.
Member of Legion West Roleplaying and 10,000 Animeniacs Anime Club
Last Games Played: Babylon 5 Wars, Mythos, Kings & Things

Gunther Schmidl

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
[...] snippity [...]

>David "Inky" Scott Member of the Bermuda Triangle

^^^^
Watch out! An impostor! Dan! Dan!!!

--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+


Andrew Plotkin

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
David \"Inky\" Scott (da...@interoz.com) wrote:
> I believe (trying to remember my days as a CS major) that Knuth once
> said that the two tests of a "valid" programming language were:

> 1) Can the language be used to write its own compiler?

> 2) Can the output of programs be used as valid input to the compiler (in
> other words, can you write programs that write programs)?

> Well, we have #2 now, anybody care to write an Inform compiler in
> Inform? :-)

It's been brought up before. The Z-machine doesn't have enough RAM to
run a port of Graham's Inform compiler. Any Inform compiler at all is
going to have to store lots of tables in memory, and the final game file
as well. So the final game size is going to be limited to under 64K, even
with the most clever memory hacks. That's barely enough for a one-object
game with the standard library.

The file opcodes aren't quite strong enough to run a virtual-memory
system, either.

So it's no go.

PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.

--Z

--

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

Dan Shiovitz

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
In article <erkyrathF...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>David \"Inky\" Scott (da...@interoz.com) wrote:
[..]

>PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.

The Frobozz Magic Inky Corporation was having a package deal, I
expect. Maybe we can work out some sort of time-share on the name.
(or "You be inky *west* of the Mississippi...")

>--Z

(inky @ ifMUD)
--
Dan Shiovitz || d...@cs.wisc.edu || http://www.cs.wisc.edu/~dbs
"...Incensed by some crack he had made about modern enlightened
thought, modern enlightened thought being practically a personal buddy
of hers, Florence gave him the swift heave-ho and--much against my
will, but she seemed to wish it--became betrothed to me." - PGW, J.a.t.F.S.

Darin Johnson

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
erky...@netcom.com (Andrew Plotkin) writes:

> > Well, we have #2 now, anybody care to write an Inform compiler in
> > Inform? :-)
>
> It's been brought up before. The Z-machine doesn't have enough RAM to
> run a port of Graham's Inform compiler.

That's a "machine" limitation, not a language one. If the language
clearly limited you to 64K as part of the language/semantics, then
that would be different

--
Darin Johnson
da...@usa.net.delete_me

David Glasser

unread,
Sep 29, 1998, 3:00:00 AM9/29/98
to
Andrew Plotkin <erky...@netcom.com> wrote:

> David \"Inky\" Scott (da...@interoz.com) wrote:

> > I believe (trying to remember my days as a CS major) that Knuth once
> > said that the two tests of a "valid" programming language were:
>
> > 1) Can the language be used to write its own compiler?
>
> > 2) Can the output of programs be used as valid input to the compiler (in
> > other words, can you write programs that write programs)?
>

> > Well, we have #2 now, anybody care to write an Inform compiler in
> > Inform? :-)
>
> It's been brought up before. The Z-machine doesn't have enough RAM to

> run a port of Graham's Inform compiler. Any Inform compiler at all is
> going to have to store lots of tables in memory, and the final game file
> as well. So the final game size is going to be limited to under 64K, even
> with the most clever memory hacks. That's barely enough for a one-object
> game with the standard library.
>
> The file opcodes aren't quite strong enough to run a virtual-memory
> system, either.
>
> So it's no go.

The answer, it seems, is that *Inform* can write a compiler for itself,
but that it is impossible to run on the ZMachine. (In other words, a
"simple" retargeting of the *language* Inform to the Z-SquaredMachine
would allow an Inform compiler in Inform.)

--David Glasser
gla...@NOSPAMuscom.com | http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to

In article <tvyogry...@cn1.connectnet.com>, Darin Johnson
<da...@usa.net.removethis> writes:

>> It's been brought up before. The Z-machine doesn't have enough RAM to
>> run a port of Graham's Inform compiler.
>

>That's a "machine" limitation, not a language one. If the language
>clearly limited you to 64K as part of the language/semantics, then
>that would be different

Just out of extreme curiosity and because I like learning new things, why
should the z-machine be limited to 64K? I mean I know why historically. Of
course I am not positive I know what the z-machine IS (someone told me an
imaginary *universal* machine that ZIL was designed for). But if we are talking
about Inform emulating the z-machine, then why the limit? Couldn't that be
changed within Inform, itself? If it was would that necessarily affect the .z
files produced by Inform? Isn't the memory allocation for Inform .z files
higher than that already? If not, would that limit what machines .z files could
be played on? Don't interpreters already exceed 64K? Why do we have to maintain
an old standard? Does changing it mean interpreters couldn't play old Infocom
games? Why the 64K limit, even now?

I could keep on asking questions, but I realize I don't know what I am talking
about. Please enlighten me.

Doe :-)


Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain

Andrew Plotkin

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
Doeadeer3 (doea...@aol.com) wrote:

> In article <tvyogry...@cn1.connectnet.com>, Darin Johnson
> <da...@usa.net.removethis> writes:

> >> It's been brought up before. The Z-machine doesn't have enough RAM to
> >> run a port of Graham's Inform compiler.
> >
> >That's a "machine" limitation, not a language one. If the language
> >clearly limited you to 64K as part of the language/semantics, then
> >that would be different

BTW, I agree this this. One could argue that some details of Inform 6 (the
language) are tied to the current Z-machine model, but they're details. An
Inform compiler for a new, 32-bit VM would have different details, but
you could sensibly call it the same language.)

> Just out of extreme curiosity and because I like learning new things, why
> should the z-machine be limited to 64K?

It shouldn't!

Oh, you weren't speaking in the ethical declension? :)

> I mean I know why historically. Of
> course I am not positive I know what the z-machine IS (someone told me an
> imaginary *universal* machine that ZIL was designed for).

That's a good description. Except I don't know why the word "universal" is
in there. It's a general-purpose computing machine, in the same sense that
any home computer is.

> But if we are talking
> about Inform emulating the z-machine, then why the limit? Couldn't that be
> changed within Inform, itself? If it was would that necessarily affect the .z
> files produced by Inform? Isn't the memory allocation for Inform .z files
> higher than that already? If not, would that limit what machines .z files could
> be played on? Don't interpreters already exceed 64K? Why do we have to maintain
> an old standard? Does changing it mean interpreters couldn't play old Infocom
> games? Why the 64K limit, even now?

Ok.

First, there are two separate limits.

64K of RAM (writable memory, including all dict words, objects, variables,
arrays, properties -- anything that can be changed during play.)

All memory outside of RAM is ROM (non-writable memory -- can *only*
contain strings and functions.) There's a limit on this, too, which is
different in different Z-machine versions. In V8, it's 512K.

The 64K limit on RAM is very hard to change, because the Z-machine
architecture uses 16-bit values everywhere. Every storage location
(including variables, properties entries, and storage positions on the
stack) is a 16-bit value. All the opcodes that look up and store data take
16-bit values. A 16-bit value can only refer to 65536 separate locations
-- that's (ahem) the long and short of it.

Strings and routines get around this by sneakily using a *non-contiguous*
set of 65536 locations. In V8, strings/routines can be stored at locations
0, 8, 16, 24, 32, 40... 524272, 524280. There are 65536 locations in that
list, so they can all be represented by a 16-bit value.

But this is only practical because very few opcodes *use* strings and
routines. Logically, only @print_string and @call_routine ever use such
values -- and they *only* use such values. (There are really a few
variations of @print and @call, but that's a detail.) It would be terribly
complicated to switch *all* data over to such a system.

Now, any expansion of the memory-space (be it terribly complicated or
simple) means that interpreters have to be changed. We saw that with V8.
That was a very very simple change, both in the Inform compiler and the
interpreters.

Unfortunately, a RAM expansion cannot be that simple. The easiest approach
is to redesign the machine to use 32-bit values everywhere, instead of
16-bit. That's still quite a bit of work.

Furthermore: There are lots of other annoying limitations in the
Z-machine. Number of attributes. Number of global variables. Number of
global properties. The I/O system. More subtle matters, like the way you
have to determine the type of a value. (Does this 16-bit value refer to a
dict word, an object, a string, or a routine? You'll recall the long
thread a couple months ago on this subject. The current methods are...
suboptimal.)

I feel (and I think there's a lot of agreement) that it would very bad to
start fixing these limitations one at a time. We'd wind up with dozens
(really, dozens) of Z-machine versions, in various stages of changedness.
It would be impossible to support either the interpreters or the compiler,
much less games.

So the ideal is to invent an entirely new interpreter, with as few hard
limitations as possible. At least, we can eliminate all the ones we've
found out in the past fifteen years of IF development!

This is, unfortunately, a lot of work. Various people are working on parts
of it. This is explicitly why I started working on Glk, which is a
solution to the "limited I/O system" problem.

Until all the parts are in place, game authors are sort of stuck.

Does that start to answer all of your questions? It all sums to "There's
lots to work on, and it would be a very great waste of time and effort to
fix things one at a time."

(The fact that the problem is structured this way is *itself* one of the
problems. This *also* is one of my goals, of which Glk is an examplar:
changing the view of the IF interpreter from a single unitary piece, which
is entirely changed if any part is changed, to a set of modules working
together.)

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to

In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:

>Does that start to answer all of your questions? It all sums to "There's
>lots to work on, and it would be a very great waste of time and effort to
>fix things one at a time."

Yes, thank you very much. Not sure I get it all, but I get the jist.

I stuck the *universal* in the description myself, it was not in the answer
that someone gave me, by inserting it I meant universal in the sense of not
tied to any particular real machine (IBM, Mac, etc.).

Only one question remains unanswered for me then, (btw, I now understand Glk
much better), would a new standard (32-bit, I presume) in the z-machine and the
resultant compilers and interpreters still allow interpreters to play the old
Infocom games? I mean I don't really know what data is stored in those files,
are opcodes stored? If so, is there anyway to adapt them so they would work on
32 bit?

Or would we also have to keep the old interpreters around?

Doe :-) TIA (Den said that was Thanks In Advance, but I don't know if he was
fooling.)

Simon 'tufty' Stapleton

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
doea...@aol.com (Doeadeer3) writes:

> Only one question remains unanswered for me then, (btw, I now understand Glk
> much better), would a new standard (32-bit, I presume) in the z-machine and the
> resultant compilers and interpreters still allow interpreters to play the old
> Infocom games? I mean I don't really know what data is stored in those files,
> are opcodes stored? If so, is there anyway to adapt them so they would work on
> 32 bit?

I personally would hope that any new 32bit z-machine interpreters would
also handle the old style games, in much the same way that the current
generation handle the various z-machine standards (z3-8). As a guess,
though, this would be a considerable amount of work, as it would
probably mean having two interpreters in one, as I understand it
(particularly as, as andrew says, a new 32bit z-machine should fix
more than just the memory space issues). If the memory space issue
was all that were at stake, it *shouldn't* be *too* hard to map the
16-bit memory space into the larger 32 bit memory space, although I
personally wouldn't want to do it.



> Or would we also have to keep the old interpreters around?

The old terps would still be useful, at leaast for those machines that
can't handle the larger memory space required by 32 bit (Palm Pilot
etc spring to mind, as do the interpreters for the older machines like
the C64, Apple II and the like.)

I may, of course, be way off the mark, in which case feel free to
flame me.

Simon (ifMUD's 'tufty')
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------

Den of Iniquity

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
On 30 Sep 1998, Doeadeer3 wrote:

>TIA (Den said that was Thanks In Advance, but I don't know if he was
>fooling.)

*Sob* I'll never be trusted again.

Listen. If what I say is utterly, _utterly_ absurd, such that you _know_
it's not true, such as molecules being painted blue and angels
manufacturing protophyta out of strawberry jelly, then I'm lying
inventively. If what I say is just utterly absurd, like television
reception tax and gasoline selling at $5 per gallon all over the UK, and
you find it hard to believe, then it's a curious piece of trivia and
certainly true (or I believe it to be, anyway). I don't set out to mislead
anyone deliberately.

Unfortunately, as you can imagine, it doesn't always work. My girlfriend
still hasn't quite forgiven me for that time I told her about Giant
Sparrows, with wingspan as large as an eagle's. Honestly.

--
Den


ne...@norwich.edu

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
In article <erkyrathF...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:

> It's been brought up before. The Z-machine doesn't have enough RAM to

> run a port of Graham's Inform compiler. Any Inform compiler at all is
> going to have to store lots of tables in memory, and the final game file
> as well. So the final game size is going to be limited to under 64K, even
> with the most clever memory hacks. That's barely enough for a one-object
> game with the standard library.
>
> The file opcodes aren't quite strong enough to run a virtual-memory
> system, either.
>
> So it's no go.
>

> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.

I toyed with identifying myself as N. Donald Cerutti, but decided it
sounded like a politicians name. Plus, being named Neil seems to have
a long a glorious tradition here. I remember when I first read this group
thinking that everybody was named Graham or Neil on rec.arts.int-ficion.

--
Neil Cerutti
ne...@norwich.edu

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Andrew Plotkin

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:
> doea...@aol.com (Doeadeer3) writes:

> > Only one question remains unanswered for me then, (btw, I now understand Glk
> > much better), would a new standard (32-bit, I presume) in the z-machine and the
> > resultant compilers and interpreters still allow interpreters to play the old
> > Infocom games? I mean I don't really know what data is stored in those files,
> > are opcodes stored? If so, is there anyway to adapt them so they would work on
> > 32 bit?

> I personally would hope that any new 32bit z-machine interpreters would
> also handle the old style games, in much the same way that the current
> generation handle the various z-machine standards (z3-8). As a guess,
> though, this would be a considerable amount of work, as it would
> probably mean having two interpreters in one, as I understand it
> (particularly as, as andrew says, a new 32bit z-machine should fix
> more than just the memory space issues). If the memory space issue
> was all that were at stake, it *shouldn't* be *too* hard to map the
> 16-bit memory space into the larger 32 bit memory space, although I
> personally wouldn't want to do it.

I think the whole thing would be too messy to deal with. I'd much rather
declare (conceptually) that it's an entirely new machine, *not* a new
version of the Z-machine, and it has entirely new interpreters.

That's just labelling, but I think it's also important not to feel stuck
to any part of Z-machine design. I can think of very fundamental changes
that might be worth doing. Stack format, opcode encoding, real dynamic
memory -- etc. Removing the I/O system is quite a change too.

Of course someone could *make* an interpreter that handles both the
Z-machine and whatever new machine this is. Just as someone could make an
interpreter that handles both Z-code and TADS. But I think it's a big, big
mistake to make it a *design goal* of a new VM to make this *easier*.

> > Or would we also have to keep the old interpreters around?

That's what I'd expect.

Magnus Olsson

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
In article <19980929225510...@ngol01.aol.com>,

Doeadeer3 <doea...@aol.com> wrote:
>Just out of extreme curiosity and because I like learning new things, why
>should the z-machine be limited to 64K? I mean I know why historically. Of

>course I am not positive I know what the z-machine IS (someone told me an
>imaginary *universal* machine that ZIL was designed for). But if we are talking

>about Inform emulating the z-machine, then why the limit? Couldn't that be
>changed within Inform, itself?

No, Inform doesn't emulate the z-machine: Frotz and JZip and the other
interpreters emulate the z-machine. Inform is

a) a language for writing IF.
b) a compiler for turning that language into code for the z-machine.

Now, Inform a) (the language) doesn't have to be affected by the 64 K
limit (but I think it is in assuming that all addresses fit in a 16-bit
word).

Inform b) most definitely is affected: it has to produce code that the
z-machine can run.

You could write an Inform compiler that didn't produce z-machine code,
but instead code for, forexample, a Pentium processor, and in that
case you could have Inform programs that didn't have to care about
the 64K limit (you might have to increase the language's word length
to 32 bits, though).

--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------

Magnus Olsson

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
In article <erkyrathF...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>BTW, I agree this this. One could argue that some details of Inform 6 (the
>language) are tied to the current Z-machine model, but they're details. An
>Inform compiler for a new, 32-bit VM would have different details, but
>you could sensibly call it the same language.)

I think there's one very important aspect of the language that's tied
to the current Z-machine model: the assumption that all values fit in
a 16-bit word. If we extended the Z-machine to use, say, 128 K of RAM,
then we would either have to increase the word length, which would
break at least some existing code, or we'd have to add new types
(like pointer vs. short in C), which would break even more existing
code, or we'd have to use packed addresses for RAM as well as for
ROM (which is being done today). But in the last case, RAM wouldn't
be byte addressable anymore, which I suppose would break a lot of
existing code as well.

Andrew Plotkin

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
> In article <erkyrathF...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >BTW, I agree this this. One could argue that some details of Inform 6 (the
> >language) are tied to the current Z-machine model, but they're details. An
> >Inform compiler for a new, 32-bit VM would have different details, but
> >you could sensibly call it the same language.)

> I think there's one very important aspect of the language that's tied


> to the current Z-machine model: the assumption that all values fit in
> a 16-bit word. If we extended the Z-machine to use, say, 128 K of RAM,
> then we would either have to increase the word length, which would
> break at least some existing code, or we'd have to add new types
> (like pointer vs. short in C), which would break even more existing
> code, or we'd have to use packed addresses for RAM as well as for
> ROM (which is being done today). But in the last case, RAM wouldn't
> be byte addressable anymore, which I suppose would break a lot of
> existing code as well.

I was thinking of the first option -- and yes, it would break existing
source code. I was thinking of it as more or less a detail change in the
Inform language, though. Just a terminology difference.

(It wouldn't affect most game code; an author usually accesses words
through the --> operator, which would still work and transparently fetch
32-bit words instead of 16-bit words.

(The *library* would require lots of changes, but they'd all be
superficial changes of "2" constants to "4". And the same would apply to
any game code that cares -- generally stuff which checks the size of a
property array.

(In fact, the sensible maneuver would be to have a compiler-defined
constant WORDSIZE which was either 2 or 4, depending on the VM target.
Then both libraries and game source could be written to be platform
independent. As I said, I was thinking of this as a fairly minor change to
the language.)

("Minor" because there are much thornier VM changes I want to make too.
:-)

--Z (whew, a four-paragraph parenthetical comment.)

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to

In article <Pine.SGI.3.95L.98093...@ebor.york.ac.uk>, Den of
Iniquity <dms...@york.ac.uk> writes:

>>TIA (Den said that was Thanks In Advance, but I don't know if he was
>>fooling.)
>
>*Sob* I'll never be trusted again.

Hehehe.

[snip]

>Unfortunately, as you can imagine, it doesn't always work. My girlfriend
>still hasn't quite forgiven me for that time I told her about Giant
>Sparrows, with wingspan as large as an eagle's. Honestly.

Rolf.

Well, I admit I was deliberately teasing you about TIA.

(Now, *sniff*, you'll never trust me again either, you'll always wonder if I am
teasing or tongue in cheek. *Sniff*. Hmmmmm, come to think of it you might be
wise not to... ;-) )

Doe

L. Ross Raszewski

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
In article <6uth40$1h9$1...@bartlet.df.lth.se>,

m...@bartlet.df.lth.se (Magnus Olsson) wrote:
> Inform b) most definitely is affected: it has to produce code that the
> z-machine can run.
>
> You could write an Inform compiler that didn't produce z-machine code,
> but instead code for, forexample, a Pentium processor, and in that
> case you could have Inform programs that didn't have to care about
> the 64K limit (you might have to increase the language's word length
> to 32 bits, though).
>


Of coursem, you also have the problem of arrays,m which in inform can be
addressed either with the byte operator -> or the word operator -->.
print_to_string (output stream 3) places the string length in the first
_word_ of the array, and the characters start in the third _byte_. If we
made words 32-bit, we'd either need to double the size of a byte (which would
cost us so much space that we might as well still be using 16 bits) or make
any code which uses print_to_string (or istring.h) break. Now, you can say
"Well, that's a small sacrifice, and we can just make all the old code
non-portable", but it becomes a BIG issue if someone starts out writing a v5
game, then halfway through decideds it won't fit, and has to use v32 instead.
Again, you could say "well, evryone should use the 32-bit VM even for short
games", but ISTR people here still really liked portablility. I somehow
doubt that a new 32 bit VM will be as widely ported as the Z-machine(look how
long it's taken to get hugo ported to _anything_)

ObGLK -- Does GLK support at least the same color options as the Z machine?
ISTR Zarf dosen't believe we programmers have any right to mess around with
color. I happen to believe that we do. I'm hard pressed to believe that glk
solves the problem of the Z machine's alleged "limited I/O" if it doesn't
allow things that Z does....

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to

In article <19980930125843...@ngol04.aol.com>, doea...@aol.com
(Doeadeer3) writes:

>>>TIA (Den said that was Thanks In Advance, but I don't know if he was
>>>fooling.)
>>
>>*Sob* I'll never be trusted again.
>

>Well, I admit I was deliberately teasing you about TIA.
>
>(Now, *sniff*, you'll never trust me again either,

Okay, to be perfectly honest (sigh, that is soooo incredibly boring), I tend to
use joking to illustrate a truth, so if I hadn't had the tiniest suspicion you
might have been fooling, I wouldn't have teased. So if you didn't often tell
tall tales, I wouldn't have had suspicions and if I didn't often joke to make a
point, I wouldn't have teased.

Donut break time, I am getting confused.

Doe :-)

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
Plotkin) writes:

>That's just labelling, but I think it's also important not to feel stuck
>to any part of Z-machine design. I can think of very fundamental changes
>that might be worth doing. Stack format, opcode encoding, real dynamic
>memory -- etc. Removing the I/O system is quite a change too.
>
>Of course someone could *make* an interpreter that handles both the
>Z-machine and whatever new machine this is. Just as someone could make an
>interpreter that handles both Z-code and TADS. But I think it's a big, big
>mistake to make it a *design goal* of a new VM to make this *easier*.

Okay, answer another *dumb* q, if you would, please.

I was under the impression that the opcodes and memory management for a 16-bit
machine are fairly compatible across platforms, i.e., it is not a tremendous
task to port the z-machine to IBM and Mac and Amiga, etc. (if that is the way
one would say it.)

Does the same hold true for 32-bit? Or do opcodes and/or memory management
start differing a lot, thus making it a MUCH harder task?

Doe :-) Just curious.

Doeadeer3

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to

In article <6uth40$1h9$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
Olsson) writes:

>But if we are talking
>>about Inform emulating the z-machine, then why the limit? Couldn't that be
>>changed within Inform, itself?
>
>No, Inform doesn't emulate the z-machine: Frotz and JZip and the other
>interpreters emulate the z-machine. Inform is
>
>a) a language for writing IF.
>b) a compiler for turning that language into code for the z-machine.

I meant b when I said that, I just didn't say it correctly.

>Now, Inform a) (the language) doesn't have to be affected by the 64 K
>limit (but I think it is in assuming that all addresses fit in a 16-bit
>word).
>

>Inform b) most definitely is affected: it has to produce code that the
>z-machine can run.

Thanks, that's very clear.

Since the Inform compiler is written in C and C is not limited to 16-bits I can
see how Inform could be easily changed for a "new standard".

Doe :-)

Allen Garvin

unread,
Sep 30, 1998, 3:00:00 AM9/30/98
to
Andrew Plotkin <erky...@netcom.com> wrote:

I think the whole thing would be too messy to deal with. I'd much
rather declare (conceptually) that it's an entirely new machine, *not*
a new version of the Z-machine, and it has entirely new interpreters.

But someone working alone, in secret, could probably modify Inform and one
of the interpreters in a pretty short time to handle 32 bits. It'd be
a bother, but could be done. To specify and develop and entire new machine
however, would probably involve months of vigorous, vociferous arguing on
rec.arts.int-fiction, spawning dozens of off-topic discussions and lots of
posts of misinformation and some hurt feelings. Hm, wait, that's what
r.a.if is normally like... Anyway, the first would probably be done pretty
quickly, but the second might take years before coming to fruition.

--
Allen Garvin I think I'll
--------------------------------------------- Let the mystery be
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil Iris Dement

Ricardo Dague

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
L. Ross Raszewski <rras...@hotmail.com> writes:
> Of coursem, you also have the problem of arrays,m which in inform can be
> addressed either with the byte operator -> or the word operator -->.
> print_to_string (output stream 3) places the string length in the first
> _word_ of the array, and the characters start in the third _byte_. If we
> made words 32-bit, we'd either need to double the size of a byte (which would
> cost us so much space that we might as well still be using 16 bits) or make
> any code which uses print_to_string (or istring.h) break.

You could define a constant like SIZEOF_INT, which would be 2 for 16-bit
machines and 4 for 32-bit.

-- Ricardo


John Francis

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
In article <6uth40$1h9$1...@bartlet.df.lth.se>,

Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>
>You could write an Inform compiler that didn't produce z-machine code,
>but instead code for, forexample, a Pentium processor, and in that
>case you could have Inform programs that didn't have to care about
>the 64K limit (you might have to increase the language's word length
>to 32 bits, though).

You don't have to increase the WORD length - just the size of an address.

Mind you, it would probably be a good idea, at that point, to also
introduce a new 32-bit arithmetic data type (a LONG, presumably).

I suppose we'd also need a new dereferencing operator ( ---> ? )

I don't think we need to let strings get beyond 64K, though, so
the 16-bit length count is probably sufficient.

--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.

Andrew Plotkin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
Doeadeer3 (doea...@aol.com) wrote:

> In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) writes:

> >That's just labelling, but I think it's also important not to feel stuck
> >to any part of Z-machine design. I can think of very fundamental changes
> >that might be worth doing. Stack format, opcode encoding, real dynamic
> >memory -- etc. Removing the I/O system is quite a change too.
> >
> >Of course someone could *make* an interpreter that handles both the
> >Z-machine and whatever new machine this is. Just as someone could make an
> >interpreter that handles both Z-code and TADS. But I think it's a big, big
> >mistake to make it a *design goal* of a new VM to make this *easier*.

> I was under the impression that the opcodes and memory management for a 16-bit


> machine are fairly compatible across platforms, i.e., it is not a tremendous
> task to port the z-machine to IBM and Mac and Amiga, etc. (if that is the way
> one would say it.)

That's correct. The CPU part is very clean and well-defined, and it
doesn't have to interface with messy OS code, which is what makes the I/O
hard to port.

> Does the same hold true for 32-bit? Or do opcodes and/or memory management
> start differing a lot, thus making it a MUCH harder task?

No, it's exactly the same. Just different constants.

When I say it's a lot of work to convert a 16-bit VM to 32-bit, I mean (1)
all old game files will break, (2) quite a bit of source code will break,
including both library and (some) game source; (3) changing an interpreter
involves going in and looking at all the interpreter code, which is pretty
much the same amount of work as writing as new interpreter from scratch.

--Z

Andrew Plotkin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
L. Ross Raszewski (rras...@hotmail.com) wrote:
> "Well, that's a small sacrifice, and we can just make all the old code
> non-portable", but it becomes a BIG issue if someone starts out writing a v5
> game, then halfway through decideds it won't fit, and has to use v32 instead.

I've posted some comments about how to extend the Inform language and
compiler so that the same source can be compiled for either target. I
don't think it's a difficult problem.

> Again, you could say "well, evryone should use the 32-bit VM even for short
> games", but ISTR people here still really liked portablility. I somehow
> doubt that a new 32 bit VM will be as widely ported as the Z-machine(look how
> long it's taken to get hugo ported to _anything_)

I bet you're wrong. I've posted about that too, in the past.

> ObGLK -- Does GLK support at least the same color options as the Z machine?
> ISTR Zarf dosen't believe we programmers have any right to mess around with
> color.

You recall incorrectly.

> I happen to believe that we do. I'm hard pressed to believe that glk
> solves the problem of the Z machine's alleged "limited I/O" if it doesn't
> allow things that Z does....

See spec section 5.5.

Doeadeer3

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to

Thanks, I now understand a lot more than I did before.

(But I would still rate that level of understanding on a scale of 1-10 about
somewhere in the 3-5 range, even that may be too high.)

Fred M. Sloniker

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
On 1 Oct 1998 01:12:30 GMT, jfra...@dungeon.engr.sgi.com (John
Francis) wrote:

>I don't think we need to let strings get beyond 64K, though

And two digits is fine for the year, right? (:3

(Just pointing out that, when you're trying to correct for obsolete
assumptions about how big is 'big enough', it's not a good idea to
introduce new assumptions. Of course, I rather suspect even the most
pessemistic Y2K fix assumes a four-digit year... wonder how much
effort it would be to code a program that could handle *any* year,
even years orders of magnitude farther in the future than any
hypothetical 'Big Crunch'? (:3)


Magnus Olsson

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
In article <6uuktu$14...@fido.engr.sgi.com>,

John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>In article <6uth40$1h9$1...@bartlet.df.lth.se>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>
>>You could write an Inform compiler that didn't produce z-machine code,
>>but instead code for, forexample, a Pentium processor, and in that
>>case you could have Inform programs that didn't have to care about
>>the 64K limit (you might have to increase the language's word length
>>to 32 bits, though).
>
>You don't have to increase the WORD length - just the size of an address.

I didn't mean the size of the machine word, but the size of the Inform
language's variables. You can think of the hgh-level language's
execution model as still another VM on top of the Z-machine, and
*that* high-level VM has a word size equal to the length of an address
- this is necessary since Inform is a typeless language where pointers
have to fit in a basic integer variable.

>Mind you, it would probably be a good idea, at that point, to also
>introduce a new 32-bit arithmetic data type (a LONG, presumably).

Introducing types to a typeless language is no small undertaking.

Simon 'tufty' Stapleton

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
m...@bartlet.df.lth.se (Magnus Olsson) writes:
> I didn't mean the size of the machine word, but the size of the Inform
> language's variables. You can think of the hgh-level language's
> execution model as still another VM on top of the Z-machine, and
> *that* high-level VM has a word size equal to the length of an address
> - this is necessary since Inform is a typeless language where pointers
> have to fit in a basic integer variable.

Surely this is the answer to the 'multiple interpreters' issue as well.

3 steps.

1 - Invent new and fixed 32bit Virtual machine. This might or might
not be based on the existing z-machine.

2 - Write an interpreter for this VM.

3 - Write an z-machine interpreter native to the new VM. this
wouldn't have to be as big as (say) frotz - as it would merely
handle the mapping from the z-machine to the new VM -
particularly easy if the new VM is based on z-machine. You would
also only need to write one of these as the front end would
be handled by the interpreter written in stage 2.

Bingo! Backwards compatibility.

Simon

I assume this has already been thought of. But it suddenly struck
me as a piece of inspiration, and given how boring my days are
normally, I thought I'd share it with you. Apologies if this has
been tedious.

Andrew Plotkin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:
> m...@bartlet.df.lth.se (Magnus Olsson) writes:
> > I didn't mean the size of the machine word, but the size of the Inform
> > language's variables. You can think of the hgh-level language's
> > execution model as still another VM on top of the Z-machine, and
> > *that* high-level VM has a word size equal to the length of an address
> > - this is necessary since Inform is a typeless language where pointers
> > have to fit in a basic integer variable.

> Surely this is the answer to the 'multiple interpreters' issue as well.

> 3 steps.
>
> 1 - Invent new and fixed 32bit Virtual machine. This might or might
> not be based on the existing z-machine.
>
> 2 - Write an interpreter for this VM.
>
> 3 - Write an z-machine interpreter native to the new VM. this
> wouldn't have to be as big as (say) frotz - as it would merely
> handle the mapping from the z-machine to the new VM -
> particularly easy if the new VM is based on z-machine. You would
> also only need to write one of these as the front end would
> be handled by the interpreter written in stage 2.
>
> Bingo! Backwards compatibility.

Yeah, but you've introduced another layer of emulation. That slows the
game down another order of magnitude. This seems a little extravagant when
the alternative is simply having two (equally fast) interpreter programs
lying around.

(This shouldn't lead to an infinite regression of interpreters, because a
well-designed 32-bit VM should last us another 15 years without *any*
further changes. That's why I'm so keen to make sure we don't get stuck
with a badly-designed one. :-)

Magnus's point is not really what you said; he was saying that the Inform
*language* is implemented in terms of the Z-machine. It's sort of
like another VM, but the analogy isn't exact.

I actually don't quite agree with him. If I were changing Inform to target
a 32-bit VM, I'd have the machine word and the Inform language storage
elements both be 32 bits. Throw out the 16-bit word at both levels. I
think that'd cause the minimum disruption to Inform *source* (both
libraries and game source.)

Actually, for completeness, a 32-bit VM should have 16-bit opcodes (in
addition to byte and 4-byte opcodes). But the Inform compiler would
probably never use them.

(That may have been a bit confusing. The Z-machine has @storew, @loadw,
@storeb, and @loadb instructions -- store and load words, store and load
bytes. A word is 2 bytes. All Inform storage elements are words, and the
--> operator also manipulates words, but you can still manipulate bytes
with the -> operator. So the compiler uses all four of those opcodes.

(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
storage elements, and the --> operator should manipulate 4-byte fields as
well. -> should still do bytes. So the compiler would only need to use
opcodes to store and load 1-byte and 4-byte fields.)

Branko Collin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
On Wed, 30 Sep 1998 22:29:56 GMT, L. Ross Raszewski
<rras...@hotmail.com> wrote:

> Again, you could say "well, evryone should use the 32-bit VM even for short
>games", but ISTR people here still really liked portablility.

^^^^

I Suspect There R?
--
branko collin, bco...@xs4all.nl
<<<I'm a moron 'n' this is my wife>>> zappa

Branko Collin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
On Thu, 01 Oct 1998 04:46:35 GMT, laz...@gte.net (Fred M. Sloniker)
wrote:

I'm sorry, but you're much to narrow minded. Who says a year has to
has digits. What if we decide next year is called Branko, and the year
after BrankoBranko, and the year after Branko, and then just when the
united programmers of the world have decided to just count 1, 2, 3, we
change the system.

(So let date point to something dynamic, then it's up to the memory
you've got.)

Doeadeer3

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to

In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:

>(That may have been a bit confusing. The Z-machine has @storew, @loadw,
>@storeb, and @loadb instructions -- store and load words, store and load
>bytes. A word is 2 bytes. All Inform storage elements are words, and the
>--> operator also manipulates words, but you can still manipulate bytes
>with the -> operator. So the compiler uses all four of those opcodes.
>
>(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
>storage elements, and the --> operator should manipulate 4-byte fields as
>well. -> should still do bytes. So the compiler would only need to use
>opcodes to store and load 1-byte and 4-byte fields.)

Another dumb q, couldn't the complier have an input parameter (when run) that
could switch between the two?

Byte Word
Inform 1 test.inf Inform 2 test.inf

Then the expansion to word addressing and additional opcodes (or features)
could be ignored unless 2 was entered. Nyah, probably wouldn't work (I do
realize I don't know what I am talking about.)

Doe :-) Just wondering

Doeadeer3

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to

In article <19981001133146...@ngol01.aol.com>, doea...@aol.com
(Doeadeer3) writes:

>Byte Word
>Inform 1 test.inf Inform 2 test.inf

PS.

Make that

Word Double Word


Inform 1 test.inf Inform 2 test.inf

Those are the kinds of things that tend to confuse me, but in principle I know
the idea.

Sowwy, for the incorrectness.

Magnus Olsson

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
In article <erkyrathF...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>Simon 'tufty' Stapleton (nob...@no.bloody.where) wrote:
>> m...@bartlet.df.lth.se (Magnus Olsson) writes:
>> > I didn't mean the size of the machine word, but the size of the Inform
>> > language's variables. You can think of the hgh-level language's
>> > execution model as still another VM on top of the Z-machine, and
>> > *that* high-level VM has a word size equal to the length of an address
>> > - this is necessary since Inform is a typeless language where pointers
>> > have to fit in a basic integer variable.

(...)

>Magnus's point is not really what you said; he was saying that the Inform
>*language* is implemented in terms of the Z-machine. It's sort of
>like another VM, but the analogy isn't exact.

It's also an analogy that can be rather confusing, I suppose, so let's
put it another way:

The Inform language doesn't have types in the way C does: it does have
different types of data, but there's only one kind of variable, which
I called "word" without thinking. It's a key feature of the language
that if I write

[ foo bar;
bar = ...;
];

then bar is a local variable that can hold an integer, or an address in
RAM, or the address of a string, or the address of a routine, or the
number of a property, or... (completing the list is left as an exercise
to the reader).

The language specification also says that an integer is a 16-bit signed
quantity.

These two things together mean that a variable must be 16 bits long. The
value 16 comes, of course, from the Z-machine's word length, but it is
in principle independent of it.

If you extend the Z-machine to 32 bits (or replace it with some other
architecture with > 16 bits word length), then you'll have to change
the Inform language so that a variable is > 16 bits long, unless
you want to do funny things with addresses that breaks a lot of
existing code. In that case, you'll also have to change the definition
of an integer as a 16-bit signed value. It won't do to restrict
integers to 16 bits, since there's no way for, say, the comparison
operators to know whether they're operating on integers or addresses.

>I actually don't quite agree with him.

Well, I think we actually do agree; it's mostly a matter of how pedantic
we are. :-)

>If I were changing Inform to target
>a 32-bit VM, I'd have the machine word and the Inform language storage
>elements both be 32 bits. Throw out the 16-bit word at both levels. I
>think that'd cause the minimum disruption to Inform *source* (both
>libraries and game source.)

I think this is the best way, yes, but I think there will still be
*some* disruption to game source.

Let me hasten to add that the disruption will be smaller than that
caused by the upgrade from Inform 5 to Inform 6, and I think it will
be worth it.

Andrew Plotkin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
Doeadeer3 (doea...@aol.com) wrote:

> In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) writes:

> >(That may have been a bit confusing. The Z-machine has @storew, @loadw,
> >@storeb, and @loadb instructions -- store and load words, store and load
> >bytes. A word is 2 bytes. All Inform storage elements are words, and the
> >--> operator also manipulates words, but you can still manipulate bytes
> >with the -> operator. So the compiler uses all four of those opcodes.
> >
> >(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
> >storage elements, and the --> operator should manipulate 4-byte fields as
> >well. -> should still do bytes. So the compiler would only need to use
> >opcodes to store and load 1-byte and 4-byte fields.)

> Another dumb q, couldn't the complier have an input parameter (when run) that
> could switch between the two?

> Byte Word


> Inform 1 test.inf Inform 2 test.inf

> Then the expansion to word addressing and additional opcodes (or features)


> could be ignored unless 2 was entered.

I assume you're talking about compiling to the same VM, but using 4-byte
or 2-byte words. (Not 1 or 2, but 2 and 4.)

Sure, that's possible. My Macintosh C compiler has a switch like this; you
can control whether "int" variables are 2-byte or 4-byte. Either way, the
output is a Macintosh executable. (Although C also has "short int" and
"long int" types that give you a little more choice -- but that's not
really relevant, never mind.)

The advantage would be more efficient use of space, for any game whch uses
less than 64K of memory. On the other hand, I don't know that the gains
would be that great. Current games are pushing 64K, and even if all of
that is storage words which double in size, that's still only another 64K,
and what's 64K these days?

Problem: A 32-bit VM probably *wouldn't* support the Z-machine-style hack
of "packing" string and routine addresses. After all, the only point of
that hack is to be able to store references to >64K memory in a 16-bit
field! So compiling a 16-bit model game file for a 32-bit VM would be
*really* limited; not just 64K of RAM, but 64K memory *total*, ROM *and*
RAM.

Yes, you could make a 32-bit VM which included the Z-machine-style hack
for strings and routines. This is almost certainly not worth it. The
gains, as I said, are not all that large; and I *hate* putting in cruddly
hacks when it's not absolutely necessary.

I think it's actually better to support both the Z-machine as it is, and a
clean new 4-byte VM, rather than making a complicated new VM which handles
both 4-byte and 2-byte game models. It's not the best position from a
standing start, but we've *got* the Z-machine support already.

TenthStone

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
laz...@gte.net (Fred M. Sloniker) caused this to appear in our collective
minds on Thu, 01 Oct 1998 04:46:35 GMT:

>On 1 Oct 1998 01:12:30 GMT, jfra...@dungeon.engr.sgi.com (John
>Francis) wrote:
>
>>I don't think we need to let strings get beyond 64K, though
>
>And two digits is fine for the year, right? (:3
>
>(Just pointing out that, when you're trying to correct for obsolete
>assumptions about how big is 'big enough', it's not a good idea to
>introduce new assumptions. Of course, I rather suspect even the most
>pessemistic Y2K fix assumes a four-digit year... wonder how much
>effort it would be to code a program that could handle *any* year,
>even years orders of magnitude farther in the future than any
>hypothetical 'Big Crunch'? (:3)

It would take a bit of effort, but using the same space that even broken
BIOSes use for year storage, we could increase the maximum number of
different year-identifiers avaible by exactly 65,436% if we just abandoned
ASCII date storage. With four digits we could store year values in excess
of 4 billion.

But that's not going to happen. So as for infinite storage space, you
could create ten-byte memory clusters and allocate them to various uses;
eight bytes of storage and the ninth and tenth a word pointing to the next
cluster. That is,
0000: "12345678"[0001]
0001: "90. "[0000]
would return 1234567890.

-----------

The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us

Allen Garvin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
John Francis <jfra...@dungeon.engr.sgi.com> wrote:

I don't think we need to let strings get beyond 64K, though, so the
16-bit length count is probably sufficient.

It might become helpful for reading and manipulating files to allow for
greater lengths.

Andrew Plotkin

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
Allen Garvin (eare...@faeryland.tamu-commerce.edu) wrote:
> Andrew Plotkin <erky...@netcom.com> wrote:

> I think the whole thing would be too messy to deal with. I'd much
> rather declare (conceptually) that it's an entirely new machine, *not*
> a new version of the Z-machine, and it has entirely new interpreters.

> But someone working alone, in secret, could probably modify Inform and one
> of the interpreters in a pretty short time to handle 32 bits. It'd be
> a bother, but could be done. To specify and develop and entire new machine
> however, would probably involve months of vigorous, vociferous arguing on
> rec.arts.int-fiction, spawning dozens of off-topic discussions and lots of
> posts of misinformation and some hurt feelings. Hm, wait, that's what
> r.a.if is normally like... Anyway, the first would probably be done pretty
> quickly, but the second might take years before coming to fruition.

I bet you're wrong.

I also bet that someone working alone *in public* would do a hell of a lot
better than someone working alone in secret. Glk has benefitted from
public comment, and I haven't let anyone else slow me down. (My own
laziness is not "anyone else". :-)

People yell and scream and flame me sometimes, but that doesn't affect the
work. I'm in charge. I'm getting it done.

Darin Johnson

unread,
Oct 1, 1998, 3:00:00 AM10/1/98
to
eare...@faeryland.tamu-commerce.edu (Allen Garvin) writes:

> I don't think we need to let strings get beyond 64K, though, so the
> 16-bit length count is probably sufficient.
>
> It might become helpful for reading and manipulating files to allow for
> greater lengths.

The workaround to this is easy though. Why does something that huge
have to be a single string anyway? You could easily write a data
structure to get around the problem. The problem really only exists
in the VM's anyway.

--
Darin Johnson
da...@usa.net.delete_me

Bryan Scattergood

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to
On Wed, 30 Sep 1998 22:29:56 GMT, L. Ross Raszewski wrote:
> I somehow doubt that a new 32 bit VM will be as widely ported as the
> Z-machine(look how long it's taken to get hugo ported to _anything_)

Of course a 32bit VM won't be ported as widely as the Z-machine. If people are
serious about lifting these restrictions then it *can't* be. The 64K RAM limit
is what makes it possible to support the Z-machine on low-end machines like the
Pilot, Psion3 and 128K Spectrum.

I'm *not* saying that going 32bit is necessarily a bad thing. I just want to be
sure that sacrificing the low end machines is going to gain us something in
return. Inform running on top of a hypothetical Z32 may be a neat hack, but it
isn't a killer app.

Bryan

[With a nasty suspicion we'll get a 32bit VM sorted out just as IA64 takes over
the desktop. Yeah, I know, IF can't possibly need more than 4G ...]


Den of Iniquity

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to
On Thu, 1 Oct 1998, Branko Collin wrote:

>> but ISTR people here still really liked portablility.
> ^^^^
>I Suspect There R?

I seem to remember (or recall, if you prefer).

--
Den


David Given

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to
In article <6uuktu$14...@fido.engr.sgi.com>,
John Francis <jfra...@dungeon.engr.sgi.com> wrote:
[...]

>>You could write an Inform compiler that didn't produce z-machine code,
>>but instead code for, forexample, a Pentium processor, and in that
>>case you could have Inform programs that didn't have to care about
>>the 64K limit (you might have to increase the language's word length
>>to 32 bits, though).
>
>You don't have to increase the WORD length - just the size of an address.
>
>Mind you, it would probably be a good idea, at that point, to also
>introduce a new 32-bit arithmetic data type (a LONG, presumably).

One way of increasing the amount of available memory while leaving the
Z-machine as unchanged as possible would be to take a leaf out of EMS'
book --- use memory windows.

Divide the 64kB RAM space up into eight 8kB windows. Each window can have
a block of memory mapped in. Create some new opcodes --- @malloc, @free,
@map. The program can use @malloc to allocate up to 8kB of memory, and is
given a handle. It can then use this handle to map the memory into one of
the windows, where it can access it. Both handles and addresses would be
16-bits.

So, you could do something like (excuse my syntax):

array = @malloc(4*2);
@map(array, 7);
window7 --> 0 = 0;
window7 --> 1 = 42;
window7 --> 2 = 1234;
window7 --> 3 = -1;

A simple back-end change to the Inform compiler would change object
addresses into block handles, so allowing objects to be stored in memory
blocks; and on startup each window would contain a different 8kB block, so
normal Z-machine programs wouldn't be affected. @map is a fast operation
so there wouldn't be much performance hit.

You could even have a set of special handles for accessing memory-mapped
devices.

Constant SysInfoHandle = -1;

@map(SysInfoHandle, 7);
memfree = window7 --> 0;

The only problems I can see is that you now no longer have any bounds on
how much memory a program will use, so you don't have the
if-it-runs-at-all-it-will-run-to-completion property of present Z-machine
programs, and allocating windows could be a little trickier than it might
first appear.


--
+- David Given ----------------+
| Work: d...@tao.co.uk | All generalizations are incorrect,
| Play: dgi...@iname.com | including this one.
+- http://wiredsoc.ml.org/~dg -+

Jonadab the Unsightly One

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to

Den of Iniquity <dms...@york.ac.uk> wrote in article

> Listen. If what I say is utterly, _utterly_ absurd, such that you
_know_
> it's not true, such as molecules being painted blue and angels
> manufacturing protophyta out of strawberry jelly, then I'm lying
> inventively. If what I say is just utterly absurd, like television
> reception tax and gasoline selling at $5 per gallon all over the
UK, and
> you find it hard to believe, then it's a curious piece of trivia
and
> certainly true (or I believe it to be, anyway). I don't set out to
mislead
> anyone deliberately.

Ah. So if I ever ask you WTUUAOMUA (Was That Utterly Utterly Absurd
Or Merely Utterly Absurd) you'll know what I want to know ;-)

> Unfortunately, as you can imagine, it doesn't always work. My
girlfriend
> still hasn't quite forgiven me for that time I told her about
Giant
> Sparrows, with wingspan as large as an eagle's. Honestly.

Now see, I might have thought that utterly absurd myself. If you
wanted
it to be utterly, utterly absurd you should have explained that you
had a saddle for one in your basement but hadn't used it in
several years now, since moving from Peru, the birds' favourite
nesting ground. Then you could have gone on to describe in
detail the feeder you had used to keep for them, in which you would
put coconuts, which they eat as seeds...

-- jonadab

(email the above name at bright.net)


Jonadab the Unsightly One

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to

Doeadeer3 <doea...@aol.com> wrote in article

> Doe :-) TIA (Den said that was Thanks In Advance, but I don't
know if he was
> fooling.)

Most likely not, because I often see "TIA in advance".

Erik Max Francis

unread,
Oct 2, 1998, 3:00:00 AM10/2/98
to
Den of Iniquity wrote:

It stands for either "I seem to remember/recall" or "it stands to
reason."

Which is why I don't use such abbreviations; many people flat out don't
know what they mean, and even when they do, they're often ambiguous.

--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Covenants without the sword are but words.
/ Camden

Jonadab the Unsightly One

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to

Ricardo Dague <tri...@hotmail.com> wrote in article

> You could define a constant like SIZEOF_INT, which would be 2 for
16-bit
> machines and 4 for 32-bit.

If we implement a 256-bit VM now, we'll be ahead of the
rest of the world for a change!

In all seriousness, though, I think it would be very, very good
if the new version of Inform could compile from the same
source code to both z8 and whatever the new thing is
with minimal modifications. Sure, you're going to have
to alter the Switches directive, and any code that does *certain*
things won't be compatible. In the libraries any code that
does those certain things can be rigged with conditional
compilation. Yeah, a few things will get broken, but if
there's a nice, accurate, complete list of them with nice
descriptions in English of how to make the changes it
would facilitate greatly the change for authors.

Say, couldn't even Inform stuff like the --> operator
and certain keywords work differently in the two
versions? To break less code? Just a thought.
I expect zasm code would get broken, though,
but most games use very little of it directly, and
as I said the libraries can have conditional
compilation.

Jonadab the Unsightly One

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to

Magnus Olsson <m...@bartlet.df.lth.se> wrote in article
<6uvum8$rbh$1...@bartlet.df.lth.se>...

> >You don't have to increase the WORD length - just the size of an
address.
>

> I didn't mean the size of the machine word, but the size of the
Inform
> language's variables. You can think of the hgh-level language's
> execution model as still another VM on top of the Z-machine, and
> *that* high-level VM has a word size equal to the length of an
address
> - this is necessary since Inform is a typeless language where
pointers
> have to fit in a basic integer variable.

Right. In Inform, any address has to fit in an integer. Period.

Did I mention that typelessness is one of my favourite features
of Inform? I really like it. It would be nice to be able to
determine (for certain) the type of a given variable at run time,
but I wouldn't want to be "boxed in" to a strongly typed language.

Sometimes I really *want* to store one type in a variable one
moment and another type another moment, for example. With
decent commenting this isn't a problem, honest.

> >Mind you, it would probably be a good idea, at that point, to
also
> >introduce a new 32-bit arithmetic data type (a LONG, presumably).
>

> Introducing types to a typeless language is no small undertaking.

And unnecessary. I have a hard time thinking that increasing the
standard integer to 32 bits would break any existing code.

OTOH, if we did that would all our z-code grow by leaps and bounds
and allow only the same amount of game in a larger file, or would
we see a real increase in usable space? Maybe we should get into
bit twiddling...

Jonadab the Unsightly One

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to

Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote in article

> Surely this is the answer to the 'multiple interpreters' issue as
well.
>
> 3 steps.
>
> 1 - Invent new and fixed 32bit Virtual machine. This might or
might
> not be based on the existing z-machine.

It would certainly be built with knowledge of the existing
z-machine and its advantages and disadvantages, at least.

> 2 - Write an interpreter for this VM.
>
> 3 - Write an z-machine interpreter native to the new VM. this
> wouldn't have to be as big as (say) frotz - as it would merely
> handle the mapping from the z-machine to the new VM -
> particularly easy if the new VM is based on z-machine. You
would
> also only need to write one of these as the front end would
> be handled by the interpreter written in stage 2.
>
> Bingo! Backwards compatibility.

The new VM would need the real, actual file support I've
been saying it needs anyhow.

> I assume this has already been thought of. But it suddenly struck
> me as a piece of inspiration, and given how boring my days are
> normally, I thought I'd share it with you. Apologies if this has
> been tedious.

Not at all. Whether it's been thought of before or not, it's a good
idea, IMO. What would also be very nice would be to write a
decent TADS interpreter for the new VM, but that could come later.

Jonadab the Unsightly One

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to

David Given <dg@> wrote in article <907328614.5946.0.nnrp-

> A simple back-end change to the Inform compiler would change
object
> addresses into block handles, so allowing objects to be stored in
memory
> blocks; and on startup each window would contain a different 8kB
block, so
> normal Z-machine programs wouldn't be affected. @map is a fast
operation
> so there wouldn't be much performance hit.

> The only problems I can see is that you now no longer have any
bounds on
> how much memory a program will use, so you don't have the
> if-it-runs-at-all-it-will-run-to-completion property of present
Z-machine
> programs, and allocating windows could be a little trickier than
it might
> first appear.

Assuming you only use the memory pages to swap different
portions of real memory into addressable space that's not
a problem. You just require the interpreter to load the whole
game into real memory from the start even though it won't
need to address it all at once. (One way to force this would
be to read a value from each page as part of the startup
procedure.)

If you use it to allocate memory dynamically at run time
then yes, all bets would be off.

Jonadab the Unsightly One

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to

Andrew Plotkin <erky...@netcom.com> wrote in article

> Yes, you could make a 32-bit VM which included the Z-machine-style
hack
> for strings and routines. This is almost certainly not worth it.
The
> gains, as I said, are not all that large; and I *hate* putting in
cruddly
> hacks when it's not absolutely necessary.
>
> I think it's actually better to support both the Z-machine as it
is, and a
> clean new 4-byte VM, rather than making a complicated new VM which
handles
> both 4-byte and 2-byte game models. It's not the best position
from a
> standing start, but we've *got* the Z-machine support already.

As long as the same *compiler* supports both, it can support them
by compiling to different VMs and that's alright with me,
particularly
since we need the old VM for old, already-compiled games, anyway.

Really, I would want most existing z8 source code to compile
to the new VM with just a changed Switches directive to
v9 or somesuch instead of v8. There would be minor breakages
elsewhere, but, as I said, if the library supported both via
IFDEF and the differences were clearly and exhaustively
documented, I think porting wouldn't be too great a nightmare.

Dark fiber

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to
On Fri, 02 Oct 1998 07:03:05 +0100, Bryan Scattergood
<1O431...@compuserve.com> wrote:

>Of course a 32bit VM won't be ported as widely as the Z-machine. If people are
>serious about lifting these restrictions then it *can't* be. The 64K RAM limit
>is what makes it possible to support the Z-machine on low-end machines like the
>Pilot, Psion3 and 128K Spectrum.
>
>I'm *not* saying that going 32bit is necessarily a bad thing. I just want to be
>sure that sacrificing the low end machines is going to gain us something in
>return. Inform running on top of a hypothetical Z32 may be a neat hack, but it
>isn't a killer app.

hmm the pilot runs on a 32bit cpu and afaik so does the psion (i not
sure tho.... :) as for maintaining low end machines, personally i dont
see the point. how many people actually copy across games to apple2's,
c64's and spectrums? maybe a handfull at the most? i played, well
attempted to play a few IF games on my pilot.. its not something i'll
ever bother with in the future.

ja ne

-df
Dark Fiber <ent...@tig.com.au>
http://homepages.tig.com.au/~entropy

Head honch of the Ed Wood school of FanFic

Sazan Aisu Fanfiction homeroom
http://www.geocities.com/Tokyo/Ginza/7478

Neil K.

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to
erky...@netcom.com (Andrew Plotkin) heretically declaimed:

> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.

Sir, when you are tired of Neils you are tired of life.

- Neil K.

(an observation; not a threat)

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

Joe Mason

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to
Neil K. <fake...@anti-spam.address> insribed:

> erky...@netcom.com (Andrew Plotkin) heretically declaimed:
>
>> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
>
> Sir, when you are tired of Neils you are tired of life.
>
> - Neil K.
>
> (an observation; not a threat)

It was this observation, I believe, which led to the tragic suicide rate among
the early formulaters of quantum physics. Strange but true.

Joe
--
I think OO is great... It's no coincidence that "woohoo" contains "oo" twice.
-- GLYPH

David Glasser

unread,
Oct 3, 1998, 3:00:00 AM10/3/98
to
Dark fiber <ent...@tig.com.au> wrote:

> On Fri, 02 Oct 1998 07:03:05 +0100, Bryan Scattergood
> <1O431...@compuserve.com> wrote:
>
> >Of course a 32bit VM won't be ported as widely as the Z-machine. If
> >people are serious about lifting these restrictions then it *can't* be.
> >The 64K RAM limit is what makes it possible to support the Z-machine on
> >low-end machines like the Pilot, Psion3 and 128K Spectrum.
> >
> >I'm *not* saying that going 32bit is necessarily a bad thing. I just want
> >to be sure that sacrificing the low end machines is going to gain us
> >something in return. Inform running on top of a hypothetical Z32 may be a
> >neat hack, but it isn't a killer app.
>
> hmm the pilot runs on a 32bit cpu and afaik so does the psion (i not
> sure tho.... :) as for maintaining low end machines, personally i dont
> see the point. how many people actually copy across games to apple2's,
> c64's and spectrums? maybe a handfull at the most? i played, well
> attempted to play a few IF games on my pilot.. its not something i'll
> ever bother with in the future.

Yes, the Pilot is 32bit. But in general, it doesn't have enough RAM to
play anything huge.

--David Glasser
gla...@NOSPAMuscom.com | http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."

Joyce Haslam

unread,
Oct 4, 1998, 3:00:00 AM10/4/98
to
Den of Iniquity <dms...@york.ac.uk> hallucinated:

> Listen. If what I say is utterly, _utterly_ absurd, such that you _know_
> it's not true, such as molecules being painted blue and angels
> manufacturing protophyta out of strawberry jelly, then I'm lying

> inventively. [...]

Have you tried the one about worn-out electrons? That what the power
station does is re-invigorate them and send them out again? If you
can get a physicist or engineer to swallow that one, you're _flying_.

Joyce.

--
Joyce Haslam
http://argonet.co.uk/users/dljhaslam/ for Gateway to Karos [INFORM]
Powerbase is for RiscOs only
c o m u s @ a r g o n e t . c o . u k

Magnus Olsson

unread,
Oct 4, 1998, 3:00:00 AM10/4/98