Even if the program does not fit into memory as a whole with optimization turned off, chances are each functional block will fit on its own.
you are TOTALLY bypassing the issue. How in hades are you going to test timing interaction betweeen interrupts in isolation???. The issue is NOT "does this function work as stated" that is DEAD EASY to verify, what will hang you out to dry is some pesky special circumstance where 7 ISRs want to be serviced at the same time. YES, I know that can be calculated, but I do not have access to a Cray or similar. ALSO if the program does not fit into memory as a whole with optimization turned off use an identical chip with more memory (e.g. RD2 instaed of RB2) on your test board DUH

Your code ought not to be so sensitive.
so, you are one of those that think REAL time is something related to a RTOS. REAL real time is responsing in nano or micro seconds. If you can write ultra high speed code that is not 'sensitive' and document you can, I might have a job for you. Of course, I make every effort to keep the code from being 'sensitive' but I forgot to polish my halo yesterday.

I give up, you keep babbling about optimizing and I do not give a hoot. If the code is not debuggable without introducing 'debugging code' I will not do it. Code that can not be debugged without interference is a nigntmare.

It is more important that code is maintainable than it is that it works You can make maintainable code work, but non-maintainable code that 'works' is bound to fail and then your largest muscle is in a sling.

In my opinion optimized code is non-maintainable and you have STILL not told me how to debug optimized code without changing anything.

Embedded development isn't all about fitting an FFT into 1 byte of program space and taking 3 months to do so anymore.
Agreed, but then WHY USE THE OBNOXIOUS CRAP 'OPTIMIZER' that makes your code non-maintainable if you can not debug without inteference the code is not maintatinable.

BTW, you are mistaken. Where optimization comes into play (very high volume products) "Embedded development IS all about fitting an FFT into 1 byte of program space and taking 3 months to do so" In the highest volkume product I have ever been involved with I spent 4 months on one detail.

You are talking out of both sides of the mouth if "Embedded development isn't all about fitting an FFT into 1 byte of program space and taking 3 months to do so" then the volume is so small that 'optimizing' to save $0.13 by using a smaller chip is totally irrelevant. The maintenance savings from having debuggable code will be far more significant

Erik