Pypy-Squeak VM generation news

 
Dear all,
today started the PyPy-Squeak sprint in Bern, with the bold goal of  
using PyPy the generate a Squeak VM. A sprint is one week of full-
time hacking. If you are interested in daily progress reports, please  
refer to

        http://pypysqueak.blogspot.com/

cheers,
AA

 
Sounds intriguing. But can you elaborate on what it means to "use PyPy
to generate a Squeak VM"?

Cheers,
   - Andreas

Adrian Kuhn wrote:

 
Hi ho,

I'd love to be in Bern right now... :-/

On 10/22/07, Andreas Raab <[hidden email]> wrote:
> Sounds intriguing. But can you elaborate on what it means to "use PyPy
> to generate a Squeak VM"?

My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".

But then... (Adrian, you know what comes next.)

Short version: Why Python? Why not Squeak?

Long version: we've got a wonderful language, Smalltalk, and a great
implementation of that language, Squeak. There is an implementation of
Squeak "in itself", or rather, in Slang. Close, but, alas, no cigar.

Slang is not much more than a Smalltalk-ish syntax for C. Some things
that are used most naturally in Smalltalk simply cannot be done in
Slang, which adds a great deal of complexity to VM development for
Squeak. RPython, on the other hand, is a minimally stripped-down
version of Python - it almost lays the full power of Python into the
hands of the VM developer.

So what about, instead of using an "alien" language for developing the
Squeak VM, Squeak itself? Possibly after a minimal strip down, much
like the one applied to Python?

The main benefit for Squeak VM development that can be drawn from the
PyPy project is not RPython. Or: should not be RPython. Maybe I'm
overly puristic, but hey, I still favour Squeak over Python for
whatever reasons, so I'm not being inconsistent. ;-)

The main benefit, in my opinion, is in the way the PyPy tool chain is
built. The approach of taking away abstractions step by step and
finally generating C code is elegant and well-designed. A similar tool
chain for Squeak would be a great thing to have. It would also allow
Squeak to remain a "Smalltalk implemented in itself", which is a nice
property.

So, instead of PySquee or SqueePy, what about SqueeSquee?

(Disclaimer: this is not to bash PyPy. Not at all. It's amazing work
that takes one of the edges off of VM development in my very humble
opinion, and that should be widely adopted beyond the Python realm.
This also is not to bash VMMaker or any of its contributors or
maintainers. See above.)

Best,

Michael

 
Michael Haupt wrote:
> On 10/22/07, Andreas Raab <[hidden email]> wrote:
>> Sounds intriguing. But can you elaborate on what it means to "use PyPy
>> to generate a Squeak VM"?
>
> My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".

And what exactly does *that* mean? Rewrite the code generator in Python
to generate C code from Slang? Rewrite the VM in Python? Use PyPy
translation tools to generate code from Squeak parse trees? There are so
many possible ways of "using tools" ...

Cheers,
   - Andreas

 
Hi Andreas,

On 10/22/07, Andreas Raab <[hidden email]> wrote:
> > My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
>
> And what exactly does *that* mean? Rewrite the code generator in Python
> to generate C code from Slang? Rewrite the VM in Python? Use PyPy
> translation tools to generate code from Squeak parse trees? There are so
> many possible ways of "using tools" ...

it means (simplified) rewriting the VM in Python and compiling it
using the PyPy tool chain.

Best,

Michael

 
Michael Haupt wrote:
> On 10/22/07, Andreas Raab <[hidden email]> wrote:
>>> My guess is it's "use the PyPy *tool chain* to generate a Squeak VM".
>> And what exactly does *that* mean? Rewrite the code generator in Python
>> to generate C code from Slang? Rewrite the VM in Python? Use PyPy
>> translation tools to generate code from Squeak parse trees? There are so
>> many possible ways of "using tools" ...
>
> it means (simplified) rewriting the VM in Python and compiling it
> using the PyPy tool chain.

How interesting! I'm very curious about the results. There are at least
two areas where I could see some interesting outcomes:

1) How to write a Squeak VM that actually consists of objects. This will
be interesting since I've always felt that it shouldn't really be all
that hard to drop the limitations of the code generator (after all,
Ian's entire work is based on a comparable approach) so it'll be
interesting to see what the structure of this VM will be.

2) Performance comparisons. It should be interesting to see how a PyPy
VM compares in benchmarks, either for improving PyPy (or learning how
and why a Squeak VM is different than for example a Python VM) or what
to do to make the C Squeak VM faster. This should be in particular
relevant if PyPy does some dataflow analysis which we've never run on
the Slang code.

Cheers,
   - Andreas

 
Hi Andreas and Michael,

On 22 Oct 2007, at 23:25 , Michael Haupt wrote:

more precise, it means writing a Smalltalk bytecode interpreter in  
RPython and using the PyPy tool chain to generate a VM out of this.

Why not SqueeSquee?

We discussed this option yesterday. Its first step would be to define  
a subset of Smalltalk in the same way it is done with RPython  
(reduced Python). Let's call this RSqueak. Then, one would implement  
a new front end for the PyPy tool chain, based on RSqueak and written  
in Smalltalk. Like that we could feed the chain from Smalltalk, and  
later start to build our own VM generation tool chain in Smalltalk.

Alas, we feel not yet ready to do that. The Pypy sprinters miss in-
depth understanding of Smalltalk, whereas we Squeak sprinters miss in-
depth understanding of PyPy. Hence we decided for the current goal to  
learn from each other, keeping SqueeSquee as a long term goal in mind.

That's at least how I grok this week's goals. But, that I initiated  
this sprint does not mean that my view is authoritative, the other  
sprinters best speak for themselves. I will ask the other sprinters  
to join the discussion on this list also today...

cheers,
AA

 
Good Morning in Bern

and happy PyPySqueak :)

Thank you very much for keeping the rest of the world informed!

BTW the codespeak.net server seems to be unreachable from here :(

- http://codespeak.net/~cfbolz/squeak-brainstorming.jpg

/Klaus

On Mon, 22 Oct 2007 22:07:54 +0200, Adrian Kuhn wrote:

 
Adrian Kuhn wrote:
> more precise, it means writing a Smalltalk bytecode interpreter in
> RPython and using the PyPy tool chain to generate a VM out of this.

So how does RPython compare to Slang? Or Pepsi for that matter?

Cheers,
   - Andreas

 
Hi again,

On 10/23/07, Andreas Raab <[hidden email]> wrote:
> So how does RPython compare to Slang? Or Pepsi for that matter?

RPython is a full-fledged Python with some restrictions: for example,
lists may only contain elements of the same type. I quote from the DLS
paper on PyPy:

"This sublanguage is not restricted syntactically, but only in the way
it manipulates objects of different types. The restrictions are a
compromise between the expressivity and the need to statically infer
enough type information to generate efficient code. RPython still
supports exceptions, inheritance but limited to single inheritance
with some mix-in support, dynamic dispatch, to some extent keywords
arguments and varargs, first-class function and class values, limited
use of bound methods, runtime isinstance and type queries, but no
runtime reflection. Bindings in class and global namespaces are
assumed constant. RPython code can be run on a Python interpreter
without severe semantics mismatches."

That is quite unlike Slang, isn't it?

BTW I don't think that, should SqueeSquee be approached one day, there
will have to be some kind of RSqueak. If Pepsi is the target language
of a SqueeSquee "VMMaker", then the differences are not too large.

Best,

Michael

 
Hi Adrian,

On 10/23/07, Adrian Kuhn <[hidden email]> wrote:
> Why not SqueeSquee?
>
> We discussed this option yesterday. Its first step would be to define
> a subset of Smalltalk in the same way it is done with RPython
> (reduced Python). Let's call this RSqueak. Then, one would implement
> a new front end for the PyPy tool chain, based on RSqueak and written
> in Smalltalk. Like that we could feed the chain from Smalltalk, and
> later start to build our own VM generation tool chain in Smalltalk.

oh, I was not suggesting to reuse the entire PyPy tool chain, but
rather to reuse the ideas that have become manifest in it. I also
don't think that RSqueak will be absolutely necessary, given that
Pepsi could be the target.

Nevertheless, good luck for the sprint!

Best,

Michael

 
It is down :(

On 23 Oct 2007, at 9:28 , Klaus D. Witzel wrote:

> BTW the codespeak.net server seems to be unreachable from here :(
>
> - http://codespeak.net/~cfbolz/squeak-brainstorming.jpg
>
> /Klaus
>

I am intruiged by what motivated this? Is it curiosity, will it create a
VM that is better in some way, will it result in a better mechanism for
creating VMs?


Joerg
 

 
Yes, curiosity.  At least for me.
It is to learn how the pypy tool chain works and to learn how a  
Squeak VM works. The first was fully unknown to me, the latter not in  
details.
Regarding the features of the VM that will result from this  
endeavor ... that's open, it has not yet been generated, neither  
benchmarked :)

cheers,
AA

On 25 Oct 2007, at 19:37 , Joerg Beekmann wrote:

 
Pypy is several orders of magnitude more complex than what we have in  
place now. So I'm curious to learn what that machinery can achieve  
for Squeak, too.

- Bert -

On Oct 25, 2007, at 14:30 , Adrian Kuhn wrote:

 
Hi,

On 10/25/07, Joerg Beekmann <[hidden email]> wrote:
> I am intruiged by what motivated this? Is it curiosity, will it create a
> VM that is better in some way, will it result in a better mechanism for
> creating VMs?

my hope is that it will lead to a different and more high-level
development approach for the Squeak VM. While Slang does a good job
for the VM as it is, it is certainly not using high-level abstractions
(and never had the intention to), which would be much more convenient.

Of course, high-level abstractions may prevent dealing with low-level
details, which are all over the place in VM implementations. This is
where the tool chain comes into play: the gory details are realised by
means of applying smart tools to the high-level source code.

I think the PyPy approach is extremely promising.

Best,

Michael