headers
sig | 29 Apr 04:25

Some notes concening VM :)

Hello , i'm new here and have particular interests in developping a Slate VM.
I didn't decided yet if i will participate in this project in nearest
future, so i just want to discuss some of my ideas with you for now.

Concerning OMM (object memory model) and stack organization.
I'm refer to tables which you can see on this page:
http://slate.tunes.org/doc/mobius/

5.1.1 stack format.

Table 3. Block format.

I see little reason why selectors must be kept apart from literals.
The only place i see where they handled differently is at
interpretation stage to use different opcode 'Load Selector'.
If there's no extra processing except that, we can merge selectors
with literals slot and remove an opcode 'Load Selector'.

This is the code that shows that they handled in same manner..

static INLINE void PSInterpreter_loadLiteral_(struct Interpreter * i,
unsigned long int n)
{
  PSInterpreter_stackPush_(i, (((i -> method) -> literals) -> elements)[n]);
}

static INLINE void PSInterpreter_loadSelector_(struct Interpreter * i,
unsigned long int n)
{
  PSInterpreter_stackPush_(i, (((i -> method) -> selectors) -> elements)[n]);
(Continue reading)

Permalink | Reply |
headers
Brian Rice | 29 Apr 19:53

Re: Some notes concening VM :)


On Apr 28, 2007, at 7:25 PM, sig wrote:

> Hello , i'm new here and have particular interests in developping a  
> Slate VM.
> I didn't decided yet if i will participate in this project in nearest
> future, so i just want to discuss some of my ideas with you for now.
>
> Concerning OMM (object memory model) and stack organization.
> I'm refer to tables which you can see on this page:
> http://slate.tunes.org/doc/mobius/
>
> 5.1.1 stack format.
>
> Table 3. Block format.
>
> I see little reason why selectors must be kept apart from literals.
> The only place i see where they handled differently is at
> interpretation stage to use different opcode 'Load Selector'.
> If there's no extra processing except that, we can merge selectors
> with literals slot and remove an opcode 'Load Selector'.
>
> This is the code that shows that they handled in same manner..
>
> static INLINE void PSInterpreter_loadLiteral_(struct Interpreter * i,
> unsigned long int n)
> {
>  PSInterpreter_stackPush_(i, (((i -> method) -> literals) ->  
> elements)[n]);
> }
(Continue reading)

Permalink | Reply |
headers
sig | 30 Apr 06:50

Re: Some notes concening VM :)

> Well, I can say that for introspection, it is easier to tell what
> selectors a method sends if they are in a separate array, so easier
> to track down a call graph without referring to source code. Granted,
> in the general case, plenty of those literal Symbols are also used by
> sendTo: and variants, or Symbols can be generated at run-time by the
> method, but this makes the base case easier. Also granted, just doing
> "method literals select: [| :each | each is: Symbol]" isn't that much
> harder (although is: is kind of expensive in aggregate). So I
> wouldn't fight much for this one.

as i see the CompiledMethod structure holds a sourceTree object, which
i suppose holds exact answers on what literals is selectors and what
is symbols or something else.
Im just against sacrificing the runtime model simplicity in favor of
analysis, which can be simply accessible through other means.

> > Why interpreter must spend its time to calculate index value (see the
> > PSInterpreter_decodeImmediate function) , when its value already known
> > at compilation time and we already can say if it fits in 1 byte code
> > or 2 bytes or 3?
>
> These are good points, and worth considering, but I think it'd be
> worth some profiling time to know what the real costs/benefits are.
>

My approach is simple: minimalize number of operations required to
evaluate single opcode instruction.The less we have - the more we
gain.

> > The next things is concerning stack organization.
(Continue reading)

Permalink | Reply |

Gmane