>>>>> "AK" == Amir Karger <[EMAIL PROTECTED]> writes:
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 ------ [EMAIL PROTECTED] -------- 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
