Re: Delay Routine: Fully-portable C89 if possible

Martin Wells wrote:
David:

You can contest all you want. At best, you can argue that it is
*possible* to write embedded code (portable or otherwise) without having
specific sized types, but there is no doubt that people write better
code by taking advantage of these types.


The C language is described in such a way that "int" should be the
most efficient type (or at the very least tied for first place).


That's only the case for some architectures - in particular, for 8-bit micros, it is far from true.

If I want to store a number, I use unsigned.
If the number can be negative, I use int.
If the number needs more than 32-Bits, I use long.
If I need to conserve memory, I use char if it has enough bits,
otherwise short.
If I *really* need to conserve memory, I make an array of raws bytes
and do bit-shifting.

There's nothing wrong with the likes of uint_atleast_8, it's just that
they're not portable C89. I've heard there's a fairly efficient fully-
portable C89 stdint.h header file going around, so maybe that would be
useful.


When writing code for small embedded systems, you are often interested in getting the code to do exactly what you ask - no more, and no less. You care at a level of detail unfamiliar to those used to programming on big systems - thinks like exact type sizes are important. For bigger systems, the tradeoffs for development are different - you don't have to worry so much about the minor details, and can afford to be sloppy about implementation efficiency in the name of developer efficiency (for example, you might use higher-level interpreted languages). For small systems, you are looking at something with similar levels of control as for assembly programming, but faster development. Thus you should be aware of things like type sizes, library implementations, and the strengths and weaknesses of your target cpu. Development for larger embedded systems falls somewhere in between these two.


You are clearly new to
embedded development, at least on small micros (judging from your
original post in particular) - those of us who have been developing on a
wide range of cpus for years understand the benefits of size-specific
types. That's why <stdint.h> was introduced, that's why number 1 hit on
lists of shortcomings of C is its inconsistent type sizes, and that's
why embedded programmers always like to know the exact size of the int
types on their target. Sure, it's possible to get away without it -
just as its possible to do embedded programming without C - but why
*not* use size specific types to your advantage?


Again I don't see much use for them. If you want efficiency, go with
int. If you wanna save memory, go with char if possible, otherwise
short. If you've got big numbers, go with long.


Certainly many of the situations where size specifics are important are
in hardware dependant and non-portable - and thus the only issue is that
the code in question is clear.
The microcontroller I'm using currently has 6-Bit ports but 8-Bit
registers and memory chunks... still no problem though.
You'll find that these are logically 8-bit registers, with only 6 bits
implemented.


Indeed the highest two bits are ignored when outputing to the pins.

Martin

.

Relevant Pages

  • Re: Delay Routine: Fully-portable C89 if possible
    ... If the number can be negative, I use int. ... If I *really* need to conserve memory, I make an array of raws bytes ... why embedded programmers always like to know the exact size of the int ... You'll find that these are logically 8-bit registers, ...
    (comp.arch.embedded)
  • Re: SQL Server 2005 Memory edition
    ... completely obsessed with efficiency and reliability (last week I worked ... which means that I can leave database work I ... fnTableWithOneRowValuesBetween (From as Int, ...
    (microsoft.public.sqlserver)
  • Re: Whats the deal with size_t?
    ... dimensions are unknown at the time of writing. ... So an index type of unsigned int seems perfectly ... If you don't know how big the maximum array is going to be, which you don't for this function - except that it fits in memory - it must be a size_t. ... If you choose to use int for efficiency then it will be converted to size_t, and if your value is within range the conversion will do what you expect. ...
    (comp.lang.c)
  • Re: Function Template Question
    ... Should be 'size_t', not 'int'. ... Efficiency: should return 'T const&' or type dependent on T. ... In effect, just about any other compiler, including MSVC 7.x. ...
    (comp.lang.cpp)
  • Re: Efficiency of the for loop
    ... int i = 10; ... Don't worry about efficiency yet: ... This is code unravelling and can lead to faster code. ... Clearly if you continue down the road of unravelling the loop as in ...
    (comp.lang.c)