--- "Randy W. Sims" <[EMAIL PROTECTED]> wrote:
> Amir Karger wrote:
> >
> > This is not an interpreter, where you run "foo zork1.z3" and get
> > to play Zork. Games::Rezrov does that. What my program does is
> > take Z-machine commands like (in a simplified Z assembly
> > language):
> >
> > 1220 add 3 top_of_stack -> local1
> > 1225 jg local1 global1a ?branch
> > 1230 call sub_foo local1 2
> > .branch
> >
> > and translates them to:
> >
> > L1220: $local[1] = 3 + pop @stack;
> > L1225: goto L1250 if $local[1] > global_var(26);
> > L1230: z_call(1476, $local[1], 2);
> >
> <snip />
> > This is why I was not so inclined to make this a Games:: module.
> > As I mentioned in the original post, there have been some
> > non-games written in Z-code. But I think a more compelling reason
> > is that this module is parsing and translating. To me, those are
> > more Language-y than Game-y things.
>
> Okay, I think I understand a little better now. This isn't really a
> Zmachine. This module deals with Zcode, transling it. So, I think I
> would use Zcode in preference to Zmachine in the name. I'm about
> 50/50 on the names Games::Zcode vs. Language::Zcode. They both make
> sense from a certain perspective: I would be more likely to look for
> it in Games::*, but it seems to fit more with the other modules in
> Language::*.
Argh! So now that I said I'd been convinced to change it to
Games::Zmachine, you're throwing my original arguments back at me,
saying I should leave it as Language::Zcode. Too bad I already changed
all the code (including changing the directory hierarchy in CVS.
Yuck.)
I do have one nit to pick, though, when you say "this isn't really a
Z-machine." It outputs code that will emulate a Z-machine, doesn't it?
And when I think on it further, it's sort of silly to say I don't have
an interpreter.
1. When I'm translating, I read the file into an array, parse the
Z-machine constants (game version, address of global variables, etc.),
and translate each Z-code routine into a "sub foo {...}" string, which
I print to a file.
2. The translated file reads the Z-code memory into an array, reads the
Z-machine constants from a hash, and has each of the routines in Perl
bytecode.
But let's make a case 1b, that starts like #1, but instead of printing
the "sub..." string, I eval it. At that point, aren't cases 1b and 2
in pretty much the same state - we've got all the Z-machine data, and
all the Z-code routines stored. Either 1b or 2 can do "use
Zmachine::Runtime" to run those Z-code routines. So 1b is basically an
interpreter!
This module has all the code needed to emulate a Z-machine; it just
does it in an order different from a straight interpreter. In fact,
the goal is eventually to translate Z-code to PIR - or even straight
Parrot bytecode. Once I get to that level (in Dan Sugalski's dreams),
the Parrot VM will BE a Z-machine, rather than emulating one, if that
makes any sense. It'll use the Parrot stacks for the Z-machine stack,
Parrot's opcodes will be changed so that it can run Z-machine opcodes
"natively", etc. If I get that far, then I'm even more a Z-machine than
an interpreter would be.
I was just thinking the other day that I hate making decisions where
both choices are just fine. It's the sort of thing that can kill your
productivity in programming, especially in Perl, where there's so many
WTDI.
Well, at some point I'll flip a coin and release this sucker.
-Amir
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
