Re:The Future of the LispM
by FullyFunctional on Saturday February 07, 2015 @07:59PM
(#9016012)
Some basic misunderstanding here: "However, as a stack machine architecture, there is no opportunity for the instruction level parallelism exploited by modern architectures as the exact state of the stack which is depended on by every instruction changes with every instruction. This forces all program execution to wait during slow operations like main memory reads, ..."
This is of course nonsense. Even an in-order implementation with non-blocking caches will let execution proceed in parallel with a load until the result is demanded. An actual out-of-order implementation will rename the (implicit) registers and proceed as normal.
The _only_ issue with stack architectures is that they are awkward (but not impossible) for compilers to generate optimized code for.
This is of course nonsense. Even an in-order implementation with non-blocking caches will let execution proceed in parallel with a load until the result is demanded. An actual out-of-order implementation will rename the (implicit) registers and proceed as normal.
The _only_ issue with stack architectures is that they are awkward (but not impossible) for compilers to generate optimized code for.
EDIT: I agree with basic motivation for pushing all the way to hardware (just not for Lisp). That's why I work on https://github.com/tommythorn/Reduceron