3 ms·
Co-author here; the first goal is to work at all, not to be awfully fast. But the branches that appear would most likely be due to inline caching, which are ver
by hayley-patton 4y ago
Co-author here; the first goal is to work at all, not to be awfully fast. But the branches that appear would most likely be due to inline caching, which are very predictable in practice; [1] claims a 95% hit rate for a simple inline cache. And given that there is little to inline, this scheme probably does approximate subroutine threading.
[1] https://bibliography.selflanguage.org/_static/pics.pdf https://bibliography.selflanguage.org/_static/pics.pdf
- jhgb 4y agoI was simply assuming that the average instruction for a Lisp implementation would be more substantial in terms of length the sequence of native instructions than an average instruction for a translation of C code. The closest thing that comes to my mind is the CLISP VM, which has fairly heavyweight instructions. The proposal doesn't give me an idea of how fine-grained the proposed instructions would be, or I must have missed it if it does.
- hayley-patton 4y agoIndeed it doesn't mention the instruction set. The closest would be Self, which only has instructions to do message sends and read particular VM registers; which boil down to calls and pushes respectively. That part of the semantics of the proposed language are closer to Smalltalk heritage than Lisp; the expression orientation, syntax and, at lack of a better term, "nesting" are the Lisp influence. Say, Smalltalk provides variable declarations at the start of a method, we intend to provide LET/LETREC forms instead. I would agree that CLISP bytecode would be heavier; this approach ("template compiler"?) has been used as a baseline JIT in e.g. Jalepeño for the JVM with some success, but being a baseline JIT it is not intended to be that fast either.