Re: [Sbcl-devel] low tag type bits

[William H. N. <wil...@ai...>]

On Sat, Sep 22, 2001 at 04:30:22AM +0100, Daniel Barlow wrote:
> A minor victory has been achieved in the PPC port today, in that I
> worked out why it was jumping around memory quite so vigourously.

Cool.
 
> Full story, pasted from cliki, below, but first let me ask the
> question: would anyone object if we swapped the low tags for function
> pointer and instance pointer (type_FunctionPointer and
> type_InstancePointer, in sbcl.h-speak)?  We can probably find some way
> to avoid it (it's something of an ugly hack IMO, I'd actually like to
> find another way), but it will involve rewriting chunks of the call
> vop and I haven't yet figured how.  CMUCL has the tags
> conditionalised on #+ppc, so that's an option.  I don't really believe
> there's any other port that depends on their being the current way
> around, though, so we could just swap them on all platforms.

I think trying to conditionalize the type codes based on target
architecture would be messier and more confusing, so I'm inclined to
just renumber them for all architectures, as per your first
suggestion.

I'll probably try doing this swap soon after I get back on the main
branch, probably with comments along the lines of 
	/* CMU CL had FunctionPointer=1 and InstancePointer=5, but
	 * on the PPC the alternative facilitates a low-level pun
	 * which reduces function-call overhead, so we've exchanged
	 * them. See the PPC documentation. */

It makes me vaguely queasy to have this kind of low-level punning
going on (using "5" both as a type tag and as something which, when
masked in the way that PPC happens to do it, works as an offset).
However, in this case it seems not too confusing, and reducing the
overhead of function call seems like a pretty good reason for
microoptimization.

Of course, "not too confusing" doesn't mean "not confusing at all", so
please
  * Document it carefully, perhaps including a few remarks about how
    relatively important it is and how you'd go about getting rid of it
    if you had to (since some future maintainer might have to).
  * At the point of the code which takes advantage of the pun, it would
    be nice if you could put in some sort of assertion that the
    preconditions hold, along the lines of
      #if type_FUNCTIONPOINTER != 5
        #error violates low-level pun assumption on PPC, see <whatever>
      #endif
    as further "documentation" (active documentation?), so that if 
    things ever change, we get a clear error instead of mysterious
    failures.

-- 
William Harold Newman <wil...@ai...>
"Sometimes if you have a cappuccino and then try again it will work OK."
  -- Dr. Brian Reid, 1992, quoted by mjr
"Sometimes one cappucino isn't enough."
  -- mjr = Marcus J. "will do TCP/IP for food" Ranum <mj...@hu...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C