Re: parrot stack and Z-machine
Luke Palmer [EMAIL PROTECTED] wrote: Maybe continuations aren't so hard to serialize after all (well, excluding things like open filehandles and such). What's the status on the serialization subsystem? *nobody* did answer my summary of different schemes. Luke leo
LANGUAGES.STATUS also for languages not in the tree?
Hi, Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? If people agree that it's a good idea I would like to submit the following three liner: OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: LANGUAGES.STATUS also for languages not in the tree?
If anyone has anything else, I have a page for this on the wiki. What's not in the Parrot distribution? http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotExtrasTOC On Wednesday, Oct 8, 2003, at 11:38 Europe/Berlin, Jos Visser wrote: Hi, Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? If people agree that it's a good idea I would like to submit the following three liner: --- - OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal --- - ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: Binary MMD vtable fucntions are in
Dan Sugalski [EMAIL PROTECTED] wrote: ... (More bizarrely, it's actually *faster* to use Integer PMCs, which do MMD, than it is to use PerlInt PMCs, which don't do MMD. Go figure :) I don't have that here (Athlon). They are equally fast. PerlInts have some overhead due to possible type morphing, though. I'll see about getting some docs into the system so this stuff is actually usable. That would be really necessary. I've some troubles to follow the flow of execution with MMD and how all these methods play together. One thing that the current MMD system does *not* do is inherited methods. PerlInt isa perlscalar isa scalar, but adding a MMD method on a scalar doesn't do anything for PerlInts. That needs to be addressed. I've put in vtable-isa() sou you could do something like: forall p (pmcs) if p-isa(SELF-name) p-type != SELF-type add_mmd_meth(p) Dan leo
Re: You too can direct the Attack of the Unicode Monster!
On Tue, 7 Oct 2003, Robert Spier wrote: Also, I'm working on OS X, so there is the library loading issue to be solved too. 10.3 should make this easier, as it has dlopen emulation. (While not necessarily the perfect long-term solution, it at least lets you get things done.) I've got about half that actually done--it's not too tough, but it's annoying, and unfortunately I've just not had the time with the iBook to get it done. (And we're going to need it as it'll be quite a while before everyone's moved to 10.3) Fink's dlopen also does this but, again, we're trying not to count on that either. Dan
[off-list] Re: LANGUAGES.STATUS also for languages not in the tree?
Hi Jos, Jos Visser writes: Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? Yeah, that's English. Mightn't is an archaic word which is sometimes fun to use. Saying it be is using the subjunctive mood in to be, also seldom used, but you use it correctly here. I just learned about the English subjunctive a little while ago; it has greatly improved my understanding of those wierd constructs involving might and lest. Luke If people agree that it's a good idea I would like to submit the following three liner: OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: [off-list] Re: LANGUAGES.STATUS also for languages not in the tree?
Luke Palmer writes: Hi Jos, Jos Visser writes: Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? Yeah, that's English. Mightn't is an archaic word which is sometimes fun to use. Saying it be is using the subjunctive mood in to be, also seldom used, but you use it correctly here. I just learned about the English subjunctive a little while ago; it has greatly improved my understanding of those wierd constructs involving might and lest. There it goes again! That was *supposed* to be off-list! Well, now the entirety of the internals list can learn about English grammar. Hoo-ray. [ ]Luke If people agree that it's a good idea I would like to submit the following three liner: OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: [off-list] Re: LANGUAGES.STATUS also for languages not in the tree?
On Wed, 8 Oct 2003, Luke Palmer wrote: Luke Palmer writes: Hi Jos, Jos Visser writes: Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? Yeah, that's English. Mightn't is an archaic word which is sometimes fun to use. Saying it be is using the subjunctive mood in to be, also seldom used, but you use it correctly here. I just learned about the English subjunctive a little while ago; it has greatly improved my understanding of those wierd constructs involving might and lest. There it goes again! That was *supposed* to be off-list! Well, now the entirety of the internals list can learn about English grammar. Hoo-ray. You mean American Grammar. I'm pretty sure it's not at all archaic English Grammar Dan
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
References ...
... are autogenrated sice some time. They delegete all but a few methods to the refered PMC. [1] But there are some pieces missing IMHO: There is no means to get at the type of what the Ref refers too. And we can't dereference the ref. I'm thinking of 2 new ops: deref Px, Py# set Px to what Ref Py refers to ref S0, Py # := typeof S0, Py-referee ref I0, Py # := typeof I0, Py-referee The deref opocde could call vtable-get_pmc, which isn't covered by any opcode yet (assign does a set_pmc - but we don't have the opposite). This could be also useful for Keys. We can do: new P0, .Key new P1, .PerlString set P1, key assign P0, P1 But there is no opcode to get the PerlString out of the key. Comments welcome, leo [1] new P1, .PerlString set P1, 42 new P0, .Ref, P1 print P0 print \n inc P1 # or inc PO print P0 print \n typeof S0, P0 print S0 print \n typeof S0, P1 print S0 print \n end 42 43 Ref PerlInt
Re: Binary MMD vtable fucntions are in
On Wed, 8 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: ... (More bizarrely, it's actually *faster* to use Integer PMCs, which do MMD, than it is to use PerlInt PMCs, which don't do MMD. Go figure :) I don't have that here (Athlon). They are equally fast. PerlInts have some overhead due to possible type morphing, though. Hrm. This system's showing the PerlInt at about 25% slower for a tight division loop, though that's the most expensive case) I'll see about getting some docs into the system so this stuff is actually usable. That would be really necessary. I've some troubles to follow the flow of execution with MMD and how all these methods play together. Prelim docs are in. Dan
Re: References ...
I think if you have the op for dereferencing, you don't need the additional ops for getting the type of the reference. Maybe in a typed VM it would make sense, but in Parrot, everything is a reference to a PMC, and a PMC knows what type it is. At least that is my opinion. I think the deref op makes sense, but not the ref type ops. Just deref it to a P register and use the existing typeof op on it directly. For a ref to a ref to a ref you'd have to do that anyway. -Melvin Leopold Toetsch [EMAIL PROTECTED] 10/08/2003 11:12 AM To: P6I [EMAIL PROTECTED] cc: Subject:References ... ... are autogenrated sice some time. They delegete all but a few methods to the refered PMC. [1] But there are some pieces missing IMHO: There is no means to get at the type of what the Ref refers too. And we can't dereference the ref. I'm thinking of 2 new ops: deref Px, Py# set Px to what Ref Py refers to ref S0, Py # := typeof S0, Py-referee ref I0, Py # := typeof I0, Py-referee The deref opocde could call vtable-get_pmc, which isn't covered by any opcode yet (assign does a set_pmc - but we don't have the opposite). This could be also useful for Keys. We can do: new P0, .Key new P1, .PerlString set P1, key assign P0, P1 But there is no opcode to get the PerlString out of the key. Comments welcome, leo [1] new P1, .PerlString set P1, 42 new P0, .Ref, P1 print P0 print \n inc P1 # or inc PO print P0 print \n typeof S0, P0 print S0 print \n typeof S0, P1 print S0 print \n end 42 43 Ref PerlInt
Re: More interface files
On Tue, Oct 07, 2003 at 03:57:54PM -0400, Dan Sugalski wrote: While I'm having a heck of a time getting anything besides a connection to happen with it... I've checked in library/postgres.pasm. It's an interface to Posgres 7.3's libpq (the C interface to postgres) library. On a vagely related note, is anyone looking into using the header files parsing abilities of ExtUtils::XSBuilder and extending it to generate pasm? Tim.
Howto write a JIT?
Hi there! I´m currently interrested a bit in howto write a just in time compilier (jit). I searched a long time using google, and there are thousands of sites which explain what a JIT stands for, but not who it works. Because of parrot has its own jit written from scratch, maybe you can point me to some useful documentation. (Please dont point me to the source, its hard to understand source when you dont know how the concept works at all) Thanks a lot, Clemens __ Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) - bei der Stiftung Warentest - ein Doppelsieg! http://f.web.de/?mc=021184
Re: Howto write a JIT?
I can point you to the docs: docs/jit.pod There should be an explanation of how it works. Daniel. On Wednesday 08 October 2003 13:16, Clemens Eisserer wrote: Hi there! I´m currently interrested a bit in howto write a just in time compilier (jit). I searched a long time using google, and there are thousands of sites which explain what a JIT stands for, but not who it works. Because of parrot has its own jit written from scratch, maybe you can point me to some useful documentation. (Please dont point me to the source, its hard to understand source when you dont know how the concept works at all) Thanks a lot, Clemens ___ ___ Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) - bei der Stiftung Warentest - ein Doppelsieg! http://f.web.de/?mc=021184
Re: Languages status (attention compiler maintainers)
On Mon, 6 Oct 2003, Melvin Smith wrote: In an attempt to get a handle on what the status is of all the language compilers we have (in various states) I added a file called LANGUAGES.STATUS under parrot/languages Just read the file and it explains itself. Please, if you are the author of one of the compilers and you don't have commit access, mail a 2 line summary of the state of your compiler to someone with commit privs. Python: Mostly working except for classes/exec/import. For licensing reasons, not in parrot's cvs tree. See http://pirate.tangentcode.com/ Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Binary MMD vtable fucntions are in
Dan Sugalski [EMAIL PROTECTED] wrote: On Wed, 8 Oct 2003, Leopold Toetsch wrote: I don't have that here (Athlon). They are equally fast. PerlInts have some overhead due to possible type morphing, though. Hrm. This system's showing the PerlInt at about 25% slower for a tight division loop, though that's the most expensive case) Have it too now. It depends on the values. 10/2 (my original) is same speed, 10/3 gives your oberved 25%. Its due to morphing the result to an PerlNum. BTW: $ time perl -e'$a=10;$b=2; $i=500; $c=$a/$b for 0..$i' real0m3.955s $ parrot -P mmd.imc # 10/3; unoptimized build, Athlon 800 1.507748 2.018662 $ parrot -j mmd.imc 1.319433 1.640584 Prelim docs are in. Thanks. Dan leo :r src/parrot-leo/mmd.imc .sub _main P0 = new Integer P1 = new Integer P2 = new Integer P1 = 10 P2 = 3 I0 = 500 time N0 l1: P0 = P1 / P2 dec I0 if I0 goto l1 time N1 sub N1, N0 print N1 print \n P0 = new PerlInt P1 = new PerlInt P2 = new PerlInt P1 = 10 P2 = 3 I0 = 500 time N0 l2: P0 = P1 / P2 dec I0 if I0 goto l2 time N1 sub N1, N0 print N1 print \n end .end
Re: References ...
Melvin Smith [EMAIL PROTECTED] wrote: I think if you have the op for dereferencing, you don't need the additional ops for getting the type of the reference. Too true, thanks leo
Re: More interface files
On Wed, 8 Oct 2003, Tim Bunce wrote: On Tue, Oct 07, 2003 at 03:57:54PM -0400, Dan Sugalski wrote: While I'm having a heck of a time getting anything besides a connection to happen with it... I've checked in library/postgres.pasm. It's an interface to Posgres 7.3's libpq (the C interface to postgres) library. On a vagely related note, is anyone looking into using the header files parsing abilities of ExtUtils::XSBuilder and extending it to generate pasm? That's a good question. I've been generating the pasm from interface files, and I've been creating the iterface files by hand, which has been less than entirely fun. :) OTOH, given what the headers look like, I'm not sure how much luck any automatic tool'd have with some of these things. (The GNU version of the ncurses file was particularly unpleasant) Dan
Re: More interface files
Tim Bunce wrote: On Tue, Oct 07, 2003 at 03:57:54PM -0400, Dan Sugalski wrote: While I'm having a heck of a time getting anything besides a connection to happen with it... I've checked in library/postgres.pasm. It's an interface to Posgres 7.3's libpq (the C interface to postgres) library. On a vagely related note, is anyone looking into using the header files parsing abilities of ExtUtils::XSBuilder and extending it to generate pasm? Tim. Along the same line, has anybody looked at SWIG, http://www.swig.org, for automatically creating interfaces to Parrot? 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: LANGUAGES.STATUS also for languages not in the tree?
Yes, Dan says we should track all know compilers as well as the last know Parrot version compatibility. I'll assume 0.0.11 for now unless anyone tells me otherwise. -Melvin At 11:38 AM 10/8/2003 +0200, Jos Visser wrote: Hi, Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? If people agree that it's a good idea I would like to submit the following three liner: OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: [off-list] Re: LANGUAGES.STATUS also for languages not in the tree?
On Wed, Oct 08, 2003 at 10:17:32AM -0400, Dan Sugalski wrote: On Wed, 8 Oct 2003, Luke Palmer wrote: There it goes again! That was *supposed* to be off-list! Well, now the entirety of the internals list can learn about English grammar. Hoo-ray. You mean American Grammar. I'm pretty sure it's not at all archaic English Grammar Well I'm a UKian (British/Irish) and it makes sense to me. Actually, thinking about it for a bit, it's a very very Northern Irish phrase. Of course, we would tend to drop the t at the end as well mightn' it be, but that's pure laziness. andrew -- Sagittarius: (Nov. 22 - Dec. 21) They said they'd be right back after those important messages, but the messages weren't all that important and it's been almost 14 years.
