> 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.
I think we need to get some initial performance characteristics of register
machine vs stack machine before we go too far. There is not much points left
debating in email list.
I believe we have some misunderstanding here. The inc/dec of sp cost
nothing,
the sp is almost always a register variable, the cost of arithmetics on it
is
mostly likely hidden by dispatch loop. The main cost is useless memory copy
like: push local #3. The register machine can only avoid copy between local
variables and expression stack. If a sub uses a lot of globals and fields,
the register machine has to load/store them (in/out register file), which is
exactly the same as push/pop stack.
I think the performance gain of a register machine comes from several areas:
1) avoid copy between local and stack, but it can not speed up global/field
access.
2) complex op reduce dispatch overhead
add i1, i2, i3;
vs
push local 1;
push local 2;
add
pop local 3
This is likely the biggest gain.
3) special registers (32 ints, 32 floats, 32 strings) simplify gc and speed
up common opcodes. In order to achieve this, we must enable some type
system.
I remember Perl6 is going to have unified int/bigint, num/bignum, multi
encoding/charset string. I wonder how the special registers can handle
this
feature, since there may be overflow/underflow problem.
Hong
