Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:59 PM +0200 6/13/03, Leopold Toetsch wrote:
>> IMCC is a much bigger problem here.
> I'm not sure it does, or at least that it should. (Though if people
> play interesting games with register set swapping it could, I suppose)
Apart from such tricks: First a short summary. We now have half sized
register frames. This almost doubles performance, when only the lower
half of registers has to be preserved (e.g. when calling a sub in a loop).
OTOH when all registers have to be preserved the current scheme only has
roughly half the performance of the old 32 registers/frame.
So IMCC has to look at the current subroutine's register usage and emit
an appropriate combination of {top,bottom}pushX opcodes to preserve used
registers. The register allocator starts allocating registers from 0 up,
so e.g. when only 16 PRegs are used and the sub is called in a loop, it
will emit only a C<toppushp> opcode.
Or e.g. a sub is called only once with one parameter and one return value
which are both in P5. IMCC has to know, that the P5 after the subcall
comes out from the subroutine. If no other PRegs are used after the
subroutine call, no pushp opcode is necessary.
The HL rather should not emit saveall/invoke/restoreall. It ought to
be done inside IMCC. This part should be handled in a way I tried to
outline in imcc/docs/calling_conventions.pod. The doc of course needs an
update for CPS.
leo
