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

2008/7/4 Eliot Miranda <[hidden email]>:

> Hi All,
>
>     does anyone know (or even better has anyone fixed it) how hard it is to
> make Slang inline methods that contain simple type declarations?
>
> I would like to eliminate compile-time integer/pointer mismatch errors in
> the new StackInterpreter I'm writing.  I'd like to say things like:
>
> callerSPOf: theFP
> "Answer the SP of the caller provided theFP is not a base frame.
> This points to the hottest item on the frame's stack."
> self var: #theFP type: 'char *'.
> self returnTypeC: 'char *'.
> self assert: (self isBaseFrame: theFP) not.
> ^theFP + FoxCallerSavedIP + ((self frameNumArgs: theFP) + 2 * BytesPerWord)
> but Slang refuses to inline anything that has C declarations.  I'm guessing
> that the issue is moving the type information from the method to its inlined
> form.  It took me half a day to discover where Slang refuses to inline
> (should have looked in the obvious place CCodeGenerator>>collectInlineList,
> instead of in the inlining code :/ ).  So I'm afraid to waste the time
> trying to find out where the restriction bites.  Anyone know how to fix this
> or better still have a fix?
>

Doesn't 'self inline: true' helps?

Or, can't you circumvent that by coercing a value to corresponding
type at call site? Like:

newSP := self cCoerce: (self callerSPOf: blabla) to: 'char *'.

And don't touch the return type of function.

> best
> Eliot
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

2008/7/4 Eliot Miranda <[hidden email]>:
>
>
> On Thu, Jul 3, 2008 at 5:48 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2008/7/4 Eliot Miranda <[hidden email]>:
>> > Hi All,
>> >
>> >     does anyone know (or even better has anyone fixed it) how hard it is
>> > to
>> > make Slang inline methods that contain simple type declarations?
>> >
>> > I would like to eliminate compile-time integer/pointer mismatch errors
>> > in
>> > the new StackInterpreter I'm writing.  I'd like to say things like:
>> >
>> > callerSPOf: theFP
>> > "Answer the SP of the caller provided theFP is not a base frame.
>> > This points to the hottest item on the frame's stack."
>> > self var: #theFP type: 'char *'.
>> > self returnTypeC: 'char *'.
>> > self assert: (self isBaseFrame: theFP) not.
>> > ^theFP + FoxCallerSavedIP + ((self frameNumArgs: theFP) + 2 *
>> > BytesPerWord)
>> > but Slang refuses to inline anything that has C declarations.  I'm
>> > guessing
>> > that the issue is moving the type information from the method to its
>> > inlined
>> > form.  It took me half a day to discover where Slang refuses to inline
>> > (should have looked in the obvious place
>> > CCodeGenerator>>collectInlineList,
>> > instead of in the inlining code :/ ).  So I'm afraid to waste the time
>> > trying to find out where the restriction bites.  Anyone know how to fix
>> > this
>> > or better still have a fix?
>> >
>>
>> Doesn't 'self inline: true' helps?
>
> No.  Slang refuses to inline anything containing a C declaration
> (retrnTypeC:, var:type: cCode:inSmalltalk: etc)
>
>>
>> Or, can't you circumvent that by coercing a value to corresponding
>> type at call site? Like:
>>
>> newSP := self cCoerce: (self callerSPOf: blabla) to: 'char *'.
>
> That's worse than the disease :)  There are many more uses than definitions.
>  So I want the uses to look clean and I'll tolerate noisy definition.  There
> are also argument types to consider.  localIP has type char * for example,
> so where it is used as an argument I want the argument type to be char * or
> void *, etc.
>
>

I guess i know why it refusing to inline methods with declarations,
because you may write like:

method: arg1

| foo |
self var: #foo declareInC: 'void **foo = malloc(arg1)'.

^ foo.

inliner simply moving any temps into enclosing method.
But here, a situation, where you have a C style declaration and
assignment both.
And ANSI C prohibits declaring vars not in the first lines of function
body. C++ allows it :)

Try comment a line of code in  collectInlineList.

hasCCode := false. "m declarations size > 0."

Its not safe, and you'll get a lot of compiler errors.

GCC will inline your method anyways, so why bother?

--

Best regards,
Igor Stasenko AKA sig.

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.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MONAGE A TROIS - I am three years old

On 4-Jul-08, at 6:35 AM, Eliot Miranda wrote:

[snip]

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

Nice to have actually achieved something this week; it's been one of those weeks...

Simulating simulating the VM to gather type data seems like a pretty complex project. I can't help feeling it would be simpler and faster to simply write the VM cleanly, with decent documentation and specs.

Igor, if you can produce a Better Slang With Lambas, do please share the code. There has to be some way of cleaning up the current mess.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Oyster (n.), a person who sprinkles his conversation with Yiddishisms.

On 4-Jul-08, at 7:35 PM, Eliot Miranda wrote:

But that's exactly what this project would allow one to do.  One implements a VM in Smalltalk as cleanly designed as one can.  If implementing a JIT then include a simulator for the processor.  Then simulate this written-in-Smalltalk VM and translate this clean design to (e.g.) C removing polymorphism and generating vanilla code based on the type information collected.

I think collecting type information via the simulation is both overkill and insufficient. On one hand, the VM code is immutable while it runs, unlike Smalltalk code. Gathering type feedback at runtime is a great technique because it can respond to changing code, changing usage or the need for reflection. But the VM doesn't need any of that - it just needs a static snapshot of the possible types that could be encountered at each call site.

On the other hand, simulation may not be able to provide that. It runs the risk of not exercising all the code paths and therefor generating incomplete type information. Even with a complete test case to run in the simulator, there's quite a bit of indeterminism in the system. When interrupts happen, when garbage is collected, where objects happen to be allocated, all that can affect the code flow in the system.

I think a static type inferencer would be a better bet. There are several out there, and it probably wouldn't be tricky to press them into service. Chuck, for example, adds a "specific implementors" command to the browser that fits the bill perfectly. The VM isn't likely to be hugely polymorphic in any case, so it probably wouldn't be difficult to track down oddities that the inferencer turns up.

On Thu, Jul 03, 2008 at 05:25:51PM -0700, Eliot Miranda wrote:

> Hi All,
>
>     does anyone know (or even better has anyone fixed it) how hard it is to
> make Slang inline methods that contain simple type declarations?

Eliot, the attached change sets are a snapshot of some tinkering I've been doing
that relates to Slang generation of inlined C code and declarations. I'm sorry it's
not tidied up better, but the short change sets with bug fixes may be of some use
to you in their current form. I do plan to post the relevant bug fixes on Mantis
some time soon.

HTH,

- Dave

------
"Change Set:            PermitInliningCCode-dtl
Date:                   6 July 2008
Author:                 David T. Lewis

Honor a 'self inline: true' request regardless of whether the method contains C code or declarations. Includes a change to case statement generation to support this inlining."!
------

"Change Set:            CaseGenerationFixes-dtl
Date:                   6 July 2008
Author:                 David T. Lewis

The main loop of the interpreter dispatches on bytecodes, with the case targets generated by TCaseStmtNode. There are a number of bytecode methods in the interpreter that make assumptions about slang generation of the case targets in order to support early fetching of the next bytecode. This change set adds #flag: markers to identify the interpreter methods that make this assumption, and adds a check to TCaseStmtNode to force the expected slang code generation regardless of the size of the parse tree for the case target."!
------
"Change Set:            TMethod-renameVarsFix-dtl
Date:                   4 July 2008
Author:                 David T. Lewis

Fix bug in TMethod>>renameVariablesUsing: that caused incorrect C variable declarations for temporary variables that are renamed during slang inlining."!

------
'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 6 July 2008 at 10:15:15 pm'!
"Change Set:            TMethod-TParseNode-comments-dtl
Date:                   6 July 2008
Author:                 David T. Lewis

Class comments, and categorization of some TParseNode methods"!
------
'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 6 July 2008 at 10:09:15 pm'!
"Change Set:            MemoryAccess-unresolvedBugs-dtl
Date:                   3 July 2008
Author:                 David T. Lewis

Interpreter>>loadFloatOrIntFrom: should be inlined, but there is now a bug in temp variable handling that prevents this. It is probably a pre-existing bug that was masked by the fact that methods with C declarations previously could not be inlined. I'm saving it here in this change set in case I feel motivated later to try to fix the bug."!
------
'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 6 July 2008 at 10:26:02 pm'!
"Change Set:            MemoryAccess-dtl
Date:                   29 June 2008
Author:                 David T. Lewis

MemoryAccess defines the low level mapping of object memory addresses to the underlying machine address space.

Prerequisite change sets:
 PermitInliningCCode-dtl
 CaseGenerationFixes-dtl
 TMethod-renameVarsFix-dtl
 TMethod-TParseNode-comments-dtl
 MemoryAccess-unresolvedBugs-dtl

This is intended to replace the traditional external definitions in sqMemoryAccess.h
"!