Still working on the prelude to the preface to the "Z-machine running natively on Parrot" project, namely translating Z-code into a Perl executable. (My brother, who's a CS professor so he should know, says I'm actually *compiling* it. Compiling bytecode to an interpreted language? Weird!) I'm making some progress, but now I have to deal with the harder opcodes I'd ignored, like I/O and save/restore. (Interesting to hear about Parrot curses, wrt Z-code I/O, btw.)
I figured I could just use the Perl subroutine mechanism to emulate Z-machine calls. So I just translate Z-code's "call routine arg0 arg1..." to "&routine(arg0, arg1, ...)" and "ret value" becomes "return $value". I realized that I get in trouble when we get to the save/restore commands. Those are supposed to save and restore the call stack, which includes the subroutine addresses & all the local variables in the various routines. Am I right in thinking I don't actually have access to that in Perl? (That is, I can't change the call stack at runtime, such that when I "return" it'll return to a different subroutine than the one that actually called the current routine.) In Perl, I can fake it by making my entire program have no subroutines (yuck!) and using gotos and manually storing the call stack. Then I thought, "but what do I do about Parrot?", which is supposed to be the whole point of this project. Then I thought that maybe I *do* have access to Parrot's stack! So the question is, will I be able to write a Parrot opcode that resets the Parrot call stack? And I guess to reset the register stacks too? Otherwise, I won't be able to save/restore games. -Amir __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
