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

[Frank Shearar]

On 11 October 2012 08:45, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
> 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.

Is that from a large PPCompositParser? (Because each rule manifests as
an instvar initialised as a delegate parser. Delegates are lazily
resolved post initialisation.)

frank

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