[Vm-dev] HackerNews + vm-dev = a lightbulb saying "STACK!"
hannes.hirzel at gmail.com
Thu Oct 11 07:45:40 UTC 2012
On 10/11/12, 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>
>>> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda <eliot.miranda at gmail.com>
>>> > 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
>> Not newspeak. But within Cadence we have internal customers that are
>> hitting limits we must lift.
> perhaps then it would cost less to customers to attend a small course
> on programming basics then?
> 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.
The answer is
Normally having more 255+ instance variables is a sign of bad design.
But not always. There are exceptions. It depends on the problem domain
and business case.
I actually welcome that this limitation is lifted because of
PetitParser (though Lukas has a workaround). At the moment I have not
hit the limit yet.
>>> 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
>> 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
> Best regards,
> Igor Stasenko.
More information about the Vm-dev