Deliberately inefficient C code

I am trying to think of some ways to "stress" C compilers, for a comparison of PIC compilers that I'm writing with AtomSoft.

Can people suggest code that is deliberately inefficient in order to test how different compilers handle it? Code which is useless and purposely obscure wont help, as nobody would write it in such a way. But algorithms which require some intelligence from the compiler would be useful.

Results will be made available to all on ETO, hopefully we can get a first version done over the next week.

Well here is what I have so far (just the loop):


Will be interesting to see how different compilers handle this. HI-TECH compiles it to just under 2KB (no optimisation), time to check the ASM and see where all that is coming from!

No compiler should optimize out an asm call for a NOP. It's an essential technique to produce a delay. And with the fact that you ASKED for a non-compiled asm command, it would not be performing what you coded if it left it out.

The code,
will not be optimized as LATA is listed as volatile.

I'll be interested to see the results of your test. Will you be including C18?

Mike.

I'm not too worried about whether the compiler will optimize out code so badly written it inherently doesn't DO anything.
I make it a point for code to do something. It's more interesting how efficient it is for typical code that "does something".

Pommie said:

will not be optimized as LATA is listed as volatile.

Click to expand...

I had not considered this. Here is a good page explaining what this means that helped me: How to Use C's volatile Keyword | Netrino

I will toggle the latch separately (was considering using it to time how accurate the delay routines are) and use a non-volatile variable to test optimization.

Pommie said:

I'll be interested to see the results of your test. Will you be including C18?

Click to expand...

Yes, C18 is on the list. It's a comparison of cost/features/libraries as well as optimization.

I'm gonna go out on a limb here and say this sort of "comparison" will only be misleading.
It is not especially important whether it optimizes out code written so badly it does nothing.

There are of course many differences in compilers. Microchip has some documentation on the optimizations it disabled with its "free" MCC18 compiler vs the "purchase" version.

There's major differences based on how pointers are handled. There's a problem with how C handles pointers, and how a PIC would access them. In particular, you could have a pointer and not know whether it's a location in RAM or ROM but the code to read the data is totally different inside the PIC, which creates troubles for the compiler and ultimately the programmer.

Optimization is not the key point of the comparison. However, it's an important thing, if one compiler generates 1KB of code and another generates 5KB from the same source then clearly somewhere the second one is doing something unusual.

The reason I'm asking about optimization is that it's one area I don't understand so well on embedded systems. On a PC where code size is not a huge issue some operations are actually "unoptimized" in space terms in order to help them run faster (e.g. unrolled loops). There is crossover with PC techniques though, such as inlining functions which are only called once (saves stack and code space), merging of constants (e.g. strings) etc.

Instead of using the word optimization or inefficiency, how about if the question is phrased "what code can be written that taxes the compiler?". Your point about pointers is a good one here.

I will be compiling some "real world code" as a comparison also. Some of that code (e.g. Pommie's GLCD code) uses pointers, so that should be a good test.

what about using some floating point stuff?