Zcode interpreter release
Hi! I adopted the Zcode interpreter that leo posted in February. Luckily, he did the hard parts. I added some opcodes, README/CHANGES/TODO files, and testing, and, finally, did my first Parrot checkin. How exciting! There's much much more to do - 41 more opcodes just for version 3 of the Z-machine. And then of course there's Dan's Holy Grail of making the Zops into native parrot ops... The only bad news is there's something wrong with my make test. The following work: - perl t/harness in languages/Zcode - perl t/whatever.t in languages/Zcode - make test in languages/Zcode - make Zcode.test in languages/ However, I couldn't put Zcode into languages/testall. It breaks when it tries to run my tests. I managed to narrow this down to a very weird Perl behavior I don't understand at all: testportal:~mkdir z testportal:~cd z testportal:~/zmkdir y testportal:~/ztouch y/foo testportal:~/zperl -we 'system(cd y)' Can't exec cd: No such file or directory at -e line 1. testportal:~/zperl -we 'system(cd y ls)' foo Because of the above, my tests break when they do: run_command($parrot z3.pir $test_file, CD=Zcode (I need to cd into Zcode so that I can run z3.pir and find the z*.pir files it depends on.) Any thoughts on why this is happening? -Amir Karger
Re: Zcode interpreter release
On 8/23/05, I wrote: I adopted the Zcode interpreter that leo posted in February. The only bad news is there's something wrong with my make test. I managed to narrow this down to a very weird Perl behavior I don't understand at all: testportal:~mkdir z testportal:~cd z testportal:~/zmkdir y testportal:~/ztouch y/foo testportal:~/zperl -we 'system(cd y)' Can't exec cd: No such file or directory at -e line 1. testportal:~/zperl -we 'system(cd y ls)' foo Several people pointed out that I didn't perldoc -f system. Sorry! Btw, even after reading the docs, I still don't understand why Perl would pass a cd command to a piece of the shell that can't understand it. Granted, I shouldn't do it anyway, because then Perl will exit the shell it created for the system() and my cd will be useless. I changed my tests to chdir to the right directory before doing anything, and now it seems to work no matter where you run it. So now, v0.2 can officially be released. Hooray! -Amir
parrot -I?
If I say perl Zcode/t/harness I want it to run parrot Zcode/z3.imc testfile.z3. My current problem is that z3.imc includes a file z3main.imc. So the above command breaks because z3.imc can't find the include file. If this were Perl, I would just say Perl-IZcode Zcode/z3.imc testfile.z3. But I can't seem to do that in Parrot. Does parrot really look only in the lib directory and nowhere else for .imc includes? Or am I doing this incorrectly? -Amir
Re: [perl #36842] interpreter.c breaks at line 277
I ran with --without-icu but I never typed in --cgoto=0. Anyway, make realclean did fix the problem. When do I need to rerun configure and/or make clean/realclean? (I guess when it breaks is an OK answer.) Btw, if I want to rerun configure with the same -- options, is there a trivial way to do that? Thanks, -Amir On 8/9/05, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (via RT) wrote: I was able to compile parrot HEAD a few days ago with no trouble. Today I tried (three times, several hours apart) after svn update, and it broke each time with the below error. src/interpreter.c: In function `get_op_lib_init': src/interpreter.c:277: `Parrot_DynOp_core_cgp_0_2_3' undeclared (first use in t is function) Looks like you configured with --cgoto=0 but didn't do a 'make realclean'. leo
In languages/, make test bc dies because I don't have antlr
Running make test in languages dies because make bc.test tries to run antlr, and I don't have antlr. Should configure test for its existence or something? -Amir
Re: What's needed for a new languages/t/*?
[Argh! Posted to google groups again!] Bernhard Schmalhofer wrote: Amir Karger schrieb: I have a test script that runs 85 tests (and will run many more once I write more opcodes. So if all I want to do is, essentially, perl -e 'chdir languages/Z and system(parrot z3.imc t/test.z3)' and let the script print out a bunch of (not )?ok's for Test::Harness to read, what should I do in my t directory? AFAIK there are no strict testing requirements for language implementations. I think that the most important thing is to try to be nice. Or, as a wise comedian once said, Be Excellent to each other. There are three things that I want to suggest: i. Z/t/z3.t should be a Perl5 script that prints output in Test Anything Protcol. So put your 'system(parrot z3.imc t/test.z3)' into Z/t/z3.t Done (ish). ii. Z/t/harness should behave like most other 't/harness'. It executes the t/*.t files and prints a harness report of the output. I think I can copy someone else's pretty much verbatim iii. 'Z/t/harness --files' returns the list of test files. Looks like I can perl -pe 's/urm/Zcode/' urm/t/harness Zcode/t/harness You could also try to put 'Z' into @unified_testable_languages of 'languages/testall' and add support for Z in 'config/gen/makefiles/languages.in'. Calling 'make languages-test' could then test 'Z' along the other languages. I think I'll try that once I can get make test to work. (Also, how do I make sure it'll find parrot before make install has been done?) I would expect that an install parrot is only found when the executable 'parrot' is in $PATH. Before installation I usually use $FindBin::Bin for building up the relevant paths. OK. I see others say PARROT=../../parrot Thanks, -Amir
What's needed for a new languages/t/*?
I'm about to commit an updated version of leo's Z-code-to-PIR translator. I'm wondering what I should do about t. I have a test script that runs 85 tests (and will run many more once I write more opcodes. Luckily, I developed it already when I was doing plotz). I could easily modify it to output ok n and not ok with a comment about what went wrong. However, because it's a big Z-code file, it would be hard to write a Test::Simple script that calls ok() 85 times. In quickly looking at languages/* I saw that there seem to be a number of different ways of doing tests, some of which use Parrot::Test. So if all I want to do is, essentially, perl -e 'chdir languages/Z and system(parrot z3.imc t/test.z3)' and let the script print out a bunch of (not )?ok's for Test::Harness to read, what should I do in my t directory? (Also, how do I make sure it'll find parrot before make install has been done?) I didn't see a languages.pod with this info, but maybe I just wasn't looking in the right place. -Amir Karger
Reading a large data structure
Is there a way to declare an array of, say, 300 strings in PIR other than arr = 300 arr[0] = hi arr[1] = there arr[2] = my ... arr[298] = very arr[299] = tired Same question with a hash of hashes or whatever. -Amir
Does it cost anything to use a big pmc everywhere?
[Accidentally posted to Google Groups first] I'm finally doing some work on Leo's PIR Z-machine interpreter. (I've added about 15 opcodes to the 10 or so he started with. Luckily, he did a lot of the infrastructure stuff that scared me as a PIR newbie. The tester I wrote while developing Plotz passes 85 tests. Mostly.) The compiler translates Z-code into PIR, then compiles and runs it. The image of the Z-file (where the Z-machine stores its global variables and other useful things) is stored in a global called Image. So if you need to access one of the Z-machine's global variables, you emit code like: .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) where the last line is a macro that pulls the global variable out of the Z-machine memory. But Leo was smart and, while translating, says to only load image (i.e. to only output the first two lines) once per Z-code subroutine. Now here's the problem. My Z-code emitted code like this: if $I17 == 3 goto L1234 .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) L1234: print yes, blah .GET_WORD($I182 , image, 692) If $I17==3, then when we get to the second GET_WORD we exit with an error because we don't know what image is. So I think to avoid these problems I need to declare image at the top of every Z-code sub. My question is, is there any cost associated with always declaring this array holding 50-500K ints, other than having one P register always full? Since everything else in the translated code is integers strings I'm not really worried about filling my P registers. The only other option I can think of is keeping track of how my scopes are nesting while translating, which sounds like a disaster. This is what I get for trying to develop in PIR after ignoring the mailing list for 6 months and not reading the basic docs. Thanks, -Amir Karger It's better to write me at [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
RE: [perl #36620] Bug in editor/ops2vim.pl
Oops, you'r right. perldoc perlop says ARGV is a nickname for , but it's
not as magical.
-Original Message-
From: jerry gay via RT [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 21, 2005 2:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [perl #36620] Bug in editor/ops2vim.pl
actually, it should be
while() {
applied, thanks.
On 7/21/05, via RT Amir Karger
[EMAIL PROTECTED] wrote:
# New Ticket Created by Amir Karger
# Please include the string: [perl #36620]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36620
editor/ops2vim.pl says:
while (@ARGV) {
AFAIK, that should be
while (ARGV) {
I'm running perl 5.8.6. Using ops2vim.pl that came with
parrot-0.2.2, I got
just one (broken) line out of the script. Removing the @
makes it work fine.
-Amir Karger
Language::Zcode - Translates Z-code to Perl (and, kinda maybe, to PIR)
Just a year after my last status report, I've uploaded Language::Zcode to CPAN. It's a Perl module that lets you work with Z-code files. (For Z-newbies: Z-code is the machine language for the Z-machine, a virtual machine used for the Infocom text adventure games, among others.) Language::Zcode v0.8 includes a program called plotz, which will translate a Z-code file to another language. (My brother, The Professor, claims that this is technically compiling.) Current target languages include: - Perl: full (?) z3 support, meaning you can translate and run most of the Infocom games (and some more modern ones) - XML: create an XML tree with XML::Simple. I've started an XSL file to display the Z-code nicely, but really don't know what I'm doing. - PIR (aha!): I just started working on this. Lame support for 25 or so opcodes. But I can get a working Hello, World. Mostly. For those who don't remember, Dan Sugalski started this Fool's Errand (http://www.fools-errand.com/) by suggesting that the Parrot VM could be tricked into thinking it's a Z-machine. When I screamed for help, folks suggested a staged plan: 1. Translate Z-code to Perl 2. Translate Z-code to PIR 2a. Write some Z-code opcodes in C, to be called by the PIR (step 2). 3. Dynamically load a Z-code opcode library (2a) into Parrot, and run a (non-translated, or just a teensy-bit translated) Z-code file as if it's Parrot bytecode. aka the Z-machine running natively on Parrot. 4. Profit? I've made much progress on step 1, and a tiny bit on step 2. Still gibbering with fear about steps 2a 3. Depending on how brave I am in upcoming months (and how much time my kids give me), I'll be upgrading step #1 or getting serious about #2. If the latter, I'll probably be asking lots of questions about PIR best practices. So be nice. Comments, advice, help will be much appreciated. -Amir Karger ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
[OT] Plotz status
(There's a bit about Parrot at the end.) Recently seen on Amir's monitor (pardon the Windows-ness): = C:\Amir\Perl\Parrot\ParrotZperl plotz.pl story\minizork.z3 Unimplemented opcode read at 15520 Unimplemented opcode restart at 22205 Unimplemented opcode restore at 22217 Unimplemented opcode save at 22367 Unimplemented opcode input_stream at 22821 Unimplemented opcode output_stream at 22859 C:\Amir\Perl\Parrot\ParrotZperl story\minizork.pl MINI-ZORK I: The Great Underground Empire Copyright (c) 1988 Infocom, Inc. All rights reserved. ZORK is a registered trademark of Infocom, Inc. Release 34 / Serial number 871124 West of House You are standing in an open field west of a white house, with a boarded front do or. You could circle the house to the north or south. There is a small mailbox here. Undefined subroutine main::unimplemented_read called at story\minizork.pl line 513. = !!! The point here is that: (1) I'm able to translate a Z-code file into a Perl file (2) I'm able to implement enough stuff to get minizork (a smaller, publicly released Zork I) started, (almost) correctly printing out some stuff, up until the famed '' prompt. (3) There's still a few crucial opcodes I haven't implemented, like the one that reads in and parses a command. I'm excited enough about #1 and #2 that #3 doesn't depress me too much. As you can see from the plotz.pl printout, what I still have left to do is game state and I/O. Which unfortunately happen to be the hard parts, but it turns out I can steal a lot of them from Games::Rezrov. I've implemented some 70 opcodes. Another 6 opcodes gets me minizork. Four more gets me two-thirds of all released Infocom games. Neat! Btw, a quick search on Google Groups tells me I haven't yet mentioned what plotz stands for: Pol(l)y-Lingual Opcode Translation for the Z-machine plotz parses Z-files. It then (in theory) has hooks that allow a coder to write a module that'll output a translation in (almost) whatever language she wants. The plan is that once I get minizork working (which I believe will take me another n weeks, where n is a nybble), I'll start working on PIR output from plotz (which will take another N months, where N is an (unsigned) byte). Then of course I get to start working on the original project behind all of this, which is getting Parrot to run Z-code natively. Of course, by that time, Parrot will probably be running on nanobots in our red blood cells, so you'll be able to run Z-code REALLY natively. -Amir __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: parrot stack and Z-machine
Luke Palmer writes: Amir Karger writes: I realized that I get in trouble when we get to the save/restore commands. Those are supposed to save and restore the call stack, which includes the subroutine addresses all the local variables in the various routines. Am I right in thinking I don't actually have access to that in Perl? (That is, I can't change the call stack at runtime, such that when I return it'll return to a different subroutine than the one that actually called the current routine.) You mean.. in Parrot? In Perl 5, using just the language, no you don't. I was first asking for Perl, because my pre-pre-project project is to translate Z-code into executable Perl. In parrot, however, you do. There is actually no call stack; it's implicit in the cascade of P1 registers. That's why we call it the 'call chain'. I'm obviously going to need to read the parrot sub docs. So the question is, will I be able to write a Parrot opcode that resets the Parrot call stack? And I guess to reset the register stacks too? Otherwise, I won't be able to save/restore games. From disk, right? Yeah. (Well, there's also the undo command, which can be implemented with the same mechanism, only you load save from memory.) No, I don't think that's possible using the basic Parrot mechanisms. That is, in general, a fairly hard thing to do (although, it might be done, considering how people have been talking about serialization recently. In any case, it's not available at the moment). So you could wait until it might be implemented. But I don't recommend that, because then you're counting on the timelyness of open source, which doesn't exist :-). Good call. OTOH, given the rate at which I'm developing, I probably won't get to this for a year anyway. (OK, I'm really hoping that's not true, but we'll see.) Then let's think of some other solutions to the problem. This will be pretty abstract, mind you. Right. I should probably explain a bit about Z-code, because saving the stack in Z is way easier (I think) than with some other languages. For example, I'll point out that EVERYTHING we're saving here is guaranteed to be an integer. No strings, floats, objects, or anything. The Z-machine has an evaluation stack, which is a regular old subroutine-scoped stack that you optionally push pop while you're doing calculations. It's got a program counter, which is also an integer. And it's got a call stack, which is just a stack of call frames. Each frame contains: the PC, the subroutine-scoped local variables (up to 15), and the evaluation stack when you left that particular subroutine (due to calling another sub). The other thing that Z-machine does is store all of its global variables and any data that might change in the program (E.g., is the axe in the living room, in the player's possession, or has it been stolen by the thief?) in dynamic memory, which is 64K of, again, integers. The neat thing about the Z-machine (maybe true of other VM's? But amazingly convenient for troll-filled adventure games) is that you can save the entire game state by saving (1) the call stack and (2) an XOR of the current dynamic memory with the original dynamic memory. Which means that saved games range from maybe 2 to 10 or rarely 20 K max even for bigger, post-Infocom games. Save stores exactly these things, in a rigorously specified format. Restore's job is a bit tougher. It loads the XOR and XORs it with the original dynamic memory. Then it REPLACES the existing call stack with the saved call stack, and goes to the PC at which the game was saved. At whcih point it will act exactly the same as the original game before saving! Brilliant! But it means we need to be able to (a) replace the call stack and (b) jump to an arbitrary address in the game. My first thought is that you can create a call frame object. This object then holds a reference to the current lexical pad, the bytecode address, and a reference to the caller's call frame object. This object would be passed into new functions much in the manner of the return continuations we now pass. To save, you walk up these frames, serializing whatever is there (presuming you know the exact set of possible data types that might be in your lexical pads). Exactly! And that's what I'm going to end up doing in Perl. Requirement (b) above requires me to have no subroutines in my program, but it's still doable. (Will it require the same in Parrot? Maybe.) And the call stack is pretty easy to maintain manually in Perl (especially when I can steal existing code that does it from Games::Rezrov). Because of the explicitness of the bytecode format, it's possible to take this data and re-create the stack out-of-band, and then jump to the proper address. It'd be a lot of work, but possible nonetheless. There are problems with that, however. The biggest one is that it places a lot of restrictions on what kinds of data you're
parrot stack and Z-machine
Still working on the prelude to the preface to the Z-machine running natively on Parrot project, namely translating Z-code into a Perl executable. (My brother, who's a CS professor so he should know, says I'm actually *compiling* it. Compiling bytecode to an interpreted language? Weird!) I'm making some progress, but now I have to deal with the harder opcodes I'd ignored, like I/O and save/restore. (Interesting to hear about Parrot curses, wrt Z-code I/O, btw.) I figured I could just use the Perl subroutine mechanism to emulate Z-machine calls. So I just translate Z-code's call routine arg0 arg1... to routine(arg0, arg1, ...) and ret value becomes return $value. I realized that I get in trouble when we get to the save/restore commands. Those are supposed to save and restore the call stack, which includes the subroutine addresses all the local variables in the various routines. Am I right in thinking I don't actually have access to that in Perl? (That is, I can't change the call stack at runtime, such that when I return it'll return to a different subroutine than the one that actually called the current routine.) In Perl, I can fake it by making my entire program have no subroutines (yuck!) and using gotos and manually storing the call stack. Then I thought, but what do I do about Parrot?, which is supposed to be the whole point of this project. Then I thought that maybe I *do* have access to Parrot's stack! So the question is, will I be able to write a Parrot opcode that resets the Parrot call stack? And I guess to reset the register stacks too? Otherwise, I won't be able to save/restore games. -Amir __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Argh!
Apologies if I'm repeating myself, but I think I accidentally posted my parrotZ status a few days ago using Google groups instead of email. Did noone receive my mail, or was it just too long to read? One of the things I mentioned there is that I would love to have some very simple examples of PIR files. The .imc files generated by perl6 tests look very machine-generated. I'd like to know what good style is (e.g., for calling subroutines -- nci? pcc?) before I completely ignore it in my machine-generated code. On the other hand, I've come up with not one but three great new names for pieces of my project. Anyway, the quick version of the status email is that, using existing C disassemblers my own Perl code, I'm currently translating many of the Z opcodes successfully into Perl (and I've created hooks for translating into arbitrary other languages too -- I'm Lazy!), although admittedly I've left all the hard ones for later. I'll obviously need to work harder if I want to get into the Perl 6 summary again. -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
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
--- 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: Bugs in BASIC interpreter?
--- Leopold Toetsch [EMAIL PROTECTED] wrote: Amir Karger [EMAIL PROTECTED] wrote: [fixes] I'll put in these fixes. Thanks! The bad news is that when I then try to parrot it, Windows throws me an error window saying parrot died. I don't know why. linux SIGSEGVs. The problem is expr.pasm:419 containing a string with 1024 chars in one line. This is one of the known problems of imcc/parrot. There is no official limit on lines, strings or identifier length, while internally its assumed that there is one. This is of course a bug. [proposed long-term solutions snipped] OK, but in the meantime, I replaced line 419 with: set S1, \x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f set S19, \x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f concat S1, S19 set S19, \x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf concat S1, S19 set S19, \xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff concat S1, S19 I'm sure I've broken several sacred Parrot rules by doing this, which I hope you'll tell me about so I can learn the sacred Parrot rules. But it *does* compile and run this way. I believe I've found another bug. All numerical variables have a s/\.?0+$// performed on them whenever their value gets fetched (e.g. when evaluating an expression including the variable name, either to do math or to print). Note the question mark in the above s/// - that's a bug! I believe the problem is in subroutine NTOA (alpha.pasm: 164), which tries to do s/\.0+$//. It seems that in the old days, variables with integer values were stored as 1.000, so NTOATRUNC: got written, but now the value gets truncated somewhere along the line, so then we're trying to remove 0's at the end and then a '.', but we end up just removing zeroes! So I guess the fix is just to remove NTOATRUNC and NTOA_ALMOST entirely. If not, at the least you should jump over them if index(S0, '.') != -1. For example, adding the following lines after line 171 of alpha.pasm fixed the problem as far as I could see: index I1, S0, '.' eq -1, I1, NTOADONE A final bug: line 820 of sampleb.bas should read 820 PRINT 355/113 :) Thanks for reporting Thanks for fixing. -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
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
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
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
