----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>


> On 31/10/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
>> sqInt primitiveAdd(void) {
>>    integerResult = stackIntegerValue(1) + stackIntegerValue(0)
>>    /* etc. */
>> }
>>
>> will then become something like here:
>>
>> sqInt primitiveAdd(struct VM *vm) {
>>    integerResult = stackIntegerValue(vm,1) + stackIntegerValue(vm,0)
>>    /* etc. */
>> }
>>
>> This is a *purely* mechanical step that can be done independent of
>> anything else. It should be possible to generate code that is entirely
>> equivalent to todays code and with a bit of tweaking it should be
>> possible to make that code roughly as fast as we have today (not that I
>> think it matters but understanding the speed difference between this and
>> the default interpreter is important for judging relative speed
>> improvements later).
>>
>
> 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 :)

Wouldn't this mean that consideration of using C++ isn't off the mark? 
There would be some degradation of performance.  However, there would be the 
benefit of structuring the VM classes, of not having to add VM as an 
argument everywhere, and it may even be possible to subclass Thread so we 
know where the thread-local storage is.

Just a thought.