> I like this. This is (IMO) the correct way to do it.

/me snatches an opportunity.

Ofcourse it is!;  I thought of it. ;)

> Just curious though, and I most likely missed this, just noticed this 
> thread and all, but how do you propose sync'ing the garbage 
> collector's activities between your "many" interpreters?


1. I plan to disentangle the Object Memory from the interpreters.
2. The GC will be fully serialized. (Attempts to do any type of GC while 
the GC is in progress is a null-op.)
3. -- this is the trickey part -- Identifying the critical sections of 
the interpreter to, hopefully, allow it to run in paralell with the GC, 
to some extent at least...

Anyway, I'm working on my "size doesn't matter" variant of the bitwise 
operators.

I think I'm hitting some bugs in other code...

Lets say we're generating a pixel word... let's say "White" in 8-bit depth.

Ints are 31 bits so it's a large int...

A partial version only accepted smallInts and worked shockingly well...

The first [somewhat working] version of my 64-bit code looked at the 
value and said (in c)

int32_t foo.
int64_t bar. (my code processes all longs as 63bits+sign)

foo = bar;
if  ( foo == bar ) blah;

This code will cause the entire thing to be treated as an 8-byte long 
int. This breaks some of the bitmap routines.

The second version stripped the highest bit and returns -1 which breaks 
the same routines again.

I then made sure it preserved the sign of input int64_t and now it 
segfaults well into the SUnit Tests in "accessableObjectAfter" with a 
negative pointer value! =\

skipping the attempt to down-shift to smallInt doesn't crash it but 
causes SUnit Tests to spew out about 7 times the "par" level of errors, 
which I believe was 6....

Since I'm now leaving the realm of simply doing cleanups and am 
beginning to design extensions to Squeak I would like some design advice...

Or should I just go back to the implementation that barfed at all 
negative values and all values larger than 32 bits?