Moving from 8051 to AVR

What makes you think structures and data stacks are less used in assembly?

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

Ian

Reply to
Ian Bell
Loading thread data ...

Nah, no job change in the near future, just was getting concerned about the '51 getting long in the tooth..

But the way it looks, i might as well stick with what i know and be happy :)

Reply to
ziggy

The 80C51 has a Boolean processor, so can do : CPL, AND OR and AND NOT etc, that's much more clumsy on a AVR. In an C51, you can simply name a BIT, and the linker does the rest, packing them for you. The AVR cannot branch on a BIT, only Skip

Thus the AVR is simpler, ( which saved them ASIC space ) but it has a cost in RAM and CODE size.

We have done this, for PulseDensity DACs, in a high priority interrupt. Somewhat specialised, but true embedded uC stuff. This mapping allows you to run/test counters, with no CY or ACC impact at all.

As an example, try INC of a DATA memory location : ... or memory-memory moves, or even Load SFR,#Constant

INC Direct in a 80C51 [2 bytes] ( or INC @ Ri via pointer ) or DJNZ DIRECT looping....

On an AVR, that's 2 x 32 bit opcodes to READ/WRITE and one 16 bit one to INC. So yes, you can _do_ it on an AVR, but in many more cycles and bytes of code, and you need a working register....

.. and a register frame pointer would have been really nice - then the efficent register stuff, (which the AVR does well), could work into the RAM. The Z8 does this. The 196 extended the register array. IIRC the Sparc (?) had a register frame scheme, that allowed split usage - some for parameters, and some for local variables.

Even the lowly 8048 could INC/DEC/XCH/DJNZ at the pointers, and it could add/subtract/or/xor/and into the ACC from at a pointer as well. The AVR can only load and store data memory....

Yes, thankfully :), most new ones have 4 options per port bit : Quasi/CMOS/IP/OpenDrain.

.. and the ARMs - if you need > 64K code, they pretty much self-select, and their peripherals tend to have better thruput, so even an 8K(!) ARM might be chosen - not for the core, but for the peripherals.

That's an advantage of multi-sourced cores :)

On the subject of Multisourced: I see today mention of an Async 80C51 core that needs 89pJ per instruction, and gives very low EMC.

-jg

Reply to
Jim Granville

You do realize that C was designed to do 'high level' system work specifically for the PDP-11. Many of the C constructs map directly into one PDP-11 instruction, such as d[i++] = s[j++]

See the old Kernigan and Ritchie papers.

--
Pat
Reply to
Pat Farrell

Why?

Would you prefer to use a micro that forces a C compiler to generate inefficent wasteful assembly code?

Op codes that are friendly to C are certainly useful in assembly. Justifying a processor as being efficient just for assembly is nonsense today. For fast development C blows away assembly. Assembly has a place in limited applications; rare time critical code, high volume cost sensitive production.

Reply to
diggerdo

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.

Reply to
diggerdo

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

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.

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

formatting link

[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
 Click to see the full signature
Reply to
Grant Edwards

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

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).

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.

Reply to
David Brown

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

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.

Why?

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.

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

ian

Reply to
Ian Bell

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.

C has its place in low volume cost insensitive applications.

Ian

Reply to
Ian Bell

Sounds a lot like Forth.

Ian

Reply to
Ian Bell

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
Reply to
John Devereux

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.

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).

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...

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).

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).

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.

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.

I fully agree with that.

mvh.,

David

Reply to
David Brown

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

Reply to
Ian Bell

Beeing C friendly, to me means that a person educated at university on a PC will not have to change his/hers programming manners in order to overcome the deficiencies of the CPU core. Getting rid of global variables is good programming practices but the 8051 will force you to use this costing extra time and making the C code more unreadable.

Getting rid of the memory to registers opcodes is key to get the performance of register to register operations. Try comparing two 16 bit (or 32 bit) numbers in a loop on an 8051. The embedded version of a road accident... Remeber, ANSI C requires "int" precision on certain operations...

Looking how good a CPU core is on a single task, is a waste of time unless the end application is *heavily* dependent on this single function. Atmel claims the AVR excels on real applications, not on small single function benchmarks.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Interesting point. I wonder why that is? (I agree it is probably true). Unfortunately (from the point of view of programming a small 8 bit microcontroller) C programmers tend to use these as a matter of course rather than because they really need them. My point is that because they are used more frequently does not mean they are better.

Dunno. I, personally, tend to use registers to pass variables for example, but I would hesitate to say that is the most likely way for certain - I have seen many code examples that do it quite differently.

Regarding data stack, I think is misunderstood your use of the term. I agree it is not used for passing variables on the 8051, but that of course is only one use of a data stack.

DPTR can also point to code space.

Well they are indexed but yes you cannot add an offset which is a pain.

I think my all time favourite microprocessor is the 6809. I first used it back in 1981.

ian

Reply to
Ian Bell

I agree we should make that distinction but my guess would be that more programmers are engaged in the high volume developments. Do you know if there are any statistics about this anywhere?

ian

Reply to
Ian Bell

I am doing just that. Already ordered an SBC. I already rum/code on Linux so gcc is familiar to me. Quite looking forward to it. I strongly suspect the ARM is the 21st century 8051.

Ian

Reply to
Ian Bell

No, I don't know I'm afraid - it's all speculation :)

I could also speculate that an increasing number of even "high volume" projects are in fact using high level languages, *despite* being cost sensitive. For example I suspect that mobile phones, set top boxes, game consoles are not (now) programmed in assembler. And these are the applications that have large teams of programmers thrown at them. Things like talking greeting cards, digital watches, kitchen appliances must surely only employ a minority of programmers.

--

John Devereux
Reply to
John Devereux

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.