[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Lightning] SPARC Fixes
[Lightning] SPARC Fixes
Mon, 30 Oct 2006 22:42:50 +0100
Mutt/1.5.4i [Guile enabled]
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
* 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.
[*] Location: http://www.laas.fr/~lcourtes/software/arch-2005/
- [Lightning] SPARC Fixes,
Ludovic Courtès <=