when shd i use a "call" and a "goto"? wh

[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?

 

[bmcculla]

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.

 

[Nigel Goodwin]

To make it clear, I'm working on the HEX file generated by the C compiler (I don't like C, and never use it!) - I've used the disassembler I wrote as part of WinPicProg to generate the assembly code from the HEX file.

From the assembler code generated I've been commenting the code, and naming the subroutines and variables - once I had that all done, I assembled the code to make sure it produced the exact same HEX file.

Then from that fully working assembly code I've been improving it, making it smaller and more readable - although (as I mentioned before) I will be making some sections slightly larger to improve their readability.