Post by thread:CCS compiler - best loop instruction (was best C c

I'm trying to optimize some code, and fighting for every byte as usual. I've got 1070 bytes of code that's got to fit in 1024 bytes of memory - you know the drill. No, I can't buy more memory - it costs money. Gotta squeeze my code. I'm replacing more and more C with assembler. This is going the wrong way. I've noticed that C always makes a less efficient loop than can be done with hand coded assembler. I need a loop that executes 256 times (handy number, eh?) I'm comparing the assembly instructions: int x; #ASM // CLRF X is implied - I make sure X is always zero at this point label: { code code code code} decfsz x, f goto label #ENDASM which generates a nice tight loop which executes 256 (or is it 255? ) times and uses 2 bytes of overhead for the loop. Racing them against ANY of the looping instructions in C - such as for (X = 0; x < 256; x++) { code code code} for(x = 255; x > 0; x--) {code code code code} while (x > 0) { code code code code x-- } which can generate a loop in AT BEST 5 and usually 6 0r 7 bytes. Is there a C instruction that can make a nice tight loop that takes up 2 bytes of ROM and executes 256 times? <Clown suit on> Why didn't I buy a real C compiler... <Clown suit off>

Lawrence Lile wrote: >Racing them against ANY of the looping instructions in C - such as > >for (X = 0; x < 256; x++) >{ code code code} > > >for(x = 255; x > 0; x--) >{code code code code} > >while (x > 0) >{ code code code code > x-- >} > how about: /* unsigned char x=0; implicit */ do{ /* code code code */ }while( --x ); this is slightly suspect, but it best expresses your asy version, and it's legal C. decfsz implys a predecrement (--x) rather than a postdecrement (x--), I'm not up with the PIC C compiler implementations though. Ross.

At 15:58 03/30/99 -0600, Lawrence Lile wrote: >I'm comparing the assembly instructions: > // CLRF X is implied - I make sure X is always zero at this >Racing them against ANY of the looping instructions in C - such as >for (X = 0; x < 256; x++) >for(x = 255; x > 0; x--) both of these do not imply x to have some sensible value, therefore they have to set it, which takes some of the overhead. >Is there a C instruction that can make a nice tight loop that takes up 2 >bytes of ROM and executes 256 times? that wouldn't be a "c instruction", because this depends a whole lot on the compiler and the optimizations it performs. ge

Thanks, Bill - except for the fact that CCS doesn't like UNTIL - it prefers WHILE this suggestion works! This code compiled to a two byte loop: do { /* code code code */ x -= 1; } while (x == 0); -----Original Message----- From: William Chops Westfield <spam_OUTbillwTakeThisOuTcisco.com> To: Lawrence Lile <.....lilelKILLspam@spam@toastmaster.com> Date: Tuesday, March 30, 1999 4:38 PM Subject: Re: CCS compiler - best loop instruction (was best C compiler) >How about > do { > code code code > x -= 1; > } until (x == 0); > >BillW

do { /* code code code */ x -= 1; } while (x != 0); Yeah - "until" is pascal, I guess. This isn't one of the more commonly used C structures, for some reason - I guess it's philosophically annoying to read a loop where you haven't seen the termination conditions till you get to the bottom. The key features that led me to suggest it include: 1) corrospondence to the assembly language you wanted to get. 2) avoid constants larger than 8 bits (ie "256") 3) Use x -= 1 rather than x-- or --x; Since you don't really care whether there is a pre or post decrement, this gives the compiler more lattitude in picking the instruction. Hopefully you'd get the same code if you pick the RIGHT type of decrement, but the optimizer would have to be considerably more clever to get the same code if you picked the WRONG form of decrement. It's something of a major milestone in compiler development when you can stop worrying about the compiler generating "WRONG" code. It's another milestone when you can stop manipulating the exact form of the source code to get "better" code, and the optimizer is good enough to generate the same code (or at least "as good" code) from widely varying source. Then you get to write source code designed for readability rather than optimization, and that's what high level languages are supposed to do. (Likewise, this is one of the problems with bad compilers - by the time the code runs well, its not much more readable than assembly language.) This doesn't happen all at once. most (All?) of my C experience is on compilers for 68k and "bigger" processors. When we moved from hpcc to gcc, it no longer made sense to use "register" declarations. As gcc improved, smaller source-level optimizations become unnecessary as well. (This doesn't mean you can be an idiot and get good code anyway, of course.) BillW