4 ms·
Since this is written in assembly is it much faster than a C version since this one can manage its own stack frames and stack variables and such? I always imagi
by _sdegutis 9y ago
Since this is written in assembly is it much faster than a C version since this one can manage its own stack frames and stack variables and such? I always imagined that’s the case and that a lisp implemented fully in assembly would be the trick to a super fast lisp that can complete with Go.
- ci5er 9y agoLISP was created a long time ago. Assembly was the weapon of choice. Thinking Machines, Symbolics and Macsyma might already say: We did that. But, uh, no.
- klmr 9y agoThe first LISP implementation was famously done in machine code, not assembly.
- tom_mellior 9y agoAn interpreter written in assembly is still an interpreter. Yes, it may have control over stack frames. But so does a compiler, and the code generated by a compiler doesn't incur interpretation overhead. If you want performance, compliation is the way to go. And that's what fast Lisps do.
- marcpaq 9y agoArpilisp author here. If you were to implement the same Lisp in C then compare, then maybe the assembly variant would be faster for the reasons you mention. Or maybe not. Also, I modeled arpilisp after the original Lisp. That's barely a first step, and possibly the wrong first step, for anything non-trivial, including applications requiring a "super fast lisp that can compete with Go." But I didn't write arpilisp for performance. I wrote it to learn and share. Enjoy!