>>11
Forth would also work.
Lisp is fine, but it tends to be a high-level language and does have certain costs(gc, possibly boxed integers, ...), it's also not really meant for low-level tasks that C is used for, however almost all real Lisp implementations will let you fiddle with memory or pointers or whatever you want (like write your own assembler or code generator and generate code objects which you can just run as you wish). However, if you're just writing the macroassembler in lisp and the generated code does not have to live within the lisp image, then these "costs" don't apply. Any high-level language could do this, it's just easier in homoiconic languages.
I'm however confused what does the Lisp Machine have to do with
>>10. LispMachine's had an OS written from ground-up in Lisp, had a microcoded CPU which ran their lispm assembly bytecode, had native support for tagged data, typechecking, gc support and some other stuff. It was quite the high-level CPU, possible due to the layered design (the assembly instructions got translated to simpler microcode which was executed by the CPU). This was a bit slow, and today we usually opt on using general-purpose CPUs and a good compiler.