"Andreas Raab" <andreas.raab at gmx.de> wrote:

> However, given that the primitive index is a full 32bit value and we only
> use about 1k out of it for "regular" indexed primitives, we could easily use
> the same trick for rewriting the primitive index of a succesfully looked up
> named primitive. This would make named primitive invokation exactly as fast
> as numbered primitives (module a few ABI issues which might affect the
> actual outcome of a benchmark).
Unless we want to make damn big table somewhere I'd suggest putting the
address of the relevant prim function in the cache instead of the index
we currently use. Slang isn't terribly clean for this but never mind.
Sure we can come up with something.

Further advantages;
could cache more specialized versions of byteAt/put/wordat/put/etc thus
speeding up the frequent scanning of homogeneous lists.
could possibly find some way to add pre/post functions for
profiling/assert/debug vms.
could have a 'primfailed and the method has not bytecodes so just return
self' pseudoprim. Actually I guess we already have that in prim 256 but
we'd have to do work to decide to use it.



tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Performance proven: It works through beta test.