On 08/21/03 Tom Locke wrote: > Note that I have *absolutely* no opinion on this (I lack the knowledge). > It's just that with Perl, Python, Ruby, the JVM and the CLR all stack based, > Parrot seems out on a limb. That's fine by me -- innovation is not about > following the crowd, but I feel it does warrant stronger justification.
A well-designed register-based interpreter can be faster than a stack-based interpreter (because of the reduced opcode dispatch overhead). Doing a simple JIT for it may be also easier, if you ignore some advanced optimizations. That seems to be the main reason for parrot to go for it. Perl/Python/Ruby don't have (opcode dispatch) speed as their main aim (they use coarse instructions) so they use a stack-based design because it's much simpler. The JVM and the CLR use a stack-based instruction representation, but they are intended for JIT compilation in the end and in that case a register-based representation doesn't buy you anything (and complicates things such as the calling convention). That said, it will be interesting to see how Parrot will turn out to be once it's reasonably feature complete: it may end up providing interesting research results (whether good or bad, we don't know yet:-). > p.s. (and at the risk of being controversial :) Why did Miguel de Icaza say > Parrot was "based on religion"? Was it realted to this issue? Why is he > wrong? See his side of the story at: http://primates.ximian.com/~miguel/activity-log.php (22 July 2003). There are also a few short comments on some blogs. But the main point is: at the end of the day numbers are what count, though anyone is free to assign more weight to different numbers such as: * execution speed (in mini, macro and bogus benchmarks:-) * number of languages that can be reasonably run on the VM * number of langauges that _cannot_ reasonably run on the VM:-) * memory usage overhead * runtime safety features * number of platforms supported * number of developers working on the VM * number of users of (programmers for) the VM So, you can't really say someone is wrong, until you measure at least some of the above quantities and set your priorities for which ones you prefer. Alas, measuring is hard and someone's priorities may not match the priorities of whoever implements/designs the virtual machines:-) I guess some first reasonably good numbers will come out of the Python on Parrot pie-fest: can't wait a year for it, though:-) lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
