Dennis wrote: >So what does this all mean? >Ok it is quite simple (simple explaination will be given) As you can see >Andy like myself does not get any code size change, or often very little, >where Andrew gets a large change. For most of the time Andrew is quite >correct, a large change can be found with just the first 3 levels of >optimisation, after this point very little. In his case the code will have >large numbers of routines and many variables being past between functions. Wow ... Dennis knows my code without even seeing it! ;-) But he is entirely correct -- The example I mention above is for a nearly-full 16C77 (i.e. just short of 8K of code). Lots and lots of functions, many of which pass three, even four parameters. As this was my first large PIC C project, I do not claim to have written all my loops, etc. in the manner which is best for minimum-size code. But I am learning. Said project compiles and runs on the PC ( a sim ) and the PIC, so portability was way up there on the list of priorities. I do look at the assembly output quite often and try to recode in C to minimize size. I've found, for instance, a good way to "help" the PIC-C compiler is to use temp auto variables when doing relatively complex statements involving pointers on both sides of the "=" sign. Sometimes the expression is too complex for the compiler, but even when it isn't, I can get a lot of speedup by pre-evaluating a variable with, say, a single level of indirection, and then using said handle to do all subsequent, double-level-of-indirection references. This would be the case where there's a pointer to a pointer to a structure which contains multiple fields which get operated on "simultaneously." As I recall, the 1st-3rd (or was it 1st-5th?) levels of optimization made a big difference, going higher made no difference at all. PIC-C rocks! (Thanks Clyde!) ___________________________________________ | Andrew E. Kalman, Ph.D. aek@netcom.com | | standard disclaimers apply | |___________________________________________|