Quantcast

Kernel

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel

Eliot Miranda-2


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.

  
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel

Stéphane Ducasse

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel

Alexandre Jasmin-2
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!



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel

Stéphane Ducasse
>>
>
> 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!
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel

Benjamin Van Ryseghem (Pharo)
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Pharo on top of Flash plugin

Alexandre Jasmin-2
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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pharo on top of Flash plugin

Mariano Martinez Peck


On Mon, Mar 7, 2011 at 1:29 PM, Alexandre Jasmin <[hidden email]> 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
 - 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.


Really interesteing. Keep us informed!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pharo on top of Flash plugin

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pharo on top of Flash plugin

Marcus Denker-4
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.


12
Loading...