Re: Parrot Z-machine
--- Uri Guttman [EMAIL PROTECTED] wrote: AK == Amir Karger [EMAIL PROTECTED] writes: 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. you can fake a stack in imcc using a PMC array or someother technique. 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 [Sound of head hitting desk] Oh! You're saying that instead of pure perl I could write the disassembler and translator in PASM. I think I've gotten so used to Perl being the best job for translating from one bytestream to another that I never imagined using PASM itself, but of course that's what the aforementioned Befunge Ook translators do. Well, that will certainly be more work than doing it in Perl, but OTOH, it'll probably be a great tutorial in PASM. And reading Dan's post, it looks like that's what he's thinking of, too. And since I can't imagine we'll get *three* people to agree on anything, I think I'll start trying to do that. I'll get back to you in six months or so :) -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot Z-machine
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
Re: Parrot Z-machine
AK == Amir Karger [EMAIL PROTECTED] writes: AK --- Uri Guttman [EMAIL PROTECTED] wrote: AK == Amir Karger [EMAIL PROTECTED] writes: 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. you can fake a stack in imcc using a PMC array or someother technique. 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 AK [Sound of head hitting desk] poor desk!! :) AK Oh! You're saying that instead of pure perl I could write the AK disassembler and translator in PASM. I think I've gotten so used AK to Perl being the best job for translating from one bytestream to AK another that I never imagined using PASM itself, but of course AK that's what the aforementioned Befunge Ook translators do. it could be done either way. AK Well, that will certainly be more work than doing it in Perl, but OTOH, AK it'll probably be a great tutorial in PASM. yes, it would. i would do a perl version first just to get it up and running. your idea to write a test game and compile it to a few common op codes sounds reasonable. then you can do a simple zcode to pasm/imcc translator. even if you only get add working, it is a signifigant first step. then you can add ops and work on a native pasm/imcc version if you want. AK And reading Dan's post, it looks like that's what he's thinking of, AK too. And since I can't imagine we'll get *three* people to agree on AK anything, I think I'll start trying to do that. hard to read dan sometimes. :) AK I'll get back to you in six months or so :) we require weekly status reports with 10 minute granularity on what you are working on. this is standard for all parrot projects. uri belated :-) -- 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
Re: Parrot Z-machine
On Mon, Sep 08, 2003 at 08:48:07PM -0700, Amir Karger wrote: 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. Cheat first to help you get started. We found at work that having a prototype system that we could incrementally improve helped enormously (Because we could test that each finished component worked in its proper, integrated environment) On Mon, Sep 08, 2003 at 08:58:29PM -0700, Amir Karger wrote: Oh! You're saying that instead of pure perl I could write the disassembler and translator in PASM. I think I've gotten so used to Perl being the best job for translating from one bytestream to another that I never imagined using PASM itself, but of course that's what the aforementioned Befunge Ook translators do. Well, that will certainly be more work than doing it in Perl, but OTOH, it'll probably be a great tutorial in PASM. I think that if you're comfortable writing it in perl, you should write one in perl first. It's a prototype. You can use it to learn how to do the real thing in PASM. And you'll have something working earlier, so hopefully you won't get demoralised part way through. Just don't make it too good, in case everyone stops working on parrot and starts playing Zork/Hitch-Hikers' Guide to the Galaxy/whatever Nicholas Clark
Re: Parrot Z-machine
--- Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 08:48:07PM -0700, Amir Karger wrote: Cheat first to help you get started. Actually, I believe True Laziness would say cheat always. Except maybe when Hubris says it'll look cooler if it's native :) We found at work that having a prototype system that we could incrementally improve helped enormously (Because we could test that each finished component worked in its proper, integrated environment) Surely you don't expect me to write this code AND test it?! Actually, I posted to rec.arts.int-fiction today to see if there are any Z-machine regression tests lying around. I think that if you're comfortable writing it in perl, you should write one in perl first. It's a prototype. You can use it to learn how to do the real thing in PASM. And you'll have something working earlier, so hopefully you won't get demoralised part way through. Agreed. It looks like if I steal enough from Games::Rezrov (same license as Perl), then a Perl disassembler should take me only a few hours (coding time, not wallclock time!) The neat thing about porting a virtual machine at that point is that translating each Z opcode to PASM shouldn't take long (at least for the simpler opcodes, and we agreed I'm not going to worry about the hard ones yet), so I'll continue to feel like I'm accomplishing things. Then if I've got a Perl translator that does enough, the excitement will hopefully push me over the rather larger energy barrier of writing the translator in PASM. Just don't make it too good, in case everyone stops working on parrot and starts playing Zork/Hitch-Hikers' Guide to the Galaxy/whatever Well, most of those aren't freely available. My biggest concern is that *I* might start playing them. (I bought a CD a few years ago with almost all the Infocom games on it.) -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot Z-machine
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
Re: Parrot Z-machine
Luke Palmer [EMAIL PROTECTED] writes: Zellyn Hunter writes: So I take it the goal is to to teach parrot to understand z-machine opcodes, rather than simply writing a z-machine interpreter that runs on parrot, or rewriting inform to compile to parrot? I doubt it. 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. And perhaps, once dynamic opcode loading is ready, those sub calls can turn into real ops for speed. But that's not important at the moment: the important thing (well, as important as z-machine can be :-) is to get the translator working. Turning them into real ops might not be the right thing to do in the presence of JIT of course.
Re: Parrot Z-machine
On Sat, 6 Sep 2003, Amir Karger wrote: 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. Yep. 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. 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. 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. 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. Dan
Re: Parrot Z-machine
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? I mean, sure, if the rule is AK anything that doesn't match a Parrot header, you're fine, but AK once you've included Python bytecode, Java bytecode, and compiled AK Befunge bytecode (a man can dream), how will you tell the Zcode AK from other bytecode noise? I don't see anything particularly AK obvious in the header contents: AK http://www.inform-fiction.org/zmachine/standards/z1point0/sect11.html 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. the unix program file does it that way right now and it is fairly decent. /etc/magic has a large table of bytes and program types. 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 I assume having a separate Z-code loader solves the Z-code has AK two-byte AK words problem? OTOH, that means even more of Parrot functionality we AK 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. 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. you can fake a stack in imcc using a PMC array or someother technique. 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 note that parrot can't directly run zcode because of the 2 byte issue. 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. i would consider this much more work but it can be truly said that parrot is running zcode natively. 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. 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 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. hope this clarified the issues, 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
Re: Parrot Z-machine
At 10:33 AM -0700 9/8/03, Amir Karger wrote: 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. The NNTP gateway's pretty much one way. You might try using the news server at nntp.perl.org, though there may still be a delay. News, unfortunately, is rather badly prone to abuse and spamming. --- 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. That's OK--there are a number of different ways to go about this. 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. Which you can do, and ultimately is probably the best thing to do. (It is, actually, what I'm suggesting you do, though I think I'm probably skipping a few bits) Though the possibility of writing a z-machine interpreter in parrot assembly, IMCC, or one of the languages that targets parrot is definitely an option. 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? Nah, I think it's a matter of some interpretation. Piers was assuming that if you used a *loadable* opcode library that you couldn't be JITted. That's not the case, though I'm not sure it's a huge issue anyway--there's a limit to how fast Lurking Horror can run, after all. :) 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) Here's what *I* think would be cool. 1) We have a set of z-machine ops to implement whatever bits you need that are otherwise inconvenient to implement in what ops we have now. (There may not be any, which is fine) 2) We have whatever support parrot assembly routines you might need. (Library code for the interpreter and whatnot) 3) We have code, written either in C or parrot assembly, that can turn a z-machine file into parrot bytecode, parrot assembly, or IMCC source. (This code should rely only on ANSI C89, the C89 libraries, and/or the parrot library routines, and shouldn't do any I/O) 4) We have code that can definitively identify a file as z-code. (This may be the fact that there's a -b:zcode switch immediately before it) What we do then is weld this all together, and it then gives us the ability to dynamically load up and run z-code files. The flow will be that parrot opens the bytecode file and tries to identify it. Using the code in #4, it identifies it as z-code, and then hands it to the code for #3 (which is a parrot bytecode loader). #3 translates it to parrot bytecode (directly or indirectly) including the support code from #2 (if there is some) and hands it to the interpreter to execute. The interpreter loads up the opcode library from #1 if it needs to, and goes. 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,
parrotZ license issues (was Re: Parrot Z-machine)
Sigh. My plan in starting this discussion was not to talk about licenses. But it sounds like it's safer not to use Winfrotz if we don't have to. I note that Games::Rezrov is same terms as Perl itself license. However, in his effort to make Rezrov run fast, the author (by his own admission) obfuscated the code. In addition, I may want to copy some pieces of the C code wholesale for implementing certain opcodes, so it'll be a lot easier to have stealable C code than translating obfuscated Perl back into C. Jzip, meanwhile, says: Copyright (c) 2000 John D. Holder. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. To my untrained eyes, that sounds safer, since it appears to be less restrictive than either GPL or Artistic. Now let's get this license stuff out of the way so I can get to actual coding! -Amir p.s. re the email subject: For now, I'm calling the Parrot Z-machine project parrotZ. It's simple, it expresses that it's Z-machine in Parrot, and it even rhymes with frotz if you pronounce it right. It might or might not stand for parrotZ: A Register-based Runtime Of The Z-machine. And as you know, coming up with a good name is half the battle in finishing a tough project. Well, maybe half a percent of the battle. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot Z-machine
Amir Karger wrote: A couple more questions on the coding front: (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. Hi, I have the same question for my 'GNU m4' port to Parrot and Perl5, http://www.schmalhofer.info/schmalhofer/bernhard/projects/m4/. In the FAQ I found following: # License compatibility. Parrot has an odd license -- it currently uses the same license as Perl 5, which is the disjunction of the GNU GPL and the Artistic License, which can be written (Artistic|GPL) for short. Thus, Parrot's license is compatible with the GNU GPL, which means you can combine Parrot with GPL'ed code. Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. This is the way I understand it: i. I can take GPLed code and derive MyLanguage from it. ii. MyLanguage is still under GPL iii. MyLanguage can become part of the Parrot core or be distributed with Parrot Did I understand that correctly? CU, Bernhard -- * Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel:+49 89 89 55 74 - 839 Fax:+49 89 89 55 74 - 25 PGP:https://ssl.biomax.de/pgp/ Email: mailto:[EMAIL PROTECTED] Web:http://www.biomax.de *
Re: Parrot Z-machine
Amir Karger [EMAIL PROTECTED] wrote: A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. You should target PIR. PIR is native parrot. -Amir leo
Re: Parrot Z-machine
On Wed, 3 Sep 2003, Bernhard Schmalhofer wrote: Amir Karger wrote: A couple more questions on the coding front: (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. Hi, I have the same question for my 'GNU m4' port to Parrot and Perl5, Here's the scoop. To have it as part of core parrot (i.e. part of the sources in the base source directory and some of the subdirectories, *not* including ICU and the languages dir) it must be GPLAL. That means no pure GPL code can go in. Anything that is built so it is dynamically loaded can be whatever license it wants, so long as it doesn't force a license on Parrot. Other stuff, like ICU, may be statically linked in if doing so doesn't put a license on parrot's sources, as parrot's source license doesn't leak out. (Which makes us not quite pure GPLAL, I think, and I expect someone'll be really cranky with us because of it somewhere) Basically if we dynamically link you in, you're fine. We can even (I think) distribute it as part of the core as long as it stays explicitly separate, though I'd rather not as it'd inadvertently burn someone who builds an all-static parrot (as the resulting executable would be undistributable). This is the way I understand it: i. I can take GPLed code and derive MyLanguage from it. ii. MyLanguage is still under GPL iii. MyLanguage can become part of the Parrot core or be distributed with Parrot Yes, yes, and no, respectively. All core code must have the same license--no part can have a more restrictive license as that makes rather a lot of trouble. Dan
Fwd: Re: Parrot Z-machine
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
Re: Parrot Z-machine
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.] [Also, apologies if this is a repost. I think I sent this only to Nicholas.] --- 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
Re: Parrot Z-machine
A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Parrot Z-machine
Amir Karger [EMAIL PROTECTED] wrote: I got my fifteen bytes of fame in the P6 summary ... Geewhillikins ... But you can always get more: Convert it into Unicode (~: _VL_ But how can we do it if we don't know what it is? Why, blame it all, we've GOT to do it. Don't I tell you it's in the books? Do you want to go to doing different from what's in the books, and get things all muddled up?
Re: Parrot Z-machine
On Tuesday 02 September 2003 13:09, Amir Karger wrote: A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. So I take it the goal is to to teach parrot to understand z-machine opcodes, rather than simply writing a z-machine interpreter that runs on parrot, or rewriting inform to compile to parrot? I'm sure it's much harder that way (especially since I'm sure someone's going to follow the dotGnu lead and implement C for parrot before we're all said and done and you could just recompile one of the more portable z-machine emulators!), but you'd certainly get mad geek respect. And since there's already a scheme implementation for z-code, you'd kill two birds with one - er, parrot. Zellyn
Re: Parrot Z-machine
Zellyn Hunter writes: On Tuesday 02 September 2003 13:09, Amir Karger wrote: A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. So I take it the goal is to to teach parrot to understand z-machine opcodes, rather than simply writing a z-machine interpreter that runs on parrot, or rewriting inform to compile to parrot? I doubt it. 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. And perhaps, once dynamic opcode loading is ready, those sub calls can turn into real ops for speed. But that's not important at the moment: the important thing (well, as important as z-machine can be :-) is to get the translator working. Luke I'm sure it's much harder that way (especially since I'm sure someone's going to follow the dotGnu lead and implement C for parrot before we're all said and done and you could just recompile one of the more portable z-machine emulators!), but you'd certainly get mad geek respect. And since there's already a scheme implementation for z-code, you'd kill two birds with one - er, parrot. Zellyn
Re: Parrot Z-machine
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. - 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) 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) 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. 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) - 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 - 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. How familiar are you with Z-code? About all that I know (and I may be wrong) is that it fits in a virtual machine with 128K total memory, that it has continuations (which we now have), and that the Hitch-Hiker's Guide to the Galaxy adventure game was written in it. Is the virtual machine stack based, or register based? (I guess from your next paragraph that it's stack based) 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? - 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. 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. Nicholas Clark
Re: Parrot Z-machine
Nicholas Clark [EMAIL PROTECTED] wrote: 2: dynamic bytecode conversion (This is the point where someone tells me that dynamic opcode loading now works) No it doesn't. Albeit I have posted a proof of concept standalone program months ago. Nicholas Clark leo
Parrot Z-machine
Hi. Hugely newbie at Parroting, but think it's the coolest. So I was bummed to see that Befunge and BASIC had already been parroted. (And Clinton Pierce even ported QuickBasic, which makes my Language::Basic completely useless. Argh!) Then I thought, What about Z-machine?! I was surprised to see that it hadn't been ported, and even more surprised when I saw that Dan et al. really wanted to port it but hadn't. So: - Is it not being ported because of a lack of tuits, or because it's extremely hard? - 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? - 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 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. - What the heck am I actually supposed to do? I read plenty of FMs but I'm sure I could still use plenty of guidance. As you can see, I'm totally clueless, but I'm a fan of Parrot, Perl, and Z, so it would be a lot of fun (if mostly useless) to get them working together. With some helpful hints and lots of free time (ha!) I might actually be able to contribute some. -Amir Karger __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
