« Return to Thread: [squeak-dev] Anyone know the following about Slang?
Re: [squeak-dev] Anyone know the following about Slang?
by Eliot Miranda-2
::
Rate this Message:
On Thu, Jul 3, 2008 at 7:38 PM, tim Rowledge <tim@...> wrote:
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!!
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>
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@...; http://www.rowledge.org/tim
Fractured Idiom:- MONAGE A TROIS - I am three years old
« Return to Thread: [squeak-dev] Anyone know the following about Slang?
| Free Forum Powered by Nabble | Forum Help |
