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

On Wed, 11 Oct 2006 09:42:20 +0200, "Frank Bemelman"
<f.bemelmanq@xxxxxxxxxxxxxxxxx> wrote:

"Jim Granville" <no.spam@xxxxxxxxxxxxxxxxxxxxxx> schreef in bericht
news:452c35c9$1@xxxxxxxxxxxxxxx
Frank Bemelman wrote:
"Joerg" <notthisjoergsch@xxxxxxxxxxxxxxxxxxxxx> schreef in bericht
news:IlVWg.21517$Ij.7449@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Generally speaking, asm is dead. Generally, using C will produce
better code in less time. Generally, with less than tiny asm
projects, a C version will give you a smaller footprint.
Generally, using asm is a waste of time and energy and
produces lower quality code.


Not dead at all. There are cases where you must be sure to control
something in x machine cycles plus/minus zero. But that would be more
like using the uC as a logic chip.


Generally speaking, my dear. I know about cases where a 74HCT74
beats every processor no matter how clever you program it.

Hey, I shouted *years* ago on this newsgroup "asm is dead". Seems
there is a little bit more concensus now.

Now I could start shouting about C is dead, use C++ instead,
but I think that is too much for today.

I wouldn't call ASM dead - Walter's example shows that it has got
more accessible : another usefull choice, as well as InLine ASM ...

I said 'generally', several times.

All uC HLL users certainly should KNOW assembler.

In C versus ASM, the ASM camp always throw in those examples
where a very speedy/tight piece of software is needed. Such are
more a matter of being smart rather than the language you use.
In most cases (if not all) it is only a very small portion of
your project. When writing that portion of software, and only
when the compiled result is not satifying, it is time to have
a look at the compiled result. And you have to know a little
bit about what you are working with. Using 32 bit longs on a
8 bit uP results in long and slow code. Since it is such a
hassle to work with 32 bit longs in assembler for an 8 bit uP,
such mistakes are not made in ASM. In ASM you are more aware of
that. Once you are familiar with you compiler and target, you
don't have to check that often anymore.

I've only had exactly one case in my entire professional life where I
was permitted to implement the exact same application, from top to
bottom, in both assembly and C. It was on a PIC processor using
Microchip's C compiler tools and their assembly under MPLAB. I was
the only programmer on the project and the first implementation was in
assembly and had to fit into a processor with 4k of code space. The
second implementation was to be placed into the then newer PIC18 with
32k of code space with an eye to start adding features, once it was
exactly ported into C at the start.

This kind of real-life application test doesn't happen that often.

We'd first decided upon the assembly route in the earlier incarnation
because of some tests we did with the earlier C compiler and the very
limited code space we had available to us in the available PICs that
were appropriate to the design. At that time, the PIC18 line of parts
was 'very new' and we still hadn't even been able to get samples. So
there was no way to consider it, seriously. We kept our eye on them,
though.

In this case, also, I was the only programmer. I've been using C
since 1978 and I've actually written a toy C compiler on my own, so I
hope you can accept the fact that I do know a little about how to use
it. I knew the application well from having written it already in the
first place. So going into the C incarnation, it was probably the
best of possible circumstances for the C side -- I knew all the
details of various functions needed. Similarly, the assembly had fit
into just 2k. After writing a nicely designed equivalent in C, the
footprint was just over 12k, by comparison. Data footprint wasn't
that much different, to be honest.

The time I had available for writing both the assembly version and the
C version was also similar, by the way -- four months or so. One of
the time-wasters in writing the C had to do with the compiler's use of
static compiler temporaries. This was bad news for interrupt events
calling C, because the compiler's live variable analysis was not able
to cover that circumstance. And it cost me time to track that down
and design a work-around for the case. Others just had to do with
learning all the #pragma's needed to deal with variable placement,
etc.

Now, I'm a very experienced assembly code writer, too. I would put
myself against any C compiler on small or large programs without any
anticipation worries that I wouldn't be able to beat the output on any
measure enough so that anyone else looking at it from the outside
would agree that it was enough better to be worth having, and on a
similar schedule.

One of the advantages in writing assembly is that your semantic
options are wider. All tools are two-edged swords. C's advantages
are also its disadvantages. Same for assembly. But assembly does
unarguably have wider semantic options, whether we are talking about
extremely miniscule details such as access to applying status bits in
ways that C cannot directly support (and if you imagine I mean
clearing or setting some status bit you have no clue what I'm talking
about here), to mid-level semantic choices such as exact timing
regardless of code edge taken, or large-scale semantic choices such as
the fixed and varying assignment of registers and value passing modes,
mixing various styles of function prologues/epilogues, or coroutine
semantics (simply unavailable in C.) Whether or not these mean as
much to your application as some of the benefits of C is another
matter.

And none of any of this means one must use either C or use assembly.
Most of my applications use both, to be honest. So for me, it's an
amalgam that works more often. But one of the really big reasons for
using C, is that other programmers for C are easier to find. And that
can be very important.

But there are times and places for assembly code. And some
applications are so competitive that the nickels and dimes are
important, or the power consumption is important, or the die size is
important, or... and assembly can at times make the difference.

My hope is that everyone be proficient at both.

I don't know if anyone else here can say that they actually were put
in a position of doing the exact same project twice -- once in
assembly and once in C -- that they had excellent experience in using
both and were competent at both and can then make a real comparison of
a real world case. But I have had that experience once. And there
was a remarkable difference in code side (not data size.)

I've also challenged myself in writing code snippets in both. I
suppose a lot of us may have done that. I'd be happy to provide one
such example here and let anyone try their compilers on it and see
what I did in assembly, by comparison. But others will legitimately
argue this proves nothing and I'd agree with them. Still, it may open
an eye or two.

Meanwhile, C is a very good choice for many if not most applications,
where a good C tool is available.

Jon
.

Relevant Pages

  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... is that other programmers for C are easier to find. ...
    (comp.arch.embedded)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... In this case, also, I was the only programmer. ...
    (comp.arch.embedded)
  • Re: What micros do you actually hate to work with?
    ... with less than tiny asm ... hassle to work with 32 bit longs in assembler for an 8 bit uP, ... Microchip's C compiler tools and their assembly under MPLAB. ... After writing a nicely designed equivalent in C, ...
    (comp.arch.embedded)
  • Re: Question about jumps
    ... for Unix in assembler. ... ASM, of course. ... No way I could trust a compiler. ...
    (alt.lang.asm)
  • Re: HLA v2.x and / or LASM suggestion: Win32 Resources
    ... Assembler" probably always get when people are actually talking about ... machine_ from ASM or even some of the more "low-level" C programming - ... "Abstraction" - as I keep saying and, one day, I Hope people will ... writing code thinking it's "portable" when, in fact, it contains ...
    (alt.lang.asm)