Moving from 8051 to AVR

"Ian Bell" <ruffrecords@yahoo.com> wrote in message 
news:dsd47e$vla$1@slavica.ukpost.com...
> David Brown wrote:
>
> Depends on the processor and the application. Here we are specifically
> considering 8 microcontrollers where the emphasis is on control. IME non C
> friendly microcontrollers make better controllers and are best programmed
> in assembler.

Best programmed in assembler? I'd agree ... ten years ago ROM space was 
limited.
Today you can buy 32K ATmega32 for $2.99 and ARMs for $1-$2 dollars.
Development time for assembler is several fold that of C. The justification
for assembler just doesn't exist today as it did in the past. Of course 
there are
always time critical applications that must be assembly.

I try to do as much microcontroller development as possible in C.
Projects are completed so much faster, with higher integrity in C.

On 2006-02-09, Pat Farrell <pfarrell@nospam.com> wrote:
>>> The msp430 is  probably the best example of a C-friendly cpu.
>> 
>> Agreed.  Though it's missing a few key features of the pdp11
>> (one of the C-friendliest architectures I've seen), it has a
>> very pdp11-like feel to it.
>
> You do realize that C was designed to do 'high level' system
> work specifically for the PDP-11.

No it wasn't.  Though I do realize it's a commonly held belief.

> Many of the C constructs map directly into one PDP-11
> instruction, such as d[i++] = s[j++]

Both of those operators were inherited from "B" and were around
before the PDP-11 was invented.  The fact that they map so well
into the PDP-11 instruction set is either happy coincidence or
great minds thinking alike.

> See the old Kernigan and Ritchie papers.

Quoting from the Bell Labs whitepaper titled "The Development
of the C Language" by Dennis Ritchie [Yes, "dmr" is Dennis Ritchie.]

    http://cm.bell-labs.com/cm/cs/who/dmr/chist.pdf

  [From a discussing the development of the "B" language on the
   PDP-7 from p5 of the above document]

      Thompson went a step further by inventing the ++ and --
   operators, which increment or decrement; their prefix or
   postfix position determines whether the alteration occurs
   before or after noting the value of the operand. They were not
   in the earliest versions of B, but appeared along the way.
   People often guess that they were created to use the
   auto-increment and auto-decrement address modes provided by the
   DEC PDP-11 on which C and Unix first became popular. This is
   historically impossible, since there was no PDP-11 when B was
   developed.
   
   [...]
   
      The B compiler on the PDP-7 did not generate machine
   instructions, but instead threaded code' [Bell 72], an
   interpretive scheme in which the compiler's output consists of
   a sequence of addresses of code fragments that perform the
   elementary operations. The operations typically in particular
   for B act on a simple stack machine.

I presume you'll believe Dennis Ritchie's account of the
development of the C language?
   
-- 
Grant Edwards                   grante             Yow!  Wow! Look!! A stray
                                  at               meatball!! Let's interview
                               visi.com            it!

In article <11ukekim2787dff@corp.supernews.com>, Grant Edwards
<grante@visi.com> writes
>On 2006-02-08, Ian Bell <ruffrecords@yahoo.com> wrote:
>
>> Depends on the processor and the application. Here we are specifically
>> considering 8 microcontrollers where the emphasis is on control. IME non C
>> friendly microcontrollers make better controllers and are best programmed
>> in assembler.
>
>There are other languages.  Intel's PLM-51 (or whatever it was
>called) seemed like a good compromise.

That, AFAIK became obsolete and "not supported" in 1986 Though I do have
a copy of the last version they did. 


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ian Bell wrote:
> David Brown wrote:
> 
> 
>> When it comes to indexed addressing, which is essential for use of
>> structures and data stacks (used in high-level languages, but less used
>> in assembly), the 8051 is a non-starter.
>>
> 
> What makes you think structures and data stacks are less used in assembly?
> 

Real life experience.  I don't mean that they are not used, but that 
they are more common in higher level languages.  In assembly 
programming, you are more likely to put parameters and local variables 
in registers, and as global data when you've run out of registers, while 
a C compiler will use a data stack when it runs out of registers (unless 
it is a C compiler for an 8051, in which case it will use global data 
but pretend it's a data stack).

> And the 8051 has three index registers so it's hardly a non-starter.
> 

As far as I can see, that would be R0, R1 (pointing only to internal 
ram), and DPTR (pointing only to external ram).  And no indexed 
addressing modes, which are essential to accessing structures through a 
pointer (unless you want to do all the calculations manually).  I have 
done this sort of thing (in assembly) on processors with no index modes, 
and processors with index modes, and I know which I prefer.

> Ian
> 

diggerdo wrote:

> 
> "Ian Bell" <ruffrecords@yahoo.com> wrote in message
>>
>> Here we go again, the tail wagging the dog. A micro 'designed' to use C
>> is not a recommendation its a good reason not to use it.
> 
> Why?
> 
> Would you prefer to use a micro that forces a C compiler
> to generate inefficent wasteful assembly code?
> 

No. I prefer to use assembly but that is not the point. I prefer to use a
micro that is right for the job.

> Op codes that are friendly to C are certainly useful in assembly.

Most micros already have these. The trouble is C does not support the low
level operations that characterize small 8 bit micros like the AVR et al.

> Justifying a processor as being efficient just for assembly is nonsense
> today.

Why?

> For fast development C blows away assembly.

The important thing is to use the best tool for the job. The problem with
saying an 8 bit microcontroller is 'designed for C' is that it implies C is
always the best language to use which is not true. It depends on the
application. Hence my comment about tail wagging the dog.

> Assembly has a place 
> in limited applications; rare time critical code, high volume cost
> sensitive production.

What makes you think these applications are limited? In practice they are by
far and away the most common.


ian

diggerdo wrote:

> 
> "Ian Bell" <ruffrecords@yahoo.com> wrote in message
> news:dsd47e$vla$1@slavica.ukpost.com...
>> David Brown wrote:
>>
>> Depends on the processor and the application. Here we are specifically
>> considering 8 microcontrollers where the emphasis is on control. IME non
>> C friendly microcontrollers make better controllers and are best
>> programmed in assembler.
> 
> Best programmed in assembler? I'd agree ... ten years ago ROM space was
> limited.
> Today you can buy 32K ATmega32 for $2.99 and ARMs for $1-$2 dollars.
> Development time for assembler is several fold that of C. The
> justification for assembler just doesn't exist today as it did in the
> past. Of course there are
> always time critical applications that must be assembly.
> 

This simply is not true. The most significant commercial driver in
electronics today is unit cost  and that is directly related to Bill of
Materials and hence microcontroller cost. If I can squeeze my code into a
50 cent cheaper device then I save half a million bucks for every million
units made. That buys a lot of engineering time.

> I try to do as much microcontroller development as possible in C.
> Projects are completed so much faster, with higher integrity in C.

C has its place in low volume cost insensitive applications.

Ian

Grant Edwards wrote:
>    
>       The B compiler on the PDP-7 did not generate machine
>    instructions, but instead threaded code' [Bell 72], an
>    interpretive scheme in which the compiler's output consists of
>    a sequence of addresses of code fragments that perform the
>    elementary operations. The operations typically in particular
>    for B act on a simple stack machine.
> 

Sounds a lot like Forth.

Ian

Ian Bell <ruffrecords@yahoo.com> writes:

> diggerdo wrote:
<SNIP>
>> Assembly has a place 
>> in limited applications; rare time critical code, high volume cost
>> sensitive production.
>
> What makes you think these applications are limited? In practice they are by
> far and away the most common.

I think you have to make a distinction between the most common end
products, and the most common programming tasks. The "high volume cost
sensitive" end products are of course *by definition* the most
"common" ones. But I would guess that most *programmers* are actually
employed in the more specialised applications, where shaving of every
penny of production cost is less important than getting the program
done, quickly and correctly.

-- 

John Devereux

Ian Bell wrote:
> David Brown wrote:
> 
>> Ian Bell wrote:
> 
>>> I don't know if C is badly designed - that's not my point. A
>>> microcontroller 'designed for C' wrongly encourages people to think that
>>> C will produce the most efficient/effective code on that device which is
>>> plainly not true.
>>>
>> Depending on what metrics you use for "efficient/effective", that may or
>> may not be true.
> 
> I agree there are cases where C is the best language of choice even on an 8
> bit microcontroller - for example where resources are not scarce or unit
> cost is not paramount or high performance is not required. I have no
> problem with using C in the right circumstances. My objection is the
> implication that 'designed for C' means C is always best when clearly it is
> not.
> 

Fair enough.

It's also worth noting that most of the features that the 8051 core has 
which AVR does not (such as instructions directly manipulating memory) 
would benefit C compilers on the AVR, apart from perhaps the bit address 
modes.  An 8-bit micro designed to be like the AVR but even more 
"designed for C" would have these features.

>> Ultimately, of course, a good assembler programmer is 
>> going to be able to get the highest code density and fastest run speed
>> on any architecture, but the cost (both in terms of time, and programmer
>> ability) of writing the code compared to the gains in code efficiency
>> are going to be different for different sorts of cpu, and different
>> sorts of programming task.
> 
> Agreed.
> 
>> On an avr, a C compiler can produce pretty 
>> good code - not optimal, but not bad.  On an 8051, it's a struggle for a
>> compiler to produce good code because the language is such a bad fit for
>> the cpu architecture.  On an msp430 or an ARM, the compiler is going to
>> be able to come much closer to optimal, and probably will produce better
>> code than an assembly programmer would (assuming the programmer is
>> interested in things like maintainability and readability of the code,
>> and in finishing in a sensible amount of time), at least for larger
>> programs. 
> 
> I'll not comment on the maintainability or readability of code - that's a
> separate debate ;-) , but I concur that C on an ARM is generally a better
> choice than assembler - if someone said the ARM was 'designed for C' I
> would have no objection. I am not familiar with the MPS340 so cannot
> comment.
> 

Have a look at it - it really is a nice chip (for C and assembly).  It 
is very consistently 16-bit - you have a single 16-bit address space, 
with no exceptions, so there is no messing with different memory areas 
or different pointer types (a problem both the 8051 and the AVR suffer 
from).  Every register can be a pointer and use any mode.  The stack 
pointer, program counter, status register, and a "constant generator" 
register are visible as normal registers.  This gives a very orthogonal 
instruction set and architecture.  Memory space limits the high end 
msp430's, but then it often makes sense to move to a 32-bit architecture 
anyway (ARM, Coldfire, or whatever).

>> (This is based on having written assembly and C code on a 
>> range of micros, from C-unfriendly ones like the COP8 and PIC16, through
>> the AVR, the msp430, and big cpus like the 68k and PPC.)
>>
> 
> Good lord, I remember the COP8 and I also remember writing 6K of code for
> the 1802 using a line based editor - I don't think C had been invented
> then.
> 

I haven't done anything new with the COP8 for a while, but I regularly 
make minor modifications to existing programs.  I've got COP8 programs 
consisting of over 20,000 lines of assembly...

>> So as a sweeping generalisation, I'd say that most "designed for C"
>> micros are most efficiently programmed in C.
>>
> 
> I am happy to agree with that statement for processors like the ARM but not
> for ones like the AVR.
>  

The AVR lies somewhat in between.  It is more C-friendly than most 
"traditional" 8-bit micros, but less so than most 16-bit or 32-bit 
micros.  I suppose where you draw the line depends on the sorts of 
programs you write, and the sort of programmer you are (or the sort you 
are talking about - I've been trying to generalise).

>> To be entirely honest, I have never actually used an 8051, and have only
>> briefly looked at the core.  But (at least for a standard 8051) AFAIK
>> access to data on the stack is very inefficient - hence 8051 C compilers
>> play all sorts of tricks to implement local variables and parameters as
>> dedicated globally-allocated objects.  And I believe different 8051
>> manufacturers have added different numbers of pointer registers in
>> attempts to make the devices more C friendly.  Am I also right in
>> thinking that different parts of memory ("normal" ram, "extended" ram,
>> flash, I/O, etc.) are all accessed in different ways?
>>
> 
> Pretty much spot on. It also has a Harvard architecture which is 'less C
> friendly' per se than a von neuman one. That's the thing with 8 bit
> microcontrollers - they are designed to do a specific job not suit a
> particular high level language.
> 

Harvard architecture is always something you have to work around for C, 
using non-standard constructs or extensions of some sort (unless the 
Harvard nature is hidden from the ISA - many cpus have one address space 
even though they have separate buses).

>> As to what "designed for C" means beyond these basics, I'd guess that
>> the other major implication is that there is a C compiler (and debugger)
>> available for it.
>>
>> I'd also note that except for cases where backwards compatibility with
>> older C-unfriendly cores is vital, or for very specialised cores,
>> probably all modern cpu designs are "designed for C".  Like it or not, C
>> is the lowest common denominator of programming languages.
>>
>>
> 
> I think it is important to differentiate between 8 bit microcontrollers and
> everything else. It is only the former where I object to the 'C friendly'
> label for the reasons given earlier. 8+ bit microprocessors and16+ bit
> microcontrollers I have no problem with as far as labeling them 'C
> friendly' is concerned.
> 
>>> Depends on the processor and the application. Here we are specifically
>>> considering 8 microcontrollers where the emphasis is on control. IME non
>>> C friendly microcontrollers make better controllers and are best
>>> programmed in assembler.
>>>
>> Non C friendly architectures are often best programmed in assembly, it's
>> true.  And for many types of programs, assembly is a sensible choice of
>> language.  But I really cannot think of any advantage the C-unfriendly
>> micros I have used have over the C-friendly ones (in terms of their cpu
>> core, I mean), for any sort of programming.  But I'm happy to hear if
>> you've got some examples of program snippets or tasks that work well on
>> the 8051 but would be poor (either big, slow, or awkward to code) on an
>> AVR or msp430, programmed in either assembly or C.
>>
> 
> Try an atomic byte increment or decrement.
> 
> Personally I don't think we are a million miles apart. 'C friendly' applied
> to anything other than an 8 bit microcontroller is OK by me.
> 

We certainly seem to agree for anything bigger than 8 bit (and we 
probably also agree for anything smaller, too - I'd not recommend C for 
the MARC4 chips).  I suspect we'd be even nearer if you were also 
thinking about how this all applies to the average embedded programmer, 
rather than those (like you and me) with lots of assembly experience.

> One last point. When using C you are at the mercy of the compiler and the C
> programmer. There is little you can do about the former and my experience
> of the latter, where C was the primary language of the programmer, has been
> that extremely inefficient code is produced. My first embedded C project
> (about 15 years ago) fell into this category. The microcontroller, an
> Hitachi H8 was certainly what you would describe as 'C friendly' but the
> combination of a poor compiler and C language programmers meant the code
> was 50% too large and 500% too slow. I spent a lot of time educating the C
> programmers how to write efficient/effective C code and just as long
> tweaking it to circumvent the idiosyncracies of the compiler.
> 

I've seen people write bad assembly code as well as bad C.  It boils 
down to the way the programmer thinks - can (s)he think embedded 
programming, or only "big cpu" programming?  An argument against C is 
that you get "big cpu" C programmers who try to use the same methods in 
embedded systems - it's seldom you see assembly programmers going down 
that route.

I also think that it is important to understand a processor at the 
assembly level to get the best out of it, even if you are always going 
to be using C (or another high-level language).  When learning a new 
processor, I generally start writing assembly code before trying the 
compiler, just to get the feel of it.  That way you can understand the 
code the compiler is producing, and writing C code that suits the target.

> We reused this code in a scaled down version of the product using the same
> H8 core quite successfully but we did have to tweak the code again to cope
> with the latest version of the compiler. Later, a third version was created
> using third party programmers (there were good reasons for this) but once
> again the resultant code was bloated and slow. This time we had to modify
> the code ourselves as by now the third party had disappeared from the
> scene.
> 
> I admit, C compilers are (hopefully) better today, but C programmers still
> do not migrate to 8 bit microcontrollers with any degree of ease. Give me
> an assembler coder who has learned C any day.
> 
> Ian

I fully agree with that.

mvh.,

David

Chris Hills wrote:

> In article <11ukekim2787dff@corp.supernews.com>, Grant Edwards
> <grante@visi.com> writes
>>On 2006-02-08, Ian Bell <ruffrecords@yahoo.com> wrote:
>>
>>> Depends on the processor and the application. Here we are specifically
>>> considering 8 microcontrollers where the emphasis is on control. IME non
>>> C friendly microcontrollers make better controllers and are best
>>> programmed in assembler.
>>
>>There are other languages.  Intel's PLM-51 (or whatever it was
>>called) seemed like a good compromise.
> 
> That, AFAIK became obsolete and "not supported" in 1986 Though I do have
> a copy of the last version they did.
> 
> 

There is/was a later kind of derivative Modula-2 but there seems to be
little activity on the 8051 port which is a pity IMHO.

Ian