[squeak-dev] Anyone know the following about Slang?

Igor Stasenko siguctua at gmail.com
Fri Jul 4 03:49:50 UTC 2008


2008/7/4 tim Rowledge <tim at rowledge.org>:
> As mentioned this is likely  a bit of precautionary restriction implemented
> way back, probably by John Maloney when at Apple. Any cCode stuff stops
> inlining.
>
> Given the fairly small set of types (ab)used you might specialise to the
> form #declareCharStar: #foo etc and instead of catching the various forms of
> #var:declareC: etc in TMethod>recordDeclarations it would let them through.
> There'd be some ugly fixups elsewhere though, guaranteed.
>
> It has to be said that the current state of the Slang translation is just
> insane. It was a fairly ugly hack to start with and has been mangled,
> folded, spindled and mutilated ever since. As an example gleaned whilst
> taking a quick look for a solution for you, consider
>  - TMethod>inlineCaseStatementBranchesIn:localizingVars: and its use of
> #hasNoCCode and
>  - CCodeGenerator>collectInlineList and its non-use of hasCCode but a
> mangled inline almost equivalent.
>
> The textual inlining is terribly poorly factored and horribly hacked. It
> makes decisions based on nonsense metrics like how many nodes in a tree and
> are there more than an arbitrary magic number. The code probably won't work
> if you don't inline! At least it didn't a while back. The
> inlining/internalising of the bytecode loop is nasty, resulting in near
> duplicates of many methods for no very good reason.
>
> My guess - and it is only a guess based on a few limited experiments ages
> ago - is that it would be smarter to drop the textual inlining completely,
> make the inline: pragma result in placement of a gcc __inline__ (or whatever
> the hell it is these days) on the function declaration line and let the
> compiler handle it.
>
> Or better yet, completely rewrite the whole damn thing to do the job
> properly. Invent a better Slang. Add those bitfileds handling capabilities
> you need, and structures.
>
>

After couple of month of hacking slang to make Hydra working, i looked
for a ways how to overcome such shortcomings, which introduces a
translation to C.
And as result , i invented own translation from smalltalk AST to
lambda message sends. And even started prototyping a C translation
backend for it. But then i thought: why the hell i need to translate
things to  C, if i have Exupery on hands, with which i can control any
operation up to smaller details i need.
First thing, which i made is native method inlining, which inlines
code based not on knowledge about variable names or their types, but
based on AST , which makes it truly indifferent to what you want to
inline or perform. In essence lambdas its an abstract algorithm
representation, so it possible to easily translate them to any form
(be it C , native code or anything else) :)

> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Fractured Idiom:- MONAGE A TROIS - I am three years old
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list