------art_123727_32510452.1167601039761
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 12/31/06, M. Edward (Ed) Borasky <znmeb / cesmail.net> wrote:
>
> >>> And if it's more efficient to
> manage two or three stacks than dozens of registers, I think you want a
> stack machine and not a register machine.
> <<<


You haven't established that it is more efficient. I'm completely
sympathetic to leveraging the strengths of particular hardware platforms as
available, but observe that most mainstream hardware is register-based.
High-quality register-based code is far harder to automatically generate
than stack-based (try it sometime), but you have more potential to squeeze
performance out of the machine by bypassing memory-bus cycles. Again, try it
sometime. It's not easy to do, and I surmise that some of the attractiveness
of the stack-based model comes from its simplicity. And also from the fact
that every register-based piece of hardware is different, so you're leaking
multiple abstractions into VM-level code where it arguably doesn't belong.
Does this make stack-based VMs axiomatically better-suited for dynamic
languages as opposed to languages like Java? I have no idea how to even
approach answering that question.

Concurrency primitives: all of the actual intra-process concurrency features
you mentioned can be implemented straightforwardly, given the availability
of the atomic check-and-set primitive. You mention a lot of things that
don't fall into this realm, and as a former language designer, I think there
is a stylistic tradeoff to be made among them. It may not necessarily make
sense to implement all of them.

------art_123727_32510452.1167601039761--