Re: What micros do you actually hate to work with?



As Walter showed, you can translate a piece of
assembler to C line-by-line and get virtually identical code on a
good compiler. You can't argue with that!

And I don't - especially when it is about compiling several nops linked
with
a few meaningless instructions, as it is in his example.

My factor of 10 is an overall figure, including the human <-> language
factor. Perhaps we can compare some actual code, can you locate
some .gif compressor or decompressor written in C? I'll then come
up with my assembly (68k, targeted at CPU32) and VPA (same code,
targeted at PPC) versions, for a comparison (they convert a plain
bitmap file into a .gif and vice versa).
Everything else is just general talk, engineering is a lot about the
details,
though.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

Wilco Dijkstra wrote:
"Didi" <dp@xxxxxxxxxxx> wrote in message
news:1160403886.857115.194630@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
For something like a PIC, I think C advantages are a chimera. For
a good assembly programmer productivity will improve with time as
the library of tested routines and techniques improves. With an
incomplete C system you are always fighting the restrictions of the
compiler port.

The key words are "a good assembly programmer", I guess. They seem
to be very scarce... To add to your point, a good assembly programmer
will typically be able to beat by a factor of at least 10 a C written
code
in terms of speed and memory resources.

You have clearly never used a compiler or you wouldn't make
such insane claims. Just show us one example where a C compiler
couldn't get within 10x of assembler. You can't, because even the
worst compiler would beat that trivially.

Modern commercial compilers always beat the average assembler
programmer and are typically within 25% of the absolute optimum.
They apply optimizations that assembly programmers have never
even heard of, and apply them consistently on large volumes of
source code even when they constantly change.

Even at the early days of C the overhead was never large - C was
specifically developed to map very easily onto the target architecture.
It is precisely this high efficiency that made C popular (and it still is
the only choice if you want fast code).

I have written lots of highly optimized code in both C and assembler.
In all cases I could get within 10-20% of the speed or size of the
assembler code. As Walter showed, you can translate a piece of
assembler to C line-by-line and get virtually identical code on a
good compiler. You can't argue with that!

I know several examples when people moved from assembler to
C (or even C++) and got significant codesize and performance
improvements. Or the case where programmers had written 100K
lines of assembler which became obsolete when they upgraded
to a better compiler...

Wilco

.