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

On 10 October 2012 22:55, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
>
>
> On Wed, Oct 10, 2012 at 11:53 AM, Colin Putney <colin@wiresong.com> wrote:
>>
>>
>> On Wed, Oct 10, 2012 at 10:22 AM, Eliot Miranda <eliot.miranda@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