4 ms·
There are some well though-out abstract machines out there that are quite efficient and map pretty directly to machine code, like the SECD or the WAM (for PROLO
by nils-m-holm 7y ago
There are some well though-out abstract machines out there that are quite efficient and map pretty directly to machine code, like the SECD or the WAM (for PROLOG).
The LISP9 Abstract Machine, which is described in the book, is very close to the metal. So much so that you might as well emit machine code instead. The approach is outlined (but not described in detail, as you noted) in the last chapter.
Then abstract machines have one huge advantage and that is portability. I can just compile the system on x86, ARM, SPARC, MIPS, Alpha, or whatever and it will simply run. So whatever the reader has, the code will work. (I acknowledge that pretty much everybody uses x86 today, but still...)
- SomeHacker44 7y agoCounting general purpose CPUs only, I have so many in my house it isn't even funny. 6502, Z80, MIPS (64-bit), Alpha, SPARC, Ivory, 680x0, x86(_64), ARM (32/64), PowerPC and a lot of variants, and some I do not even know offhand (Xerox, TI). I am actually ashamed to have no RS/6000, PA-RISC or Itanium to go with it. So... Thank the world for IR, ByteCodes and VMs.
- Annatar 7y agoWhat does owning all these processors have to do with bytecodes and VM's? What kind of a statement is that?
- new4thaccount 7y agoI assume he means that the intermediate code allows for easier abstractions to support all those different processors instead of writing a specific machine code compiler for each one.
- Annatar 7y ago"So much so that you might as well emit machine code instead." Exactly, thank you!!! So why the hell would you screw around with bytecode!?!?! I don't want portability, my source code is portability! I want the fastest possible machine code translation for the smallest possible program!!! That "portability" thing with bytecode makes me absolutely livid!!!
- avmich 7y agoRemember, neither translation to machine code is guaranteed to be faster than translation to a VM bytecode, nor execution of such a code is guaranteed to be faster than execution of bytecode.
- Annatar 7y agoThe machine code has to be faster because the intermediate to machine code step, which impacts performance at least once is eliminated.
- FullyFunctional 7y agoSECD is _not_ a quite efficient abstract machine, by a long shot. Something a lot closer to the state of the art would be Leroy's modern version of his Zinc or, far more extreme, GRIN by Boquist (there are several implementation and a new one under way).