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.h> types?

Martin

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

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

On Oct 18, 10:21 am, Martin Wells <war...@eircom.net> 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.

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.

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.

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

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

CBFalconer <cbfalconer@yahoo.com> writes:

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

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.

CBFalconer <cbfalconer@yahoo.com> writes:
> 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.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.

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) kst-u@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"

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:47175D25.B0E10F8C@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.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.
Interpersonal normative statement => philosophically unintelligible.

> because they are hardware
> dependant.
As, usual, you err.
--
wade ward
wade@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

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 er
routines.

--
Thad