VM pluginisation and misc primitives

Raab, Andreas Andreas.Raab at disney.com
Sat Feb 26 06:23:47 UTC 2000


Tim,

> [...] I've come up against some mildy ugly places where
> prims are generated using code in various (for example) sound 
> related classes.

Could you say more about what you mean by this?!

> The implementation of translating these methods 
> (FMSound>mixSamples....  is one case) is very clever but 
> produces code that has to link with the main VM.

Theoretically this should not be the case - all the necessary stuff is
exported through the interpreter proxy and looking at FMSound>>mixSamples...
appears to be relatively trivial to translate (no message sends to any other
place).

> Since I want to pull the prims out and move them 
> to plugins I think I can see two feasible choices:-
> a) take the 25(? any more known?) prims created via 
> #codeStringForPrimitives: and rewrite them. Bit tricky, fairly 
> tedious, but only needs doing once.
> b) mangle the codegen some more and make it able to produce 
> plugin-style code for these cases. Pretty tricky, lots of room 
> for breaking the VM code generation, but would allow future use 
> of the same idiom for writing prims.

In theory (e.g., if I have my homework done right when originally working on
the PluggableCodeGenerator) all you need to do is to change the primitive
index into a primitive name and generate the code for it. If that doesn't
work, please let me know what the problems are. BTW, there are examples
using this mechanism in FloatArray category 'primitives-translated' - that's
what I used for testing the stuff.

> I don't allow windows machines in the house. :-)

You sure?! What's running on your cell phone?! ;-)

  Andreas





More information about the Squeak-dev mailing list