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