I think the answer is lazy developers - if it works and you have enough flash why bother to make your code good. Of course this sort of thinking will come back and bite you when you try to add features or maintain the code.

Make sure you're careful when turning on optimisations because they can break bad code.

I'm agree with you Nigel, but I didn't mean to exclude goto instruction at all.
goto is very usefull in combination with decfsz, incfsz, etc.
But if I can use subroutine in my code, I will "call" it , not goto it.

Gotos generated by compilers of high level languages (C-compilers are good example), as well as another disadvantages - mainly unpredicted code size force me to use assembler only. ... At least till the moment when I will fing a really good compiler.

Originally Posted by bmcculla

I think the answer is lazy developers - if it works and you have enough flash why bother to make your code good. Of course this sort of thinking will come back and bite you when you try to add features or maintain the code.

Make sure you're careful when turning on optimisations because they can break bad code.

This is exactly what I used to do when i wrote C programs for the PC. Poor memory management and lazy techniques. Programming pics has taught me alot.

With a good compiler you should be able to make the code longer without generating any extra instructions.

You should be able to turn on and off specific optimisations for code segments. #pragma ot(5) is Keil's directive to use optimisation level 5 for the next code segment. The down side is that stuff like this is nonstandard C.

Nigel you really should look at SDCC. Its an open source C compiler. They are in the process of retargeting it to the PIC. Its online manuals have good info about a bunch of different compiler optimisation techniques.

Originally Posted by Nigel Goodwin

Originally Posted by dak246

This is exactly what I used to do when i wrote C programs for the PC. Poor memory management and lazy techniques. Programming pics has taught me alot.

I'm currently having fun improving the 'optimised' C code in assembler, although some of it's optimisations I don't like, and I'll probably make some sections longer, but more readable.

One improvement I've just done (very applicable to the title of this thread), it to make one four line piece of code into a subroutine, as it's called 13 times this saves 38 words of memory - and makes the program more readable. I've been doing the same with other multiple pieces of code.

What exactly do you mean? Are you optimizing C code with assembly?

It's actually quite easy to go through the assembly code generated by a compiler and hand optimise the critical sections of the code. Most compilers generate an output for the debugger that has the C code as comments on the generated assembly. It's a good idea to do the best you can with C first though because its really hard to maintain code that has been done this way - you basicly have to do assembly programming after you make any changes, for all your future revisions too.

I think Nigel is just doing a "port" of the C code to assembly using the compilers output.