Before I start, a list question: is Google groups mailing list-aware, such that posting to Google's perl.perl6.internals group will email [EMAIL PROTECTED] Might be more convenient for me than reading stuff on Google & then logging in to my Yahoo account to post.
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Sat, 6 Sep 2003, Amir Karger wrote: > > > I'll need to write Zmachine.ops, or some such. It will include all > > the Z-machine operations, which the bytecode will call. > > Yep. OK. Although Luke Palmer seems to think differently. He said: > I think a z-machine to parrot converter, making some of the > more complex ops sub calls or something, would be best. We need to work > with the z-machine bytecode directly, though, because many games are > distributed without source. That sounds more like my "disassemble Zcode 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." Of course, between these two solutions, there would be some overlap in the Z-specific opcodes, but there's the major question of whether we go through PASM or not. But as Luke (and my-ticket-to-fame Piers Cawley) mention, not using PASM loses you some fancy optimizations. (At least I think that's what they said.) Are these optimizations unnecessary if we write the whole bytecode implementer in C? I'm happy to do (or, maybe more likely, try and fail miserably to do) either method, but The List should probably figure out a direction for me to go in first. (Given my knowledge of Parrot, I'm probably the least qualified person on this list right now to make this decision. Unless you tell me to do whichever I think will be more fun, in which case I'll write a Z-code to BASIC translator....) > > > 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. > > Right, which is good. > > What I want to have happen is that when parrot is handed a bytecode > file to execute, it examines the header of the file to find out what > type of bytecode it is, and dispatch to the right loader. So when > you load up a story file as if it were native bytecode, the bytecode > loading routines identify it as a zcode story file rather than > parrot bytecode and dispatch it to the zcode loader rather than the > parrot bytecode loader. Er, I'll assume you have a magic (pun slightly intended) way to decide which files are Zcode? I mean, sure, if the rule is "anything that doesn't match a Parrot header", you're fine, but once you've included Python bytecode, Java bytecode, and compiled Befunge bytecode (a man can dream), how will you tell the Zcode from other bytecode noise? I don't see anything particularly obvious in the header contents: http://www.inform-fiction.org/zmachine/standards/z1point0/sect11.html I assume having a separate Z-code loader solves the "Z-code has two-byte words" problem? OTOH, that means even more of Parrot functionality we don't get to use. > > From what I can understand, "native" means 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?) > > PASM is parrot's assembly, but when you're writing actual op functions > you're extending parrot's opcodes--C is essentially Parrot's > microcode. From within opcode functions you have full access to all > of the underlying structures, so if you want to access Parrot's stack > in z-machine ops, go for it. Hm. Well, *do* I want access Parrot's stack? Something to think about if I ever start actually writing code for this project, instead of talking about it. -Amir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
