4 ms·

"The compiler can be similar to the compiler we proposed in I don't want to go to Chel-C, which merely replaces each bytecode instruction with a set of native i

by jhgb 4y ago

"The compiler can be similar to the compiler we proposed in I don't want to go to Chel-C, which merely replaces each bytecode instruction with a set of native instructions. " I'm just wondering...with modern CPUs, isn't this just a version of subroutine threading [1] that doesn't take advantage of modern pipelined CPU hardware and also blows up instruction caches? Why not go for subroutine threading? [1] https://en.wikipedia.org/wiki/Threaded_code#Subroutine_threading https://en.wikipedia.org/wiki/Threaded_code#Subroutine_threa...

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 ago
  I 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 ago
    Indeed 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.
deleted 4y ago
[deleted]

by jhgb 4y ago

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 ago
I 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 ago
  Indeed 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.

deleted 4y ago

[deleted]