On 12/31/06, Wilson Bilkovich <wilsonb / gmail.com> wrote:
 > Doesn't this mapping imply generating platform-specific machine code
> directly from the code that targets your V-ISA?
> To my knowledge, Parrot isn't planning to do this. (Feel free to
> correct me with a link I missed on Google, though.)
>
> That is a big, big job requiring more machine-level expertise than has
> yet arrived in the #rubinius IRC channel. Heh.
>
> That's the basic thrust of my argument against register-based VMs.
> Conceptually, the idea of having 'hard' mappings between virtual
> registers and architected registers is cool. Actually implementing it
> means basically reinventing gcc inside your project. Also, given that
> by far the largest target platform is x86, and it has a tiny number of
> gprs, you're going to be doing a lot of shuffling anyway. Why not let
> a compiler handle that for you, since they spend all day, every day,
> working on making it good at that task?
>
>


Fair enough, but from the small amount of commentary I've seen, I
don't think parrot is going to matter to anyone anyway. From what I
can tell, most people would be happy with a Ruby implementation that
had "better" performance (in most cases that means faster and more
linear with respect to working set size), more modern GC, and native
threads. Very few people are looking for a "better" version of the
language itself, and since that would constitute a fork, it's not
likely to succeed anyway.

Intel chips: why do you say they have a tiny number of gprs's? That
hasn't been true for years, unless your idea of tiny is as big as,
say, the size of the register file on an ultrasparc chip.