Kernel
Locked
12
12
 
|
On Sat, Mar 5, 2011 at 12:12 AM, Stéphane Ducasse <[hidden email]> wrote:
Of course. From source one produces the smallest thing that can bring up the rest of the system. IMO, collections, numbers, compiler, files & a stdi/o read-eval-print loop.
But form source is /vital/ to be able to produce a new object representation and that's absolutely necessary to improve performance. Using the tracer makes things like changing the bytecode set or replacing characters with immediate characters more difficult. There's also value in having a declarative definition of the core system.
I would like to play with a source bootstrap. |
|
|
On Mar 5, 2011, at 5:15 PM, Eliot Miranda wrote: > > > On Sat, Mar 5, 2011 at 12:12 AM, Stéphane Ducasse <[hidden email]> wrote: > > Woot!!!!! Is this still a tracer or does it create a new kernel from source? If it's still a tracer when do you think you'll have a creator and what are you calling it? > > From source may be a way to go but only for the smallest core. > > Of course. From source one produces the smallest thing that can bring up the rest of the system. IMO, collections, numbers, compiler, files & a stdi/o read-eval-print loop. > > But form source is /vital/ to be able to produce a new object representation and that's absolutely necessary to improve performance. Using the tracer makes things like changing the bytecode set or replacing characters with immediate characters more difficult. There's also value in having a declarative definition of the core system. Yes. now our problem is not really to have a source code bootstrap for a smalltalk. Gwenael did that in 3 days for his smalltalk but he was controlling all the details (all his object have named and variable size) and only one kind. With Pharo we are reverse engineering format and other hardcoded knowledge with bitAnd: and bitshift: when it would have been so much simpler to have better names. So we will go there but first we should extract the knowledge from the mud. Stef > > > I would like to play with a source bootstrap. > For now we use a tracer and we should learn also how to build dynamically cores (like aljandro nurturing) > > Stef > > > |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
On Fri, 04 Mar 2011 13:51:46 +0100, Benjamin wrote:
> I finally success (with the help of Igor) to trace and create a new > Smalltalk kernel based on Pharo. The new born weight 2.2Mb and includes > 230 classes ;) Your image helps me a lot. I'm trying to get the Squeak VM compiling with Adobe Alchemy. Alchemy is a C compiler targeting the flash VM. My initial approach is to stub about all entry points expect for ioBeep() which prints a debug message. But I had problems loading a normal image. I think it's just too big for flash to handle. In any case this kernel image worked wonderfully! Thanks! |
|
|
>>
> > Your image helps me a lot. > > I'm trying to get the Squeak VM compiling with Adobe Alchemy. tell us more :) > Alchemy is a C compiler targeting the flash VM. ? the flash use bytecode? why does it need a C compiler? > My initial approach is to stub about all entry points expect for ioBeep() > which prints a debug message. But I had problems loading a normal image. > I think it's just too big for flash to handle. In any case this kernel > image worked wonderfully! Tell us more :) Stef > > Thanks! > > > |
|
|
In reply to this post by Alexandre Jasmin-2
On Mar 7, 2011, at 11:04 AM, Alexandre Jasmin wrote: > On Fri, 04 Mar 2011 13:51:46 +0100, Benjamin wrote: > >> I finally success (with the help of Igor) to trace and create a new >> Smalltalk kernel based on Pharo. The new born weight 2.2Mb and includes >> 230 classes ;) > > Your image helps me a lot. > > I'm trying to get the Squeak VM compiling with Adobe Alchemy. Alchemy is > a C compiler targeting the flash VM. > > My initial approach is to stub about all entry points expect for ioBeep() > which prints a debug message. But I had problems loading a normal image. > I think it's just too big for flash to handle. In any case this kernel > image worked wonderfully! > > Thanks! > > > I'm glad that my work could help someone :) As Stef said, if you can provide us more info, it will be really cool ;) Thanks for your feedback ;) Ben |
Pharo on top of Flash plugin
|
|
In reply to this post by Stéphane Ducasse
>> Your image helps me a lot.
>> >> I'm trying to get the Squeak VM compiling with Adobe Alchemy. > > tell us more :) I'm exploring ways to use Smalltalk inside a web page. There are already few interesting Javascript converters and Smalltalk inspired projects like the Clamato and the Lively Kernel. But it'd be nice to run unchanged code from Pharo or Squeak directly. The simplest way to bring Pharo on the web would be to run the existing VM inside a web page. The Squeak plug-in does that already but good luck getting anyone to install it. There are at least two solutions aiming to bring native code to the web without installing plug-ins - Google Native Client provides a sandboxed environment for x86 code - Alchemy (a research project at Adobe) compiles C into the bytecode language interpreted by Flash. Since Flash seems to have wider adoption than Native Client I'm doing a little experiment with it. I just took the VMMaker generated C code for the Squeak VM and passed it through the Alchemy compiler to get something that runs on top of the Flash plug-in. It's too soon to tell if this kind of nested VM is really usable. Performance will undoubtedly be an issue but I can at least run the Hazel image and have it beep in a loop which is encouraging. It seems Flash also supports some dynamic class loading which could enable performance improvements but the execution model while a bit better than Javascript doesn't really compare with Smalltalk. I don't see how we could support continuations for the debugger with pure AVM bytecode for instance. Anyways just recompiling the existing interpreter with Alchemy compiler requires a minimum of work so I'm focusing on that now. Will let you know how it goes. |
Re: Pharo on top of Flash plugin
|
|
On Mon, Mar 7, 2011 at 1:29 PM, Alexandre Jasmin <[hidden email]> wrote: >> Your image helps me a lot. Really interesteing. Keep us informed!
|
Re: Pharo on top of Flash plugin
|
|
In reply to this post by Alexandre Jasmin-2
On Mar 7, 2011, at 1:29 PM, Alexandre Jasmin wrote: >>> Your image helps me a lot. >>> >>> I'm trying to get the Squeak VM compiling with Adobe Alchemy. >> >> tell us more :) > > I'm exploring ways to use Smalltalk inside a web page. > > There are already few interesting Javascript converters and Smalltalk > inspired projects like the Clamato and the Lively Kernel. But it'd be > nice to run unchanged code from Pharo or Squeak directly. > > The simplest way to bring Pharo on the web would be to run the existing VM > inside a web page. The Squeak plug-in does that already but good luck > getting anyone to install it. > > There are at least two solutions aiming to bring native code to the web > without installing plug-ins > - Google Native Client provides a sandboxed environment for x86 code We would love to have somebody working on the google native client for pharo. > - Alchemy (a research project at Adobe) compiles C into the bytecode > language interpreted by Flash. > > Since Flash seems to have wider adoption than Native Client I'm doing a > little experiment with it. I just took the VMMaker generated C code for > the Squeak VM and passed it through the Alchemy compiler to get something > that runs on top of the Flash plug-in. Ok now I understand. > > It's too soon to tell if this kind of nested VM is really usable. > Performance will undoubtedly be an issue but I can at least run the Hazel > image and have it beep in a loop which is encouraging. Fascinating! > It seems Flash also supports some dynamic class loading which could > enable performance improvements but the execution model while a bit > better than Javascript doesn't really compare with Smalltalk. I don't see > how we could support continuations for the debugger with pure AVM bytecode > for instance. Anyways just recompiling the existing interpreter with > Alchemy compiler requires a minimum of work so I'm focusing on that now. > > Will let you know how it goes. Thanks a lot. Ben is already really happy to see 3 or 4 months of works been used by somebody else. It is a great feedback. Stef |
Re: Pharo on top of Flash plugin
|
|
In reply to this post by Stéphane Ducasse
On Mar 7, 2011, at 1:29 PM, Alexandre Jasmin wrote: >>> Your image helps me a lot. >>> >>> I'm trying to get the Squeak VM compiling with Adobe Alchemy. >> >> tell us more :) > > > There are at least two solutions aiming to bring native code to the web > without installing plug-ins > - Google Native Client provides a sandboxed environment for x86 code The interesting aspect of NaCl is that it does have a JIT compiler API... (Mono is using it already). This means, it would be possible to port Cog to NaCl *and* have all the speed... Getting the stack interpreter to run should be even simpler (recompile.. plus implementing I/O via the NaCl APIs , of course). http://blog.chromium.org/2011/02/native-client-getting-ready-for-takeoff.html > - Alchemy (a research project at Adobe) compiles C into the bytecode > language interpreted by Flash. > ... > > Will let you know how it goes. Very interesting direction, too! The most challenging question is if it's possible to somehow "JIT" code... and how fast that then can be. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |