Large blocks of code in if-else/goto

[notbad]

hi
my code is like this:

[RF_Developer]

Functions are THE way to solve this sort of problem. Whenever code is used twice or more then a function is the way to go. So, why, precisely, are they causing you problems?

Gotos are a tool of last resort, and in thirty years of professional programming I have NEVER used one. I've used many, many functions, and functions of functions, and functions within functions within functions. Provided you are aware of the limited stack space provided by most PICs, there should be very few problems.

What can cause memory bloat issues are where the compiler is forced to generate multiple copies of functions. This happens when they are inlined, or are used in ISRs AND mainline code, which forces multiple copies to prevent re-entrancy which is not possible with many PICs due to hardware limitations, such as the very restrictive stack.

So, what problems are you seeing? If you are considering using gotos then you're clearly in quite a lot of trouble.

RF Developer

[temtronic]

Instead of using 'if...then...else..) try 'switch'.
It'll make your code easier to read, produce tighter (smaller) code.
Several examples are in the examples folder that CCS supplies, as well as the manual.

hth
jay


btw, RF_D, we've all been using 'hidden' gotos for decades. It's an assembler command.Dump any listing and it'll be there. I think the reason why some programmers don't use it, is it reminds them of BASIC. Kind of a 'Ford vs Chevy' thing.

[RF_Developer]

[Ttelmah]

It is also critical, to understand that using functions, allows the code to be split up. _unless_ you use functions, you _will_ eventually run into the problem of code being too large to fit in a memory page (except with chips like the DsPIC's).
Splitting the code, rather than being 'monolithic', is an _essential_ part of allowing things to actually fit in the processor's memory.

Best Wishes

[Mike Walne]

The problem I see with GOTOs is maintaining code structure.

I prefer to be able to see all of any one module/function/routine or whatever on ~one screen full.
All modules etc have one input at the top and one return output at the bottom.
That way, I can see the whole of any one module at a glance.
Any calls etc. to other sections are known to return to the next code line.

If your code does a GOTO to A, then A does a GOTO to B, things very quickly get out of hand and the whole thing rapidly degenerates into spaghetti code.
Been there, done that, got the tee-shirt.

I got out of the habit of GOTOs in the dim and distant days of Z80 assembler. The only jumps/branches I allowed myself were within the module being worked on i.e. tight loops within the screenfull I could see. Everything else was a call of some sort, or equivalent. With GOTOs I often had to print out code onto reams of paper, just to be able to follow my own work!

Mike

[notbad]

[Ttelmah]

C, is a relatively low level language.
Only a step up from assembler, but aimed at giving you at least reasonable program structure, and pre-written solutions for maths etc..
Most 'high level' languages, are themselves written in something like C now.

If you want to write an object based 'superset' based on this, then do so. Define yourself a structure to contain your 'object'. Include the definitions of the operations. Hand this to your function either 'by reference' (a pointer), or 'by value' (pass the variable itself), and have the function do it's job.

Do a search for XT toolkit. This was a set of C code that would port to CCS fairly easily, which implemented many of the basic OO programming concepts. There is also OOC, which wrote a pretty complete object orientated system in C. However, you seem to be losing the point of C.
C was designed to be nearly as efficient as assembler, to write relatively low level code. Object orientation is a concept designed to improve reliability when working with complex data types and operations. It is not aimed at efficient programming at a low level. It is a complex solution, that is unlikely to suit writing efficient code for hardware. Programmers writing code for things like Windows drivers, don't use OO.

You need though to remember that the PIC does not have a variable stack (except for the DsPIC's). This makes many things done in OO very hard to implement, and not the way you should be thinking for efficient PIC coding.