At 11:17 AM +0200 5/24/02, Sebastian Bergmann wrote:
> Hello there!
>
> I'm currently preparing an article on Parrot for a German magazine.
Cool. Can we have a URL when it's done? (An english translation'd be
keen too, but there's always BabelFish to mangle the heck out of it)
> While describing the architecture of Parrot as not being "only" the
> Runtime component for Perl 6, but also a Software CPU / Virtual
> Machine for other languages (BASIC, COLA, ...), it came to me that this
> is more or less what .Net (and the Mono project, as far as Open Source
> is concerned) is about: Compiling different languages to a common
> bytecode for execution by a common Virtual Machine.
>
> It'd be great if you could comment of different goals, etc. between
> Parrot and the .Net concept.
Well, you've gotten some answers from some of the contributors. Here
are a few of mine.
Firstly, .Net wasn't really an option when I started in on the design
back in the summer of 2000. I don't remember if there was any noise
at all about it then--I don't really remember any until some time in
2001. That made not choosing .Net pretty simple, since it just wasn't
there when I started. It's really not had much influence on Parrot's
design, either. (Neither, honestly, has the JVM)
I can't really speak to the goals for either .NET or Java's JVM.
That's something you'll need to talk to the .NET and JVM folks about.
(It'd be interesting to get together with them all in a room and talk
this stuff over someday) What I can do, though, is talk about the
underpinnings of Parrot.
Parrot's design is strongly influenced by hardware. It owes as much
to the VAX and 68000 CPU chips as any piece of software, something I
did on purpose. There's a lot of literature and research available on
optimizing for a register-based system which we can leverage, and
being more like the hardware we're running on lessens the 'impedance
mismatch' you can get when you design for your software rather than
your hardware.
The design also assumes the lack of systematic, mid-level,
development teams. Available talent is a hit-or-miss thing. We've
been pretty lucky so far--Daniel Grunblatt with his JIT work, for
example--but I'm trying not to count on that. It makes things kind of
interesting, and it's one of the reasons I'm trying to get design
documents and solid walls built between segments of the interpreter.
I've been trying to keep the end result in mind, not what's easy now.
The register architecture, for example, is more difficult to write a
compiler for, but there's more opportunity for optimization in the
long run. I'm willing to leave things in a less than optimal state at
the moment if it can be fixed without breaking things and there's a
reasonable chance to get a good win later on.
Finally, whenever there's a choice that will allow more flexibility
in the future, we take it if it won't impact performance, or if the
impact is justified by the flexibility win. This covers things like
using vtables for variables, or the loadable opcode libraries, or
providing continuation support in the core.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
