[Vm-dev] HackerNews + vm-dev = a lightbulb saying "STACK!"

Eliot Miranda eliot.miranda at gmail.com
Thu Oct 11 01:34:12 UTC 2012


On Wed, Oct 10, 2012 at 3:23 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 10 October 2012 22:55, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney <colin at wiresong.com>
> wrote:
> >>
> >>
> >> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda <
> eliot.miranda at gmail.com> wrote:
> >>
> >> > Right now I'm redesigning the bytecode set to lift limits on branch
> distances, number of literals, and number of inst vars.  So a small
> increment.
> >>
> >> I suppose that Newspeak is different from Smalltalk in terms of the
> >> size and complexity of methods that it encourages. It could be that
> >> the existing limits are blocking the development of Newspeak, and
> >> obviously legacy code is much less of an issue for Newspeak than
> >> Squeak.
> >
> >
> > Not newspeak.  But within Cadence we have internal customers that are
> hitting limits we must lift.
> >
>
> <trolling>
> perhaps then it would cost less to customers to attend a small course
> on programming basics then?
> </trolling>
>

hint, our internal customers are not using either Smalltalk or Newspeak; we
are compiling a third language down to the bytecode.


>
> The biggest bloat of inst vars, which i ever seen in smalltalk is
> Interpreter & ObjectMemory classes.
> And this is mainly because this code has to be translated to C due to
> limitations/design of VMMaker.
> But VMMaker is special. A regular code don't requires so much state
> kept per single object.
>
> Now, it is hard to imagine, how much more complex the software must be
> that it requires even more instances in class than those two?
> Especially when you saying it is not because of Newspeak.
>
> These news saddening me a lot.
>
> >>
> >>
> >> But… isn't that an odd cost/benefit mismatch? It would seem that
> >> switching instruction sets isn't easy, even given VM support. Are
> >> there no other changes that could/should be made at the same time?  Is
> >> this something we could imagine doing more than once in the near
> >> future?
> >
> >
> > I had reason to add support for two bytecode sets to the VM recently so
> all the support at the VM level is there to do incremental development of
> the new bytecode set.  i'm writing the image-level support (you'll perhaps
> have noticed the fag to select the bytecode set added to trunk recently).
>  I can imagine having multiple bytecode sets being very useful and
> something one does quite often.  Claus Gittinger's Smalltalk/X has support
> for four bytecode sets and can execute Java bytecode natively.  With the
> current header format I've only been able to shoe-horn in a single one.
> >
> > Making lots of changes at one time is a way of increasing the risk of
> failure.
> >
> >>
> >>
> >> Colin
> >
> >
> >
> >
> > --
> > best,
> > Eliot
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20121010/dad19b68/attachment-0001.htm


More information about the Vm-dev mailing list