Darn. I was all set to write an amusing email about how I wasn't offended that noone responded to my email, when someone went and responded to my mail. OTOH, in the meantime I got my fifteen bytes of fame in the P6 summary, plus the opportunity to play this week's Perl Golf instead of mucking about with Z-code and PASM.
[I'd better apologize up front for verbosity. Hard to believe I play Perl Golf, really.] --- Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Thu, Aug 28, 2003 at 06:17:07AM -0700, Amir Karger wrote: > > Hi. Hugely newbie at Parroting, but think it's the coolest. > > Good stuff. I hope it stays that with the inevitable setbacks and > annoyances that will come while gaining experience. Strange how almost no language (or software project in general) remains perfect, isn't it? I still think Befunge-93 is close to perfect (simple enough to learn quickly, but hilariously crooked), but they had to go add all those silly opcodes (like reading from a file. Whatever for, when you can store data in your program?!) for Befunge-98. > > - Is it not being ported because of a lack of tuits, or because it's > > extremely hard? > > I think it's party because of tuits, and party because to be done > "properly" it requires a couple of big features to be added to parrot, > notably > > 1: dynamic opcode loading > 2: dynamic bytecode conversion > > (This is the point where someone tells me that dynamic opcode loading > now works) I would tell you, but I wouldn't even know if I was lying or not. This is the point where you tell me that I can work on pieces of the problem without having all this working, and when I've finished a large part of the job, one of the core Parroters will be inspired to hack up #s 1 and 2 overnight while at some YAPC instead of sleeping or drinking beer. > 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) Surely the majority of Parrot coders will want to use Z-machine opcodes?! > 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. Ah. I thought this was true, when I saw Dan's quote that Z-code would run "natively". However, I wanted it not to be true because it sounded scary. I kind of figured I would need to implement all the Z-machine opcodes in order to get this to work, so you'd be calling Z opcodes instead of parrot ones. But I'm still confused about how you deal with the Z-code Header, which is a bunch of data, not opcodes, and which doesn't follow (by a longshot) the Parrot bytecode format specification. And Dan pointed out that Z-code has 16-bit words, not Parrot's 32. I guess this is what you mean by "dynamic bytecode conversion". Only I don't have the first idea how this is supposed to happen. (Are there docs about it I'm supposed to be reading?) Is this different from running a Perl script to put the Z-code header into a Parrot data object and create a Parrot header? > 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) Aha! So now all you need to do is tell me how to do *that*. RTFM's welcomed, as long as I don't have to R ALL of TFMs. Would it begin by doing a "non-native" port that does use a Perl translator? > > - A Perl 6 Summary from last year claimed Josh Wilmes was going to > > work on it. Does anyone know if he is and, if so, how far he's > > gotten? > > I have no idea This is where Josh jumps in, sends me 90%-finished code and says he'll give me all the credit if I write up the documentation. > > - Whether or not it's extremely hard, would it be useful to have > > some of the easy parts done by a newbie who can hack assembly but > > not well enough to put into the parrot core? In that case, which > > would be the easy parts? > > I've no idea. Well, then, we make a great pair! > How familiar are you with Z-code? Um, somewhat. The Z-machine has been ported to PalmOS, but save files aren't compatible. I started working on a Perl script to convert them, but got distracted by a neat Perl Golf competition. In the meantime, though, I read the Z-machine spec and played with some headers and, most importantly, subscribed to the Z-machine mailing list where I can ask lots of questions. To be honest, given the shape (as it were) of my tuits and my knowledge of Z and Parrot, I'm more hoping to get the ball rolling on this and then have some experts do the hard stuff (Some versions of the Z-machine support sound, graphics....) than to create a complete implementation. But we'll see. It doesn't look like Parrot will be finished next week either. > About all that I know (and I may be wrong) is that it fits in a > virtual machine with 128K total memory, I believe later versions (post-Infocom) allow up to a whopping 512K. > that it has continuations (which we now have), Until I reread the spec and read more about continuations, I'll say "maybe". I'm not sure whether this quote has anything to do with what you're talking about: A "stack frame" is an index to the routine call state (that is, the call-stack of return addresses from routines currently running, and values of local variables within them). This index is a Z-machine number. The interpreter must be able to produce the current value and to set a value further down the call-stack than the current one, effectively throwing away its recent history (see catch and throw). > and that the Hitch-Hiker's Guide to the Galaxy adventure game was > written in it. In fact, ALL of the Infocom games were written in it, which means you can download the Z-machine (for any of a zillion OSes including the aforementioned Palm) and then buy the Infocom CD (if you can find it) and play almost every Infocom game. (It was particularly fun playing on Palm, because after every command, the computer has to think for a few seconds before printing out the result. Just fill in a bit of Apple //e floppy drive ker-chunking, and it's a trip right down memory lane.) Not to mention the hundreds (at least) of games written in Inform, a more modern language that compiles to Z-code. (Just to confuse you, though, there's a Befunge interpreter written in Inform that you can run using the Z-machine. And there's a mini-text adventure written in Befunge...) > Is the virtual machine stack based, or register based? (I guess from > your next paragraph that it's stack based) Definitely stack. > Do you know enough Z-code to create Z-code regression tests that > progressively exercise features of the Z-machine (along with the > expected correct output) so that any implementor (possibly yourself) > knows when they've got it right? Nope! But I think that with some help from Parroters and Z-machiners, I could get there. In fact, I think there may already be some tests written for the Z-machine, since it's been ported so many times. <pause type="Google"> rustle rustle rustle </pause> Aha! TerpEtude: A Z-Machine Interpreter Exerciser by Andrew Plotkin, Release 2. Tests compliance with Z-Machine Standards Document 0.99. I think this may get us somewhere. If not, I'll ask on the mailing list. > > - I saw that Dan wanted to create a library to handle stack-based > > languages. I don't suppose that's been done at all? If not, I could > > steal from, e.g., befunge, which would be way better than starting > > from scratch. I would offer to create the library, but I'm not > > really confident enough about my (as-yet nonexistent) pasm-writing > > skills to write a library a bunch of other people use. > > 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. And that's just what they'd expect us to do. > 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. I see that this would be useful. However, it seems to be it'd be easier to learn PASM than to learn the CS needed to do this intelligently. (I did computational chemistry, so all my CS is 2 semesters of coding classes and things I've picked up here and there.) I think my talents might be better utilized in porting Z opcodes & whatnot. Or, if someone has already thought about how to do this (Dan?) then maybe I could be the co-volunteer you mention above who actually writes it up. > Nicholas Clark Thanks for your detailed response! -Amir Karger __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com