[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lightning] `pushr' on SPARC

From: Ludovic Courtès
Subject: [Lightning] `pushr' on SPARC
Date: Mon, 06 Nov 2006 15:44:40 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

>> Then, if we are to keep them for this release, wouldn't it be nicer to
>> have the working version on SPARC, even if people must have come to not
>> rely on it?  ;-)
> It would.  But it would also cause 32 extra bytes per frame, and I
> don't really like the idea...

We have 3 possibilities as far as the SPARC port is concerned:

  1. Keep the non-working pushr/popr.

  2. Include a fixed pushr/popr.  The fix I proposed does indeed
     systematically allocate 32 extra octets per frame in case pushr is
     used.  I can't think of a better fix right now (unless we consider
     that `allocai' is never used along with `pushr', in which case we
     could simply patch the `save' insn -- let's call it (2b)).

  3. Completely remove pushr and popr from SPARC, even though they are
     still documented and available on other platforms.

Solution (1) seems quite harmful since the resulting programs produce
erroneous results.

While (2) incurs some overhead, I don't clearly understand the impact of
larger stack frames.  Are you concerned by cache misses?  Keep in mind
that lightning 1.2 allocated 120 octets per stack frame (it could have
allocated only 104) while this fix allocates 104 + 32 = 136 octets (that
is, "only" 16 additional octets compared to 1.2).

Solution (2b) could be a nice compromise, provided we clearly recommend
against using both `allocai' and `pushr' (which is needed anyway for the
other architectures, according to your previous post).

Solution (3) is not very nice but it is IMO better than (1) because at
least the error is caught.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]