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 microcontroller s 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]

On 16 okt, 11:58, Martin Wells <war...@eircom. netwrote:

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 microcontroller s 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]

On Oct 16, 10:58 am, Martin Wells <war...@eircom. netwrote:

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 microcontroller s 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]

Spiros Bousbouras wrote:

On Oct 16, 10:58 am, Martin Wells <war...@eircom. netwrote:

>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 microcontroller s 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 ?

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

--
Thad

[Jack Klein]

On Tue, 16 Oct 2007 02:58:53 -0700, Martin Wells <wa****@eircom. net>
wrote in comp.lang.c:

>
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 microcontroller s 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.embed ded 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.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Martin Wells]

Spiros:

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 (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.htype s?

Martin

[Richard Heathfield]

Martin Wells said:

<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.htype s?

Given the limited availability of conforming C99 implementations , a *fully*
portable program cannot assume the existence of <stdint.hor 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.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Spiros Bousbouras]

On Oct 18, 10:21 am, Martin Wells <war...@eircom. netwrote:

Spiros:

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

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.htype s?

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

Martin Wells wrote:

Spiros:

>>Standarisin g 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 (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.

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]

Martin Wells wrote:

>

.... 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.htype s?

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com