[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lightning] SPARC Fixes
Re: [Lightning] SPARC Fixes
Tue, 31 Oct 2006 09:25:17 +0100
Thunderbird 188.8.131.52 (Macintosh/20060909)
Ludovic Courtès wrote:
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
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?
* 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.
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.
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.
That's --enable-assertions. :-)
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.
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.