William Harold Newman writes:
> On Thu, Aug 30, 2001 at 11:38:34PM +0100, Daniel Barlow wrote:
> > It's not covered in the manual, and I doubt it's officially supported
> > either. But it's something I spent some time with recently, so here's
> > the short guide. Note that this is largely based on experimentation
> > and looking at the source code, so is quite likely all wrong. People
> > who know more than me are welcome to chime in.
> Officially supported? Not likely. Trying to ensure the stability of
> the interface to this kind of thing looks like a nightmare.
This seems like it would be a really good thing to keep documented,
even if marked as "this will likely change radically as time goes on".
For some things (mostly systems-level stuff), it's vital to be able to
drop into assembly. I've been really enjoying SBCL so far, and now
I'm quite encouraged that I'll be able to use it for pretty much
everything. I'd hate for anyone to be put off by the lack of a
documented assembly interface.
> However, some kinds of performance hacks could be officially
> supported. If there's a relevant optimization that the compiler could
> make and doesn't, and you can teach the compiler to make it, I'd
> probably be happy to make it a permanent part of SBCL. Examples of
> this kind of thing in the reasonably recent past include
> * transforms for TRUNCATE, FLOOR, and friends to avoid consing,
> added to CMU CL by Raymond Toy (I think) and ported to SBCL
> * my new transforms for MAP, for quantifiers (e.g. EVERY), and
> for adjustable arrays
> * my tweaks in the type system so that keywords and other
> intersection types can be handled better
> So if, e.g., you need to do some kind of operation on bit vectors and
> SBCL is currently doing it badly, consider teaching SBCL to optimize
> it better and submitting the optimization as a patch, rather than
> writing your optimized version in inline assembly language.
Unless I'm mistaken, this is a somewhat orthogonal facility. If I'm
worried about bit-twiddling in an inner loop, I'd probably try to get
the compiler to generate better bit-twiddling code. However, some
times knowing the exact circumstances you're implementing some
algorithm in can allow you to write overly-clever assembly, often
saving 5-10% in speed. I don't think I'd *want* this sort of
intelligence in a compiler, even if it would be feasible to implement.
Mostly I wanted to know that I *could* write stuff by hand on a
per-case basis. I'll come back when/if I find myself actually doing
this in SBCL :)