2014-10-23 16:38 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Thierry,
On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 09:18, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
How long is long?
900 nodes in the AST seems to be the limit for the type of method SmaCC generates (cascading ifTrue:ifFalse:).
Other limits exist (number of literals, for example). Unless you generate automatically some code, it's hard to hit them. Once you generate automatically, it's easy to hit them :P
Spur and Sista together lift these limits. Spur provides 64k literals per method and Sista uses a bytecode set with effectively unlimited jumps. We could possibly deploy the Sista bytecode set before the Sista optimizer. Would you be interested in being a guinea pig?
I want that too.
If we deploy it we will deploy it for the Pharo 4 anyway. I thought we'll move to spur then to the new bytecode set because some sista bytecode (traps, inlined primitives, ...) will only work with Spur. We won't spend time implementing and stabilizing them for V3.
Eliot (phone)
Now, the point is to see all that as a stream, cut methods at appropriate places and compile code under a WAComponent subclass.
Yes. But then you need some kind of syntax to mark the start of a
method. Change sets and dolphin packages use !! markers.
I don't know about SmaCC but I think I can do something with PetitParser and Smalltalk compile:
It's all done with RBParser. Since you're parsing Smalltalk, it's easier
to do it that way (and probably a bit faster). And you're also playing with the AST, so you want to fall back to a well defined API for that AST (and visitors, and the like).
Extending RBParser with a scheme to parse multi-methods files could be
convenient.
Unless you fall back on a variant of a changeset.
Thierry