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

[H. Hirzel]

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>
>> 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>
>
> 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

"It depends".

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.

--Hannes

>>>
>>>
>>> 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.
>