On 12/31/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> 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.
>

Tiny compared to the PowerPC, for example. x86 is characterized by a
small number of registers, assisted by some crazy-fast instructions
for flipping them around. I think that's a fair statement still, yes?

re: concurrency. We're implementing STM in Rubinius, so you'll be able to say:
atomic do
  critical section of code here
end

I'm (personally) amused by being able to use the same 'pseudo-code'
syntax as the papers that introduced the idea of transactional memory.
Heh.