[Vm-dev] Pragmas in VMMaker (was: Cryptography plugins

Eliot Miranda eliot.miranda at gmail.com
Thu Jul 22 02:48:22 UTC 2010


On Wed, Jul 21, 2010 at 6:56 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Wed, Jul 21, 2010 at 12:42:06AM -0700, Andreas Raab wrote:
> >
> > On 7/20/2010 7:10 PM, David T. Lewis wrote:
> > >The current VMMaker for SqueakVM does not use or support pragmas
> > >(method annotations). Converting to pragmas makes VMMaker unloadable
> > >in older Squeak images.
> >
> > But these Squeak images won't run on the generated VM either. There is a
> > point and a time when it's worthwhile to move forward and given that
> > we've just hit a new major version in Squeak it seems quite reasonable
> > to say that the VMMaker 4 series requires Squeak 4 to run on.
>
> Actually many older images do run on the latest VMs. I frequently
> run Squeak 3.6 (and sometimes Squeak 2.4) on the latest VM whenever
> I want to look at older versions of methods to figure out how they
> were originally intended to work. I do expect these older images
> to run on newer VMs to the extent possible.
>
> I regularly run VMMaker in a 3.8 image, and I always run that image
> on the latest generated VM. But the only real reason I do that is
> to verify some degree of backward compatibility for VMMaker updates,
> so I don't really know if this matters to anyone else.
>
> Certainly for most of the folks on this list, doing VM work in
> a recent Squeak, Pharo, or Cuis image is a reasonable expectation.
> On the other hand, there may still be people who for various reasons
> prefer to use other images, and it would be nice if the most up to
> date VMMaker remains loadable in those images where possible.
>

I don't see the rationale.  If one wants to produce a VM for an older image
I don't see why one needs to be able to run the VMMaker in that image.  What
am I missing?



> If anyone on the list *does* know of a need for VMMaker to work
> on images that do not support pragmas, please speak up now so we
> do not cause unnecessary problems.
>
> I am also curious about the motivation for using method annotations
> here. Is it a style preference, or is there a functional benefit?
>

They're much neater in that they need no associated implementation, and in
the VMMaker's case since they're purely used for communicating with Slang
that's goodness (I think pragmas having implementations is a good thing in a
Smalltalk context, e.g. preferences, menu building etc).  It means the
simulator doesn't execute them.  It means less work for Slang to extract
them.  They're much easier to browse and analyse because the arguments are
immediately available; with messages in bytecode one needs to compile the
method and walk the parse tree to extract arguments.

I added quite a few pragmas, doNotGenerate, doNotGenerate: api api:
asmLabel: cmacro: volatile, and it was much easier to do than the fake
method in object, parse tree walk approach necessitated by the old scheme.
 In short, leaner 'n meaner.

But the Slang in Cog does support the older source annotations.  TMethod &
SmartSyntaxPluginTMethod recordDeclarations still walk the parse tree to
check for old annotations, so the Cog Slang should, fingers crossed, still
translate the current VMMaker Interpreter.  That would be a worth-while
experiment to see if it produces a functional interpreter.

If you do think of moving forward to pragmas I have some scripts I used to
convert the VMMaker to pragmas wen I started on Cog, but I think Lukas'
Squeak/Pharo rewrite editor from the refactoring browser is a much better
way of doing it.  I've recently taken the Cog interpreter out from under
ObjectMemory using Lukas' fork of the rewrite editor.  Let me know and I can
lend a hand developing a script to convert from null messages to pragmas.

best,
Eliot



> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100721/a9c2d1a1/attachment.htm


More information about the Vm-dev mailing list