Darn. I was all set to write an amusing email about how I wasn't
offended that noone responded to my email, when someone went and
responded to my mail. OTOH, in the meantime I got my fifteen bytes of
fame in the P6 summary, plus the opportunity to play this week's Perl
Golf instead of mucking about with Z-code and PASM.
[I'd better apologize up front for verbosity. Hard to believe I play
Perl Golf, really.]
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 28, 2003 at 06:17:07AM -0700, Amir Karger wrote:
> > Hi. Hugely newbie at Parroting, but think it's the coolest.
>
> Good stuff. I hope it stays that with the inevitable setbacks and
> annoyances that will come while gaining experience.
Strange how almost no language (or software project in general)
remains
perfect, isn't it? I still think Befunge-93 is close to perfect
(simple
enough
to learn quickly, but hilariously crooked), but they had to go add
all
those silly opcodes (like reading from a file. Whatever for, when you
can
store data in your program?!) for Befunge-98.
> > - Is it not being ported because of a lack of tuits, or because
it's
> > extremely hard?
>
> I think it's party because of tuits, and party because to be done
> "properly" it requires a couple of big features to be added to
parrot,
> notably
>
> 1: dynamic opcode loading
> 2: dynamic bytecode conversion
>
> (This is the point where someone tells me that dynamic opcode
loading
> now works)
I would tell you, but I wouldn't even know if I was lying or not.
This is the point where you tell me that I can work on pieces of the
problem without having all this working, and when I've finished a
large
part of the job, one of the core Parroters will be inspired to hack
up #s 1 and 2 overnight while at some YAPC instead of sleeping or
drinking beer.
> We'd need dynamic opcode loading because we don't want to have the
> Z-machine specific opcodes compiled into every parrot (or every
other
> specialist set of opcodes)
Surely the majority of Parrot coders will want to use Z-machine
opcodes?!
> We'd want dynamic bytecode conversion because we want parrot to be
> able to directly load Z-code files, rather than having to first run
> an external program to convert them.
Ah. I thought this was true, when I saw Dan's quote that Z-code would
run "natively". However, I wanted it not to be true because it
sounded
scary.
I kind of figured I would need to implement all the Z-machine opcodes
in
order to get this to work, so you'd be calling Z opcodes instead of
parrot ones. But I'm still confused about how you deal with the
Z-code
Header, which is a bunch of data, not opcodes, and which doesn't
follow
(by a longshot) the Parrot bytecode format specification. And Dan
pointed out that Z-code has 16-bit words, not Parrot's 32.
I guess this is what you mean by "dynamic bytecode conversion". Only
I
don't have the first idea how this is supposed to happen. (Are there
docs about it I'm supposed to be reading?) Is this different from
running a Perl script to put the Z-code header into a Parrot data
object
and create a Parrot header?
> However, I don't think that we'd need them in place to begin
working
> on a Z-code port. (We'd just have to arrange to link in any
specialist
> Z-code ops for a while, and to convert Z-code before loading it)
Aha! So now all you need to do is tell me how to do *that*. RTFM's
welcomed, as long as I don't have to R ALL of TFMs.
Would it begin by doing a "non-native" port that does use a Perl
translator?
> > - A Perl 6 Summary from last year claimed Josh Wilmes was going
to
> > work on it. Does anyone know if he is and, if so, how far he's
> > gotten?
>
> I have no idea
This is where Josh jumps in, sends me 90%-finished code and says
he'll
give me all the credit if I write up the documentation.
> > - Whether or not it's extremely hard, would it be useful to have
> > some of the easy parts done by a newbie who can hack assembly but
> > not well enough to put into the parrot core? In that case, which
> > would be the easy parts?
>
> I've no idea.
Well, then, we make a great pair!
> How familiar are you with Z-code?
Um, somewhat. The Z-machine has been ported to PalmOS, but save files
aren't compatible. I started working on a Perl script to convert
them,
but got distracted by a neat Perl Golf competition. In the meantime,
though, I read the Z-machine spec and played with some headers and,
most
importantly, subscribed to the Z-machine mailing list where I can ask
lots of questions.
To be honest, given the shape (as it were) of my tuits and my
knowledge
of Z and Parrot, I'm more hoping to get the ball rolling on this and
then have some experts do the hard stuff (Some versions of the
Z-machine
support sound, graphics....) than to create a complete
implementation.
But we'll see. It doesn't look like Parrot will be finished next week
either.
> About all that I know (and I may be wrong) is that it fits in a
> virtual machine with 128K total memory,
I believe later versions (post-Infocom) allow up to a whopping 512K.
> that it has continuations (which we now have),
Until I reread the spec and read more about continuations, I'll say
"maybe". I'm not sure whether this quote has anything to do with what
you're talking about:
A "stack frame" is an index to the routine call state (that is,
the
call-stack of return addresses from routines currently running,
and
values of local variables within them). This index is a Z-machine
number. The interpreter must be able to produce the current value
and to set a value further down the call-stack than the current
one,
effectively throwing away its recent history (see catch and
throw).
> and that the Hitch-Hiker's Guide to the Galaxy adventure game was
> written in it.
In fact, ALL of the Infocom games were written in it, which means you
can download the Z-machine (for any of a zillion OSes including the
aforementioned Palm) and then buy the Infocom CD (if you can find it)
and play almost every Infocom game. (It was particularly fun playing
on
Palm, because after every command, the computer has to think for a
few
seconds before printing out the result. Just fill in a bit of Apple
//e
floppy drive ker-chunking, and it's a trip right down memory lane.)
Not
to mention the hundreds (at least) of games written in Inform, a more
modern language that compiles to Z-code. (Just to confuse you,
though,
there's a Befunge interpreter written in Inform that you can run
using
the Z-machine. And there's a mini-text adventure written in
Befunge...)
> Is the virtual machine stack based, or register based? (I guess
from
> your next paragraph that it's stack based)
Definitely stack.
> Do you know enough Z-code to create Z-code regression tests that
> progressively exercise features of the Z-machine (along with the
> expected correct output) so that any implementor (possibly
yourself)
> knows when they've got it right?
Nope! But I think that with some help from Parroters and Z-machiners,
I
could get there. In fact, I think there may already be some tests
written for the Z-machine, since it's been ported so many times.
<pause type="Google">
rustle rustle rustle
</pause>
Aha! TerpEtude: A Z-Machine Interpreter Exerciser by Andrew Plotkin,
Release 2. Tests compliance with Z-Machine Standards Document 0.99.
I think this may get us somewhere. If not, I'll ask on the mailing
list.
> > - I saw that Dan wanted to create a library to handle stack-based
> > languages. I don't suppose that's been done at all? If not, I
could
> > steal from, e.g., befunge, which would be way better than
starting
> > from scratch. I would offer to create the library, but I'm not
> > really confident enough about my (as-yet nonexistent)
pasm-writing
> > skills to write a library a bunch of other people use.
>
> I don't think you'd necessarily need to know actual PASM. I think
that
> the tricky part is thinking about how to map from a stack machine
to
a
> register machine. I've no idea what academic (or other) literature
> there is on this. The simplest way to run a stack based language on
> parrot would be to ignore most of the registers and just use
parrot's
> stack. However, this isn't going to be efficient.
And that's just what they'd expect us to do.
> So
> researching/working out how to efficiently map stack operations to
use
> more than a couple of registers would be very useful for all sorts
of
> stack based languages. Getting started on that would probably be
very
> helpful - you don't need to actually write the implementation PASM
if
> you're able to describe what needs to a co-volunteer.
I see that this would be useful. However, it seems to be it'd be
easier
to learn PASM than to learn the CS needed to do this intelligently.
(I
did computational chemistry, so all my CS is 2 semesters of coding
classes and things I've picked up here and there.) I think my talents
might be better utilized in porting Z opcodes & whatnot. Or, if
someone
has already thought about how to do this (Dan?) then maybe I could be
the co-volunteer you mention above who actually writes it up.
> Nicholas Clark
Thanks for your detailed response!
-Amir Karger
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
