[Lightning] SPARC Fixes

[Ludovic Courtès]

Hi,

My Arch branch[*] cotains a few fixes for SPARC, namely:

  * Fixed a typo in `jit_modi' which prevented compilation of programs
    making use of it (patch-11).

  * Fixed `jit_immsize' which passed its arguments to `_siP' in the
    wrong order (patch-12).  This macro is used by `jit_prepare_y' and
    `jit_clr_y' in order to make sure register Y is not read from at
    least 3 instructions after.  This bug had no negative impact beside
    the output of a warning ("left shift count >= width of type").  I
    added a `divi' test case (patches 14 and 15) which thusly cannot
    catch this bug (but anyway, too many tests is better than not
    enought ;-)).

  * Fixed the use of `JIT_RET' (patch-19).  Lightning's `JIT_RET'
    actually maps to two registers on SPARC: %i0 is where a procedure's
    own return value should be put, and %o0 is where the return value of
    a called procedure should be read.  The way I fixed this is simple,
    although not very efficient, but I couldn't think of anything
    better: any `calli' or `callr' is followed by a `mov %o0, %i0' so
    that one can expect %i0 to always contain the callee's return value.

  * Fixed `pushr' and `popr' (patch-19, which is actually a merge of the
    `sparc-fixes' branch).  This was implemented by incrementing %sp and
    storing pushed registers there (i.e., below the original %sp).
    However, this doesn't work on SPARC as the area pointed to by %sp
    (actually %sp to %sp+16) can be used upon register window
    overflow/underflow to store the current register window (thereby
    overwriting the pushed registers).  Thus, a different strategy has
    to be used to dynamically increase the stack space (details and
    pointers in the comments of `sparc/core.h').

    This patch increases the size of the stack frame as it is created
    during a function prolog so that there are always
    `JIT_MAX_STACK_AUTOMATIC_AREA' words available to put registers to
    (at the top of the stack frame, as required by the SysV ABI SPARC
    Supplement and as suggested in Appendix D of the SPARC V8 specs).
    This effectively limits the number of registers that can be pushed
    from within a function, but I think that shouldn't be a problem.

    Under `_ASM_SAFETY', `pushr' "overflows" and `popr' "underflows" are
    detected.  I think we should document `_ASM_SAFETY' and perhaps
    define it by default.

    Instead of having a hard limit on the number of registers that may
    be pushed, we could also patch the `save' instruction based on the
    actual number of `pushr' encountered in the function's code, but I'm
    not sure it's worth it.


I'm not a SPARC expected so all this can possibly be improved.

The last item raises a more important issue with Lightning's
abstractions that I'll describe in another mail.

Thanks,
Ludovic.

[*] Location: http://www.laas.fr/~lcourtes/software/arch-2005/
    Branch:   lightning--stable--1.2