Integer types in embedded systems

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Let's say we had a simple function for returning the amount of days in
a month:

unsigned DaysInMonth(uns igned const month)
{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

Notice the integer type I've used, i.e. "unsigned int" rather than
"unsigned char" or "unsigned short".

Many of the microcontroller s (i.e. a small chip that has a CPU and
RAM, basically it's a tiny little computer) in use nowadays do
arithmetic on 8-Bit numbers.

An example of a prevalent microcontroller nowadays would be the
PIC16F684. It's only got about 35 different CPU instructions. All of
the arithmetic instructions work on 8-Bit registers.

In my little code snippet above, the biggest number used is 31, which
of course would fit inside an "unsigned char".

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

The only problem with int, however, is that it must be at least 16-
Bit.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with
this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to
re-write the code for an embedded system, we'd probably have:

char unsigned DaysInMonth(cha r unsigned const month)
{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

I'd like now to bring up the topic of portable programming. In my own
code, I've begun to use types such as:

uint_fast8_t

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

Of course, even if our target platform doesn't supply an stdint.h, we
can always have a default version of it, e.g.:

typedef char unsigned uint_fast8_t;
or:
typedef unsigned uint_fast8_t;

[pete]

Re: Integer types in embedded systems

Tomás Ó hÉilidhe wrote:

PIC16F684. It's only got about 35 different CPU instructions.

I program that in assembly,
*because* it's only got about 35 different CPU instructions.
I've never felt any desire to use C on that chip.

do {
/*
** This whole loop is a single opcode on a PIC16F684
*/
} while (--n != 0);

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

--
pete

[Jack Klein]

Re: Integer types in embedded systems

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe
<toe@lavabit.co mwrote in comp.lang.c:

>
Let's say we had a simple function for returning the amount of days in
a month:
>
unsigned DaysInMonth(uns igned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;
>
case 1: return 28;
>
default: return 31;
}
}
>
Notice the integer type I've used, i.e. "unsigned int" rather than
"unsigned char" or "unsigned short".
>
Many of the microcontroller s (i.e. a small chip that has a CPU and
RAM, basically it's a tiny little computer) in use nowadays do
arithmetic on 8-Bit numbers.
>
An example of a prevalent microcontroller nowadays would be the
PIC16F684. It's only got about 35 different CPU instructions. All of
the arithmetic instructions work on 8-Bit registers.

We won't get into many people's opinions about PICs, it would be
off-topic here.

In my little code snippet above, the biggest number used is 31, which
of course would fit inside an "unsigned char".

Which would, in C, immediately be promoted to either signed or
unsigned int. So you'd gain nothing. Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. Once you do that, it's not really C anymore.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embed ded. On the other
hand, you make these opinionated statements like "a lot of people
expect". Who are these people? How do you know what they expect?

I think that no experienced embedded programmer would expect that. I
think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems. And on
anything outside the embedded arena these days, they can get away with
expecting that.

Most C programmers these days are woefully ignorant, and they expect
many things, such as...

--a char is signed and has a range of [-128,127]

--an int is four bytes

--a pointer is four bytes

--a float is four bytes

--there is a stack

....an I could go on and on.

The only problem with int, however, is that it must be at least 16-
Bit.

Actually, that's not a problem. That's a guarantee and a good one.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

Your assumption is that they think that. Have you asked "they" what
they think, or are you just assuming?

re-write the code for an embedded system, we'd probably have:

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization. Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below. But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

char unsigned DaysInMonth(cha r unsigned const month)
{

Really, lose the const, it just makes you look silly.

As does your insistence on putting the base type before the unsigned
qualifier. At least as important as portability, and more important
in many cases in the real world, is maintainability . While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance. If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

{
case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

case 3:
case 5:
case 10: return 30;
>
case 1: return 28;
>
default: return 31;
}
}
>
I'd like now to bring up the topic of portable programming. In my own
code, I've begun to use types such as:
>
uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions. If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

Actually, I haven't had a use for the fast types yet. I have used the
(u)int_leastx_t types, for portability between DSPs where CHAR_BIT is
larger than 8, and "ordinary" platforms where CHAR_BIT is exactly 8.
In fact I've successfully written code that had to pack and unpack
binary communications packets using unit_least8_t that compiles
unchanged on CHAR_BIT 8 and CHAR_BIT 16 implementations .

Of course, even if our target platform doesn't supply an stdint.h, we
can always have a default version of it, e.g.:
>
typedef char unsigned uint_fast8_t;
or:
typedef unsigned uint_fast8_t;

There have been plenty of examples on the web of stdint.h files for
compilers that do not supply them. At least one was written by a
member of the C standard committee. I've written quite a few myself
for older embedded compilers. And I've written one for Visual C++ 6,
which I often use for testing algorithms.

The real issue here is premature micro optimization. The majority of
the posters and readers in this group, as opposed to
comp.arch.embed ded, are not embedded system programmers. They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor. Your advice is not relevant to them.

In my opinion, you are worrying about efficiency under the guise of
portability. If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.

Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do. Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this. But only
if this is the code causing one of the bottle necks.

For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Thad Smith]

Re: Integer types in embedded systems

Jack Klein wrote:

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe
<toe@lavabit.co mwrote in comp.lang.c:
>

>Let's say we had a simple function for returning the amount of days in
>a month:
>>
>unsigned DaysInMonth(uns igned const month)
>{
> switch (month)
> {
> case 8:
> case 3:
> case 5:
> case 10: return 30;
>>
> case 1: return 28;
>>
> default: return 31;
> }
>}
>>

....

>In my little code snippet above, the biggest number used is 31, which
>of course would fit inside an "unsigned char".

>
Which would, in C, immediately be promoted to either signed or
unsigned int. So you'd gain nothing. Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. Once you do that, it's not really C anymore.

For parameters and return values if they are declared as 8-bit types, you
will save instructions on an 8-bit processor. Promotion doesn't happen on
those.

> switch (month)

>
But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

Yes, month is promoted to an int, but my compiler is clever -- it knows
that the operand is 8 bits and doesn't needlessly generate a leading zero
byte before performing the switch evaluation.

Good compilers do that kind of optimization. a = b + 5; can be done with
single byte operations for single byte operands. So can many other
expressions.

>

> {
> case 8:

>
And the type of the 8, and the rest of the constants in your cases
already have type int.

So what? These are constants. The clever compiler knows that the 8-bit
unsigned value can be contained in a single byte.

>I'd like now to bring up the topic of portable programming. In my own
>code, I've begun to use types such as:
>>
> uint_fast8_t

>
Does that mean that you don't use 'char', 'int', 'long', etc.?
>

>Basically I'm saying "I want the fastest integer type whose range is
>at least up to 255".

>
Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions. If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

I disagree. I am familiar with my compiler. It does take advantage of
smaller operand size. Any yes, it is conforming in regards to integer
promotion.

>In this way, I can write code that will peform optimally on both
>embedded systems and PC's.

>
Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

Not the one I use.

--
Thad

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Re: Integer types in embedded systems

On May 3, 4:53 am, Jack Klein <jackkl...@spam cop.netwrote:

unsigned DaysInMonth(uns igned const month)

>
First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "profession al"
programmer.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.

Which would, in C, immediately be promoted to either signed or
unsigned int.  So you'd gain nothing.  Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values.  Once you do that, it's not really C anymore.

Don't forget about the "as if" rule. I compiler doesn't have to do
something, it just has to act as if it does seomthing.

If you do:

char unsigned a = 5, b = 6;

char unsigned c = a + b;

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

>
You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embed ded.  On the other
hand, you make these opinionated statements like "a lot of people
expect".  Who are these people?  How do you know what they expect?

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

I think that no experienced embedded programmer would expect that.

I realise that, and this is why they're distinct from more generic
programmers. (By generic programmers, I mean someone who writes an
algorithm and doesn't know what their platform is.)

 

I think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems.

Obviously, since I wrote the original post in this thread, I realise
that "int" is slow on an 8-Bit micrcontroller.

I'm talking about more generic programming, e.g. just being a C
programmer. A good C programmer should be able to write portable code
that will perform well on everything. Since the portable programmer
will assume that "int" is the best type for the job, this will have
negative consequences when the code is brought to an embedded system.

The solution: Use things like uint_fast8_t instead of int.

Most C programmers these days are woefully ignorant, and they expect
many things, such as...
>
--a char is signed and has a range of [-128,127]
>
--an int is four bytes
>
--a pointer is four bytes
>
--a float is four bytes
>
--there is a stack
>
...an I could go on and on.

Yes, the majority of programmers are bad programmers. Kind of like ice
skaters.

Any half-decent C programmer will know what freedom and restrictions
the Standard provides.

The only problem with int, however, is that it must be at least 16-
Bit.

>
Actually, that's not a problem.  That's a guarantee and a good one.

Are you paying attention? It's bad for 8-Bit microcontroller s. It's
fine for 16-Bit microcontroller s and upwards.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

>
Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

I'm now talking about that specific range, I'm talking about storing
"just a number", even like small numbers that don't go above 200.

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

>
Your assumption is that they think that.  Have you asked "they" what
they think, or are you just assuming?

I've had many discussions about portability on various different
newsgroups. Do a google search of comp.lang.c for my name and
"portable portability". I never shut up about it.

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization.  Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below.  But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

You'd have to have the intelligence of a squid not to realise that the
micrcontroller can work with 8-Bit numbers with a single instruction,
and that it needs mutliple instructions (and multiple bytes in memory)
to work with 16-Bit numbers.

char unsigned DaysInMonth(cha r unsigned const month)
{

>
Really, lose the const, it just makes you look silly.

I'm beginning to think that I should probably be glad if you think I'm
silly.

That const serves a purpose; I put it there for a reason.

As does your insistence on putting the base type before the unsigned
qualifier.  At least as important as portability, and more important
in many cases in the real world, is maintainability .  While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

Oh the woes of being a good programmer.

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance.  If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

I'm not a professional programmer. If I was, I'd make sure I'm working
with good, competant programmers. If my colleague can't get his head
around "short unsigned" then we'd be better off not working together.
I'm not prejudiced against stupid people, I just don't like working
with them.

    switch (month)

>
But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

Again, the assembler produced will work with a single 8-Bit register.

    {
    case 8:

>
And the type of the 8, and the rest of the constants in your cases
already have type int.

Single 8-Bit register again.

In my own
code, I've begun to use types such as:

>

    uint_fast8_t

>
Does that mean that you don't use 'char', 'int', 'long', etc.?

Not entirely.

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

>
Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions.

Against your argument is invalid. The compiler knows when the
promotion will have no effect.

> If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

You'll find that these smart compilers conform to the standard in
terms of integer promotion.

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

>
Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

Again, a single 8-Bit register.

The real issue here is premature micro optimization.  The majority of
the posters and readers in this group, as opposed to
comp.arch.embed ded, are not embedded system programmers.

White coats not mixing with blue blazers?

A programmer is a programmer. I programmed in C on PC's for years
before I started doing embedded systems programming... and guess what
there was no difference.

If you have a fully-portable algorithm in compliance to the C89
standard, then it should run on everything from your microwave's
interface to your PC. The only problem with algorithm is that it might
be inefficient on the microwave if it's using "int" as its everyday
integer type. If the algorithm instead used uint_fast8_t, then the
code would be fast on every kind of system.

> They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor.  Your advice is not relevant to them.

Where are you getting this distinction between a C programmer and an
embedded systems programmer. You can program an embedded system in C,
and I do it.

In my opinion, you are worrying about efficiency under the guise of
portability.  If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.
>
Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do.

Again, I've not interest to accomodate lact-lustre programmers. If
they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.

> Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

And would you believe that I think my own code is simple and clear.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this.  But only
if this is the code causing one of the bottle necks.
>
For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

What if the code is run in an eternal loop on a microcontroller that's
running at 4 MHz. If the microcontroller is also flashing an LED
display, then the decrease in speed will result in display flicker.
And I *have* seen this in my very own college project this year.

[Jack Klein]

Re: Integer types in embedded systems

On Sat, 3 May 2008 04:53:12 -0700 (PDT), Tomás Ó hÉilidhe
<toe@lavabit.co mwrote in comp.lang.c:

On May 3, 4:53 am, Jack Klein <jackkl...@spam cop.netwrote:
>

unsigned DaysInMonth(uns igned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

>
>
I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "profession al"
programmer.

Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best. I'll make a note of that.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

>
Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.

In that case, why are you bothering to waste your time bestowing your
wisdom on other, lesser, programmers? Our opinion is meaningless to
you.

Which would, in C, immediately be promoted to either signed or
unsigned int.  So you'd gain nothing.  Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values.  Once you do that, it's not really C anymore.

>
>
Don't forget about the "as if" rule. I compiler doesn't have to do
something, it just has to act as if it does seomthing.
>
If you do:
>
char unsigned a = 5, b = 6;
>
char unsigned c = a + b;
>
Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

Sadly, I have to disagree with you there. Take ARM for example, in
the majority of the world's cell phones. I guarantee you it will use
a 32-bit register. Regardless of any compiler, past, present, or
future, regardless of options used when invoking the compiler.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embed ded.  On the other
hand, you make these opinionated statements like "a lot of people
expect".  Who are these people?  How do you know what they expect?

>
>
Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

That is one of the many assumptions you will need to rid yourself of
if you expect to become an expert embedded programmer.

I think that no experienced embedded programmer would expect that.

>
>
I realise that, and this is why they're distinct from more generic
programmers. (By generic programmers, I mean someone who writes an
algorithm and doesn't know what their platform is.)
>
 

I think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems.

>
>
Obviously, since I wrote the original post in this thread, I realise
that "int" is slow on an 8-Bit micrcontroller.
>
I'm talking about more generic programming, e.g. just being a C
programmer. A good C programmer should be able to write portable code
that will perform well on everything. Since the portable programmer
will assume that "int" is the best type for the job, this will have
negative consequences when the code is brought to an embedded system.

Actually, I couldn't disagree more. Most professional programmers are
concerned, as they should be, with producing error free (or as error
free as possible) programs that meet their requirements. Suggesting
that programmers for desk top environments such as *nix or Windows
should worry about their code being ported to an eight-bit micro is
inefficient and not cost effective.

The solution: Use things like uint_fast8_t instead of int.
>
>

Most C programmers these days are woefully ignorant, and they expect
many things, such as...

--a char is signed and has a range of [-128,127]

--an int is four bytes

--a pointer is four bytes

--a float is four bytes

--there is a stack

...an I could go on and on.

>
>
Yes, the majority of programmers are bad programmers. Kind of like ice
skaters.
>
Any half-decent C programmer will know what freedom and restrictions
the Standard provides.
>
>

The only problem with int, however, is that it must be at least 16-
Bit.

Actually, that's not a problem.  That's a guarantee and a good one.

>
>
Are you paying attention? It's bad for 8-Bit microcontroller s. It's
fine for 16-Bit microcontroller s and upwards.

My attention skills are quite adequate, thank you. You said, and
quite specifically, "The only problem with int, however, is that is
must be at least 16-Bit(sic)." In fact, it's still just a few lines
above where I am typing this, quoted several times from your original
post.

And that is absolutely, positively, not a problem, but an extremely
useful guarantee provided by the C language.

The problem you are expressing is that you think that an int is not
the most efficient type for you to use in one particular code snippet,
on one particular hardware architecture, with one particular compiler.

That is a problem with your expectations or wants, not a problem with
the C language requirement for the type int.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

>
>
I'm now talking about that specific range, I'm talking about storing
"just a number", even like small numbers that don't go above 200.
>
>

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

Your assumption is that they think that.  Have you asked "they" what
they think, or are you just assuming?

>
>
I've had many discussions about portability on various different
newsgroups. Do a google search of comp.lang.c for my name and
"portable portability". I never shut up about it.
>
>

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization.  Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below.  But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

>
>
You'd have to have the intelligence of a squid not to realise that the

Oops, now your getting insulting. I don't recall casting any
aspersions on your intelligence.

micrcontroller can work with 8-Bit numbers with a single instruction,
and that it needs mutliple instructions (and multiple bytes in memory)
to work with 16-Bit numbers.

I was making a living designing, building, and selling embedded
systems with various 8-bit microprocessors and microcontroller s for at
least ten years before Microchip released the first PIC. There is
little you can teach me about 8-bit architectures.

char unsigned DaysInMonth(cha r unsigned const month)
{

Really, lose the const, it just makes you look silly.

>
>
I'm beginning to think that I should probably be glad if you think I'm
silly.
>
That const serves a purpose; I put it there for a reason.
>
>

As does your insistence on putting the base type before the unsigned
qualifier.  At least as important as portability, and more important
in many cases in the real world, is maintainability .  While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

>
>
Oh the woes of being a good programmer.

Oh, woe is you! Or should that be "are you"? Now you have ventured
into a completely subjective area, your definition of "good".

Indulge me, tell me how your insistence on writing "char unsigned
const" "good", as opposed to "const unsigned char", which is what the
vast majority of C programmers would write.

What makes that "good", and, by definition, the way (almost) everybody
else would write it not "good", or at least not as "good" as your way?

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance.  If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

>
>
I'm not a professional programmer. If I was, I'd make sure I'm working
with good, competant programmers. If my colleague can't get his head
around "short unsigned" then we'd be better off not working together.
I'm not prejudiced against stupid people, I just don't like working
with them.

Oh, now anyone who writes "const unsigned char" is "stupid", unless
they cheerfully adapt to your idiosyncrasies?

You can actually make a point about putting the const keyword after
the type. The C grammar basically wants it there, and only allows it
at the beginning of a declaration as a special case.

It would be quite a bit harder to provide a justification for "char
unsigned" or "long unsigned", since an unsigned char is neither an
unsigned nor a char, it is a unique type on it's own. The unsigned
keyword is not a cv qualifier, it is an integral part of the type
name.

    switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

>
>
Again, the assembler produced will work with a single 8-Bit register.

The assembler produced by one particular compiler.

    {
    case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

>
>
Single 8-Bit register again.
>
>

In my own
code, I've begun to use types such as:

    uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

>
>
Not entirely.

Haven't yet attained perfection.

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions.

>
>
Against your argument is invalid. The compiler knows when the
promotion will have no effect.
>
>

 If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

>
>
You'll find that these smart compilers conform to the standard in
terms of integer promotion.
>
>

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

>
>
Again, a single 8-Bit register.
>
>

The real issue here is premature micro optimization.  The majority of
the posters and readers in this group, as opposed to
comp.arch.embed ded, are not embedded system programmers.

>
>
White coats not mixing with blue blazers?
>
A programmer is a programmer. I programmed in C on PC's for years
before I started doing embedded systems programming... and guess what
there was no difference.

Actually, you are quite wrong about that. Does your PIC compiler
provide a double that meets the C specifications?

If you have a fully-portable algorithm in compliance to the C89
standard, then it should run on everything from your microwave's
interface to your PC. The only problem with algorithm is that it might
be inefficient on the microwave if it's using "int" as its everyday
integer type. If the algorithm instead used uint_fast8_t, then the
code would be fast on every kind of system.
>
>

 They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor.  Your advice is not relevant to them.

>
>
Where are you getting this distinction between a C programmer and an
embedded systems programmer. You can program an embedded system in C,
and I do it.

Because embedded programmers in C might need to worry about choosing
the best data type on some micros and DSPs, and C programmers working
in 32-bit or larger hosted environments do not.

In my opinion, you are worrying about efficiency under the guise of
portability.  If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.

Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do.

>
>
Again, I've not interest to accomodate lact-lustre programmers. If

"Accomodate(sic )". So everybody else who has been writing C for forty
years should accommodate you. Including Brian Kernighan and Dennis
Ritchie, including the authors of the various versions of ANSI and ISO
C standards. Obviously lack-luster programmers, the lot of them.

they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.

You're absolutely right, I'm sure that none of people I alluded to
above could understand your clever algorithms.

 Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

>
>
And would you believe that I think my own code is simple and clear.

But you persist in posting your code to a public forum read almost
exclusively by C programmers who conclusively demonstrate that they
don't think your way of writing code is appropriate by not writing
code the way that you do.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this.  But only
if this is the code causing one of the bottle necks.

For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

>
What if the code is run in an eternal loop on a microcontroller that's
running at 4 MHz. If the microcontroller is also flashing an LED
display, then the decrease in speed will result in display flicker.
And I *have* seen this in my very own college project this year.

I will repeat, since you seem to have missed it, this paragraph of my
response:

"And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this.  But only
if this is the code causing one of the bottle necks."

So you have correctly discovered that there were performance issues in
your program, and found optimizations that improved them. Excellent.

As I've said to you in at least one previous post, it is important for
embedded programmers working on "unusual" architectures to be aware
not only of the features and limitations of the underlying hardware,
but also of the details of their compiler.

Where you take the great and unjustified, in my opinion, leap, is in
deciding that you have uncovered a great truth and every C programmer
working on any kind of code anywhere should analyze every integer
object used in their code and use the stdint.h code for the fastest
possible type.

Quite frankly, for many programmers, that would be an absolutely
unjustified use of time and resources. They would expend extra
effort, and therefore produce working, tested code more slowly, on an
activity that would not improve the correctness or efficiency of their
code by even the tiniest amount.

Perhaps you should conduct a survey, to determine the percentage of C
programmers who are currently coding for Windows or Linux or OSX and
are planning a future port to PIC or 8051 or AVR.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Anand Hariharan]

Re: Integer types in embedded systems

On Sat, 03 May 2008 04:53:12 -0700, Tomás Ó hÉilidhe wrote:

On May 3, 4:53 am, Jack Klein <jackkl...@spam cop.netwrote:
>

unsigned DaysInMonth(uns igned const month)

>>

(...)

>Second, applying a const qualifier to a value parameter might pass a
>code inspection, but is considered by many to be just plain prissy.

>
>
Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.
>

(...)

>

char unsigned DaysInMonth(cha r unsigned const month)
{

>>
>Really, lose the const, it just makes you look silly.

>
>
I'm beginning to think that I should probably be glad if you think I'm
silly.
>
That const serves a purpose; I put it there for a reason.
>
>

Am guessing your reason is to tell yourself as the function's
/implementer/ that you are not going to modify the function
argument. However, most functions are written for the caller.

As a programmer who is going to call your function, if I were to
look at your function declaration, I see that it has a value
parameter (i.e., a copy of my argument is passed to your function).
So, the const there is indeed redundant to the caller.


--
ROT-13 email address to reply

[Ian Collins]

Re: Integer types in embedded systems

Tomás Ó hÉilidhe wrote:

On May 3, 4:53 am, Jack Klein <jackkl...@spam cop.netwrote:

>Get rid of "char unsigned const" and write "const unsigned char" like
>all the other C programmers do.

>
>
Again, I've not interest to accomodate lact-lustre programmers. If
they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.
>

Are we witnessing the return of Frederick Gotham?

--
Ian Collins.

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Re: Integer types in embedded systems

On May 4, 7:05 am, Jack Klein <jackkl...@spam cop.netwrote:

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "profession al"
programmer.

>
Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best.  I'll make a note of that.

You'll notice I said "aspire to". There are many C programmers in the
world. Many of them are not very good, and a very small proportion of
them are excellent. You spoke of "code inspection" which is why I
assumed you were talking about professional programmers. The vast
majority of professional programmers are not very good, which is why I
expressed the view that I'd aspire to be better than a professional
programmer.

How you took arrogance from my statement, I don't know.

In that case, why are you bothering to waste your time bestowing your
wisdom on other, lesser, programmers?  Our opinion is meaningless to
you.

Again, I think your arrogance sensor is dodgy.

If you do:

>

    char unsigned a = 5, b = 6;

>

    char unsigned c = a + b;

>

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

>
Sadly, I have to disagree with you there.  Take ARM for example, in
the majority of the world's cell phones.  I guarantee you it will use
a 32-bit register.  Regardless of any compiler, past, present, or
future, regardless of options used when invoking the compiler.

That's unfortunate. The only embedded compiler I've worked with is the
PIC C compiler, and thankfully it will only use an 8-Bit register for
the code above.

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

>
That is one of the many assumptions you will need to rid yourself of
if you expect to become an expert embedded programmer.

The idea of "int" in the C programming language was that it would be
the main integer type to use. I myself take this to mean that it will
be the fastest type. (I can't think of any more suitable meaning of
"natural type" as worded in the Standard).

Actually, I couldn't disagree more.  Most professional programmers are
concerned, as they should be, with producing error free (or as error
free as possible) programs that meet their requirements.  Suggesting
that programmers for desk top environments such as *nix or Windows
should worry about their code being ported to an eight-bit micro is
inefficient and not cost effective.

I'm trying to devise a strategy that will take away the need to worry.

When writing a simple algorithm in C, you can sit there with a smile
on your face knowing that it will run on Solaris, Redhat, Windows XP,
Playstation 3, XBox 360. Here's an example algorithm for instance:

void SetToFive(int *p,int const *const pend)
{
do *p++ = 5;
while (pend != p);
}

You can also be happy that it will run on an embedded system... but
then it might be too slow for the embedded system because of the use
of int instead of char.

My attention skills are quite adequate, thank you.  You said, and
quite specifically, "The only problem with int, however, is that is
must be at least 16-Bit(sic)."  In fact, it's still just a few lines
above where I am typing this, quoted several times from your original
post.
>
And that is absolutely, positively, not a problem, but an extremely
useful guarantee provided by the C language.

To accomodate 8-Bit systems, it would have been better to decree that
the "natural type" only be at least 8-Bit, instead of 16-Bit as the
Standard decrees. (Of course this would require a reorganisation of
the types).

The problem you are expressing is that you think that an int is not
the most efficient type for you to use in one particular code snippet,
on one particular hardware architecture, with one particular compiler.

Only the hardware architecture. In my most recent embedded systems
project, I didn't need int at all because I had no need for a number
greater than 255, so this thing of not opting for int isn't a "once
off". The compiler hasn't got much power in deciding int type lengths
if it has to work with an 8-Bit microcontroller .

That is a problem with your expectations or wants, not a problem with
the C language requirement for the type int.

I disagree. Int is the "natural type", but the problem is that it
simply cannot be the natural type for an 8-Bit system by virtue of the
fact that int must be at least 16-Bit. That's the problem.

I was making a living designing, building, and selling embedded
systems with various 8-bit microprocessors and microcontroller s for at
least ten years before Microchip released the first PIC.  There is
little you can teach me about 8-bit architectures.

Then I would expect you to realise, even far better than myself, the
detrimental effect of using int in embedded systems code.

Oh the woes of being a good programmer.

>
Oh, woe is you!  Or should that be "are you"?  Now you have ventured
into a completely subjective area, your definition of "good".
>
Indulge me, tell me how your insistence on writing "char unsigned
const" "good", as opposed to "const unsigned char", which is what the
vast majority of C programmers would write.

It's just personal preference. I find it more intuitive to see the
most basic type information first.

What makes that "good", and, by definition, the way (almost) everybody
else would write it not "good", or at least not as "good" as your way?

I was referring to my const correctness, not my word ordering.

Oh, now anyone who writes "const unsigned char" is "stupid", unless
they cheerfully adapt to your idiosyncrasies?

No at all. I've seen more than one excellent programmer write like
that. Another thing I do is write "++i" instead of "i++", but of
course a lot of excellent programmers write "i++" (this of course only
applies to a context where the resultant expression is discarded).

You can actually make a point about putting the const keyword after
the type.  The C grammar basically wants it there, and only allows it
at the beginning of a declaration as a special case.
>
It would be quite a bit harder to provide a justification for "char
unsigned" or "long unsigned", since an unsigned char is neither an
unsigned nor a char, it is a

It mirrors C's syntax for printf, e.g. "%lu".

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Re: Integer types in embedded systems

On May 4, 8:09 am, Ian Collins <ian-n...@hotmail.co mwrote:

Are we witnessing the return of Frederick Gotham?

I am not sock puppeting. The most recent post I can find of Frederick
Gotham dates back to Dec 4th 2006, and quite ironically the first
thing Google found when I did a search was a thread in which he was
accused of sock puppeting; less ironically, you yourself made quite a
contribution to that thread.

I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

[CBFalconer]

Re: Integer types in embedded systems

Tomás Ó hÉilidhe wrote:

>

.... snip ...

>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is
automatically used for email replies. My from address is also
real, but does nothing but collect spam.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Eligiusz Narutowicz]

Re: Integer types in embedded systems

CBFalconer <cbfalconer@yah oo.comwrites:

Tomás Ó hÉilidhe wrote:

>>

... snip ...

>>
>I have my real e-mail address attached to my posts and I only post
>under one name (on all kinds of fora across the internet), so I'd
>appreciate if you'd abandon that accusation.

>
That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

automatically used for email replies. My from address is also
real, but does nothing but collect spam.

Why you make it then? How you know which is used to collate emails
addresses?

[CBFalconer]

Re: Integer types in embedded systems

Eligiusz Narutowicz wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

>Tomás Ó hÉilidhe wrote:

>>>

>... snip ...

>>>
>>I have my real e-mail address attached to my posts and I only post
>>under one name (on all kinds of fora across the internet), so I'd
>>appreciate if you'd abandon that accusation.

>>
>That is not a good idea, because of the ease with which the
>spammers can access it. I suggest putting the real address in the
>'Reply-To' header, which is much less accessible, but is

>
Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Eligiusz Narutowicz]

Re: Integer types in embedded systems

CBFalconer <cbfalconer@yah oo.comwrites:

Eligiusz Narutowicz wrote:

>CBFalconer <cbfalconer@yah oo.comwrites:

>>Tomás Ó hÉilidhe wrote:
>>>>
>>... snip ...
>>>>
>>>I have my real e-mail address attached to my posts and I only post
>>>under one name (on all kinds of fora across the internet), so I'd
>>>appreciate if you'd abandon that accusation.
>>>
>>That is not a good idea, because of the ease with which the
>>spammers can access it. I suggest putting the real address in the
>>'Reply-To' header, which is much less accessible, but is

>>
>Do not be so stupid.

>
You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

[rio]

Re: Integer types in embedded systems


"Tomás Ó hÉilidhe" <toe@lavabit.co mha scritto nel messaggio
news:e5f6e159-d944-4a84-87b0-188d64f3df6b@z7 2g2000hsb.googl egroups.com...
On May 4, 7:05 am, Jack Klein <jackkl...@spam cop.netwrote:

>Oh, my, I had no idea that you were the ultimate programmer, better
>than all the rest, better than the best. I'll make a note of that.

each one say about himself to be a programmer imagine to be that one

>Again, I think your arrogance sensor is dodgy.

If you do:

>>

char unsigned a = 5, b = 6;

>>

char unsigned c = a + b;

>>

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

>>
>Sadly, I have to disagree with you there. Take ARM for example, in
>the majority of the world's cell phones. I guarantee you it will use
>a 32-bit register. Regardless of any compiler, past, present, or
>future, regardless of options used when invoking the compiler.

you for gain the speed lose the portability. the future will
be of true portable languages (the part has to need to be fast
will be rewritten in assembly of each cpu of port)

>That's unfortunate. The only embedded compiler I've worked with is the
>PIC C compiler, and thankfully it will only use an 8-Bit register for
>the code above.

i agree that the code has to be portable;
one time i write something for a cpu it will go well for all
something like
uns32 a=5, b=6, c=a+b;

something without any interpretation from one machine to some other
with no Undefinite Beaviour

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

>>
>That is one of the many assumptions you will need to rid yourself of
>if you expect to become an expert embedded programmer.

>The idea of "int" in the C programming language was that it would be
>the main integer type to use. I myself take this to mean that it will
>be the fastest type. (I can't think of any more suitable meaning of
>"natural type" as worded in the Standard).

for me the above is not the right way to go

>Actually, I couldn't disagree more. Most professional programmers are
>concerned, as they should be, with producing error free (or as error
>free as possible) programs that meet their requirements. Suggesting
>that programmers for desk top environments such as *nix or Windows
>should worry about their code being ported to an eight-bit micro is
>inefficient and not cost effective.

>I'm trying to devise a strategy that will take away the need to worry.

>When writing a simple algorithm in C, you can sit there with a smile
>on your face knowing that it will run on Solaris, Redhat, Windows XP,
>Playstation 3, XBox 360. Here's an example algorithm for instance:

>void SetToFive(int *p,int const *const pend)
>{
do *p++ = 5;
while (pend != p);
>}

>You can also be happy that it will run on an embedded system... but
>then it might be too slow for the embedded system because of the use
>of int instead of char.

the problem with the fast cpu that are in production is not that
are slow.
the problem is rewrite each program for each cpu or OS
Buon Giorno