Closure bytecodes added to VM (was: [squeak-dev] Status of 4.0)
David T. Lewis
lewis at mail.msen.com
Thu Feb 19 04:03:17 UTC 2009
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 <lewis at mail.msen.com> 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
> >
> >
> >
> >
More information about the Squeak-dev
mailing list
|