[Lightning] Porting GNU Smalltalk to lightning 2

[Paulo César Pereira de Andrade]

  Last weekend I did talk a bit with Holger when asked
about @subject.
  I have been busy recently, but now looking at it again...

  I will call GNU Smalltalk gst :)

  First, gst expects lightning 1.x behaviour, with direct
translation (not the intermediate representation of
lightning 2.x), and fills data structures with the value
returned by jit_get_label(). But patching those should
be not too difficult.

  As far as I could understand, the main "trampoline" is,
in pseudo C (with gcc'ism of goto computed label):

run_native_code:
void trampoline(void *addr) {
    load_smalltalk_stack_frame(JIT_V2);
    load_pointer_to_some_address_suitable_as_argument_to_trampoline(JIT_V1);
    goto *addr;
does_not_understand:
    addr = do_something_to_tell_does_not_undetstand();
    goto *addr;
do_super_code:
    if (!(addr = call_the_super_code()))
        goto *does_not_understand;
    goto *addr;
do_send_code:
    if (!(addr = call_the_send_code()))
        goto *does_not_understand;
    goto *addr;
/* like other labels, &&return_from_native_code
 * is a possible argument to trampoline */
return_from_native_code:
    return;
}

It generates a static jit for the equivalent of the above, and
then generates jit for small chunks of translated Smalltalk
code, that uses the trampoline.

When actually generating code for Smalltalk input, it uses
a dialect like this:

1. Get address of buffer where to write jit to. Lets call it
    void *addr;
2. Start generating jit:
    jit_set_ip(addr);
    jit_prolog();
3. The jit_prolog() call was just to make it have the same
   stack frame as "trampoline", and initialize lightning 1.x
   internal state to understand the stack frame.
4. jit_set_ip(addr);
    This just overwrites the prolog.
5. Generate jit code suitable as argument to the
    example "trampoline" function above.

----------
  Now the main problem.
  Lightning 2.x does not really work very well if you instruct
it to jump from one function body to another, just like in C
it would not. The solution I am considering for it is a new
call:

    jit_frame(bytes);

that must be issues just after the jit_prolog() call, and
will cause lightning to generate code to save/restore all
callee save registers, and allocate "bytes" bytes in the
stack, for building stack frames for any called function,
allocai and any spill. It should have an assertion if it would
ever need more than "bytes" bytes, because that would
mean data corruption in the stack. This would allow
what gst needs (equivalent of jump from C function to
C function) in a "portable" way, that would work on all
lightning 2.x backends.

----------
Another minor problem is that lightning 2.x did not clearly
specify it did not support jit_jmpi(absolute_address). But
I remember to have been asked about it at some point, and
told to use:
jit_movi(reg, absolute_address); jit_jmpr(reg);
but I will make this work:
jit_patch_abs(jit_jmpi(), absolute_address);

----------
  Yet another tricky thing to do, is that gst assumes it
can compute address of some data structures if given
the address of a jit chunk, because it declares it as a
variable length structure, like this:

struct method_entry {
   gst_stuff;
   char code[1];
};

and then it cases the jit pointer to the address of code in the
above structure to get the jit_info pointer, like this:

entry = (struct method_entry *)((char *)code - sizeof(gst_stuff));

The workaround should be to adapt to the new declaration,
that should loosely match:

struct method_entry {
    gst_stuff;
    jit_state_t *_jit;
};

  Lightning 2.x can do it with jit_set_code, but I really do not
like it, because jit_set_code() assumes a page aligned argument,
and I do not like the idea of aligning it to a lower address, because
that would mean marking "random" memory as executable.

Thanks,
Paulo