C both slow and memory-hungry for embedded systems?

[Martin Wells]

When I want to store a number, I use "unsigned". I go with unsigned
because it's the natural type for the system, and so should be the
fastest.

However, there are 8-Bit microcontrollers out there that do 8-Bit
arithmetic faster than 16-Bit arithmetic, and so on these systems char
is faster than int.

Standarising C in such a way that int is at least 16-Bit, has this
made C both slow and memory-hungry for embedded systems programming?

Martin

 

[Bart van Ingen Schenau]

When I want to store a number, I use "unsigned". I go with unsigned
because it's the natural type for the system, and so should be the
fastest.

However, there are 8-Bit microcontrollers out there that do 8-Bit
arithmetic faster than 16-Bit arithmetic, and so on these systems char
is faster than int.

Standarising C in such a way that int is at least 16-Bit, has this
made C both slow and memory-hungry for embedded systems programming?

Not in my experience.
There are an increasing number of embedded systems that use processors
whose optimal datatype is 16 bits or wider.
And when memory or performance is really at a premium, software
engineers are likely to use whatever works best. This typically means
making assumptions about the target platform.

Martin

Bart v Ingen Schenau

 

[Spiros Bousbouras]

When I want to store a number, I use "unsigned". I go with unsigned
because it's the natural type for the system, and so should be the
fastest.

However, there are 8-Bit microcontrollers out there that do 8-Bit
arithmetic faster than 16-Bit arithmetic, and so on these systems char
is faster than int.

Standarising C in such a way that int is at least 16-Bit, has this
made C both slow and memory-hungry for embedded systems programming?

What's stopping you from using (usnigned) char on such systems ?

 

[Thad Smith]

What's stopping you from using (usnigned) char on such systems ?

Unsigned char is indeed a common data type for embedded programming on
small processors.

 

[Jack Klein]

When I want to store a number, I use "unsigned". I go with unsigned
because it's the natural type for the system, and so should be the
fastest.

I seriously doubt that. I don't know of any current, or even 20 year
old embedded architecture where unsigned int is any more natural, or
any faster, than signed int.

However, there are 8-Bit microcontrollers out there that do 8-Bit
arithmetic faster than 16-Bit arithmetic, and so on these systems char
is faster than int.

Standarising C in such a way that int is at least 16-Bit, has this
made C both slow and memory-hungry for embedded systems programming?

Martin

In the first place, comp.arch.embedded would be a better place to
discuss this.

In the second place, and this is one of the reasons why comp.lang.c is
not a good place to discuss this, is that a whole lot of C compilers
for embedded architectures are not really conforming C
implementations. This is true for many of the 16-bit processors, not
just the 8-bit ones.

Many such implementations for 8-bitters especially offer the option to
do arithmetic and logical instructions on signed and unsigned 8-bit
values without extending them to int, jut for example.

--
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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Martin Wells]

Spiros:

What's stopping you from using (unsigned) char on such systems ?

I write fully-portably in C89, paying no attention to the particulars
of the platform. If I was to start using char instead of int, I'd
introduce inefficiency on systems whose optimal int type is >= 16
bits.

I think a fair few embedded programmers are starting to use things
like int_fastest_at_least_8 which are defined in C99.

To be a fully-portable programmer both for PC's and for embedded
systems, should we start using these <stdint.h> types?

Martin

 

[Richard Heathfield]

Martin Wells said:

I think a fair few embedded programmers are starting to use things
like int_fastest_at_least_8 which are defined in C99.

To be a fully-portable programmer both for PC's and for embedded
systems, should we start using these <stdint.h> types?

Given the limited availability of conforming C99 implementations, a *fully*
portable program cannot assume the existence of <stdint.h> or the C99
types defined therein. So, at the very least, you should be prepared to
supply your own definitions of those types if you can (portably) determine
that they are not provided by the implementation.

Personally, I don't bother - I find the types in C90 to be perfectly
adequate to my needs - but it's something to consider if your view isn't
quite as... um... radical as mine.

 

[Spiros Bousbouras]

Spiros:



I write fully-portably in C89, paying no attention to the particulars
of the platform. If I was to start using char instead of int, I'd
introduce inefficiency on systems whose optimal int type is >= 16
bits.

Not necessarily. It is entirely possible that a compiler will
represent internally a char using whichever integer type is the
fastest in the platform.

I think a fair few embedded programmers are starting to use things
like int_fastest_at_least_8 which are defined in C99.

To be a fully-portable programmer both for PC's and for embedded
systems, should we start using these <stdint.h> types?

If you want to be fully portable *and* the fastest possible *and* pay
no attention to the particulars of the platform then I guess you
would have to use int_fast8_t. If on the other hand you are willing
to pay just a bit of attention to the particulars of the platform
then you could do something like
typedef char my_int_fast_8_t
and replace char in the line above by whatever type is the fastest
in each platform.

 

[James Kuyper Jr.]

Spiros:



I write fully-portably in C89, paying no attention to the particulars
of the platform. If I was to start using char instead of int, I'd
introduce inefficiency on systems whose optimal int type is >= 16
bits.

I think a fair few embedded programmers are starting to use things
like int_fastest_at_least_8 which are defined in C99.

Using int_fast8_t isn't sufficient; you also have to put the compiler
into a mode which is nonconforming either because it disables automatic
conversion to 'int' in the many contexts where that conversion is
required, or because 'int' is an 8 bit type.

The other problem, of course, is the number of C standard library
routines which take 'int' arguments and return 'int' values. However,
there's an easy workaround for that: create alternative functions that
take 8-bit arguments, where appropriate.

 

[CBFalconer]

.... snip ...

I think a fair few embedded programmers are starting to use things
like int_fastest_at_least_8 which are defined in C99.

To be a fully-portable programmer both for PC's and for embedded
systems, should we start using these <stdint.h> types?

No. They (and we) should avoid them. They are not portable,
because they are not universally available (as are byte, int, long)
and are also a C99 construct. Note that even a C99 system will not
necessarily make those types available, because they are hardware
dependant.

 

[Ben Pfaff]

No. They (and we) should avoid them. They are not portable,
because they are not universally available (as are byte, int, long)
and are also a C99 construct. Note that even a C99 system will not
necessarily make those types available, because they are hardware
dependant.

You must be reading a different C99 from me, because my copy says
this in 7.18.1:

3 The following types are required:
int_least8_t uint_least8_t
int_least16_t uint_least16_t
int_least32_t uint_least32_t
int_least64_t uint_least64_t
All other types of this form are optional.

...

3 The following types are required:
int_fast8_t uint_fast8_t
int_fast16_t uint_fast16_t
int_fast32_t uint_fast32_t
int_fast64_t uint_fast64_t

(It's the exact-width types that are optional.)

 

[Keith Thompson]

Martin Wells wrote:
... snip ...

No. They (and we) should avoid them. They are not portable,
because they are not universally available (as are byte, int, long)
and are also a C99 construct. Note that even a C99 system will not
necessarily make those types available, because they are hardware
dependant.

As Ben Pfaff points out, the 8-, 16-, 32-, and 64-bit "least" and
"fast" types are mandatory; only the exact-width types are optional.
And even though they weren't standardized until C99, they're not hard
to define in C90 (except perhaps for the 64-bit types). See for
example Doug Gywn's "q8" package (though I suppose the "fast" types
can't reliably be defined automatically).

 

[CBFalconer]

You must be reading a different C99 from me, because my copy says
this in 7.18.1:

3 The following types are required:
int_least8_t uint_least8_t
int_least16_t uint_least16_t
int_least32_t uint_least32_t
int_least64_t uint_least64_t
All other types of this form are optional.

...

3 The following types are required:
int_fast8_t uint_fast8_t
int_fast16_t uint_fast16_t
int_fast32_t uint_fast32_t
int_fast64_t uint_fast64_t

(It's the exact-width types that are optional.)

s/those types/all those types/

 

[Wade Ward]

No. They (and we) should avoid them. They are not portable,
because they are not universally available (as are byte, int, long)
and are also a C99 construct. Note that even a C99 system will not
necessarily make those types available, because they are hardware
dependant.

Interpersonal normative statement => philosophically unintelligible.

because they are hardware
dependant.

As, usual, you err.
--
wade ward
(e-mail address removed)
"Der Katze tritt die Treppe hoch; Der Kater tritt sie krumm.%
% De Teufel geit um; er bringt de menschen allet dumm."
schau, schau

 

[Thad Smith]

Martin Wells wrote:

Using int_fast8_t isn't sufficient; you also have to put the compiler
into a mode which is nonconforming either because it disables automatic
conversion to 'int' in the many contexts where that conversion is
required, or because 'int' is an 8 bit type.

A good compiler for 8-bit targets can optimize many expressions with
8-bit operands and still be conforming. Addition, multiplication, and,
or, exclusive or, and left shift operations can be combined with 8-bit
operands, ignoring upper bytes. A single subtraction, division, or
right shift on 8-bit operands can also be done. The upper byte DOES
need to be calculated when these operation are combined, such as a*b/c.

The other problem, of course, is the number of C standard library
routines which take 'int' arguments and return 'int' values.

True. Optimized library routines can test for values which fit within a
byte and use simper code. This is often done for the arithmetic helper
routines.