On Wednesday, November 20, 2002, at 11:33  Uhr, Tim Rowledge wrote:

> Marcel Weiher <marcel at metaobject.com> is claimed by the authorities to 
> have written:
>
>> By the way, couldn't passing the pointer to the interpreter struct to
>> each function be faster still?  After all, registers are probably
>> plentyful, and that would eliminate access to the global structure
>> pointer.  Of course, that would mean altering the signature of the C
>> functions.
> It's likely to be very cpu specific - remember, x86s only have three 
> (or
> is it four, or five?) registers not already dedicated to something or
> other. PPC has quite a few, ARM has a modest surplus, Alpha has a
> gazillion etc etc. It's one of those details that one ought to be able
> to leave to a compiler but can't really trust completely.

I thought the whole "globals as structures" idea was already 
CPU/ABI/compiler specific, as the OS-X combination causes access to 
global variables to be very painful(ly slow).

> Notwithstanding that matter it would be nice to pass args etc to the
> primitives in a 'normal' manner so that we could take advantage of the
> cpus calling conventions properly.

That, too.  I am guessing you mean that primitives should just have 
their arguments as C-function arguments, and not have to get them off 
the Smalltalk stack per-pedes.  Wouldn't this be fairly easy to do?  
Just generate a number of "template" functions that are specialized to 
a specific number of arguments.  Each takes a primitive function 
pointer, pops the arguments off the interpreter stack and calls the 
function pointer with those arguments.  The arguments would still be 
ints.  That way, you have a fairly generic solution without the FFI 
hassles and without every primitive having to fiddle the Squeak stack.

However, my ulterior motive in all of this is still turning the Squeak 
interpreter into a real object, and I wouldn't mind at all if it were 
structurally equivalent to an Objective-C object.

With all the globals in a structure, we are already part of the way 
there ( adding an "isa" pointer to the start of that structure doesn't 
seem like such a big deal).

The next part is turning the global functions into methods, which is 
also just a small step.  An Objective-C method is just a function with 
two additional parameters:  "self" is the first, and "_cmd" (the 
selector) is the second.  The only issue with this that I can see is 
that we have some literal C code interspersed with the automatically 
generated parts.

Something along those lines.

Marcel