On Thu, Jul 3, 2008 at 6:19 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/7/4 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Thu, Jul 3, 2008 at 5:48 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> 2008/7/4 Eliot Miranda <eliot.miranda at gmail.com>:
> >> > 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.



I did that.  I got lots of errors :)


> GCC will inline your method anyways, so why bother?


The current sources use the localIP localSP localHomeContext
localReturnContext localReturnValue scheme to get important variables in
registers.  The translator rips out methods it can't inline that refer to
these.  So lots of methods end up getting deleted unless they're inlined.

The localFoo scheme may or may not be important for performance.  I don't
want to rip it out until I can measure in a working VM whether it has any
effect or not.  I want to measure my new VM not the old one  The benefit of
having localFP (the frame pointer) in a register in my VM is likely to be
quite high.

I only want the type declarations to eliminate warnings.  So its easier to
do without the declarations.  But I'd like my cake and eat it too, dammit :)


>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080703/79a577b7/attachment.htm