>Pouring over the source VM code, it looks like the primitiveBitXOr routine
>needs a failSpecialPrim(16) after the end of the routine if the pop is 
>not successful and after the unPop.
>
>This sound reasonable?

Entirely.  However, it is not the case ;-)

My guess is that you looked at primitiveBitOr (or similar), and reasoned that primitiveBitXOr should work the same way.  However, note that bitOr: is compiled as a special bytecode (see Smalltalk specialSelectors), and therefore enters its primitive method earlier than most other primitives.  If you look at the comment in failSpecialPrim, you'll see that this is explained somewhat:

	"Used only for failing from a primitive that was entered as a special
	bytecode.  This routine will look up the real method and, only if its
	primitiveIndex is different, then it will run that primitive, otherwise
	it will simply activate to run the fail code"

Why is OR a special primitve but XOR is not?  It was just a speed/space issue many years ago when the special integer ops were parcelled out, and there wasn't room for every common function.

What is such a crufty mechanism doing in a nice clean system like Squeak?  Chalk it up to many hours spent trying to make an interpreter run as fast as a compiler.  My hope is that when jitter passes the 2x mark, we can back the interpreter off to being a thing of elegance and beauty.  'Til then, warts like this are mostly paying their way.

Hope this helps

	- Dan