Tim Rowledge wrote:

Thanks so much for taking the time to comment on my sometimes misguided 
ideas.

>There's a couple of miscellaneous prims hanging around that could be
>moved but that would require co-ordinated image changes. Since we try to
>maintain backward compatability over fairly long periods of time, this
>is a barrier. I intend to excise them for the v4 release since we wil
>be breaking backwards compatability all over the place. I disagree that
>large ints and floatarrays are basic data structures. I don't think
>there is any real reason to care whether LargeInt or FloatArray prims
>are implemented as plugins code or internal-to-the-core code. There will
>be even less when the new prim calling system is in use.
>  
>

Well then, I will definitely have to gain a better understanding of 
which things you want to keep around and which things are going and 
why... The changes I have made so far have been focused on the current 
image and how it is coded. I havn't changed terribly much but when I see 
two bits of code doing the exact same thing I tend to combine them...
In object memory there were functions "fetch pointer of object" and 
"fetch integer of object" which seemed to have identical texts... (or at 
least textst that reduced to the exact same form...)


>>Furthermore the Large Integer Plugin seems to be very stale. The code in 
>>the LargeIntegerPlugin seemed content to process a 64 bit int on a 64 
>>bit platform with a loop that processed 1 byte at a time!!! I have not 
>>really looked at it yet, I just discovered it this evening.
>>    
>>
>That's not stale, that's the chosen alorithm. Since LargeInts are byte
>array objects it works well t process them byte by byte. Anything else
>adds endian complications. If you have time to write faster
>replacements that will work on all endian types, please do so and they
>will be used.
>  
>

To the best of my limited understanding, bitAnd, bitOr, and bitXor are 
done strictly on corresponding bits... Once the arrays are made and 
lined up I can't immagine any reason not to process them as a group 
since there is no type of borrowing or carrying the CPU's interpretation 
of the object is moot. I went ahead and re-coded them to blindly work on 
32-bit chunks (looping as neccessary) without any visable problems on my 
x86... Ofcourse this is fairly evil because with byte objects you could 
get odd-sized chunks. Here again I'm exploiting Squeak's memory model. 
Since everything is word aligned I can cheerfully process out-of-range 
bits.

This only creates an issue when the function is passed two mis-matched 
odd-sized variables. I think that will be sufficiently uncommon as to 
not be an issue.

I used a similar hack on the memory-fill function. ;)

>>It tried to write a version of BitAnd etc... to process anything that 
>>could be thrown at it with one function. That effort showed that any 
>>solution that my meager skills colud write would be very awkward and 
>>slow... I think the best approach would be to simply attempt to do a 
>>small-int -- small-int  operation then put, as the first operation of 
>>the failue code, to simply swap the order of the first two items on the 
>>stack and re-attempt the same selector. That should have the effect of 
>>triggering the code that is more specialized for large ints...
>>    
>>
>I don't think attempting double dispatching within the VM is a very good
>idea. Fail the prim and let the image work it out. Have multiple
>versions of the prim that handle different mixes efficiently. Allow
>polymorphism to work.
>  
>

Yes, that's what I meant. I think you had said that the code that comes 
after the prim code in the image is called the "failure code". I did 
indeed use this term here.