Introducing Huemul

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Guillermo Adrián Molina
> Enviado el: Lunes, 21 de Mayo de 2007 19:56
> Para: Discussion about Exupery a native code compiler.
> Asunto: Introducing Huemul
>
> I would be pleased if you could take a look at:
>
> http://www.guillermomolina.com.ar/huemul/index.php
>
> There you will find information to download a demo of the
> Smalltalk implementation that translates st code directly to
> assembler, using Exupery as the final compiler phase.
>
> Please let me know what you think.
>
> Regards, Guille
>
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

>
> Guille,
>
> can this be used to take a normal squeak and transform it's image
> into something that runs like huemul?
>
> cheers,
>
> Sebastian
>
>

>
> Guille,
>
>         can this be used to take a normal squeak and transform it's image
> into something that runs like huemul?
>
>         cheers,
>
> Sebastian
>
> > -----Mensaje original-----
> > De: [hidden email]
> > [mailto:[hidden email]] En nombre
> > de Guillermo Adrián Molina
> > Enviado el: Lunes, 21 de Mayo de 2007 19:56
> > Para: Discussion about Exupery a native code compiler.
> > Asunto: Introducing Huemul
> >
> > I would be pleased if you could take a look at:
> >
> > http://www.guillermomolina.com.ar/huemul/index.php
> >
> > There you will find information to download a demo of the
> > Smalltalk implementation that translates st code directly to
> > assembler, using Exupery as the final compiler phase.
> >
> > Please let me know what you think.
> >
> > Regards, Guille
> >
> > _______________________________________________
> > Exupery mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

> For example: i know a good guy 'gulik' on IRC who is already doing a
> namespaces. So better to help him, rather than implement own.
> And there's many other areas which intersects with your goals, like
> HTML, GUI, Dynamic class loading e.t.c.
> I think you just need to focus on narrow area - making a good and fast
> VM, and then just share your code with others and reuse their code for
> own matters.
> Don't think that i want to offend you in this way, i'm just thinking
> it would be better for you as well as for community.
>

>
> > great job.
> Thank you very much.
>
> > I'm just wondering, why its not a part of squeak :)
>
> Well, that's Bryce job :-)
> I mean. Exupery will be part of Squeak one day (a very important one).
> But Exupery is facing with the fact that most Squeak's internals can't be
> changed.
> I have the ability to change what ever I want in Huemul. An example, Bryce
> suggested 0 tagged SmallInts. I was using 1 tagged, changed that in a
> week, then Huemul got faster. The fact is that I am really into learning
> things. I didn't know how to implement 0 tagged int. Thanks to Klaus (a
> member of this list), I was able to do it.
> That kind of reaction is more difficult in Squeak.
>
> > At some day i thought, why i want to reinvent the wheel, while there's
> > already a good and working smalltalk implementation with reach set of
> > projects/features.
>
> I completely agree with you on this matters, I will try to make Huemul
> compatible with most of them.
>
> > And i decided to join squeak community, and asking you to do the same.
> > You can benefit from others works, while doing your part.
>
> Believe me, I use Squeak.
> There is another thing. Huemul is a Linux X86-32 application. Squeak
> images run without modification on lots of platforms. It would be very
> difficult to do that with Huemul. I think the target is different.
>
> > For example: i know a good guy 'gulik' on IRC who is already doing a
> > namespaces. So better to help him, rather than implement own.
> > And there's many other areas which intersects with your goals, like
> > HTML, GUI, Dynamic class loading e.t.c.
> > I think you just need to focus on narrow area - making a good and fast
> > VM, and then just share your code with others and reuse their code for
> > own matters.
> > Don't think that i want to offend you in this way, i'm just thinking
> > it would be better for you as well as for community.
> >
>
> Don't worry. I asked you for advise. Everybody is welcome.
>
> Cheers, Guille
>
>
>
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

> Good! Your reply shows me that i may not vorry about this.
>
> Then i would ask you about design of your VM architecture.
> Its better to start from a clean view, that everything in VM could be
> changed at some point.
> And changed by programmer using smalltalk, not C or other external tools.
> I mean, i want a truly flexible system.
> I want to be able the smalltalk VM to rebuild self from scratch
> (producing new VM executable) without using C complier/e.t.c.
> And be able to change any low level primitives in running VM.
> As example - let programmer to decide, how to tag smallintegers , with
> 0 or with 1 ,
> and make this as easy as clicking a single button, just by changing a
> single line of code in single place.
> This will open a wide range perspective, how programmer can experiment
> with VM, how he can add or change its core functionality and test it.
> Another example - suppose we want to run our VM/image on different
> platform. All we need is a hooks (like special binary format,
> accessing to kernel function e.t.c), provided by that platform and
> assembler support from Exupery to generate opcodes suitable for
> platform CPU. The we generate a small bootstrap executable, which then
> can be used for loading image in new platform, and providing a
> bootstrapping mechanism for recompiling a core VM methods contained in
> your image.
> So, you can keep any low-level VM code in your image and be able to
> run it anywhere without dependancy from external tools like C compiler
> or linker e.t.c.
>
> On 23/05/07, Guillermo Adrián Molina <[hidden email]> wrote:
>>
>> > great job.
>> Thank you very much.
>>
>> > I'm just wondering, why its not a part of squeak :)
>>
>> Well, that's Bryce job :-)
>> I mean. Exupery will be part of Squeak one day (a very important one).
>> But Exupery is facing with the fact that most Squeak's internals can't
>> be
>> changed.
>> I have the ability to change what ever I want in Huemul. An example,
>> Bryce
>> suggested 0 tagged SmallInts. I was using 1 tagged, changed that in a
>> week, then Huemul got faster. The fact is that I am really into learning
>> things. I didn't know how to implement 0 tagged int. Thanks to Klaus (a
>> member of this list), I was able to do it.
>> That kind of reaction is more difficult in Squeak.
>>
>> > At some day i thought, why i want to reinvent the wheel, while there's
>> > already a good and working smalltalk implementation with reach set of
>> > projects/features.
>>
>> I completely agree with you on this matters, I will try to make Huemul
>> compatible with most of them.
>>
>> > And i decided to join squeak community, and asking you to do the same.
>> > You can benefit from others works, while doing your part.
>>
>> Believe me, I use Squeak.
>> There is another thing. Huemul is a Linux X86-32 application. Squeak
>> images run without modification on lots of platforms. It would be very
>> difficult to do that with Huemul. I think the target is different.
>>
>> > For example: i know a good guy 'gulik' on IRC who is already doing a
>> > namespaces. So better to help him, rather than implement own.
>> > And there's many other areas which intersects with your goals, like
>> > HTML, GUI, Dynamic class loading e.t.c.
>> > I think you just need to focus on narrow area - making a good and fast
>> > VM, and then just share your code with others and reuse their code for
>> > own matters.
>> > Don't think that i want to offend you in this way, i'm just thinking
>> > it would be better for you as well as for community.
>> >
>>
>> Don't worry. I asked you for advise. Everybody is welcome.
>>
>> Cheers, Guille
>>
>>
>>
>> _______________________________________________
>> Exupery mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>>
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>

> Yes, I would like such a system too.
> But right now, Huemul is very far away from that.
> Huemul's core is still in C. To translate it to ST, I would need your
> compiler.
> That is why I asked you about it. Klaus suggested that it would be
> interesting to use it, just the way you want.
>
> I am getting close to a Huemul release that doesn't need Squeak. When that
> is done. I will finally release source code, for anyone to play with it.
>
> Cheers, Guille
>
> PS: May be the example about changing SmallInts behavior would be a bit
> difficult to implement. Not the part of getting 0 or 1 tagged arithmetic,
> that part would be easy to implement for both behaviors. The problem is
> the way you access the other objects. It is much more difficult to access
> an oop with a 1 tagged int system, than a 0 tagged one. Believe me, the
> hardest part of implementing 0 tagged wasn't the arithmetic part, at
> least, that was my experience with Huemul. But apart from that, I got the
> idea behind the example, and I agree with you.
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de sig
> Enviado el: Jueves, 24 de Mayo de 2007 09:56
> Para: Discussion about Exupery a native code compiler.
> Asunto: Re: Introducing Huemul
>
> Good! Your reply shows me that i may not vorry about this.
>
> Then i would ask you about design of your VM architecture.
> Its better to start from a clean view, that everything in VM
> could be changed at some point.
> And changed by programmer using smalltalk, not C or other
> external tools.

> > Otherwise people will easily be demotivated and efforts
> become quickly diluted.
>
> Yes, sometimes you need to stop the car, because changing the
> tires while driving is impossible. Currently to write a
> plugin i need to use slate, then compile it , stop the car
> (VM) and finally start using it.
> With new architecture, which i propose you don't need to stop
> VM in most cases and you having instant results. So, who
> stops the car? ;)
>
> And if you talking about that i want to replace a slate, then
> i agree, every custom plugin written in slate must be
> rewritten. But who will argue about stopping the car, when
> tires you changing will give you more speed and maneurability?
>
> Also, don't forget that in spite of С compilers having heavy
> optimizing algorithms , they still have limitations which you
> can't avoid, because of language itself. For instance - you
> can't check the integer overflow in C while summing two
> integers. Can't construct a function calls based on
> previously unknown type info, and have no dynamic type system.
>

>From: sig <[hidden email]>
>Reply-To: "Discussion about Exupery a native code
>compiler."<[hidden email]>
>To: "Discussion about Exupery a native code
>compiler."<[hidden email]>
>Subject: Re: Introducing Huemul
>Date: Thu, 24 May 2007 15:55:46 +0300
>
>I want to be able the smalltalk VM to rebuild self from scratch
>(producing new VM executable) without using C complier/e.t.c.

> On Thu, 24 May 2007 16:38:20 +0200, sig wrote:
> > On 24/05/07, Sebastian Sastre wrote:
> >> ... It's 'changing the tire in a running car'. For sustainable projects
> >> we can't 'stop the car'. Otherwise people will easily be demotivated and
> >> efforts become quickly diluted.
> >
> > Yes, sometimes you need to stop the car, because changing the tires
> > while driving is impossible.
>
> Have you considered using a ClassBox, available from SqueakSource.
>
> Let's change one of the tires while on at full speed: create a new
> ClassBox which includes all of your car. In that isolated box change the
> tire. If this works out fine, release the changes to the running car's
> ClassBox. A more practical Smalltalk example is to change the compiler in
> the running system, this needs the compiler.
>

> Yes, and, as I told you before I agree. But this does not give us more
> certainty of a way to do it in practice sustainably. The 'running car'
> metaphore was meant to be read also meaning that one are producting with a
> smalltalk besides developing with it. So, one should stop the car only if
> the costs of stopping are not too high. If one will have to stop several
> short (cheap) times probably will be no big deal. But what happen when you
> have a year of a non producting system? That could easily become inaceptable
> and you should provide alternatives. This is why people other than
> enthusiasts are still using Squeak with no optimizations at all but
> producing real value while others invest it's time in exploring new and
> experimental ways meant to be better ones of making Squeak to run, the
> future of Squeak.
>

>>> car's ClassBox. A more practical Smalltalk example is to change the
>>> compiler in the running system, this needs the compiler.
>>>
>> Thanks for pointing out. I'll check details. I wonder if this
>> concept can be used for hot-swapping VM at runtime .
>>
> If the smalltalk is persistent it certainly could be feasible. In  
> the other
> hand I find difficult to see two VM with hashes and instances  
> assignations
> in sync for a clean swap.
>
> Cheers,
>
> Sebastian
> PS: by persistant I mean a smalltalk that has it's instances  
> "living" in a
> persistent medium and the VM uses the RAM of the computer as a mere  
> cache.
> Based on the blue book and with some theoretical guidelines from  
> Guille here
> I've was able to make a prototype of a persistent ST for business  
> objects
> (it didn't persist contexts and such)

> > Based on the blue book and with some theoretical guidelines from
> > Guille here I've was able to make a prototype of a
> persistent ST for
> > business objects (it didn't persist contexts and such)
>
> That's how Gemstone Smalltalk works. It's got a transactional
> object memory on disk (arbitrary size) and you can run any
> number of VMs on that image concurrently ... pretty cool.
>
> - Bert -
>
>

> Bert Freudenberg writes:
>>> Sebastian
>>> PS: by persistant I mean a smalltalk that has it's instances
>>> "living" in a
>>> persistent medium and the VM uses the RAM of the computer as a mere
>>> cache.
>>> Based on the blue book and with some theoretical guidelines from
>>> Guille here
>>> I've was able to make a prototype of a persistent ST for business
>>> objects
>>> (it didn't persist contexts and such)
>>
>> That's how Gemstone Smalltalk works. It's got a transactional object
>> memory on disk (arbitrary size) and you can run any number of VMs on
>> that image concurrently ... pretty cool.
>
> Magma does a similar thing for Squeak.