[Vm-dev] Re: Pragmas in VMMaker

Andreas Raab andreas.raab at gmx.de
Tue Sep 7 17:02:41 UTC 2010


++1 (i.e., double-plus-good :-)

FWIW, the main advantage I see when using method tags is that we don't 
need to carry all of these Object>>var:declareC: methods around. While 
not a problem for plugins, they can be a real hazzle for inline 
primitives such as Bitmap>>compress:toByteArray: etc.

Cheers,
   - Andreas

On 9/7/2010 9:56 AM, David T. Lewis wrote:
>
> On Tue, Sep 07, 2010 at 09:15:48AM -0700, Eliot Miranda wrote:
>>
>> On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi<leves at elte.hu>  wrote:
>>
>>> On Sun, 5 Sep 2010, Rob Withers wrote:
>>>
>>>   I did some rework so that all plugins build on Cog.  This mainly entailed
>>>> pulling MD5Plugin from a previous version and renaming several methods
>>>> implemented with the same name in MD5Plugin and SHA256Plugin.  The version
>>>> is
>>>>
>>>
>>> What was the point of renaming those methods? In MD5Plugin those methods
>>> are generated as the category and the method comment states. So renaming
>>> them without changing the code that generates those methods is not a good
>>> idea.
>>> Also the codegenerator should be updated a bit. It should generate code for
>>> both litte- and big-endian machines and the C compiler should decide which
>>> method to use based on the platform, so the C code can be shared.
>>> The current code in the package is generated for 32-bit little-endian
>>> machines (it may work for 64-bit but that has to be checked).
>>>
>>>
>>>   the latest with 'oscog' as the initials.
>>>>
>>>
>>> I think that the plugin code (Smalltalk) should be the same for SqueakVM
>>> and CogVM, using the non-pragma declarations.
>>>
>>
>> I agree that they should be the same but feel they should /use/ the pragma
>> declarations.  We can easily post the pragma declarations support into the
>> standard Slang (we should merge Cog's and the standard) and as discussed a
>> few weeks ago there really isn't a compelling argument that says one needs
>> to be able to run VMMaker in old versions.  That's quite a different
>> statement to saying it's not useful to support older VMs; it is.  But the VM
>> definition code doesn't need to be backwards-compatible, unless we want to
>> be truly shackled.
>>
>
> This topic was covered in a thread on vm-dev here:
> http://lists.squeakfoundation.org/pipermail/vm-dev/2010-July/005077.html
>
> Since that time (July) we have heard no one express an interest in running
> VMMaker in images that do not support pragmas. While I personally prefer
> the non-pragma declarations (probably due to my natural luddite tendencies),
> I think we need to defer to Eliot to cast the deciding vote here.
>
> So one last time - does anyone out there care about running VMMaker on older
> images that do not support Pragmas? If not, then the decision is made and we
> will follow Eliot's lead.
>
> What this means:
>
> The classic SqueakVM in project VMMaker, including all plugins maintained
> in that package, will be updated to use Pragmas exactly as in Cog. This
> will reduce the cosmetic differences between Cog and the traditional
> interpreter, and will make it easier to identify the real differences that
> need to be merged or otherwise addressed.
>
> The old non-pragma declarations should still work, so if you are maintaining
> a plugin outside of the VMMaker project, you will not be forced to change
> the declarations in your package. It will be considered good form if you do,
> but it should not be required.
>
> Dave
>
>



More information about the Vm-dev mailing list