Thoughts on a concurrent Squeak VM

Igor Stasenko siguctua at gmail.com
Wed Oct 31 20:46:16 UTC 2007


On 31/10/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > There are already some steps done in this direction. A sources for
> > RISC architecture generate a foo struct , which holds all interpreter
> > globals.
> > Also, i did some changes in Exupery to create a single struct of all
> > VM globals (not only variables, but functions too).
> > This was done to make it easier to get address of any global symbol
> > what Exupery needs.
> > I'm also experimented to replace all direct calls to function to
> > indirect (i.e. foo->primAdd(x,y) instead of primAdd(x,y)). This caused
> > about ~1% of speed degradation in tinyBenchmarks :)
>
> Ah, indeed, I forgot about that.
>
> > Also, moving forward on this renders an InterpreterProxy struct
> > useless, because we can just pass an address to our 'foo' struct to
> > plugins which already contains everything what plugin can reach.
>
> But this isn't quite true. One of the reasons for the proxy is to
> abstract from the actual implementation since C doesn't do proper name
> lookup for names but rather uses indexes. And so, if you happen to add
> or remove a method from that struct, your plugins will be screwed ;-)
>

You mean for dynamically linked plugins? Yes, that can be a problem.
But again, a struct which is generated contains not only address of a
variable, but names too (in string literals).

a single entry for function:
	accessibleObjectAfter, "accessibleObjectAfter:", "sqInt
(*accessibleObjectAfter)(sqInt oop)",

a single entry for a var:
	&activeContext, "activeContext" , "<var>".

So, there is enough info to get everything you need even with dynamic linkage.
And even without linkage, you can parse a function prototypes and use
some FFI to call them :)
All you need is to have a pointer to that struct and number of entries.

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list