Re: [Lightning] SPARC Fixes

[Paolo Bonzini]

Ludovic Courtès wrote:
> 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 ;-)).
>   
Applied, thanks.
>   * 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.
>   
This is wrong, you have to use jit_retval_i to retrieve %o0 exactly for 
this reason.  It is also wrong because, IIRC, %i0 is a callee-save 
register and you cannot write into it if a function returns void.  Would 
you mind preparing a patch-20 to undo the JIT_RET changes?
>     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.
>   
Another possibility (simpler for now to implement) is that if  
JIT_MAX_STACK_AUTOMATIC_AREA is defined, clients should be careful not 
to push more than that amount of words.  Or we could just deprecate 
pushr/popr and define a better way to provide stack space for spills.
>     Under `_ASM_SAFETY', `pushr' "overflows" and `popr' "underflows" are
>     detected.  I think we should document `_ASM_SAFETY' and perhaps
>     define it by default.
>   
That's --enable-assertions.  :-)
>     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.
>   
That would be the way to provide stack space for spills -- a lightning 
instruction patching the `save' on the SPARC, and on other architectures 
compiling to subr JIT_SP, JIT_SP, N.

Paolo