By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,098 Members | 2,007 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,098 IT Pros & Developers. It's quick & easy.

C both slow and memory-hungry for embedded systems?

P: n/a

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

Oct 16 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
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 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

Oct 16 '07 #2

P: n/a
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 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 ?

Oct 16 '07 #3

P: n/a
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 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 ?
Unsigned char is indeed a common data type for embedded programming on
small processors.

--
Thad
Oct 16 '07 #4

P: n/a
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 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
Oct 16 '07 #5

P: n/a
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.htypes?

Martin

Oct 18 '07 #6

P: n/a
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.htypes?
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
Oct 18 '07 #7

P: n/a
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.htypes?
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.
Oct 18 '07 #8

P: n/a
Martin Wells wrote:
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.
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.
Oct 18 '07 #9

P: n/a
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.htypes?
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

Oct 19 '07 #10

P: n/a
CBFalconer <cb********@yahoo.comwrites:
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.htypes?

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.)
--
Go not to Usenet for counsel, for they will say both no and yes.
Oct 19 '07 #11

P: n/a
CBFalconer <cb********@yahoo.comwrites:
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.htypes?

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 19 '07 #12

P: n/a


"CBFalconer" <cb********@yahoo.comwrote in message
news:47***************@yahoo.com...
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.htypes?

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
wa**@zaxfuuq.net
"Der Katze tritt die Treppe hoch; Der Kater tritt sie krumm.%
% De Teufel geit um; er bringt de menschen allet dumm."
schau, schau
Oct 21 '07 #13

P: n/a
James Kuyper Jr. wrote:
Martin Wells wrote:
>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.
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.

--
Thad
Oct 21 '07 #14

P: n/a
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
>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.htypes?

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.)
s/those types/all those types/ :-)

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

Oct 22 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.