--- Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "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? How will you tell the Zcode > AK> from other bytecode noise? I don't see anything particularly > AK> obvious in the header contents: > > 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.
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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
