Re: [squeak-dev] Crypto Plugins on Cog

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Crypto Plugins on Cog

Eliot Miranda-2
 


On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi <[hidden email]> 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.

best
Eliot



Levente



All test pass GREEN.

Rob



Reply | Threaded
Open this post in threaded view
|

Pragmas in VMMaker (was: Crypto Plugins on Cog)

David T. Lewis
 
On Tue, Sep 07, 2010 at 09:15:48AM -0700, Eliot Miranda wrote:

>  
> On Mon, Sep 6, 2010 at 11:30 PM, Levente Uzonyi <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Pragmas in VMMaker

Andreas.Raab
 
++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<[hidden email]>  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
>
>