> The C compiler I use (BoostC) supports "inline" functions, so there is > no additional overhead if a function is called only once. But you do know (don't you?) that an 'inline' only tells the compiler, that you *prefer* that function to be inlined... Also when you have variables inside that inline function, then those variables has to be "doubled" - aka the stack for those local variables has to be crated + the values has to be copied - otherwise the funcion behaves different than what the programmer may wants. Now get into some pratcise: I have chosen "gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)" for this testing, and just created a silly test source as follows: ------------------------------------------------------------------ #include inline void inl(int i) { int h, j; h = i; i+=h; j = i; h += j; i++; printf("%u",i); } int main(void) { int i; for(i = 10; i--; ) { inl(i); printf("%X\n",i); } return 0; } ------------------------------------------------------------------ I know, there is no comments but I hope everyone see what it does: nothing :-) Now the first attempt to compile this code: $ gcc -Winline -o testInline testInline.c For those who not familiar with gcc, -Winline tells the compiler to warn if there was a function marked as inline but was not inlined. We got not warnings, so I think it is good, but let's check the generated code: $ objdump -d testInline ... 080483ab
: 80483ab: 8d 4c 24 04 lea 0x4(%esp),%ecx 80483af: 83 e4 f0 and $0xfffffff0,%esp 80483b2: ff 71 fc pushl -0x4(%ecx) 80483b5: 55 push %ebp 80483b6: 89 e5 mov %esp,%ebp 80483b8: 51 push %ecx 80483b9: 83 ec 24 sub $0x24,%esp 80483bc: c7 45 f8 0a 00 00 00 movl $0xa,-0x8(%ebp) 80483c3: eb 1e jmp 80483e3 80483c5: 8b 45 f8 mov -0x8(%ebp),%eax 80483c8: 89 04 24 mov %eax,(%esp) 80483cb: e8 a4 ff ff ff call 8048374 <=== THAT IS INTERESING! 80483d0: 8b 45 f8 mov -0x8(%ebp),%eax 80483d3: 89 44 24 04 mov %eax,0x4(%esp) 80483d7: c7 04 24 c3 84 04 08 movl $0x80484c3,(%esp) 80483de: e8 f5 fe ff ff call 80482d8 80483e3: 83 6d f8 01 subl $0x1,-0x8(%ebp) 80483e7: 83 7d f8 ff cmpl $0xffffffff,-0x8(%ebp) 80483eb: 75 d8 jne 80483c5 80483ed: b8 00 00 00 00 mov $0x0,%eax 80483f2: 83 c4 24 add $0x24,%esp 80483f5: 59 pop %ecx 80483f6: 5d pop %ebp 80483f7: 8d 61 fc lea -0x4(%ecx),%esp 80483fa: c3 ret Now as we realised something is wrong try somwthing else: $ gcc -Winline -Os -o testInline testInline.c testInline.c: In function 'main': testInline.c:5: warning: inlining failed in call to 'inl': --param max-inline-insns-single limit reached testInline.c:24: warning: called from here Ok, so when we ask the compiler to do optimization for size it warns us that the inline was uncussessful. Right, try to increase the size of the function that can be inlined: $ gcc -Winline -finline-limit=1200 -Os -o testInline testInline.c No warning, so far so good again, but as it happened previously just check if inline occured: $ objdump -d testInline ... 08048391
: 8048391: 8d 4c 24 04 lea 0x4(%esp),%ecx 8048395: 83 e4 f0 and $0xfffffff0,%esp 8048398: ff 71 fc pushl -0x4(%ecx) 804839b: 55 push %ebp 804839c: 89 e5 mov %esp,%ebp 804839e: 56 push %esi 804839f: be 13 00 00 00 mov $0x13,%esi 80483a4: 53 push %ebx 80483a5: bb 0a 00 00 00 mov $0xa,%ebx 80483aa: 51 push %ecx 80483ab: 83 ec 0c sub $0xc,%esp 80483ae: eb 20 jmp 80483d0 80483b0: 51 push %ecx 80483b1: 51 push %ecx 80483b2: 56 push %esi 80483b3: 83 ee 02 sub $0x2,%esi 80483b6: 68 b0 84 04 08 push $0x80484b0 80483bb: e8 18 ff ff ff call 80482d8 80483c0: 58 pop %eax 80483c1: 5a pop %edx 80483c2: 53 push %ebx 80483c3: 68 b3 84 04 08 push $0x80484b3 80483c8: e8 0b ff ff ff call 80482d8 80483cd: 83 c4 10 add $0x10,%esp 80483d0: 4b dec %ebx 80483d1: 83 fb ff cmp $0xffffffff,%ebx 80483d4: 75 da jne 80483b0 80483d6: 8d 65 f4 lea -0xc(%ebp),%esp 80483d9: 31 c0 xor %eax,%eax 80483db: 59 pop %ecx 80483dc: 5b pop %ebx 80483dd: 5e pop %esi 80483de: 5d pop %ebp 80483df: 8d 61 fc lea -0x4(%ecx),%esp 80483e2: c3 ret Right, now the function inlined, but do you notice the size of the code? Loads of stack operation for nothing - this is only a snipplet, it does not contain the startup ccode and the C library of course. Now examine this binary a bit further. Just before the main function, I notice this: 08048374 : 8048374: 55 push %ebp 8048375: 89 e5 mov %esp,%ebp 8048377: 83 ec 10 sub $0x10,%esp 804837a: 8b 45 08 mov 0x8(%ebp),%eax 804837d: 8d 44 00 01 lea 0x1(%eax,%eax,1),%eax 8048381: 50 push %eax 8048382: 68 b0 84 04 08 push $0x80484b0 8048387: e8 4c ff ff ff call 80482d8 804838c: 83 c4 10 add $0x10,%esp 804838f: c9 leave 8048390: c3 ret Erm, if this function was inlined, why the earth it was stored separately? I know, gcc is only one compiler out of the millions, I just wanted to point out, that sometimes a theory about these compiler techniques just does not work or works erratically, and that's why assembly programmers like better to control everything instead of relying on compiler features. Tamas On Sun, Oct 12, 2008 at 4:00 PM, Timothy J. Weber wrote: > Olin Lathrop wrote: >> Tamas Rudnai wrote: >>> I was so surprised that when there is a sentence here about "typical >>> length of function" noone replies that "hey, you have a very limited >>> stack + the overhead of the function call is what everyone wants to >>> avoid + in an ISR probably not so good idea to call functions" etc. >> >> I had considered doing that, but it seemed to me nobody was interested in >> listening any more, only about explaining how their way was so wonderful. > > The C compiler I use (BoostC) supports "inline" functions, so there is > no additional overhead if a function is called only once. > > So, the function can be used as a purely syntactic element to point out > a unit of functionality (function-ality?). > -- > Timothy J. Weber > http://timothyweber.org > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- Rudonix DoubleSaver http://www.rudonix.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist