[Vm-dev] VM Maker: VMMaker-dtl.302.mcz

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 12 18:25:23 UTC 2013


On Tue, Mar 12, 2013 at 11:04 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> 2013/3/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> > 2013/3/12 Eliot Miranda <eliot.miranda at gmail.com>:
> >>
> >> Hi Dave,
> >>
> >>     thanks, but...
> >>
> >> On Sat, Mar 9, 2013 at 7:06 AM, <commits at source.squeak.org> wrote:
> >>>
> >>>
> >>> Item was changed:
> >>>   ----- Method: VMMaker class>>versionString (in category 'version
> testing') -----
> >>>   versionString
> >>>
> >>>         "VMMaker versionString"
> >>>
> >>> +       ^'4.10.13'!
> >>> -       ^'4.10.12'!
> >>
> >>
> >> I *hate* the above.  It is busy work (it must be done manually before
> each commit).  It is really easy to forget to do.  It is meaningless
> (because it is easy to forget it makes no guarantee that it identifies a
> unique version). It is not a good search key.  Mapping the version number
> into the software configuration that produced the C code is hard (you have
> to trawl through Monticello packages searching for the version with the
> relevant version string; you can script this but fer christ's sake...).
> >>
> >> Using the Monticello package name and version (with the dirty marker)
> on the other hand is automatic, is a really good key, and is meaningful.
>  So please can we discard VMMaker versionString and move to using the
> Monticello package?  Please?  Please.
> >> --
> >> best,
> >> Eliot
> >>
> >
> > +1, the two requirements are
> > - automatic
> > - meaningful
>
> However, there is also a dependency on external source (platform...),
> and I think it is also included in COG id no?
>

Yes.  To mark the generated sources, the Cog VMMaker does this:

For each source file generated, the Cog CCodeGenerator adds a comment
containing the Smalltalk class and its VMMaker version that is translated
to C and the Slang class and its version, e.g. from src/vm/gcc3x-cointerp,c:

/* Automatically generated by
    CCodeGeneratorGlobalStructure VMMaker.oscog-eem.272 uuid:
8f4167f2-5bf0-4d90-9b7f-5355c741c68f
   from
    CoInterpreter VMMaker.oscog-eem.272 uuid:
8f4167f2-5bf0-4d90-9b7f-5355c741c68f
 */

and from src/plugins/AsynchFilePlugin/AsynchFilePlugin.c

/* Automatically generated by
    SmartSyntaxPluginCodeGenerator VMMaker.oscog-eem.235 uuid:
954df856-3f83-498c-9735-6cd3777ba9c7
   from
    AsynchFilePlugin VMMaker.oscog-eem.235 uuid:
954df856-3f83-498c-9735-6cd3777ba9c7
 */

and for the misc primitives you'll also get the class contributing the
primitive implementation (which in this case has a dirty package) so from
src/plugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c

/* Automatically generated by
    VMPluginCodeGenerator VMMaker.oscog-eem.248 uuid:
325b96ad-3c25-438e-af36-04a93839f195
   from
    ADPCMCodecPlugin VMMaker.oscog-eem.248 uuid:
325b96ad-3c25-438e-af36-04a93839f195
    ADPCMCodec * Sound-ar.30 uuid: c0c6133c-73b7-7b47-9858-99b64868d35c
 */

Then each file has a static string containing the source class(es), e.g.

static char __buildInfo[] = "CoInterpreter VMMaker.oscog-eem.272 uuid:
8f4167f2-5bf0-4d90-9b7f-5355c741c68f " __DATE__ ;
char *__interpBuildInfo = __buildInfo;


static char __buildInfo[] = "ADPCMCodecPlugin VMMaker.oscog-eem.248 uuid:
325b96ad-3c25-438e-af36-04a93839f195\n\
ADPCMCodec * Sound-ar.30 uuid: c0c6133c-73b7-7b47-9858-99b64868d35c "
__DATE__ ;

So you'd think you can grep for these in the VM binary, via e.g. strings -
Fast.app/Contents/MacOS/Croquet | grep ADPCMCodecPlugin.  But the optimizer
removes the strings.  This needs to be fixed.

Then the build info for the interpreter, and the cogit (if there is one),
is exported for Smalltalk getSystemAttribute: 1007 and 1008.
Then the C repository version info for the root and Cross/plugins is
exported for attribute 1009.  And as always the C compiler build info is
attribute 1006.

e.g.
(1006 to: 1009) collect: [:i| Smalltalk getSystemAttribute: i]
#('Mac OS X built on Mar 11 2013 14:06:19 Compiler: 4.2.1 (Apple Inc. build
5666) (dot 3)'
'CoInterpreter VMMaker.oscog-eem.272 uuid:
8f4167f2-5bf0-4d90-9b7f-5355c741c68f Mar 11 2013'
'StackToRegisterMappingCogit VMMaker.oscog-eem.270 uuid:
014f0153-bb02-49b7-b544-d8f3ac2deef6 Mar 11 2013'
 'VM: r2701 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545
http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins')

With the uuid there's no need to specify repository name, and anyway
repositories are neither permanent institutions, nor unique to packages.

So IMO the Cog branch (and I think the Pharo branch) has the right info.
 From the binary one can map back to both C and Slang/VMMaker.  From the C
one can map back to Slang/VMMaker.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130312/30583ffc/attachment-0001.htm


More information about the Vm-dev mailing list