On Sat, Jul 11, 2009 at 11:03 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
Edward,
Sorry for replying to an introduction email but...
No, I meant for people to comment.
At Fri, 10 Jul 2009 11:34:33 -0700, Edward Cherlin wrote:
o I am also talking with Allison Randal, head of the Parrot project, about various projects. She told me that she would love to have a Squeak for Parrot. (Right now, they only have their toy language Squaak. No relation. ^_^). This means compiling the Smalltalk VM for Parrot. But that means getting a C compiler to generate Parrot assembler. I don't know how far along that project is.
Hmm... Why not compile Smalltalk to Parrot bytecode?
Is there a difference? Actually, I may be wrong. It may be that the C compiler will generate PIR, Pirate Intermediate Representation. But that doesn't matter, since it all ends up as byte code.
If you think it would work better to have Smalltalk translate the Smalltalk VM to PIR rather than to C, that's fine, too. But the PIR compiler includes register optimization, which I don't think you want to rewrite.
But, however, the real strength of Squeak for us has been that the same program runs pixel-identically on various platforms; so that a developer who doesn't want to deal with Linux or Sugar can have reasonable assumptions of his program when developing on other platforms.
Fine. That's what I meant for you to do. Compile the existing C version of the VM, just as for any other processor.
This is because Squeak VM provides all graphics and user input and socket and etc (in addition to garbage collection, concurrency, a meta system). (Yeah, a virtual machine should be a machine just happens to be a virtual one; so not just instruction emulation, it should provide such things).
Parrot doesn't offer such abstraction, as far as I can tell. If we are to provide a such layer, we need to write platform specific implementations for these features (as Squeak VM does) and that would mean that we need to re-do whole a lot of work just to be at the same place.
You are getting ahead of yourself. I said to compile the existing VM. Reimplementing is below, and only if it turns out to make sense.
If this was about implementing the Squeak VM on Flash, that would have made more sense.
After we have a functioning version, we should investigate whether any Smalltalk VM features can be replaced by or integrated with Parrot features. Parrot provides garbage collection, concurrency, hooks for an object class system, and an assortment of other high-level features,
OK, here is where we can consider a rewrite.
and is intended to allow dynamic languages to run unchanged on more than 200 hardware/OS combinations.
Wow. Is there the list of these 200 combinations? I'd be happy to be surprised, but I have a feeling that Squeak VM has a bigger list...
Intended, Yoshiki, not implemented. Current targets are Linux x86 and ARM, Mac x86 and ppc, and Windows x86. Others will be done by whoever wants them badly enough.
The question is not whose is bigger. The question is whether it is worthwhile having an environment in which multiple dynamic languages with or without object class systems can interoperate safely.
-- Yoshiki
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev