Re: [Lightning] Re: About using lightning on a dynamically typed language

[Paulo César Pereira de Andrade]

Paolo Bonzini wrote:
>>  The idea is to create several small C functions, for most opcodes, so
>> that I don't need to (or should not) bother with c99 complex numbers,
>> tls variables, etc from the jit code, only from the small "callbacks".
>
> Makes sense, like a mixture of JIT and threaded code.

  The initial code I am writing (almost 3k lines already, but not yet
compiled, and mostly cut&paste of the current implementation), basically
starts with a call to mmap() of 16Mb, and I believe calling mremap if it
every needs more memory (or just to shrink it back later should work...)
should do it without the need of some "massaging" to adjust offsets...

  Basically it calls these callbacks, and have a few specialized ones,
for constant values, like known types and offsets. Very simple opcodes
like load of constants are being written directly in jit.

  I am a bit unsure if I could figure out some logic for fast dispatching
based on "current value type", as in the current vm, there are 11 dispatch
tables (and could have more, like one for when the loaded value is a
hash table, or some other special types), based on the type of the
current value, so, for example, if it finds an "add" opcode, it only
checks the value in the top of the stack, and doesn't need to check the
current value type again, and if the operation is invalid, the entry in
the dispatch table is a direct jump to the error handling.
  A naive implementation could be to have 11+ versions of the jit code,
jumping from one to another when the type changes, but that may become
worse then checking the type, most times redundantly, in every "callback"
in C code.
  But I believe for code working on only dynamically typed objects, it
should still be around twice as fast, where it should become really fast
is in code handling statically typed variables.

> BTW in the GNU Smalltalk JIT the superoperators are completely
> separated at JIT time.  In the interpreter instead there is a program
> to generate the "glued" code.  The glued code is more efficient
> because it avoids writing temporary data to the stack.

  I probably will still use a few superoperator like "callbacks", to
avoid writing to the vm stack (the worst case is bignums, as they
are handled by value, so, inplace operations or knowing if can call
"mp*_swap" is very desirable), but in a peephole pass that will happen
to be during generation of jit.

> Paolo

Thanks,
Paulo