Tim:

I *think* that what you suggest is what Ohshima is proposing. It's
a good idea. A slight refinement might be to sort the primitive names
and then do a binary search in the lookup. While it's true that for
named primitives that are *found* you only have to do the lookup
once. But I believe that primitive that is not found (and thus fails)
will get looked up every time. If the primitive is "optional" and
there is actually Smalltalk code that runs when the primitive fails,
it might be better not to penalize that Smalltalk code any more
than necessary. Of course, if the cost of a linear search of
a couple dozen entries is small compared to the cost of method
activation, we needn't worry about this. :->

An alternative would be to have the VM cache the fact that it
failed to find the primitive. On machines that actually don't
have dynamic libraries like the Zaurus (all named primitives
must be built into the VM), that would make sense. On other
platforms, you probably need to look for the library every time
because the user may have installed it since the last (failed)
attempt to run the primitive.

	-- John


At 3:50 PM -0800 12/9/99, Tim Rowledge wrote:
>On Thu 09 Dec, ohshima at is.titech.ac.jp wrote:
>
>>   I wrote a snippet of code to make the named primitive
>> mechanism works on the platform where the dynamic loading
>> (by name) is not supported.
>> 
>>   The idea is to generate a C data something like:
>> 
>> int (*namedPrimitivesAddr[])() =
>>   {setInterpreter, gePrimitiveAddLine,
>>    gePrimitiveAddRect, gePrimitiveSetDepth,
>>    gePrimitiveSetOffset, gePrimitiveGetTimes, ...};
>> 
>> whose entries are the exported C functions, and lookup the
>> address of the called primitive at runtime.
>
>I have a similar problem with the Acorn, the named prims that are compiled into
>the VM are tricky to find reliably. Luckily, I found a utility to do the
>external plugins calling!
>I'd like to sugest a much simpler solution, based on the observation that
>finding the address does not need to be fast since it is done only one and the
>result is recorded in the method literals. This avoids the need to worry about
>hashing, and I claim that simple strcmp() searching would be ok.
>If we change the codegen to produce a structure with the function name strings
>and addresses, we can just run through it in a linear fashion.
>The good news is that it is completely known how many entries are needed and
>how many characters each function name uses so it should be simple to make the
>structure - an array of {(char *)name; *addr()} like structs would do, with the
>strings off in some long char array.
>
>tim
>
>-- 
>Useful Latin Phrases:- Nullo metro compositum est.
>It doesn't rhyme.
>Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
> tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>