'microcode' stackbased machine on top of parrotVM

Bart Wiegmans bartwiegmans at gmail.com
Wed Oct 31 20:41:58 UTC 2012


I'm going to be honest here, I don't think that is the way to go forward.
First of all, what problem are you trying to solve here?

The advantage of stack machines - if any - is that subroutine
invocation becomes a very simple matter, i.e. push the stack, jump
some location, do some computation, push the result, jump back. This
is trivial, and this triviality is the main reason many virtual
machines are stack machines, it is just somewhat easier to get
started. Also, garbage collection becomes really simple.

Stack machine programs are executed more slowly, however, because of
the need to push and pop arguments to operands, while the register
machine can just specify the relevant registers. With many operations
on the same operands, this saves a lot of time. The cost is a somewhat
larger bytecode format.

Parrots' bytecode format is quite high-level as it is, it is not
nearly suitable to be a 'microcode'. m0 may well be, but I have my
doubts. Again, the main advantage is to have a somewhat simpler
interpreter. A compiler doesn't benefit so much from switching to a
stack machine.

Lastly, it is my impression that the main difficulty of parrot is the
goal of running X dynamic languages interoperably, fast. This is
difficult because each of X has its own brilliant idea of what should
be modifiable at run-time, what objects should look like and how
routines shuold be invoked, and thus it is nearly impossible to take
shortcuts and optimise. This is made somewhat worse due to the fact
that a lot of parrot's objects (the operands) are `written in C, thus
unavailable for inspection by a optimiser.

Anyway, long story short, stack vs register isn't quite risc vs cisc.
You're suggestion is to push another layer of interpretation on an
already not-so-fast interpretation.

Kind regards,

> Date: Mon, 29 Oct 2012 00:40:49 +1100
> From: mofo syne <mofosyne at gmail.com>
> To: parrot-dev at lists.parrot.org
> Subject: 'microcode' stackbased machine on top of parrotVM
> Message-ID:
>         <CAPJM1pdrNMpSxP6C=51iYCXQfVkHVdF8W6sMwxYwgQkVDhCh0Q at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> I've been reading about how JVM is stack based, and this is register based.
> I also read about how both has its advantage and disadvantages. I also
> recently read about how there are CPUs out there that are essentially RISC
> in the core, but runs 'microcodes' on top to process/emulate higher level
> instructions.
> I'm just wondering if it would be possible to somehow include, a
> 'stackmachine VM' on top of parrotVM, or would the emulation overhead
> defeat the purpose.
> If we do take that route, would we make it so that a program instruction is
> 'either' stackbased, or register based (which is simpler as you can start
> the 'stackbased microcode' on demand)? Or can it be possible to mix the
> instruction sets to have bits of code be 'stack' and 'register'.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20121029/ec7bf955/attachment-0001.html>
> ------------------------------
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
> End of parrot-dev Digest, Vol 50, Issue 11
> ******************************************

More information about the parrot-dev mailing list