Parrot Z-machine
Amir Karger
So I was bummed to see that Befunge and BASIC had already been
parroted. (And Clinton Pierce even ported QuickBasic, which makes my
Language::Basic completely useless. Argh!) Then I thought, "What about
Z-machine?!" I was surprised to see that it hadn't been ported, and
even more surprised when I saw that Dan et al. really wanted to port it
but hadn't.
So:
- Is it not being ported because of a lack of tuits, or because it's
extremely hard?
- 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?
- 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 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.
- What the heck am I actually supposed to do? I read plenty of FMs but
I'm sure I could still use plenty of guidance.
As you can see, I'm totally clueless, but I'm a fan of Parrot, Perl,
and Z, so it would be a lot of fun (if mostly useless) to get them
working together. With some helpful hints and lots of free time (ha!) I
might actually be able to contribute some.
-Amir Karger
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Nicholas Clark
> 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.
> - 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)
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)
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.
Both these features are wanted to seamlessly run any "alien" bytecode,
such as Python's bytecode, Java bytecode or .NET bytecode.
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)
> - 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
> - 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. How familiar are you with Z-code? About all that I know
(and I may be wrong) is that it fits in a virtual machine with 128K
total memory, that it has continuations (which we now have), and that
the Hitch-Hiker's Guide to the Galaxy adventure game was written in it.
Is the virtual machine stack based, or register based?
(I guess from your next paragraph that it's stack based)
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?
> - 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. 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.
Nicholas Clark
Leopold Toetsch
> 2: dynamic bytecode conversion
> (This is the point where someone tells me that dynamic opcode loading now
> works)
No it doesn't. Albeit I have posted a proof of concept standalone
program months ago.
> Nicholas Clark
leo
Amir Karger
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.]
[Also, apologies if this is a repost. I think I sent this only to
Nicholas.]
--- Nicholas Clark <ni...@ccl4.org> 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
(1) Even though it's supposed to be "native" Parrot support, I'm still
allowed to write in PIR, right? Because that'll be translated to pasm
and thereby be native.
(2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
steal code or ideas from there, does Parrot or this piece of it have to
be GPL only instead of GPL/Artistic? I am happily ignorant about
licensing issues.
-Amir
Vladimir Lipskiy
> I got my fifteen bytes of fame in the P6 summary ...
Geewhillikins ... But you can always get more: Convert it into
Unicode (~:
_VL_________________________________________
"But how can we do it if we don't know what it is?"
"Why, blame it all, we've GOT to do it. Don't I tell you it's
in the books? Do you want to go to doing different from
what's in the books, and get things all muddled up?"
Zellyn Hunter
> A couple more questions on the coding front:
>
> (1) Even though it's supposed to be "native" Parrot support, I'm still
> allowed to write in PIR, right? Because that'll be translated to pasm
> and thereby be native.
>
> (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> steal code or ideas from there, does Parrot or this piece of it have to
> be GPL only instead of GPL/Artistic? I am happily ignorant about
> licensing issues.
So I take it the goal is to to teach parrot to understand z-machine opcodes,
rather than simply writing a z-machine interpreter that runs on parrot, or
rewriting inform to compile to parrot?
I'm sure it's much harder that way (especially since I'm sure someone's going
to follow the dotGnu lead and implement C for parrot before we're all said
and done and you could just recompile one of the more portable z-machine
emulators!), but you'd certainly get mad geek respect. And since there's
already a scheme implementation for z-code, you'd kill two birds with one -
er, parrot.
Zellyn
Luke Palmer
> On Tuesday 02 September 2003 13:09, Amir Karger wrote:
> > A couple more questions on the coding front:
> >
> > (1) Even though it's supposed to be "native" Parrot support, I'm still
> > allowed to write in PIR, right? Because that'll be translated to pasm
> > and thereby be native.
> >
> > (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> > steal code or ideas from there, does Parrot or this piece of it have to
> > be GPL only instead of GPL/Artistic? I am happily ignorant about
> > licensing issues.
>
> So I take it the goal is to to teach parrot to understand z-machine opcodes,
> rather than simply writing a z-machine interpreter that runs on parrot, or
> rewriting inform to compile to parrot?
I doubt it. I think a z-machine to parrot converter, making some of the
more complex ops sub calls or something, would be best. We need to work
with the z-machine bytecode directly, though, because many games are
distributed without source.
And perhaps, once dynamic opcode loading is ready, those sub calls can
turn into real ops for speed. But that's not important at the moment:
the important thing (well, as important as z-machine can be :-) is to
get the translator working.
Luke
Bernhard Schmalhofer
> A couple more questions on the coding front:
>
> steal code or ideas from there, does Parrot or this piece of it have to
> be GPL only instead of GPL/Artistic? I am happily ignorant about
> licensing issues.
>
Hi,
I have the same question for my 'GNU m4' port to Parrot and Perl5,
http://www.schmalhofer.info/schmalhofer/bernhard/projects/m4/.
In the FAQ I found following:
--------------------------------------------------------
# License compatibility.
Parrot has an odd license -- it currently uses the same license as Perl
5, which is the disjunction of the GNU GPL and the Artistic License,
which can be written (Artistic|GPL) for short. Thus, Parrot's license is
compatible with the GNU GPL, which means you can combine Parrot with
GPL'ed code.
Code accepted into the core interpreter must fall under the same terms
as parrot. Library code (for example the ICU library we're using for
Unicode) we link into the interpreter can be covered by other licenses
so long as their terms don't prohibit this.
--------------------------------------------------------
This is the way I understand it:
i. I can take GPLed code and derive <MyLanguage> from it.
ii. <MyLanguage> is still under GPL
iii. <MyLanguage> can become part of the Parrot core or be distributed
with Parrot
Did I understand that correctly?
CU, Bernhard
--
*************************************************
Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 89 55 74 - 839
Fax: +49 89 89 55 74 - 25
PGP: https://ssl.biomax.de/pgp/
Email: mailto:Bernhard.S...@biomax.de
Web: http://www.biomax.de
*************************************************
Leopold Toetsch
> A couple more questions on the coding front:
> (1) Even though it's supposed to be "native" Parrot support, I'm still
> allowed to write in PIR, right? Because that'll be translated to pasm
> and thereby be native.
You should target PIR. PIR is "native" parrot.
> -Amir
leo
Dan Sugalski
> Amir Karger wrote:
> > A couple more questions on the coding front:
> >
> > (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I
> > steal code or ideas from there, does Parrot or this piece of it have to
> > be GPL only instead of GPL/Artistic? I am happily ignorant about
> > licensing issues.
> >
>
> Hi,
>
> I have the same question for my 'GNU m4' port to Parrot and Perl5,
Here's the scoop.
To have it as part of core parrot (i.e. part of the sources in the base
source directory and some of the subdirectories, *not* including ICU and
the languages dir) it must be GPL&AL. That means no pure GPL code can go
in. Anything that is built so it is dynamically loaded can be whatever
license it wants, so long as it doesn't force a license on Parrot. Other
stuff, like ICU, may be statically linked in if doing so doesn't put a
license on parrot's sources, as parrot's source license doesn't leak out.
(Which makes us not quite pure GPL&AL, I think, and I expect someone'll be
really cranky with us because of it somewhere)
Basically if we dynamically link you in, you're fine. We can even (I
think) distribute it as part of the core as long as it stays explicitly
separate, though I'd rather not as it'd inadvertently burn someone who
builds an all-static parrot (as the resulting executable would be
undistributable).
> This is the way I understand it:
> i. I can take GPLed code and derive <MyLanguage> from it.
> ii. <MyLanguage> is still under GPL
> iii. <MyLanguage> can become part of the Parrot core or be distributed
> with Parrot
Yes, yes, and no, respectively. All core code must have the same
license--no part can have a more restrictive license as that makes rather
a lot of trouble.
Dan
Amir Karger
intelligently.
--- Nicholas Clark <ni...@ccl4.org> wrote:
> > - Is it not being ported because of a lack of tuits, or because
> > it's extremely hard?
>
> 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)
Right. What you're saying here is that I'll need to write Zmachine.ops,
or some such. It will include all the Z-machine operations, which the
bytecode will call.
> 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.
Right. The problem that I see with this is that Z-code "story" files
have a very definite header format, which is almost but not quite
entirely unlike Parrot bytecode. Just for example, the first few bytes
are totally different, but are necessary for both languages.
One way to get around this, as you say, is to convert them beforehand.
For example, write a Parrot header, followed by bytecode whose first
command is "skip the next few hundred bytes", then have the Parrot
header, then set all the ops that would read the header to add an
offset
to the address. Or something. Yuck. On the other hand, I'm not quite
sure what else you can do.
> Both these features are wanted to seamlessly run any "alien"
> bytecode, such as Python's bytecode, Java bytecode or .NET bytecode.
>
> 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)
Good point!
And since I can steal all of the C code for the ops, well, we're almost
done with project!
[What should I do now?]
>
> 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. 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.
OK, here's where I get very confused.
What I started to understand is that if we're reading bytecode
natively,
then it's silly to translate to PASM, because that's going backwards:
PASM just gets compiled to parrot bytecode.
[Actually, it might be fun to disassemble Zcode (disassemblers exist)
to
Z assembly, then translate that to PASM+, i.e., PASM that calls Zcode
ops in addition to the regular ops, but uses the Parrot registers et
al., then compile and run that. But if I understand correctly, that's
not what "native" means.]
From what I can understand, "native" means (if we ignore dynamic
bytecode
conversion issues) running directly from the bytecode, but writing new
ops. That is, not using PASM at all. In that case, do I even have
access
to Parrot's stack? (Or do I just need to access all of it through C?) I
guess maybe my mistake is in thinking of PASM as Parrot.
Obviously, I need to do some more learning.
Piers Cawley
> Zellyn Hunter writes:
>> So I take it the goal is to to teach parrot to understand z-machine
>> opcodes, rather than simply writing a z-machine interpreter that
>> runs on parrot, or rewriting inform to compile to parrot?
>
> I doubt it. I think a z-machine to parrot converter, making some of the
> more complex ops sub calls or something, would be best. We need to work
> with the z-machine bytecode directly, though, because many games are
> distributed without source.
>
> And perhaps, once dynamic opcode loading is ready, those sub calls can
> turn into real ops for speed. But that's not important at the moment:
> the important thing (well, as important as z-machine can be :-) is to
> get the translator working.
Turning them into real ops might not be the right thing to do in the
presence of JIT of course.
Dan Sugalski
Nah, that's not an issue. The JIT has to be able to handle loadable op
libraries. It can TIL the unknown ops easily enough, and we can make sure
sufficient information is attached to the op libraries to allow real
JITting as well.
Dan
Dan Sugalski
> OK. I think I've learned enough about Parrot to respond to this email
> intelligently.
>
> --- Nicholas Clark <ni...@ccl4.org> wrote:
> > > - Is it not being ported because of a lack of tuits, or because
> > > it's extremely hard?
> >
> > 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)
>
> Right. What you're saying here is that I'll need to write Zmachine.ops,
> or some such. It will include all the Z-machine operations, which the
> bytecode will call.
Yep.
> > 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.
>
> Right. The problem that I see with this is that Z-code "story" files
> have a very definite header format, which is almost but not quite
> entirely unlike Parrot bytecode. Just for example, the first few bytes
> are totally different, but are necessary for both languages.
Right, which is good.
What I want to have happen is that when parrot is handed a bytecode file
to execute, it examines the header of the file to find out what type of
bytecode it is, and dispatch to the right loader. So when you load up a
story file as if it were native bytecode, the bytecode loading routines
identify it as a zcode story file rather than parrot bytecode and dispatch
it to the zcode loader rather than the parrot bytecode loader.
> From what I can understand, "native" means (if we ignore dynamic
> bytecode
> conversion issues) running directly from the bytecode, but writing new
> ops. That is, not using PASM at all. In that case, do I even have
> access
> to Parrot's stack? (Or do I just need to access all of it through C?) I
> guess maybe my mistake is in thinking of PASM as Parrot.
PASM is parrot's assembly, but when you're writing actual op functions
you're extending parrot's opcodes--C is essentially Parrot's microcode.
From within opcode functions you have full access to all of the underlying
structures, so if you want to access Parrot's stack in z-machine ops, go
for it.
Dan
Amir Karger
such that posting to Google's perl.perl6.internals group will email
perl6-i...@perl.org? Might be more convenient for me than reading
stuff on Google & then logging in to my Yahoo account to post.
--- Dan Sugalski <d...@sidhe.org> wrote:
> On Sat, 6 Sep 2003, Amir Karger wrote:
>
> > I'll need to write Zmachine.ops, or some such. It will include all
> > the Z-machine operations, which the bytecode will call.
>
> Yep.
OK. Although Luke Palmer seems to think differently. He said:
> I think a z-machine to parrot converter, making some of the
> more complex ops sub calls or something, would be best. We need to
work
> with the z-machine bytecode directly, though, because many games are
> distributed without source.
That sounds more like my "disassemble Zcode to Z assembly, then
translate that to PASM+, i.e., PASM that calls Zcode ops in addition to
the regular ops, but uses the Parrot registers et al., then compile and
run that."
Of course, between these two solutions, there would be some overlap in
the Z-specific opcodes, but there's the major question of whether we go
through PASM or not. But as Luke (and my-ticket-to-fame Piers Cawley)
mention, not using PASM loses you some fancy optimizations. (At least I
think that's what they said.) Are these optimizations unnecessary if we
write the whole bytecode implementer in C?
I'm happy to do (or, maybe more likely, try and fail miserably to do)
either method, but The List should probably figure out a direction for
me to go in first. (Given my knowledge of Parrot, I'm probably the
least
qualified person on this list right now to make this decision. Unless
you tell me to do whichever I think will be more fun, in which case
I'll
write a Z-code to BASIC translator....)
> > > we want parrot to be able to directly load Z-code files, rather
> > > than having to first run an external program to convert them.
> >
> > Right. The problem that I see with this is that Z-code "story"
> > files have a very definite header format, which is almost but not
> > quite entirely unlike Parrot bytecode. Just for example, the first
> > few bytes are totally different, but are necessary for both
> > languages.
>
> Right, which is good.
>
> What I want to have happen is that when parrot is handed a bytecode
> file to execute, it examines the header of the file to find out what
> type of bytecode it is, and dispatch to the right loader. So when
> you load up a story file as if it were native bytecode, the bytecode
> loading routines identify it as a zcode story file rather than
> parrot bytecode and dispatch it to the zcode loader rather than the
> parrot bytecode loader.
Er, I'll assume you have a magic (pun slightly intended) way to decide
which files are Zcode? I mean, sure, if the rule is "anything that
doesn't match a Parrot header", you're fine, but once you've included
Python bytecode, Java bytecode, and compiled Befunge bytecode (a man
can
dream), how will you tell the Zcode from other bytecode noise? I don't
see anything particularly obvious in the header contents:
http://www.inform-fiction.org/zmachine/standards/z1point0/sect11.html
I assume having a separate Z-code loader solves the "Z-code has
two-byte
words" problem? OTOH, that means even more of Parrot functionality we
don't get to use.
> > From what I can understand, "native" means running directly from
the
> > bytecode, but writing new ops. That is, not using PASM at all. In
> > that case, do I even have access to Parrot's stack? (Or do I just
> > need to access all of it through C?)
>
> PASM is parrot's assembly, but when you're writing actual op
functions
> you're extending parrot's opcodes--C is essentially Parrot's
> microcode. From within opcode functions you have full access to all
> of the underlying structures, so if you want to access Parrot's stack
> in z-machine ops, go for it.
Hm. Well, *do* I want access Parrot's stack? Something to think about
if
I ever start actually writing code for this project, instead of talking
about it.
Uri Guttman
AK> Er, I'll assume you have a magic (pun slightly intended) way to
AK> decide which files are Zcode? I mean, sure, if the rule is
AK> "anything that doesn't match a Parrot header", you're fine, but
AK> once you've included Python bytecode, Java bytecode, and compiled
AK> Befunge bytecode (a man can dream), how will you tell the Zcode
AK> from other bytecode noise? I don't see anything particularly
AK> obvious in the header contents:
AK> http://www.inform-fiction.org/zmachine/standards/z1point0/sect11.html
i see plenty there than can be used to identify a zcode file. it would
take a little work to select a set of interesting fixed offset bytes and
their normal range of values. then writing the magic detector is easy.
the unix program file does it that way right now and it is fairly
decent. /etc/magic has a large table of bytes and program types.
also we can have a short script read a normal zcode file and put it in a
special and marked section (using the standard directory stuff) of a
parrotcode file from which it can be easily loaded and run. in fact this
is a general tool that can wrap any other format code into something
parrot could load and then invoke the appropriate byte code converter.
AK> I assume having a separate Z-code loader solves the "Z-code has
AK> two-byte
AK> words" problem? OTOH, that means even more of Parrot functionality we
AK> don't get to use.
it all depends on how the zcode interpreter is built. as others have
said there are many choices and many overlapping ideas. so i doubt we
would all agree on the best way to do this. the designs range from a
total code conversion, load and translate the zcode into equivilent
imcc. this should be the easiest to do as you just need to write a code
generator for each zcode op. you can fake a stack in imcc using a PMC
array or someother technique. just have all the zcode stack opcodes use
the pmc based stack in the translation. this could be done in pure perl
as well and run offline to generate imcc code. this would still run
directly on parrot but use its existing set of opcodes
note that parrot can't directly run zcode because of the 2 byte
issue. a real zcode loader would have to read in the zcode (from a file
or maybe that marked section i mentioned before) and translate it to
legal parrot opcodes in 32 (or 64) bit sizes. then you would need to
write real code to handle each of the needed parrot opcodes. i would
consider this much more work but it can be truly said that parrot is
running zcode natively.
and of course you can have a mix of the above two. the main system will
translate simple zcode ops to equivilent short pieces of imcc code. then
the heavier duty zcode ops can be written in c and loaded on
demand. these new codes can be generated by the translator when it sees
the zcodes that need them.
by following that path, you can start with a pure translator (first
design) and then migrate over to a native interpreter (second design)
but as incrementally as desired.
AK> Hm. Well, *do* I want access Parrot's stack? Something to think
AK> about if I ever start actually writing code for this project,
AK> instead of talking about it.
well you need a stack somewhere. you can acces parrot internal stacks
from any parrot ops that you create (in c). regular parrot ops only some
limited access to those stacks. but you can use your own stacks in the
registers and with arrays which would mean both parrot ops and your own
ops would be able to access them.
hope this clarified the issues,
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Class in Boston - Sept 2003 -- http://www.stemsystems.com/class
Dan Sugalski
>Before I start, a list question: is Google groups mailing list-aware,
>such that posting to Google's perl.perl6.internals group will email
>perl6-i...@perl.org? Might be more convenient for me than reading
>stuff on Google & then logging in to my Yahoo account to post.
The NNTP gateway's pretty much one way. You might try using the news
server at nntp.perl.org, though there may still be a delay. News,
unfortunately, is rather badly prone to abuse and spamming.
>--- Dan Sugalski <d...@sidhe.org> wrote:
>> On Sat, 6 Sep 2003, Amir Karger wrote:
>>
>> > I'll need to write Zmachine.ops, or some such. It will include all
>> > the Z-machine operations, which the bytecode will call.
>>
>> Yep.
>
>OK. Although Luke Palmer seems to think differently.
That's OK--there are a number of different ways to go about this.
> He said:
>
>> I think a z-machine to parrot converter, making some of the
>> more complex ops sub calls or something, would be best. We need to
>work
>> with the z-machine bytecode directly, though, because many games are
>> distributed without source.
>
>That sounds more like my "disassemble Zcode to Z assembly, then
>translate that to PASM+, i.e., PASM that calls Zcode ops in addition to
>the regular ops, but uses the Parrot registers et al., then compile and
>run that."
Which you can do, and ultimately is probably the best thing to do.
(It is, actually, what I'm suggesting you do, though I think I'm
probably skipping a few bits) Though the possibility of writing a
z-machine interpreter in parrot assembly, IMCC, or one of the
languages that targets parrot is definitely an option.
>Of course, between these two solutions, there would be some overlap in
>the Z-specific opcodes, but there's the major question of whether we go
>through PASM or not. But as Luke (and my-ticket-to-fame Piers Cawley)
>mention, not using PASM loses you some fancy optimizations. (At least I
>think that's what they said.) Are these optimizations unnecessary if we
>write the whole bytecode implementer in C?
Nah, I think it's a matter of some interpretation. Piers was assuming
that if you used a *loadable* opcode library that you couldn't be
JITted. That's not the case, though I'm not sure it's a huge issue
anyway--there's a limit to how fast Lurking Horror can run, after
all. :)
>I'm happy to do (or, maybe more likely, try and fail miserably to do)
>either method, but The List should probably figure out a direction for
>me to go in first. (Given my knowledge of Parrot, I'm probably the
>least
>qualified person on this list right now to make this decision. Unless
>you tell me to do whichever I think will be more fun, in which case
>I'll
>write a Z-code to BASIC translator....)
Here's what *I* think would be cool.
1) We have a set of z-machine ops to implement whatever bits you need
that are otherwise inconvenient to implement in what ops we have now.
(There may not be any, which is fine)
2) We have whatever support parrot assembly routines you might need.
(Library code for the interpreter and whatnot)
3) We have code, written either in C or parrot assembly, that can
turn a z-machine file into parrot bytecode, parrot assembly, or IMCC
source. (This code should rely only on ANSI C89, the C89 libraries,
and/or the parrot library routines, and shouldn't do any I/O)
4) We have code that can definitively identify a file as z-code.
(This may be the fact that there's a -b:zcode switch immediately
before it)
What we do then is weld this all together, and it then gives us the
ability to dynamically load up and run z-code files. The flow will be
that parrot opens the bytecode file and tries to identify it. Using
the code in #4, it identifies it as z-code, and then hands it to the
code for #3 (which is a parrot bytecode loader). #3 translates it to
parrot bytecode (directly or indirectly) including the support code
from #2 (if there is some) and hands it to the interpreter to
execute. The interpreter loads up the opcode library from #1 if it
needs to, and goes.
> > > > we want parrot to be able to directly load Z-code files, rather
>> > > than having to first run an external program to convert them.
>> >
>> > Right. The problem that I see with this is that Z-code "story"
>> > files have a very definite header format, which is almost but not
>> > quite entirely unlike Parrot bytecode. Just for example, the first
>> > few bytes are totally different, but are necessary for both
>> > languages.
>>
>> Right, which is good.
>>
>> What I want to have happen is that when parrot is handed a bytecode
>> file to execute, it examines the header of the file to find out what
>> type of bytecode it is, and dispatch to the right loader. So when
>> you load up a story file as if it were native bytecode, the bytecode
>> loading routines identify it as a zcode story file rather than
>> parrot bytecode and dispatch it to the zcode loader rather than the
>> parrot bytecode loader.
>
>Er, I'll assume you have a magic (pun slightly intended) way to decide
>which files are Zcode? I mean, sure, if the rule is "anything that
>doesn't match a Parrot header", you're fine, but once you've included
>Python bytecode, Java bytecode, and compiled Befunge bytecode (a man
>can
>dream), how will you tell the Zcode from other bytecode noise?
Potentially we can't, in which case we have to punt and force it to
be specified on the command line as a parameter indicating bytecode
type. That'd be unfortunate, but possible. On the other hand, there
may well be some good heuristic that can be applied to identify the
code. I'd expect there probably is, though I may be wrong here--many
bytecode formats don't embed type or version info into them. (Which,
having dealt with *far* too many binary formats, I consider a design
flaw. I like binary formats, but it's nice to be able to identify the
darned things)
>I don't
>see anything particularly obvious in the header contents:
>
>http://www.inform-fiction.org/zmachine/standards/z1point0/sect11.html
>
>I assume having a separate Z-code loader solves the "Z-code has
>two-byte
>words" problem? OTOH, that means even more of Parrot functionality we
>don't get to use.
Nope. Note that, while the loader gets handed the bytecode file from
disk, it can hand anything it likes to Parrot. Sure, in the case of
parrot bytecode of the right endianness and word size it gets mmapped
in, but you're perfectly within the design to dynamically mash,
mangle, munge, warp, bend, fold, spindle, or mutilate that bytecode
to do whatever you want. This includes on-the-fly translation from
whatever format it is in (say, z-machine bytecode) to parrot
bytecode. (Note that it'd be fine for the bytecode loader to see the
signature "#!\s*\S+\bperl\b" and decide that the bytecode's really
perl source and hand it off to the perl compiler...)
> > > From what I can understand, "native" means running directly from
>the
>> > bytecode, but writing new ops. That is, not using PASM at all. In
>> > that case, do I even have access to Parrot's stack? (Or do I just
>> > need to access all of it through C?)
>>
>> PASM is parrot's assembly, but when you're writing actual op
>functions
>> you're extending parrot's opcodes--C is essentially Parrot's
>> microcode. From within opcode functions you have full access to all
>> of the underlying structures, so if you want to access Parrot's stack
>> in z-machine ops, go for it.
>
>Hm. Well, *do* I want access Parrot's stack? Something to think about
>if I ever start actually writing code for this project, instead of talking
>about it.
Good question. Probably, yes. Pushing things on it is a useful thing,
and may match what you need to do well. (IIRC z-code is stack based,
but I might remember wrong) You could also have a custom PMC class
that holds all your state, the data, or whatever else you want, which
is only easily accessible from within translated z-code, too.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Amir Karger
> >>>>> "AK" == Amir Karger <amirka...@yahoo.com> writes:
>
> AK> Er, I'll assume you have a magic (pun slightly intended) way to
> AK> from other bytecode noise? I don't see anything particularly
> AK> obvious in the header contents:
>
would
> take a little work to select a set of interesting fixed offset bytes
> and their normal range of values. then writing the magic detector is
> easy.
So you mean you require the first byte to be a number <=8, and the
pointer to the end of the dictionary has to be less than the size of
the
file, the flag bits need to have sane values, etc.? Interesting. I
guess
with some work you can do it; it's just that there isn't one magic
number at one particular offset at the beginning of the file.
> also we can have a short script read a normal zcode file and put it
> in a
> special and marked section (using the standard directory stuff) of a
> parrotcode file from which it can be easily loaded and run. in fact
> this
> is a general tool that can wrap any other format code into something
> parrot could load and then invoke the appropriate byte code
> converter.
Sure we can, and it's a tool we might want. I had gotten the impression
that Dan considered having any extra scripts to be cheating. Then
again,
maybe cheating isn't such a bad thing, if it helps get the project
started.
> AK> I assume having a separate Z-code loader solves the "Z-code has
> AK> two-byte words" problem? OTOH, that means even more of Parrot
> AK> functionality we don't get to use.
>
> it all depends on how the zcode interpreter is built. as others have
> said there are many choices and many overlapping ideas. so i doubt we
> would all agree on the best way to do this.
What? Disagreement on a mailing list? I'm shocked! Next you'll tell me
there's more than one way to do it!
> the designs range from a total code conversion, load and translate
the
> zcode into equivilent imcc. this should be the easiest to do as you
> just need to write a code generator for each zcode op.
This is kind of what I was first thinking, because the first code I
looked at was the Befunge (and, I'll admit it, Ook!) PASM, which does
exactly that.
Though not quite so trivial when one of the opcodes is "restore a saved
game", which you can imagine may include more stuff than, say, the
"add"
opcode. (Interestingly, I noticed yesterday that Z's add opcode doesn't
pop two off the top of the stack, like Befunge, but rather takes as
arguments two adding operands followed by a storage variable. Sounds
familiar!)
The other reason this isn't as easy as going straight to C is that I
already have (several minor variations on) working C (open source) code
for all of the opcodes. So, yes, I can copy them to turn them into PIR,
but if I go for the all-opcode route, I could just cut and paste each
opcode's C! Um, maybe. Although that would mean totally ignoring all
Parrot stuff.
> you can fake a stack in imcc using a PMC array or someother
technique.
Yup, like Befunge does.
> just have all the zcode stack opcodes use the pmc based stack in the
> translation. this could be done in pure perl as well and run offline
> to generate imcc code. this would still run directly on parrot but
use
> its existing set of opcodes
"pure perl as well"? As well as what? I assumed pure Perl translation
from disassembled Zcode to PASM opcodes was what you were writing about
above.
> note that parrot can't directly run zcode because of the 2 byte
> issue.
Right. I don't know enough about parrotcode to understand why - if you
already have a variable that can be set to 4 or 8, you can't also set
it
to 2. But I'm sure there's a good reason. (What happens when the
128-bit
"Insteinium" chip comes out?)
> a real zcode loader would have to read in the zcode (from a
> file or maybe that marked section i mentioned before) and translate
it
> to legal parrot opcodes in 32 (or 64) bit sizes. then you would need
> to write real code to handle each of the needed parrot opcodes.
Write or *steal*, but yes.
> i would consider this much more work but it can be truly said that
> parrot is running zcode natively.
Right. Is that our first goal, or our end goal?
> and of course you can have a mix of the above two. the main system
> will translate simple zcode ops to equivilent short pieces of imcc
> code. then the heavier duty zcode ops can be written in c and loaded
> on demand. these new codes can be generated by the translator when it
> sees the zcodes that need them.
Well, I plan to first write programs in Inform that generate
valid story files that use only simple opcodes (print, add, et al.)
I guess after I've worked on that for a while, I can decide whether for
the harder Zcode ops I want to do Perl disassembly & translation to PIR
or just call C directly.
> by following that path, you can start with a pure translator (first
> design) and then migrate over to a native interpreter (second design)
> but as incrementally as desired.
Right, what you said.
> AK> Hm. Well, *do* I want access Parrot's stack? Something to think
> AK> about if I ever start actually writing code for this project,
> AK> instead of talking about it.
>
> well you need a stack somewhere. you can acces parrot internal stacks
> from any parrot ops that you create (in c). regular parrot ops only
> some limited access to those stacks. but you can use your own stacks
> in the registers and with arrays which would mean both parrot ops and
> your own ops would be able to access them.
Right.
> hope this clarified the issues,
It definitely did! I think the thing that may make this decision for me
is that I know Perl better than C, and I know that Zcode disassembly is
easy, and can steal from people's PASM translators. So I feel like
that's a place I could get started on the project without too much
difficulty. (Not to mention that I'm currently running on Windows
without a C compiler and know that the Perl code I write will work.
Although this project may have finally inspired me to start using the
other half of my dual boot -- or, more accurately, I spent $12 today to
get RH9 so I can upgrade to an easily installed firewall that I can
boot
to and have a complete dev environment (modulo some rpm updates).)
And I haven't even thought yet about Z objects (PMCs? What kind?), the
Z
dictionary (Can we translate it easily to a Parrot constant code
segment?), and all that header stuff. But I'm itching to actually start
typing stuff, so maybe I'll just jump in headfirst!
> uri
Toda raba (thanks)!
Amir Karger
>
> the designs range from a
> total code conversion, load and translate the zcode into equivilent
> imcc. this should be the easiest to do as you just need to write a
> code
> generator for each zcode op. you can fake a stack in imcc using a PMC
> array or someother technique. just have all the zcode stack opcodes
> use
> the pmc based stack in the translation. this could be done in pure
> perl
> as well and run offline to generate imcc code. this would still run
> directly on parrot but use its existing set of opcodes
[Sound of head hitting desk]
Oh! You're saying that instead of pure perl I could write the
disassembler and translator in PASM. I think I've gotten so used to
Perl being the best job for translating from one bytestream to another
that I never imagined using PASM itself, but of course that's what the
aforementioned Befunge & Ook translators do.
Well, that will certainly be more work than doing it in Perl, but OTOH,
it'll probably be a great tutorial in PASM.
And reading Dan's post, it looks like that's what he's thinking of,
too. And since I can't imagine we'll get *three* people to agree on
anything, I think I'll start trying to do that.
I'll get back to you in six months or so :)
Uri Guttman
AK> So you mean you require the first byte to be a number <=8, and the
AK> pointer to the end of the dictionary has to be less than the size
AK> of the file, the flag bits need to have sane values, etc.?
AK> Interesting. I guess with some work you can do it; it's just that
AK> there isn't one magic number at one particular offset at the
AK> beginning of the file.
something like that. there is definitely a signature to be found
there. also dan's point of just telling the loader it is zcode with a
flag is fine too. and the translator program would just know the first
file arg is zcode.
>> also we can have a short script read a normal zcode file and put it
>> in a special and marked section (using the standard directory
>> stuff) of a parrotcode file from which it can be easily loaded and
>> run. in fact this is a general tool that can wrap any other format
>> code into something parrot could load and then invoke the
>> appropriate byte code converter.
AK> Sure we can, and it's a tool we might want. I had gotten the
AK> impression that Dan considered having any extra scripts to be
AK> cheating. Then again, maybe cheating isn't such a bad thing, if it
AK> helps get the project started.
who said this is cheating? call it parrot aids.
AK> Though not quite so trivial when one of the opcodes is "restore a
AK> saved game", which you can imagine may include more stuff than,
AK> say, the "add" opcode. (Interestingly, I noticed yesterday that
AK> Z's add opcode doesn't pop two off the top of the stack, like
AK> Befunge, but rather takes as arguments two adding operands
AK> followed by a storage variable. Sounds familiar!)
AK> The other reason this isn't as easy as going straight to C is that
AK> I already have (several minor variations on) working C (open
AK> source) code for all of the opcodes. So, yes, I can copy them to
AK> turn them into PIR, but if I go for the all-opcode route, I could
AK> just cut and paste each opcode's C! Um, maybe. Although that would
AK> mean totally ignoring all Parrot stuff.
then you do the mixed approach where you translate simple zcode ops to
their parrot equivilents and translate complex ops to the parrot ops you
create from the c libs you have.
>> note that parrot can't directly run zcode because of the 2 byte
>> issue.
AK> Right. I don't know enough about parrotcode to understand why - if
AK> you already have a variable that can be set to 4 or 8, you can't
AK> also set it to 2. But I'm sure there's a good reason. (What
AK> happens when the 128-bit "Insteinium" chip comes out?)
it has to do with how parrot reads in bytefiles. it uses mmap to read
them in and it can only execute ops on 32 bit boundaries so zcode's 16
bit ops will be broken. so at least the zcode has to be read in and
converted to 32 bit ops by expanding them into another buffer. this can
be done offline by a tool which would make allow it to load faster and
use mmap directly.
>> i would consider this much more work but it can be truly said that
>> parrot is running zcode natively.
AK> Right. Is that our first goal, or our end goal?
your choice. getting zcode working at all is the first goal. getting it
to run fast/well/cheap :) are later goals.
>> and of course you can have a mix of the above two. the main system
>> will translate simple zcode ops to equivilent short pieces of imcc
>> code. then the heavier duty zcode ops can be written in c and loaded
>> on demand. these new codes can be generated by the translator when it
>> sees the zcodes that need them.
AK> Well, I plan to first write programs in Inform that generate
AK> valid story files that use only simple opcodes (print, add, et al.)
AK> I guess after I've worked on that for a while, I can decide whether for
AK> the harder Zcode ops I want to do Perl disassembly & translation to PIR
AK> or just call C directly.
again, your choice. this project has many design decisions and you will
have to make most of them yourself. you can usually change some of the
decisions later or improve things. but the overall design should be
pretty much what you seem to grasp.
>> by following that path, you can start with a pure translator (first
>> design) and then migrate over to a native interpreter (second design)
>> but as incrementally as desired.
AK> Right, what you said.
or even start with a mixed design if you want to use some of that zcode
lib in c.
AK> And I haven't even thought yet about Z objects (PMCs? What kind?),
AK> the Z dictionary (Can we translate it easily to a Parrot constant
AK> code segment?), and all that header stuff. But I'm itching to
AK> actually start typing stuff, so maybe I'll just jump in headfirst!
when you get into zcode specifics, i am outa here since i know nothing
about it. i was just helping with the big picture and overall design for
a bytecode translator. my ideas could be applied to a jvn on parrot
system just as easily.
AK> Toda raba (thanks)!
you're welcome. good luck on this journey into the swamp. may you have
many castles in your backpack. :)
Uri Guttman
AK> --- Uri Guttman <u...@stemsystems.com> wrote:
>> >>>>> "AK" == Amir Karger <amirka...@yahoo.com> writes:
>>
>> the designs range from a total code conversion, load and translate
>> the zcode into equivilent imcc. this should be the easiest to do as
>> you just need to write a code generator for each zcode op. you can
>> fake a stack in imcc using a PMC array or someother technique. just
>> have all the zcode stack opcodes use the pmc based stack in the
>> translation. this could be done in pure perl as well and run
>> offline to generate imcc code. this would still run directly on
>> parrot but use its existing set of opcodes
AK> [Sound of head hitting desk]
poor desk!! :)
AK> Oh! You're saying that instead of pure perl I could write the
AK> disassembler and translator in PASM. I think I've gotten so used
AK> to Perl being the best job for translating from one bytestream to
AK> another that I never imagined using PASM itself, but of course
AK> that's what the aforementioned Befunge & Ook translators do.
it could be done either way.
AK> Well, that will certainly be more work than doing it in Perl, but OTOH,
AK> it'll probably be a great tutorial in PASM.
yes, it would. i would do a perl version first just to get it up and
running. your idea to write a test game and compile it to a few common
op codes sounds reasonable. then you can do a simple zcode to pasm/imcc
translator. even if you only get add working, it is a signifigant first
step. then you can add ops and work on a native pasm/imcc version if you
want.
AK> And reading Dan's post, it looks like that's what he's thinking of,
AK> too. And since I can't imagine we'll get *three* people to agree on
AK> anything, I think I'll start trying to do that.
hard to read dan sometimes. :)
AK> I'll get back to you in six months or so :)
we require weekly status reports with 10 minute granularity on what you
are working on. this is standard for all parrot projects.
uri
belated :-)
Nicholas Clark
> Sure we can, and it's a tool we might want. I had gotten the impression
> that Dan considered having any extra scripts to be cheating. Then
> again,
> maybe cheating isn't such a bad thing, if it helps get the project
> started.
Cheat first to help you get started.
We found at work that having a prototype system that we could incrementally
improve helped enormously
(Because we could test that each finished component worked in its proper,
integrated environment)
On Mon, Sep 08, 2003 at 08:58:29PM -0700, Amir Karger wrote:
> Oh! You're saying that instead of pure perl I could write the
> disassembler and translator in PASM. I think I've gotten so used to
> Perl being the best job for translating from one bytestream to another
> that I never imagined using PASM itself, but of course that's what the
> aforementioned Befunge & Ook translators do.
>
> Well, that will certainly be more work than doing it in Perl, but OTOH,
> it'll probably be a great tutorial in PASM.
I think that if you're comfortable writing it in perl, you should write
one in perl first. It's a prototype. You can use it to learn how to
do the real thing in PASM. And you'll have something working earlier,
so hopefully you won't get demoralised part way through.
Just don't make it too good, in case everyone stops working on parrot
and starts playing Zork/Hitch-Hikers' Guide to the Galaxy/whatever
Nicholas Clark
Amir Karger
>
>
> Cheat first to help you get started.
Actually, I believe True Laziness would say cheat always. Except maybe
when Hubris says it'll look cooler if it's native :)
> We found at work that having a prototype system that we could
> incrementally
> improve helped enormously
> (Because we could test that each finished component worked in its
> proper,
> integrated environment)
Surely you don't expect me to write this code AND test it?!
Actually, I posted to rec.arts.int-fiction today to see if there are
any Z-machine regression tests lying around.
> I think that if you're comfortable writing it in perl, you should
> write
> one in perl first. It's a prototype. You can use it to learn how to
> do the real thing in PASM. And you'll have something working earlier,
> so hopefully you won't get demoralised part way through.
Agreed. It looks like if I steal enough from Games::Rezrov (same
license as Perl), then a Perl disassembler should take me only a few
hours (coding time, not wallclock time!) The neat thing about porting a
virtual machine at that point is that translating each Z opcode to PASM
shouldn't take long (at least for the simpler opcodes, and we agreed
I'm not going to worry about the hard ones yet), so I'll continue to
feel like I'm accomplishing things. Then if I've got a Perl translator
that does enough, the excitement will hopefully push me over the rather
larger energy barrier of writing the translator in PASM.
> Just don't make it too good, in case everyone stops working on parrot
> and starts playing Zork/Hitch-Hikers' Guide to the Galaxy/whatever
Well, most of those aren't freely available. My biggest concern is that
*I* might start playing them. (I bought a CD a few years ago with
almost all the Infocom games on it.)