Ian Bell wrote:> diggerdo wrote: >> I've used the 8051 for years, but it is dated. I've used the PICS too, >> arrg! The 8051 was a great microcontroller in its time. However, the new >> AVR >> is very pointer friendly, instruction set designed to be optimum with C, >> highly scalable FLASH (4K-256K), fair amount of on board RAM, EE, and >> flexible peripherials. >> > > 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. > > IanWhy do you say that? If you want to complain that C is a badly designed language, that's fair enough - you'll get plenty of agreement there. But generally speaking, being "designed for C" means the cpu must have support for accessing data on a stack through some sort of index, and it should have fast access to data through a pointer or two. Where is the disadvantage in that? Some high level languages could benefit from other features (Forth would benefit from direct stack operations, Pascal would benefit from a frame pointer, etc.). Some types of code cannot be conveniently expressed in C (bit variables, rotation, dsp-type operations), but being designed for C doesn't mean non-C operations not supported. And from experience writing assembly code on "C-friendly" and "non-C-friendly" architectures, I have no doubt that being C-friendly is a big plus. The AVR is not actually very C-friendly - it is merely somewhat IAR-C-friendly (although far better than the 8051). The msp430 is probably the best example of a C-friendly cpu.
Moving from 8051 to AVR
Started by ●February 5, 2006
Reply by ●February 8, 20062006-02-08
Reply by ●February 8, 20062006-02-08
On 2006-02-08, John Devereux <jdREMOVE@THISdevereux.me.uk> wrote:> Grant Edwards <grante@visi.com> writes: > ><SNIP> > >> 8048 > > Arrghhh!Another veteran of the page-boundary wars, I presume? -- Grant Edwards grante Yow! As a FAD follower, at my BEVERAGE choices are visi.com rich and fulfilling!
Reply by ●February 8, 20062006-02-08
On 2006-02-08, Ian Bell <ruffrecords@yahoo.com> wrote:> diggerdo wrote: >> >> I've used the 8051 for years, but it is dated. I've used the PICS too, >> arrg! The 8051 was a great microcontroller in its time. However, the new >> AVR >> is very pointer friendly, instruction set designed to be optimum with C, >> highly scalable FLASH (4K-256K), fair amount of on board RAM, EE, and >> flexible peripherials. >> > > 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.If you want/need to use C, it seems like a pretty good recommendation to me. -- Grant Edwards grante Yow! I'm rated PG-34!! at visi.com
Reply by ●February 8, 20062006-02-08
On 2006-02-08, David Brown <david@westcontrol.removethisbit.com> wrote:> The AVR is not actually very C-friendly - it is merely somewhat > IAR-C-friendly (although far better than the 8051).After hearing about how the AVR was designed as a C target, I was a bit dissappointed at how badly it deals with pointers and stack manipulation.> 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. I just did a comparison yesterday between the AVR and the '430 (usign gcc for both). Code size on the AVR is about 50% larger than the '430 for functions with any significant use of pointers or 16-bit integers. For byte-oriented stuff the AVR code size is about 30% larger. I counted clock cycles for a few of the smaller functions, and in a few cases the '430 is faster, but in general they're pretty comparable. This is due to the fact that a higher percentage of the AVR instructions are single-cycle where the equivalent '430 instruction is 2 cycles -- this is particularly evident for instructions that access RAM. This is probably due to the fact that the AVR is a Harvard architecture and the '430 is von Neumann. The '430 also seems to be significantly lower power at the same clock rate. So, if your app's code+data can fit in in the single 16-bit address space of the 430, it seems to be the clear winner, core-wise. For bigger apps, the 128K+64K combined address space of the AVR may trump the 430's better CPU core. Of course if one has the combination of peripherals that you need and the other doesn't, then that probably decides the issue. -- Grant Edwards grante Yow! HELLO, little boys! at Gimme a MINT TULIP!! Let's visi.com do the BOSSA NOVA!!
Reply by ●February 8, 20062006-02-08
David Brown wrote:> Ian Bell wrote: >> >> 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. >> >> Ian > > Why do you say that? If you want to complain that C is a badly designed > language, that's fair enough - you'll get plenty of agreement there.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.> But generally speaking, being "designed for C" means the cpu must have > support for accessing data on a stack through some sort of index, and it > should have fast access to data through a pointer or two.I disagree on two counts. First I do not think that that is all 'designed for C means, is meant to mean by those saying so and is assumed to mean by those reading the phrase. At a minimum it is a recipe for a whole host of erroneous assumptions. Secondly, the 8051 has the characteristics you mention but noone would say it was 'designed for C'> Where is the > disadvantage in that?There is no disadvantage in being able to access data on a stack through a pointer or two. Why not say just that?> Some high level languages could benefit from > other features (Forth would benefit from direct stack operations, Pascal > would benefit from a frame pointer, etc.). Some types of code cannot be > conveniently expressed in C (bit variables, rotation, dsp-type > operations), but being designed for C doesn't mean non-C operations not > supported.Precisely, and because C does not support those operations, suggesting that a microcontroller is 'designed for C' is not a plus because it could mean that the micro does not even support those operations at an assembler level. In my book that makes it a waste of time as a microcontroller.> And from experience writing assembly code on "C-friendly" > and "non-C-friendly" architectures, I have no doubt that being > C-friendly is a big plus. >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.> The AVR is not actually very C-friendly - it is merely somewhat > IAR-C-friendly (although far better than the 8051). The msp430 is > probably the best example of a C-friendly cpu.As I said, to me C friendly is not an asset. Ian
Reply by ●February 8, 20062006-02-08
Grant Edwards <grante@visi.com> writes:> On 2006-02-08, John Devereux <jdREMOVE@THISdevereux.me.uk> wrote: >> Grant Edwards <grante@visi.com> writes: >> >><SNIP> >> >>> 8048 >> >> Arrghhh! > > Another veteran of the page-boundary wars, I presume?Oh yes. Add a few NOPs here, take away a NOP there... shuffle and repeat. -- John Devereux
Reply by ●February 8, 20062006-02-08
Grant Edwards <grante@visi.com> writes:> On 2006-02-08, David Brown <david@westcontrol.removethisbit.com> wrote: > >> The AVR is not actually very C-friendly - it is merely somewhat >> IAR-C-friendly (although far better than the 8051). > > After hearing about how the AVR was designed as a C target, I > was a bit dissappointed at how badly it deals with pointers and > stack manipulation.Also the C compilers do not seem to be able to elegantly deal with the separate code and data spaces. So your constant data either eats up RAM, or else you have to wrap everything in unportable compiler extensions. May not matter for small applications, but the larger the application, the more likely you will need to have data driven code with large menu structures, string tables, crc tables etc. This is the primary reason I am using ARM (instead of atmega128) for new designs. But I would certainly choose AVR over 8051 or PIC. Or 8048 :) -- John Devereux
Reply by ●February 8, 20062006-02-08
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.>> The AVR is not actually very C-friendly - it is merely somewhat >> IAR-C-friendly (although far better than the 8051). The msp430 is >> probably the best example of a C-friendly cpu. > > As I said, to me C friendly is not an asset.It is to those of us with C code that we need to run. :) -- Grant Edwards grante Yow! Mr and Mrs PED, can at I borrow 26.7 visi.com
Reply by ●February 8, 20062006-02-08
Ian Bell wrote:> David Brown wrote: > >> Ian Bell wrote: >>> 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. >>> >>> Ian >> Why do you say that? If you want to complain that C is a badly designed >> language, that's fair enough - you'll get plenty of agreement there. > > 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. 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. 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. (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.) Of course, there are other language choices than just C or assembly, but the same thing applies - plus you have to take into account availability of good compilers for the language, and possibly training the programmer, which will reduce the real-life practical efficiency. So as a sweeping generalisation, I'd say that most "designed for C" micros are most efficiently programmed in C.>> But generally speaking, being "designed for C" means the cpu must have >> support for accessing data on a stack through some sort of index, and it >> should have fast access to data through a pointer or two. > > I disagree on two counts. First I do not think that that is all 'designed > for C means, is meant to mean by those saying so and is assumed to mean by > those reading the phrase. At a minimum it is a recipe for a whole host of > erroneous assumptions. Secondly, the 8051 has the characteristics you > mention but noone would say it was 'designed for C' >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? 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.>> Where is the >> disadvantage in that? > > There is no disadvantage in being able to access data on a stack through a > pointer or two. Why not say just that? > >> Some high level languages could benefit from >> other features (Forth would benefit from direct stack operations, Pascal >> would benefit from a frame pointer, etc.). Some types of code cannot be >> conveniently expressed in C (bit variables, rotation, dsp-type >> operations), but being designed for C doesn't mean non-C operations not >> supported. > > Precisely, and because C does not support those operations, suggesting that > a microcontroller is 'designed for C' is not a plus because it could mean > that the micro does not even support those operations at an assembler > level. In my book that makes it a waste of time as a microcontroller. >Just because there is no direct C expression for, say, "rotate left through the carry flag", does not mean a "designed for C" micro will not implement it. In fact, you can be very certain that it will, since it is C-friendly - it forms an essential part of a 16-bit left shift (on an 8-bit micro), and such shifts *are* accessible in C. Similarly, a compiler for a DSP with a selection of instructions for complex operations will come with a library of intrinsic functions to give C programmers access to the functionality. Being "designed for C" does not in any way imply "designed *only* for C".>> And from experience writing assembly code on "C-friendly" >> and "non-C-friendly" architectures, I have no doubt that being >> C-friendly is a big plus. >> > > 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.>> The AVR is not actually very C-friendly - it is merely somewhat >> IAR-C-friendly (although far better than the 8051). The msp430 is >> probably the best example of a C-friendly cpu. > > As I said, to me C friendly is not an asset. > > Ian
Reply by ●February 8, 20062006-02-08
David Brown wrote:> Ian Bell wrote: >... snip ...>> >> 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 do you say that? If you want to complain that C is a badly > designed language, that's fair enough - you'll get plenty of > agreement there. But generally speaking, being "designed for C" > means the cpu must have support for accessing data on a stack > through some sort of index, and it should have fast access to data > through a pointer or two. Where is the disadvantage in that? > Some high level languages could benefit from other features (Forth > would benefit from direct stack operations, Pascal would benefit > from a frame pointer, etc.). Some types of code cannot be > conveniently expressed in C (bit variables, rotation, dsp-type > operations), but being designed for C doesn't mean non-C > operations not supported. And from experience writing assembly > code on "C-friendly" and "non-C-friendly" architectures, I have > no doubt that being C-friendly is a big plus.I am not sufficiently conversant with Forth to be sure, but I believe it does have direct stack operations available. You may not recognize them. However Pascal most definitely does have frame pointers. They are embodied in nested procedures, and suitable local declarations, not to mention the use of the WITH statement. Again, you may not recognize them. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
