An improved version of C is needed for embedded systems.

[Bill Hanna]

C is inadequate for embedded systems for the following reasons:

1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O.

2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.

3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications.

4) C does not provide overflow detection or carry out detection.

The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.

Comments are solicted.
Thanks,
Bill Hanna

[Mike Wahler]

Bill Hanna <bi*****@aol.com> wrote in message
news:97**************************@posting.google.c om...

C is inadequate for embedded systems for the following reasons:

1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O.

2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.

3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications.

4) C does not provide overflow detection or carry out detection.

The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.

Comments are solicted.

My comment:

You seem to feel that C is insufficient to your needs.
So use (or create) something that is sufficient.

Here, we discuss C as it is.

-Mike

[Jack Klein]

On 4 Jul 2003 22:36:08 -0700, bi*****@aol.com (Bill Hanna) wrote in
comp.lang.c:

C is inadequate for embedded systems for the following reasons:
That's funny, I've been using C for embedded systems for more than 20
years, and I find it highly adequate.

Besides which, who ever said that C was supposed to be adequate for
embedded systems?

Finally, what's better?
1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O.
What's wrong with any of the above? If your compiler does not provide
a format for macros that it recognizes and optimizes away the
pointers, take it up with the compiler vendor or buy a better
compiler. The syntax works quite directly.

And what about things stranger than memory-mapped I/O, such as special
registers, the separate I/O space of some Intel (and some other)
architectures, memory-mapped registers, and quite a few other things?
So what?
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.
The interrupt vectoring is hardware dependent, depending on the
processor and quite a few other things.
3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications.
C does not support fixed point data at all. It supports integer and
floating point types natively. Fixed point is supported by vendor
supplied libraries.
4) C does not provide overflow detection or carry out detection.
Right, and that's deliberate. One of the fundamental design goals of
C is that you don't pay for what you don't need. In the cases where
you need these features, add them. Don't try to burden every program
by everyone else with them when they are not needed.
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.

Comments are solicted.
Thanks,
Bill Hanna

C is adequate for embedded systems because customers demand it. And
also because of the huge number of robust embedded systems that have
been built with it over more than a quarter of a century.

While all of this is off-topic, I do have two additional comments:

1. Stop whining. If the requirement of your customers is to use C,
either do it without complaint or perhaps look for another line of
work.

2. Most of your complaints are not about the language proper. C
doesn't support any hardware at all, not keyboards, video displays,
disk drives, serial terminals, not anything. Nor does it support
interrupts at all. So the fact that it doesn't support ADCs or PWMs
or DACs is irrelevant. Lack of support for the first list of hardware
I mentioned hasn't stopped C from being used for almost every major
operating system. Lack of standardized support for interrupts (and
what a nightmare that would be) has not prevented interrupt routines
from being written in (non-standard, extended) C in operating systems
and applications for desk tops.

Your problems appear to be not so much with the language, but with
your compiler vendor. Apparently they are not doing such a good job
providing usable extensions for your particular platform.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Derk Gwen]

# Comments are solicted.

The usual technique is to find a base language that you like, perhaps C
or Bliss or Ada or PL/I or Algol or Fortran, then adapt it to your specific
needs. Some of things you want simply do not exist on this or that cpu
I've worked on over the years. Demanding all of them to be standardised
into something like C would create a language that would be unusable for
some systems.

If customers demand things be done in a language that can't possibly
support it, you should've negotiated those issues before accepting them
as customers.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
What kind of convenience store do you run here?

[Morris Dovey]

Bill Hanna wrote:

C is inadequate for embedded systems for the following reasons:

1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O.
Direct addressing of memory mapped I/O /is/ supported simply and
easily.

Work-arounds for what?

What's your problem with macros? They're a language feature used
in C programs of all types.

Casts are seldom needed by programmers who've learned to work
/with/ the compiler instead of trying to force their incomplete
understanding of the language on it.

Pointers are a language feature that can provide flexibility and
efficiency, whether used to access memory or I/O space.
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.
Sorry. I (and /many/ others) have used C to service real time
interrupts. Some implementations even provide extensions to the
language to facilitate this activity. Please take notice of the
fact that such extensions may or not even be useful depending on
the hardware architecture.

Sorry again. Interrupt vectoring (when there are interrupts; and
when they are vectored) is dependent on the particular /hardware/
involved.
3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications.
Eh? In a wild and crazy moment, I wrote functions in C to perform
2048 x 2048 multiplication (also addition, subtraction, division,
and take square roots). The operations will work on even wider
operands if I change the 2048 to a larger number in a #define
statement in a header file.

Perhaps you meant to say that your processor doesn't provide
64-bit products? If so, this is hardly a C issue - just write the
code to do what you want...
4) C does not provide overflow detection or carry out detection.
Urk? WTFAYTA? It provides you with the ability to write code to
determine /before/ the fact that o'flo / carry will occur. The C
standard is unconcerned with particular ALU architectures. I've
seen hardware that not only didn't generate these status
conditions; but couldn't add (didn't even try).

For hardware specific code you'll need to take the time and
trouble to [1] learn the hardware; and [2] learn to program. I
don't think there's any compiler for any language that can do
either of these things for you.
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.
Obvious only to someone who knows assembler (and not C). I'm not
a C++ guru, so you'll have to ask about that language in the
news:comp.lang.c++ forum.
Comments are solicted.

C is a powerful tool for embedded systems development if you know
how to use it. If you don't, then you can either learn to use it
or choose another tool that works better for you.

If a prospect is determined to have C; and if you want that
prospect to become /your/ customer, then I'd suggest learning how
to deliver C - or find a prospect who wants something you /can/
deliver [hardly reocket science, is it?]
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

[Bhushit Joshipura]

1) and 3) are answered more adeptly than I can ever dream. However,
let me add my two cents worth for 2) and 4) . I will shuffle those
parts of original message :

The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.
The following requirements *are* hardware dependent. As these
solutions are not provided within standard C, you need to have glue
assembly code (or have to depend on non-portable libraries - where
your library provider is using assembly instead of you using it). If
your customer demands these things in absolute C/C++, your customer
really needs education.
4) C does not provide overflow detection or carry out detection.
However, it depends what you mean by "support" in 2)
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.

Vectoring is actually machine dependent

So far as you are protecting your resources, you can safely use C in
ISRs. Linking and loading may be trickier - but are out of C's context

And you can *send and receive* signals (software interrupts) through C
- if your OS provides that facility. Signals are real time interrupts
too. And there is a world of RTOS doing various fantastic things with
signalling among tasks in C.

-Bhushit

[Thomas Matthews]

Bill Hanna wrote:

C is inadequate for embedded systems for the following reasons:

1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Direct addressing of memory mapped I/O is supported very simply:
volatile unsigned char * UART_RX = (unsigned char *) 0x40030;
/* .. */
unsigned char byte_read = *UART_RX;
Are you looking for something simpler?
I didn't use any macros above.
I haven't used any macros for reading from hardware devices for
the last 10 years in my embedded systems programming experience.

Usually, we also add a higher layer to to this:
unsigned char Read_Uart_By_Polling(void)
{
/* ... */
return byte_read;
}
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=


2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Some compilers add support that allow C functions to be designated
as ISRs. In the embedded system I am working on, the interrupt
vector points to an ASM routine which calls a C routine.

The reason interrupt vectoring is compiler dependent is that each
platform handles it differently. Some OSes don't allow a program
to alter the any ISR.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=


3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Do you mean integral multiplication?
I am not familiar with DFAs, but my embedded C compiler has no
problems using 32 bits for an integral multiply.

I am in the process of writing C code for 1024-bit integer
multiplication. I'm not complaining that C doesn't support 1024-bit
integers; I'm adding additional support.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
4) C does not provide overflow detection or carry out detection. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Yes, you are correct. For the majority of applications, this is
not required. However, the C language does allow you to use inline
assembly. If your processor's instructions allow detection of
carry and overflow, you could insert some inline assembly. OTOH,
you could just write the whole routine in assembly and link it in.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Wrong. I've never programmed an entire embedded system in pure
C; it has always been a mix of C and assembly language. Sometimes
the contents of the function was replaced by assembly language (so
the function calling I/F would not be changed). One company I worked
for had a rule: C functions could be replaced by assembly as long
as the assembly function worked the same or better than the C version.

Most companies restrict the use of assembly language. The primary
reason is productivity. I've found that time just comes to a halt
when I write functions in assembly language. I can code more
functionality in C than in assembly. I use assembly language routines
to take advantage of processor specific features (and maybe other
h/w devices).

If you can't program purely in C, try a hybrid. Some companies now
use more than just C. They might code something up in Perl and
link it to a C function or vice-versa. The situation all depends
on what can be done to get the product to market faster with
higher quality.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Comments are solicted.
Thanks,
Bill Hanna

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[Malcolm]

"Thomas Matthews" <to********@sbcglobal.net> wrote in message

The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.

=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-= Wrong. I've never programmed an entire embedded system in pure
C; it has always been a mix of C and assembly language. Sometimes
the contents of the function was replaced by assembly language (so
the function calling I/F would not be changed). One company I worked
for had a rule: C functions could be replaced by assembly as long
as the assembly function worked the same or better than the C version.

The OP does have a valid complaint, if it isn't possible to write embedded
systems wholly in C without resorting to use of the assembler.
However the problems of designing a portable language that could make use of
low-level hardware functions would seem to be insuperable. C is the best
option that we have.

[Gammaburst]

>> 3) C does not provide the full result of a fixed point 32X32

multiply. It only provides the LH result. The UH result is needed for
digital filter applications.

C does not support fixed point data at all. It supports integer and
floating point types natively. Fixed point is supported by vendor
supplied libraries.

When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.

[Richard Bos]

Gammaburst <sp******@eat.this> wrote:

When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.

uint_16_t factor1, factor2;
uint_32_t result;

result = (uint_32_t)factor1 * factor2;

Surely that should work in C99? For C89, typedef uint_N_t to be
whichever type is appropriate.

Richard

[Ben Pfaff]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Gammaburst <sp******@eat.this> wrote:

When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.

uint_16_t factor1, factor2;
uint_32_t result;

result = (uint_32_t)factor1 * factor2;

Surely that should work in C99? For C89, typedef uint_N_t to be
whichever type is appropriate.

Notably, `unsigned long' is always appropriate (for many uses).

Also, the types you are thinking of are named uintN_t, not
uint_N_t.
--
"...Almost makes you wonder why Heisenberg didn't include postinc/dec operators
in the uncertainty principle. Which of course makes the above equivalent to
Schrodinger's pointer..."
--Anthony McDonald

[Tom St Denis]

Richard Bos wrote:

Gammaburst <sp******@eat.this> wrote:

When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.

uint_16_t factor1, factor2;
uint_32_t result;

result = (uint_32_t)factor1 * factor2;

Surely that should work in C99? For C89, typedef uint_N_t to be
whichever type is appropriate.

I use this idea for my LibTomMath [http://math.libtomcrypt.org]. Except
I use 32/64 bit types per default.

GCC will even optimize a 32x32 => 64 multiply to a single MUL [on x86].

I think if the OP had just looked a little "closer" at the C language he
would realize there are ways of dealing with alot of things.

Tom

[Gammaburst]

On Mon, 07 Jul 2003 17:04:58 GMT, Tom St Denis <to********@iahu.ca>
wrote:

I use this idea for my LibTomMath [http://math.libtomcrypt.org]. Except
I use 32/64 bit types per default.
Uh-oh, it says "Forbidden - You don't have permission to access / on
this server." Is there another way in?
GCC will even optimize a 32x32 => 64 multiply to a single MUL [on x86].

Hey you're right! GCC for x86 (I tried MinGW) is pretty smart about
that.