Parrot's's bytecode can be thought of as a form of machine language for a virtual super CISC machine. It makes sense, then, to define an assembly language for it for those people who may need to generate bytecode directly, rather than indirectly via the perl (or any other) language.And the obvious question is: why would a software machine closely emulating CISC architecture be expected to execute as efficiently on RISC machines?
Does it make any sense to create a low-level machine modeled on one-architecture instead of a high-level architecture which can flexibly optimize to either architecture?
Hell, if you want a nice pseudo-assembly language, GCC has compiled to RTL (register transfer language) for years, supporting C, Objective C, and C++. When we just need to code a RTL -> JVM and RTL -> CRL converter
But instead it was decided to create a whole new project and use C and a machine-like language. Why?
Registers will be stored in register frames, which can be pushed and popped onto the register stack. For instance, a subroutine or a block might need its own register frame.
In reply to 3 Criticisms of the Parrot Project for Perl 6 by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |