Closure bytecodes added to VM (was: [squeak-dev] Status of 4.0)

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

Closure bytecodes added to VM (was: [squeak-dev] Status of 4.0)

David T. Lewis
 
Eliot,

Excellent, thanks for committing this directly to the SqueakSource project.
I'm short of time now but look forward to building a VM with closure
bytecodes this weekend.

(subject line changed, and CC to vm-dev list)

Dave

On Wed, Feb 18, 2009 at 05:50:33PM -0800, Eliot Miranda wrote:

> On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
> > >
> > > On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
> > > >Works for me.  When and if the VM is no longer backwards-compatible
> > > >(e.g. the Stack VM) one can move to 5.0.
> > > >However, I would recommend getting the VM changes into the 4.0 VM as
> > > >this will make migrating to image-level closures much easier.  I
> > > >believe (John, can you confirm) that John's latest Mac 3.8 beta VMs
> > > >have included the closure bytecodes.
> > >
> > > Well I've not done that (yet) was waiting on Eliot for the latest VM
> > > changes before christmas. Then I've been
> > > distracted by an iPhone application.
> > >
> > > I recall David T and I last discussed the issues around the source
> > > code changes and how it cheerfully
> > > upgrades your image, which then makes it un-run-able  on the raft of
> > > VMs one has on one's machine, but
> > > I recall we thought we could tie the image version change on save to
> > > only happen if in fact the image
> > > *uses* the closure bytes code.
> >
> > Right, Eliot's bytecode changes are fully backward compatible, so they
> > can be added to VMMaker without breaking anything. The image version
> > numbering change needs to be left out for now, but that's a small issue
> > that can be the subject of separate discussion.
>
>
> I've fixed the image numbering version issue.  The VM has a variable holding
> the version number which is initialized to teh standard version.  If the
> create-closure bytecode is evaluated it changes to the new version.  Hence
> the VM can safely be used for both old and new and will not change the image
> version unless it should be changed.
>
> Eliot, if you can confirm that the bytecode changes are ready for
> > release, and that the license is <whatever>, then I'll volunteer to
> > add your bytecode bootstrap changes to the Squeaksource VMMaker project
> > and make whatever minor changes are needed to avoid the image numbering
> > glitch.
>
>
> They're ready for your and John's review.  See
>     Name: VMMaker-eem.114
>     Author: eem
>     Time: 18 February 2009, 5:42:18 pm
>     UUID: 169887e2-d54c-43a6-9042-eabfcaa08146
>     Ancestors: VMMaker-dtl.113
> in http://squeaksource.com/VMMaker.  There's a verbose version comment
> describing the changes.  It omitted to mention that in the version of
> Monticello I'm using class variables appear in alphabetical order and hence
> there are some artificial changes in class definitions.
>
> The license is the new Squeak license because I am the author of these
> changes and have informed Yoshiki that I assent to the new Squeak licencing
> scheme.  Sorry for being so inarticulate; I'm not sure what the right form
> of words  is for this :/
>
> Best
> Eliot
>
> P.S.  John and David, thanks for your help today, and apologies for the
> delay.
>
> >
> >
> > Dave
> >
> >
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Closure bytecodes added to VM (was: [squeak-dev] Status of 4.0)

David T. Lewis
 
FYI, Eliot's closure bytecode support is now included in VMMaker on SqueakSource
as VMMaker-eem.114. A couple of updates were required to get this to load into
a vanilla Squeak image; these are in VMMaker-dtl.115.

The changes are backward compatible, and it is safe to use this for general
purpose VM building. There are a number of new numbered primitives, and I
can't say if these might cause conflicts with other VM projects (Exupery?).

Dave

On Wed, Feb 18, 2009 at 11:03:17PM -0500, David T. Lewis wrote:

>  
> Eliot,
>
> Excellent, thanks for committing this directly to the SqueakSource project.
> I'm short of time now but look forward to building a VM with closure
> bytecodes this weekend.
>
> (subject line changed, and CC to vm-dev list)
>
> Dave
>
> On Wed, Feb 18, 2009 at 05:50:33PM -0800, Eliot Miranda wrote:
> > On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis <[hidden email]> wrote:
> >
> > > On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
> > > >
> > > > On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
> > > > >Works for me.  When and if the VM is no longer backwards-compatible
> > > > >(e.g. the Stack VM) one can move to 5.0.
> > > > >However, I would recommend getting the VM changes into the 4.0 VM as
> > > > >this will make migrating to image-level closures much easier.  I
> > > > >believe (John, can you confirm) that John's latest Mac 3.8 beta VMs
> > > > >have included the closure bytecodes.
> > > >
> > > > Well I've not done that (yet) was waiting on Eliot for the latest VM
> > > > changes before christmas. Then I've been
> > > > distracted by an iPhone application.
> > > >
> > > > I recall David T and I last discussed the issues around the source
> > > > code changes and how it cheerfully
> > > > upgrades your image, which then makes it un-run-able  on the raft of
> > > > VMs one has on one's machine, but
> > > > I recall we thought we could tie the image version change on save to
> > > > only happen if in fact the image
> > > > *uses* the closure bytes code.
> > >
> > > Right, Eliot's bytecode changes are fully backward compatible, so they
> > > can be added to VMMaker without breaking anything. The image version
> > > numbering change needs to be left out for now, but that's a small issue
> > > that can be the subject of separate discussion.
> >
> >
> > I've fixed the image numbering version issue.  The VM has a variable holding
> > the version number which is initialized to teh standard version.  If the
> > create-closure bytecode is evaluated it changes to the new version.  Hence
> > the VM can safely be used for both old and new and will not change the image
> > version unless it should be changed.
> >
> > Eliot, if you can confirm that the bytecode changes are ready for
> > > release, and that the license is <whatever>, then I'll volunteer to
> > > add your bytecode bootstrap changes to the Squeaksource VMMaker project
> > > and make whatever minor changes are needed to avoid the image numbering
> > > glitch.
> >
> >
> > They're ready for your and John's review.  See
> >     Name: VMMaker-eem.114
> >     Author: eem
> >     Time: 18 February 2009, 5:42:18 pm
> >     UUID: 169887e2-d54c-43a6-9042-eabfcaa08146
> >     Ancestors: VMMaker-dtl.113
> > in http://squeaksource.com/VMMaker.  There's a verbose version comment
> > describing the changes.  It omitted to mention that in the version of
> > Monticello I'm using class variables appear in alphabetical order and hence
> > there are some artificial changes in class definitions.
> >
> > The license is the new Squeak license because I am the author of these
> > changes and have informed Yoshiki that I assent to the new Squeak licencing
> > scheme.  Sorry for being so inarticulate; I'm not sure what the right form
> > of words  is for this :/
> >
> > Best
> > Eliot
> >
> > P.S.  John and David, thanks for your help today, and apologies for the
> > delay.
> >
> > >
> > >
> > > Dave
> > >
> > >
> > >
> > >