Re: Moving from 8051 to AVR



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 global variables is not "good programming practice".

Global variables should only be used when necessary.
It should not be the standard way of doing things.

There are times when global variables are the right choice, and times when
they are not. For some sorts of programming, it makes sense to
encapsulate everything in structures or classes, and pass around pointers
to data rather than directly accessing global variables. For other sorts
of programming, global variables are the most appropriate tool.

For example, when programming on a PC, if you have a function that
calculates two results and returns an error code, you might declare it as:
int foo(int arg, int *pResA, int *pResB);


I think functions which returns two results in itself is bad programming
practice.
Makes code less readable.

The advantages of avoiding globals are better control of your namespace,
less interdependencies between modules, and re-entrant and thread-safe
code.

On an AVR (assuming re-entrancy is not an issue - a valid assumption for
most code), it makes far more sense to use:

int resA; int resB;
int foo(int arg); // Sets resA and resB

The advantages here are smaller and faster code for both the caller and
the callee, clearer generated assembly (checking the generated assembly is
important), and easier debugging.

And less readability.


Getting rid of the memory to registers opcodes is key to get the
performance of register to register operations.

I'll not dispute that - there are reasons why the AVR instruction set was
designed like it is (though I think a few mistakes were made).

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.


It won't excel on anything if you let PC-style C programmers anywhere near
the chip without proper re-education, although I'll agree they would do
even worse when faced with an 8051.


Which is the point...


--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB


.



Relevant Pages

  • Re: Moving from 8051 to AVR
    ... Getting rid of global variables is not "good programming practice". ... embedded programming requires a rather different balance between data abstraction and encapsulation and efficient implementation than is common in "big system" programming. ... int foo; ...
    (comp.arch.embedded)
  • Re: Portability: Harmony between PC and microcontroller
    ... int is the natural integer type for the system. ... You are, perhaps unintentionally, paraphrasing the standard in a way ... One of the things that you might not realize is that the C programming ... In the real world, most embedded systems have more complex jobs to do, ...
    (comp.lang.c)
  • Re: What will be the next MAJOR programming language for commercial use?
    ... Variants can be considered as such a common OO pattern that it is worth ... Int of int ... As lists are built-in, they can be decomposed in a pattern just as they are ... features found in other state-of-the-art programming languages. ...
    (comp.lang.misc)
  • Re: global variables are bad?
    ... You dont say? ... about global and local variables in programming. ... The latter was not my intention. ... suiggest that "global variables do not exist in C". ...
    (comp.lang.c)
  • Re: Bug/Gross InEfficiency in HeathFields fgetline program
    ... Maybe this is true in the sort of programming you do, ... you are storing a list of amounts of money as integers. ... int average ... the array, rounded towards zero. ...
    (comp.lang.c)

Loading