[sdiy] Quick C query

Neil Johnson neil.johnson97 at ntlworld.com
Mon Nov 22 11:17:46 CET 2010


> Phillip, thanks for a very interesting post. Regarding optimizations,
> isn't Tom's MCU supported by some sort of gcc-based toolchain?

GCC is pretty good these days.  Since they moved over to SSA for the
internal representation there are many many more optimisations that
are possible.

>>> With MCU's you're dealing with something that's slower than a 386.
>>> Most applications for the 386 were written in pure assembler.
>> I doubt that somehow even if by virtue of the compiler wars between Borland and Microsoft.
> I think you're more right than I am, given that you must be viewing
> the computer based on where it was intended to go - i.e. companies and
> scientific usage.

Ahhh, fond memories - the first PC I used for serious engineering use
was a Tandon 386/20, with a HUGE (!!!!) 1MB of RAM.  And OrCad SDT
worked well on it too.  Was it really only 20 years ago???

>> Which gets me back to knowing what the compiler does with code. Output to a listing file and look can get you a very long way before having to goto assembly.
> same reason why I have suggested a disassembler!

One advantage of a listing file is that you get source interspersed
with the assembler so you get a clear connection between C and asm.

> Premature optimization is one thing, but writing dumb idiot-code is
> another. You don't want to do either, unfortunately the latter group
> you mentioned seems to correlate well with the latter group I mention.
> It's much easier for newbies to say "buy a faster computer" than for
> them to learn how to do things right.

Using a language like C gives you, I think, the best of both worlds:
it handles all the drudgery of local and global variables, if-trees,
math expressions, and so on, and yet it is sufficiently low-level that
if you know what the compiler is going to do you can code pretty close
to assembler.  PLUS the benefit of the optimizer to do some funky
stuff with your code to give you improvements in execution speed or

The whole issue about the optimiser is quite interesting.  If you want
the optimizer to work for you then write simple CORRECT code, and then
it will be able to do a better job.  The optimiser has to *try* to
work out what you want your program to do, not necessarily what you
coded.  A quick example: if GCC sees you writing a trivial loop that
looks like doing a memcpy it will optimise out that code with a call
to memcpy, which will usually be smaller (reuse of library code) and
faster (a good memcpy will be handed coded to be fast on the target

I've seen instances of where some "clever" programmer wrote some
horribly contorted and difficult to understand code because they
thought it would be smaller/faster, and then the optimiser found it
too difficult to understand so it didn't bother optimising it.
Rewritten in simple steps and the optimiser ended up doing a better
job than the original contorted code.

But then I did a PhD in optimising compilers so I guess I'm biased :)


More information about the Synth-diy mailing list