Am 25.03.2004 um 22:08 schrieb Alan Grimes:

> [appologies if posting too often bothers people, just have a lot to 
> say at the moment. ]
>
> In doing profile analysies on my code I came across something truly 
> bizzare:
>
> SmallInteger > bitAnd:  was, itself, calling  SmallInteger>  bitOr: 
> !!!!
>
> I thought "WTF?!?!?!?!"
>
> and went to investigate. The code in interp.c was nearly what I had 
> expected it to be.

Eek, your looking at generated code? Why don't you look into 
Interpreter>>primitiveBitAnd which is much more readable?

> I looked very closely at the code in bitAnd: and came to the 
> conclusion that the primative implementation was stripping out the 
> sign bit and that the code in the image was correcting for this with a 
> kludge involving bitOr....

Hihi, why assume a simple explanation if you can think of a crazy one? 
;-)

> I'm probably wrong... What's the real story here?

You are way off. Read the code again, and remember that (x and y) = 
not(not (x) or not (y)).

What you are seeing is the code that is executed when the primitive 
*fails*. SmallInteger operations fail when the argument is no 
SmallInteger or the result would not fit into a SmallInteger. In the 
latter case, the SmallInteger is automagically promoted to a positive 
or negative LargeInteger.

Try to execute "1000 factorial" to see what LargeIntegers are.

Once you're done with Integers you should start to look into rational 
numbers, like the result of (999 factorial / 1000 factorial).

- Bert -