On 09/05/01 Nick Ing-Simmons wrote:
> >It's easier to generate code for a stack machine
>
> True, but it is easier to generate FAST code for a register machine.
> A stack machine forces a lot of book-keeping either run-time inc/dec of sp,
> or alternatively compile-time what-is-offset-now stuff. The latter is a real
> pain if you are trying to issue multiple instructions at once.
There is an issue that is at the roots of all these discussions:
should parrot execute also low-level opcodes or not?
We all know from the paper that instruction decoding/dispatch is
a bottleneck in interpreter's execution speed and that it's better to
execute few heavy opcodes than many smaller ones.
The current perl has high-level opcodes and when most of the time
is spent in the opcode implementation it's quite fast (the regex engine
for example). However perl5 falls short when you need to perform integer/fp
operations and subroutine calls.
Now, the proposal for parrot is also to handle low-level opcodes.
This is all well and good and the proposed architecture to handle it
is a register machine. If the register machine is implemented in sw
any talk about issuing multiple instructions at once is moot, it's
not under our control, but of the compiler. If anyone has any
evidence that coding a stack-based virtual machine or a register one
provides for better instructions scheduling in the dispatch code,
please step forward.
I believe that a stack-based machine will have roughly the same
performance when interpreted as a register-based machine, but
it easily allows to take a step further and JIT compile the bytecode
to machine code. If we are going to execute low-level opcodes,
no matter what architecture you choose for the interpreter,
JIT code runs faster:-)
> is a pain.) Explicit stack ops are going to give them indigestion.
> The P-III+ model is that most things are "on the C stack" i.e. offsets
> from the few "base" registers. The hardware then "aliases" those offsets
> into its real registers. I don't think Parrot's register files will give
> it much trouble, but throwing away the right inc/dec-of-pointer ops that
> a stack machine implies will (there are obviously HW special cases for x86's
With the difference that the registers are malloc()ed while the eval
stack in a stack machine is in the actual cpu stack. A good compiler
will put the stack pointer on a register, anyway.
lupus
--
-----------------------------------------------------------------
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
