JVM-PIR translator (was: Re: subroutines and python status)
Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... Speaking of adding new projects to languages, I have a partially complete JVM-PIR translator done. It's complete, with the exception of: 1: The two threading ops arent translated 2: I need to translate the core libraries. I'm hoping GNU Classpath will be of some help here. 3: I'm missing some runtime exceptions, which I just havent gotten around to yet. Other than that, its pretty complete. However, the code it generates isn't quite runnable. Pasm seems to be missing a few instructions, specifically add_method and add_attribute instructions. So, I just made them up. As you can imagine, this causes a few errors :) That means that beyond trivial cases, the code is mostly untested. So, would anyone want this in the tree? Or should I wait until it is better tested and documented? You take a look at it at: http://jryan.perlmonk.org/images/jirate.tar.gz Let me know what you think. - Joe
Re: subroutines and python status
- Original Message - From: Melvin Smith [EMAIL PROTECTED] To: Luke Palmer [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 31, 2003 3:33 PM Subject: Re: subroutines and python status At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote: You mind submitting a patch to put this in the languages/pirate directory of the parrot distro? I'd like to stay up to date, and probably do some work (as, I imagine, would others). I'd like to officially complain that pirate is a cooler name than my own cola and I haven't figured out what to do about it yet. :) Actually, I named my little project pirate (s. http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of a dead end already (although I learnt much of it), so I don't mind. Klaas-Jan -Melvin
Re: subroutines and python status
K Stol sent the following bits through the ether: Actually, I named my little project pirate (s. http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of a dead end already (although I learnt much of it), so I don't mind. Quick, we need more parrot jokes... I don't like things becoming dead-ends. How much work do you think it'd be to extend it some more and update it to latest Lua? Would it be worth checking this into parrot CVS? Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Dang this hobby is expensive!
Re: subroutines and python status
- Original Message - From: Leon Brocard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 01, 2003 1:30 AM Subject: Re: subroutines and python status K Stol sent the following bits through the ether: Actually, I named my little project pirate (s. http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of a dead end already (although I learnt much of it), so I don't mind. Quick, we need more parrot jokes... :-) I don't like things becoming dead-ends. How much work do you think it'd be to extend it some more and update it to latest Lua? Well, at some point while writing the code generator, I had 2 problems. 1: I needed some Parrot features that weren't working yet, like events (I need an op to post events or something) so some essential features of the language couldn't be implemented. 2: I misdesigned the code generator; that is, at the point where I couldn't start over, it was too late, the code generator was too big already (it was unmaintainable). But because I had a time schedule, I kept it this way (the product itself wasn't the most important thing, I was writing an undergraduate report for the last semester of my education (for the record: the project served me well, I finished this education)) Would it be worth checking this into parrot CVS? Only if the thing would be working, otherwise it would only be a source of confusion and frustration. Now I'm just thinking very hard to decide if I've got enough spare time to rewrite the code generator Klaas-Jan
Re: subroutines and python status
At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... As would I. If you're willing, Michal, we can check it in and get you CVS repository access. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: subroutines and python status
On Fri, 1 Aug 2003, Dan Sugalski wrote: At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... As would I. If you're willing, Michal, we can check it in and get you CVS repository access. Hey guys, I'd kind of like to keep it where it is - for now, anyway. But I'm *more* than happy to give people access to the repository. I just set up users for you three (I'll send your logins in a second), and if anyone else wants access, just drop me a note. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
Michal Wallace: I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. Is that the right approach? It seems strange to me, but I'm new at this. That seems to be the way to do it, speaking as someone who's working on a Perl 5-to-PIL converter (using the B optree-introspection modules). The problem here is that .sub has meanings beyond just here's a subroutine. .sub is actually a compilation unit, which complicates things terribly. You *could* just use branches and labels to create a new sub without actually making a new compilation unit: .sub main ... branch mysub_after mysub: ... ret mysub_after: ... .end But that makes imcc run slower, so I don't recommend it. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker
Re: subroutines and python status
Michal Wallace wrote: Hey all, What seems natural to me is to define subroutines in the middle of the code as I walk the parse tree: You can do that: .sub __main__ bsr _main end .end .sub _main .sub _f print :)\n ret .end .sub _g print ;-)\n ret .end bsr _f bsr _g ret .end So you have just to emit code, to call your real main at the beginning. You could also have a look at docs/calling_conventions.pod, which currently is being implemented. But if you have your code generation for subs/params/return values in one place, its for sure not complicated to switch calling conventions later. Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: Wow. Sincerely, Michal J Wallace leo
Re: subroutines and python status
Michal Wallace [EMAIL PROTECTED] wrote: .sub __start__ call __main__ .end .sub __main__ .sub _f print :) ret .end $I0 = addr _f print $I0 end .end That prints :), followed by the address, No, can't imagine that: $ parrot -o- pirate.imc __start__: bsr __main__ _f: print :) ret __main__: set_addr I16, _f print I16 end leo
Re: subroutines and python status
Hey all, I'm trying to get functions working in python, and I'm not sure the best way to do this. What seems natural to me is to define subroutines in the middle of the code as I walk the parse tree: .sub __main__ goto endsub .sub _f print :(\n ret .end endsub: $I0 = addr _f end .end But of course, this prints a sad face. :/ I've read imcc/docs/parsing.pod, so I know why it does this... But what's the alternative? I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. Is that the right approach? It seems strange to me, but I'm new at this. I think your approach may be fine. You can store them in a list and dump them at the cost of a little extra memory (not a concern at this point), but you can also put them inline, so long as you have something like this at the beginning of the file: .sub __START__ call __main__ .end So it emits that code right away, because it's the first compilation unit imcc sees. --- Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: - lists, strings, ints - assignment and multi-assignment ( x,y=1,2 ) - while, for, if/elif/else, break, continue - math operations (+, -, *, /, %) - boolean logic (and, or, not) - comparison operators Very Cool. It now runs amk's euclid.py perfectly now. Do we have a way to compare the speed vs python? :) We just modify it to repeat 100,000 times or so, and compare that way. Which I did. Parrot comes in about 3x slower than python on euclid. From looking at the imcc code, though, I think it could be much much better. One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? In any case, great work! Luke Also, I wrote a pretty-printer for the lists in parrot, and you can call it (and presumably other parrot subs) directly from python code: if 1 2: _pyprint(one is greater than two...) print neat,huh? If I could get this subroutine stuff figured out, you could call functions written in python, too. :) http://sixthdev.versionhost.com/viewcvs.cgi/pirate/ Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
On Thu, 31 Jul 2003, Leopold Toetsch wrote: You can do that: .sub __main__ bsr _main end .end .sub _main ... So you have just to emit code, to call your real main at the beginning. Well that worked, and even let me get rid of the endsub label: .sub __start__ call __main__ .end .sub __main__ .sub _f print :) ret .end $I0 = addr _f print $I0 end .end That prints :), followed by the address, which is what I wnat. I can't seem to duplicate the problem I was having now, but somehow last night, if I commented out the addr line, the _f sub wouldn't run. In other words, it was like the addr call was actually invoking the routine. Maybe I was just tired. :) You could also have a look at docs/calling_conventions.pod, which currently is being implemented. Thanks. I hadn't seen the pdd version. I was going off the other version in imcc/docs [ in pirate, not in this example :) ] Incidentally, I spent all day working on pirate, and it now generates (and runs!) code for a bunch of python structures: Wow. Actually, between imcc and the python compiler module, it's not nearly as hard as I thought it would be. So far, I think the parrot version is actually a lot simpler than the python compiler, just because imcc is doing so much of the work. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
On Thu, 31 Jul 2003, Brent Royal-Gordon wrote: Michal Wallace: I can store all my subroutine definitions in a list or something and then dump them out after the __main__ routine. That seems to be the way to do it, speaking as someone who's working on a Perl 5-to-PIL converter (using the B optree-introspection modules). I think I'm going to go ahead and take this approach. Thanks! :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
On 31 Jul 2003, Luke Palmer wrote: It now runs amk's euclid.py perfectly now. Do we have a way to compare the speed vs python? :) We just modify it to repeat 100,000 times or so, and compare that way. Oh, duh. :) Which I did. Parrot comes in about 3x slower than python on euclid. From looking at the imcc code, though, I think it could be much much better. No doubt. One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? Because I didn't read the docs that said PerlNum means float. :) I'll switch it to PerlInt (or maybe int?) later... It's also using far more temporary variables than it needs. Right now I'm thinking that no matter how complicated the expression, it really only needs two extra registers: the result and a temporary variable, because all the operators are either unary or binary... I might try that after I get functions and classes working. In any case, great work! :) thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
One of my questions is, why do you make so many PerlNums when there isn't a trace of a floating point number to be found...? Because I didn't read the docs that said PerlNum means float. :) I'll switch it to PerlInt (or maybe int?) later... Yeah, all your auxillary data; i.e. the flags you check for control flow, c. should be int registers. Python ints should still probably be pmcs. It's also using far more temporary variables than it needs. Right now I'm thinking that no matter how complicated the expression, it really only needs two extra registers: the result and a temporary variable, because all the operators are either unary or binary... I might try that after I get functions and classes working. Indeed. Functionality is the most important thing at the moment; we can worry about speed later. You mind submitting a patch to put this in the languages/pirate directory of the parrot distro? I'd like to stay up to date, and probably do some work (as, I imagine, would others). Luke In any case, great work! :) thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: subroutines and python status
Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... Luke leo
Re: subroutines and python status
At 02:54 PM 7/31/2003 -0400, Michal Wallace wrote: Actually, between imcc and the python compiler module, it's not nearly as hard as I thought it would be. So far, I think the parrot version is actually a lot simpler than the python compiler, just because imcc is doing so much of the work. Leo and I (and the rest of us) like to hear comments like this that actually validate the work put into the tools. Although they have a long way to go, its a heck of a lot nicer than this time a year ago. Thanks again, -Melvin
Re: subroutines and python status
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote: You mind submitting a patch to put this in the languages/pirate directory of the parrot distro? I'd like to stay up to date, and probably do some work (as, I imagine, would others). I'd like to officially complain that pirate is a cooler name than my own cola and I haven't figured out what to do about it yet. :) -Melvin
