C both slow and memory-hungry for embedded systems?

Discussion in 'C Programming' started by Martin Wells, Oct 16, 2007.

  1. Martin Wells

    Martin Wells Guest

    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
     
    Martin Wells, Oct 16, 2007
    #1
    1. Advertising

  2. On 16 okt, 11:58, Martin Wells <> wrote:
    > 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
     
    Bart van Ingen Schenau, Oct 16, 2007
    #2
    1. Advertising

  3. On Oct 16, 10:58 am, Martin Wells <> wrote:
    > 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 ?
     
    Spiros Bousbouras, Oct 16, 2007
    #3
  4. Martin Wells

    Thad Smith Guest

    Spiros Bousbouras wrote:
    > On Oct 16, 10:58 am, Martin Wells <> wrote:
    >> 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
     
    Thad Smith, Oct 16, 2007
    #4
  5. Martin Wells

    Jack Klein Guest

    On Tue, 16 Oct 2007 02:58:53 -0700, Martin Wells <>
    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
     
    Jack Klein, Oct 16, 2007
    #5
  6. Martin Wells

    Martin Wells Guest

    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, Oct 18, 2007
    #6
  7. 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
     
    Richard Heathfield, Oct 18, 2007
    #7
  8. On Oct 18, 10:21 am, 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.


    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.
     
    Spiros Bousbouras, Oct 18, 2007
    #8
  9. 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.
     
    James Kuyper Jr., Oct 18, 2007
    #9
  10. Martin Wells

    CBFalconer Guest

    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, Oct 18, 2007
    #10
  11. Martin Wells

    Ben Pfaff Guest

    CBFalconer <> 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.
     
    Ben Pfaff, Oct 19, 2007
    #11
  12. CBFalconer <> 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) <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"
     
    Keith Thompson, Oct 19, 2007
    #12
  13. Martin Wells

    CBFalconer Guest

    Ben Pfaff wrote:
    > CBFalconer <> 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.)


    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
     
    CBFalconer, Oct 19, 2007
    #13
  14. Martin Wells

    Wade Ward Guest

    "CBFalconer" <> wrote in message
    news:...
    > 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

    "Der Katze tritt die Treppe hoch; Der Kater tritt sie krumm.%
    % De Teufel geit um; er bringt de menschen allet dumm."
    schau, schau
     
    Wade Ward, Oct 21, 2007
    #14
  15. Martin Wells

    Thad Smith Guest

    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
     
    Thad Smith, Oct 21, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike
    Replies:
    2
    Views:
    668
  2. Geiger Ho

    Memory Hungry in Windows

    Geiger Ho, Nov 27, 2003, in forum: Python
    Replies:
    1
    Views:
    255
    Andrew Bennetts
    Nov 27, 2003
  3. Alex Vinokur
    Replies:
    10
    Views:
    561
    Alex Vinokur
    Apr 1, 2006
  4. vishnu
    Replies:
    5
    Views:
    357
    Gabriel Genellina
    Jun 12, 2007
  5. ABCL
    Replies:
    0
    Views:
    593
Loading...

Share This Page