OK. I think I've learned enough about Parrot to respond to this email intelligently.
--- Nicholas Clark <[EMAIL PROTECTED]> 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. -Amir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
