Well, I've got the laptop back from repair (for the fourth time) and after two days of getting it in order (It went in with a bad 20G drive with 10.3.4 on it, came back with a 30G drive with 10.2 on it, and my full-system backups turned out to be useless. Important safey tip--rsync is useless for any file with a resource fork, including all OS 9 apps, many (if not all) Carbon apps, and a goodly number of data and system files) I'm finally up and running. It's kind of amazing how many update passes the damned thing needed to go from a stock 10.3 install to latest up-to-date. But that's a rant for another time.
Time's really short here for the piethon challenge. Leo's been working on the back end, and Python::Bytecode is mostly working (I'm running into some issues now, dammit), but I need to leave for Oregon next Thursday, so I've about a week to go with full 'Net access. (And I'll probably be painting for a goodly part of the time between me leaving and OSCON) At least I've got evenings (sort of--the work project's behind) and weekends as my wife and kids are heading out early.
Anyway, enough lame excuses. On to the actual info.
Since people are going to play along at home, and I'm not going to turn down any help, I'm putting the translator program up for fetching. If you want to see what it looks like, the thing's at http://www.sidhe.org/~dan/piethon/translator.pl. No, no rsync or CVS access (no time), and it's not going into the parrot repository since that's a bit much (I may change my mind on this) but you can snag it and thump it to see what, if anything, it does.
The translator itself requires just perl with the Python::Bytecode module installed, so it's pretty low-overhead. It only works (for loose values of works) on Python 2.3 bytecode, but that's fine. We may or may not make it work for earlier versions, but we'll deal with that later.
The current scheme for going from python's stack-based system to parrot's register-based one is somewhat simple, since I'm too pressed for time to make it fancier and faster. (Losing more than a month to @!#$!$ machine problems has been a major pain) The scheme is simple. We turn Parrot PMC registers 18-29 into a temporary stack (with an array in P31 as overflow), and add in support to parrot for that being the case. TOS is P18, with the stack tail held in I31, and we've a few new ops to manipulate the stack, basically a fake push and fake pop op. From then on, all the ops that act on the TOS just act on P18, TOS1 is P19, and standard register manipulation ops go from there. Stack shifts require a memmove, which isn't free, so this isn't without its costs, but it's pretty simple to handle.
I'll start putting together (or, rather, reputting together, since I had one which got lost, but it was pretty wrong anyway) a table of python to parrot op translations for folks to look at and comment on, though it'll be going to the (soon to be renamed) perl6-internals list as well.
Posted by Dan at July 14, 2004 12:01 PM | TrackBack (0)Dan, you have my sympathy regarding your hardware problems. And I hope you win since I'd love to see Python go faster.
I've found that Carbon Copy Cloner plus an external FireWire drive is a really good way to back up my OS X laptop. I haven't yet had to restore using it, but you can boot from the FireWire disk and prove to yourself that it's a functionally identical copy. I went into that in some detail at:
http://www.mondoinfo.com/blog/C182263547/E222265756/index.html
Posted by: Matthew Dixon Cowles at July 14, 2004 01:20 PMrsync with support for resource forks and other HFS+ meta data: http://www.macosxlabs.org/rsyncx/rsyncx.html
Only works with another HFS volume and rsyncx binary (can't send data to plain rsync on non-HFS machine, yet).
Posted by: Andrew Sweger at July 14, 2004 01:22 PM*blink*
You are going to call memmove on virtually every opcode? Even with the fastest opcode dispatch you are going to be treading water with concrete boots on.
Posted by: captain obvious at July 14, 2004 01:34 PMUnfortunately I don't have any spare firewire drives hanging around, and even if I did, when I needed one I didn't have a working disk drive to source from. (Or backlight to actually see what I was doing, depending on which time)
Also, there are very few memmoves generated--besides being relatively clever and not moving memory when the stack's empty, and only moving the actual used part when it's not, the move ops only happen relatively rarely. Many of the ops when translated don't have stack actions, and the bytecode stream's straightforward enough to allow for peeking forward within the basic block to skip it in a lot of cases.
It may turn out to be a bad idea. I'll find out tonight when I get a chance to dig into it more.
Posted by: Dan at July 14, 2004 02:21 PMYesterday, I wandered the net to read everything about the piethon contest. Now, I'll just say: you go, guy! For the sake of Parrot, I hope you win (well and for the sake of your pride, of course).
Posted by: Manuzhai at July 14, 2004 02:22 PM