Is SPIN "inlining" functions?

jmspaggi

Hi all,

Let's imagine I have this code:

PUB Main
  repeat
    outxy(1,2,48)


PUB outxy(x, y, c)
  screen[noparse][[/noparse]y * cols + x] := (color << 1 + c & 1) << 10 + $200 + c & $FE

Will that be as fast as:

PUB Main
  repeat
    screen[noparse][[/noparse]2 * cols + 1] := (color << 1 + 48 & 1) << 10 + $200 + c & $FE

?

I mean, is the spin compiler doing some inlining (not sure of the term here)? Or do I need to do it manually? Or do we have a way to ask him to do it?

Thanks,

JM

bill190

Compiler optimization?
http://en.wikipedia.org/wiki/Compiler_optimization
·

Dave Hein

The current Spin compilers will generate method calls, and they do not inline functions.

jmspaggi

Ok. I just did some testing.

x := 5
y :=5
z := x+y

is twice faster than

x := 5
y := 5
z := f(x,y)
...

where f return x+y.

So I will look at my code at the end, and if I still have some memory available, I will probably try to do some manual inlining...

http://en.wikipedia.org/wiki/Inline_expansion

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

Mike Green

For simple examples like you've shown, in-lining is always much faster than method calls. It's not a fair comparison though. Generally, methods are used for relatively complex operations where the call and parameter passing is a very small portion of the overhead. Using a method call provides you with efficiently accessed parameters. It doesn't take much complexity in the original call for the method call and use of local parameters to be more efficient.

Something else to consider ... in-lining is a trade off between execution speed and code size and the Propeller is mostly constrained by available memory. Unless a piece of code involving method calls is executed a lot, there's probably no effective advantage in in-lining the code. You have to do the analysis of execution time patterns after the program is all done and working in order to see where in-lining will help.

Post Edited (Mike Green) : 8/5/2010 6:35:33 PM GMT

jmspaggi

Hi Mike,

Thanks for your feedback.

I was thinking about inlining when I saw that in another post:

PUB getbit(target, pos)
  return (target >> pos) & 1

PUB putbit(target, pos, value)
  if (value & 1)
    target |= (1 << pos)
  else
    target &= !(1 << pos)

  return target

getBit is very small. So I was wondering if it's beter to use this method, or to inline it. Even for the memory. This method should take only few longs, but calling it should take the same.

Anyway, so far I still have half of the memory available, even with the screen-driver. So I will not start to do such optimizations, but I was just wondering. I will have to review all my code when it will be over to see if such optimization can be a +, or a -...

Thanks,

JM

Update: forgot the CODE tags...

Message Edité (jmspaggi) : 8/5/2010 6:56:08 PM GMT

ericball

SPIN is also very operator rich so you should use the built-in operators as much as possible. So use |< pos in putbit.

There's no reason not to inline getbit, just watch your precedence if target or pos is an expression. getbit too unless it's used a huge number of times.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum