Re: [Sbcl-devel] Peephole Optimizing

[Nathan F. <fr...@cs...>]

On Mon, Dec 04, 2006 at 05:00:56PM +0200, Nikodemus Siivola wrote:
> >                       (setf (tn-ref-tn tn-ref) tn))
>                               
> The SETF here should probably be change-tn-ref-tn, no?

Ah, it probably should  Very handy!

> One thing that annoys me out of all proportion is the way we get one
> verify-arg-count per entry-point, which end up injecting multipl
> identical error trap sequences for every function. It doesn't really
> matter all that much since a trap sequence is only 5 bytes, but...

One way around this would be the strategy that Allegro (IIUC) employs:
there is a common trampoline for funcalling, which unifies call counting,
function tracing, etc. etc. in one location.  I think Duane Rettig also
claimed this scheme is easier on the processor's I-cache (less duplicate
code) and epsilon slower than SBCL's approach (since the trampoline
is always in cache).  I think it would shave ~150-200k off an x86 core.
(You could also move some of the stack manipulation from a typical
calling sequence into this trampoline, too.)

Another possibility comes from OpenMCL.  IIU OpenMCL's source correctly,
certain codes after a trap instruction denote particular frequent traps;
encoding them this way saves space compared to expanding them out.  So,
instead of SBCL's current:

;     4FC8:       CC0A             BREAK 10                   ; error trap
;     4FCA:       02               BYTE #X02
;     4FCB:       18               BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
;     4FCC:       4D               BYTE #X4D                  ; ECX

we might have instead:

;     4FC8:       CC9A             BREAK 154     ; INVALID-ARG-COUNT-ERROR, ECX

which is three bytes shorter.  The most common errors in SBCL are

1. OBJECT-NOT-TYPE
2. UNBOUND-SYMBOL (!)
3. INVALID-ARG-COUNT
4. OBJECT-NOT-LIST
5. LAYOUT-INVALID (I think)

Christophe graciously ran my script for calculating error frequency on
his lisp-world.core and found that the top four, at least, stay the
same.  I think there's just enough space in one byte that these four
errors could be encoded in the byte directly after the BREAK and still
have space left over for the current trap codes.  (It's also worth
noting that doing this would save <1% of the space of even Christophe's
lisp-world.core...every little bit counts, I guess.)
-- 
Nathan | From Man's effeminate slackness it begins.  --Paradise Lost

The last good thing written in C was Franz Schubert's Symphony Number 9.
                                               --Erwin Dieterich