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...)
Counting 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.
I 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.
SECD 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).
"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!!!
Remember, 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.
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...)