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

Eliot Miranda eliot.miranda at gmail.com
Fri Jul 4 13:35:11 UTC 2008


On Thu, Jul 3, 2008 at 7:38 PM, tim Rowledge <tim at rowledge.org> wrote:

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



Thanks Tim!  That's what I needed.  Being pointed to the right place.  It
has taken 20 minutes to understand the code and 20 minutes to fix it.
 Thanks so much!!

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.


Right.  Any one brave enough should have a go at this.  Right now I can work
within the existing system's limitations and so its not on my critical path
(thank goodness).

The way that Dave Simmons and I thought would be a great way to do it is to
run a simulation of the VM in some context that allows one to collect
concrete type information.  This could be e.g.

- a simulation of the simulation using
ContextPart>>runSimulated:contextAtEachStep:, that captures the receiver
type(s) at each send site, very slow being a simulation of a simulation

- a simulation above a VM that has polymorphic inline caches, extracting the
type information from the PICs a la adaptive optimization/speculative
inlining

The simulation has to be run with an exhaustive case that fully exercises
the VM simulation so no code is left untouched.  This can be checked (but
not verified) by seeing that one has collected type information for all send
sites in the VM code. (Not verified because it doesn't prove that for a
given send site a different execution would not introduce another type).

Applying a closed-world assumption to the VM code (it doesn't change once
compiled as a C program) one can then transform the Smalltalk code,
decorated with type information, into C.  Monomorphic send sites map to
procedure calls and/or textual inlining.  <handwave>Polymorphic send sites
transform to some form of case sttement based on some sort of discriminated
union, or perhaps a warning to the programmer to try again</handwave>.

<hint weight="heavy">IMO THIS WOULD MAKE AN EXCELLENT MASTERS OR PHd
TOPIC!!</hint>

tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Fractured Idiom:- MONAGE A TROIS - I am three years old
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080704/a0475750/attachment.htm


More information about the Squeak-dev mailing list