|
|
This meshes with something I've been thinking about.
One could probably get very high code density (at the expense of lower performance in the VM)
by going to a TIL (Threaded Interpretive Language, like some Forth implementations) code format, e.g. each 16-bit word in the VM instruction stream is treated as either a constant push (say if it's high-order bit is zero) or as the address of code to call (with a lighter-weight function calling protocol than that the VM implements). This format would result in most VM operations being represented as one 16-bit word (some would take two or three). That's much denser than the Hack assembly inlining that the VM translators usually do.
There would have to be assembly code in the VM implementation to interpret this code format, which is what would make it slow compared to just translating VM instructions into series of hack assembly instructions.
On the other hand, it might be possible to implement the necessary stack and function call handling
as part of the Hack "hardware" architecture, using some of the currently unused instruction encodings (and of course, additional logic in the Hack CPU). I haven't tried this, but it's a possibility.
|
Locked
