[Vm-dev] Re: goto instruction with Cog VM

[Ralph Boland]

> Hi Ralph,
...

> >
> > I was aware of caseOf: in Squeak.  I always found it awkward to use and
> > felt a true case statement would be simpler.  Alas, it's impossible to
> > have a true case statement added to Smalltalk now I think.

> So what's a "true" case statement?  For me, at least, the Squeak one *is*,
> and is more general than one limited to purely integer keys, as for
example
> is C's switch statement.  A number of languages provide case statements
> that are like Squeak's.  What do you consider a "true" case statement?

I mean that:  caseOf: is not part of the language itself but rather part of
the
standard library or set of packages that one finds in the IDE.  To be part
of the
language it would need to be something the compiler is aware of.  That is to
day the Smalltalk language is not very much.  Smalltalk (Squeak) the
language
would not include Sets or Dictionaries but would include (some) Array
classes
because some aspects of Arrays are dealt with directly by the compiler.
Selectors such as  ifTrue: and  to:do:  are part of the language because
they are inlined by the compiler.
Put another way,  if I could get my doBlockAt: method incorporated into the
Squeak IDE
it would nevertheless NOT be part of Squeak the language.
The consequence of  caseOf:  not being part of the language is that the
compiler/VM
cannot perform optimizations when caseOf:  is run into but must treat it as
user written code.

Squeak's  caseOf:  is more general than C's switch statement but it could
be more
general in that there is a hard coded message (=).  I would like to be able
to replace
the '=' message by an arbitrary binary operator such as  includes:  or '>'.

I have to backtrack here:  I looked at the code and it looks like the
compiler inlines
caseOf:  and caseOf:otherwise.  If so then these selectors are part of the
language
by my definition.

...

> > But I wouldn't want to be forced to implement my FSMs this way.
> > It might be acceptable for small FSMs.
> > I want to avoid sequential search and
> >  even binary search might be rather expensive.
> > I look at computed gotos as the solution but,
> > as you pointed out, computed gotos pose problems for JIT.
> > Admittedly, for large FSM's, it might be best or necessary to
> > use a FSM simulator anyway, as I do now.


> Nah.  One should always be able to map it down somehow.  Tis will be
easier
> with the Spur instruction set which lifts number of literals and length of
> branches limits.

Good to hear.


> > Again, for my FSM, case this would often be considered to be good.
> > But if the state transition tables are sparse then Dictionaries
> > might be preferable to Arrays.
>

> Yes, but getting to the limit of what the VM can reasonably interpret.
> Better would be an Array of value. pc pairs, where the keys are the values
> the switch bytecode compares top of stack against, and the pcs are where
to
> jump to on a match.  The JIT can therefore implement the table as it sees
> fit, whereas the interpreter can just do a linear search through the
Array.

I am looking at this from the point of view of a compiler writer/generator
and consider
your proposal as inadequate for my needs.  You, I think, are looking at
this from
the point of view of a VM writer and what can reasonably be delivered.  I
don't think
what I want is overly difficult for the interpreter to deliver but as you
pointed out,
and you know much better than I, what I want causes serious problems for
the VM.

> > My expection is that  at:  be sent to the collection object
> >  to get the address to go to.  Knowing that the collection
> > is an array though makes it easier for the compiler/VM to
> > ensure that the addresses stored in the collection are valid.
> > Actually, the compiler will be generating the addresses.
> > Does the VM have absolute trust in the compiler to generate valid
> > addresses?


> Yes.  Generate bad bytecode and the VM crashes.

This is what I expected to hear but wanted it to be clear for compilers
generated
by my parser generator tool as you did.

Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141108/dfd4082c/attachment.htm