What you're saying about the VM is a software problem, not a hardware one. You're right about the VT-x extensions, and read barriers for GC is exactly what Azul is trying to do with their kernel patches, but there was no reason why the GC couldn't have been moved into kernel space before virtualization extensions came along.
Same thing with stack machines vs registers (why would you ever want a stack machine for CPS-compiled code?), tagged arithmetic (SPARC has tagged arithmetic instructions, but it turns out pipelining makes "manual" tag-checking just as fast), etc.
If anything, a pipelined, superscalar RISC CPU benefits Lisp more than it does C.
> What you're saying about the VM is a software problem, not a hardware one.
The strict conceptual partitioning of software problems and hardware problems is quite passé these days. In the last 10 years, Intel and AMD have added a tremendous amount of very CISC-y functionality into x86 (e.g. string search instructions), in recognition of the fact that exploding transistor budgets make hardware the right place to implement certain things.
> but there was no reason why the GC couldn't have been moved into kernel space before virtualization extensions came along.
GC couldn't have been moved into kernel space because of the second part of my argument: UNIX hides hardware features not necessary to run C programs. The MMU can do quite a lot that is obscured behind the very limited mmap() abstraction.
Same thing with stack machines vs registers (why would you ever want a stack machine for CPS-compiled code?), tagged arithmetic (SPARC has tagged arithmetic instructions, but it turns out pipelining makes "manual" tag-checking just as fast), etc.
If anything, a pipelined, superscalar RISC CPU benefits Lisp more than it does C.