Re: Moving from 8051 to AVR

On Fri, 10 Feb 2006 16:07:36 +0100, "Ulf Samuelsson"
<ulf@xxxxxxxxxxxxx> wrote:

: I generally agree with a lot of what you write, but this seems like a
: thin point if you suggest that it is Atmel's intent to make a chip
: that is friendly to C programmers who know as little about embedded
: programming as a PC programmer without such education might...


But I cannot recall having a product business meeting where others at
the table were asking me whether or not the CPU I had selected was "C
friendly" or not. A lot of other things come up -- availability,
sourcing, cost, power, size, etc., etc., etc. But no one really cares
that much, except possibly for programmers. And I don't care. Being
the programmer, that means no one cares, in my case.

Have been to multiple meetings where people like to hear about the AVR
and do not want to hear about the 8051s even if they have the same set of
peripherals.

I like the AVR, too, Ulf. I already pointed you to a post I made in
1999 here, where I lauded it over and above my other experiences in
writing assembly code.

But this changes nothing in my comments today and yesterday. Both are
simultaneously true. If you cannot see why, then you do not follow
what I'm saying very well.

To me, beeing C friendly means that you do get better code size and
performance than C-Unfriendly architectures.

How could I argue with the way you have now defined the question?

If a C compiler is a requirement for your project and you meet your
overall application better using some well-selected C compiler for CPU
x than when using a similarly well-selected C compiler for CPU y, then
you should probably use the one that meets the needs better. That is,
of course, if there aren't other reasons that compete for attention in
the project and would argue otherwise.

But I have to say that I don't recall making that kind of comparison
in 30+ years. I can't recall everything else being so equal that the
deciding issue was whether or not this particular well-selected C
compiler for CPU x was better than that well-selected C compiler for
CPU y, suggesting that I choose CPU x over CPU y on the basis of that
narrow focus. In my experience, the decisions are taken for a variety
of other reasons long before I start worrying about things like that.
Stuff like I've already mentioned: peripheral features, availability,
sourcing options, cost, power, packaging, future projections, and so
on.

So I don't find your focus very useful, in practice.

It should also give effect in development time.

Really? I thought you defined it as "better code size." But now you
conflate it with this? I think you don't even know yet how you define
"c friendly," except in that religious (and useless) meaning I already
mentioned -- as "everything good." So now, if development time is
better, than that is "c friendly," too. What else would you like to
include, Ulf?

There is no objective meaning here, from how I read you.

People care about this factors as you say.

Indeed they do care about development time.

Typically you select the CPU on peripherals, preferably in a family of
different memory sizes.
Then you write the code, and finally you optimize to make it fit the
smallest possible member of the family.
If you can reach that without having to do nasty tricks, then your
development time is reduced significantly.

My experience is that there really _are_ bad problems with certain C
compilers that can crop up and eat your time away. But none of my
experience says that the truly bad issues have anything to do with the
processor, as an issue inherent to it (though I may grant an exception
or two, it's not the usual case for 8 bit CPUs and above, today.) The
time drain I've experienced in using C compilers has had to do with
poor design or implementation by the vendor that I had to track down.
And I can't say that this has been more or less, by CPU family.

But on the subject of C compilers, it's been my experience that it is
the tool vendor I've had to worry about, not the CPU itself.

I guess my main point, though, is that CPU manufacturers like to push
their product on some canard, like "my CPU is more C-friendly than
theirs!" But it's (1) more misdirection than fact, and (2) isn't an
important focus, anyway. What counts are the larger fundamentals
about the CPU family -- it's peripheral features, it's availability,
sourcing options, cost, power, packaging, business model relationships
to your own, and whether or not the actual tools together with all the
rest can serve your application well. So I've no idea why a narrow
focus on "c friendly" is meaningful to anyone much except for those
marketing their CPUs and those writing compilers for them. At least,
you haven't managed to convince me about it.

Jon
.

Relevant Pages

  • Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation
    ... let's start with the compiler. ... generates an expensive cache miss. ... Now consider the following sequence of events on a superscalar CPU: ... One special part of this is that the ops structure is never to be freed ...
    (Linux-Kernel)
  • Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation
    ... let's start with the compiler. ... generates an expensive cache miss. ... Now consider the following sequence of events on a superscalar CPU: ... One special part of this is that the ops structure is never to be freed ...
    (Linux-Kernel)
  • Re: Critical Performance Issue - Help!
    ... various optimization levels or combinations of compiler flags. ... unless it's precipitating some sort of CPU pathology. ...
    (comp.programming)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)
  • Re: Moving from 8051 to AVR
    ... make the CPU architectures more C friendly. ... If I were a compiler vendor considering porting an existing compiler ... then I'd probably care more. ... that much, except possibly for programmers. ...
    (comp.arch.embedded)