C vs C++ in Embedded Systems?

On Sat, 29 Jan 2005 04:18:01 +0000, Ed Beroset wrote:
> You may know, but just for those watching, C++ does not employ any 
> garbage collection scheme (unlike Smalltalk and Java), and was developed 
> for and has been successfully used in telephone switches, which are most 
> certainly a real-time application.

Yeah, but so was Erlang, and it's an OO-functional language with all the
usual ML-style garbage collection facities.  So I don't think that's a
great argument...

-- 
Andrew

On Fri, 28 Jan 2005 19:17:55 -0000, "Peter"
<moocowmoo@newprovidence.demon.co.uk> wrote:

>I prefer C++ when I have the resources because I can use the STL and have 
>all the other benefits of object oriented programming. 

My understanding is that STL relies heavily on using dynamic memory.

In small embedded/realtime systems (not using virtual memory), using
dynamic memory can cause severe memory pool fragmentation, which would
case a memory allocation failure sooner or later. In systems designed
to run continuously for decades (or until the hardware is replaced),
the use of dynamic memory can be a quite critical question.

Paul
  

Andrew Reilly wrote:
> On Sat, 29 Jan 2005 04:18:01 +0000, Ed Beroset wrote:
> 
>>You may know, but just for those watching, C++ does not employ any 
>>garbage collection scheme (unlike Smalltalk and Java), and was developed 
>>for and has been successfully used in telephone switches, which are most 
>>certainly a real-time application.
> 
> 
> Yeah, but so was Erlang, and it's an OO-functional language with all the
> usual ML-style garbage collection facities.  So I don't think that's a
> great argument...

Actually, that just bolsters the argument -- real time systems can be 
built in a lot of different ways, including with C++.

Ed

On Sun, 30 Jan 2005 16:01:06 +0200, Paul Keinanen wrote:

> On Fri, 28 Jan 2005 19:17:55 -0000, "Peter"
> <moocowmoo@newprovidence.demon.co.uk> wrote:
> 
>>I prefer C++ when I have the resources because I can use the STL and have 
>>all the other benefits of object oriented programming. 
> 
> My understanding is that STL relies heavily on using dynamic memory.
> 
> In small embedded/realtime systems (not using virtual memory), using
> dynamic memory can cause severe memory pool fragmentation, which would
> case a memory allocation failure sooner or later. In systems designed
> to run continuously for decades (or until the hardware is replaced),
> the use of dynamic memory can be a quite critical question.

My understanding is that there are modern coping garbage collection
systems (for languages that don't mind having things move around at run
time[*]) that are supposed to not break as long as there is at least twice
as much physical memory as the worst-case active memory load.  So if
you're prepared to pay that price (allocate no more than half of available
memory at once), you should be able to use dynamic memory and garbage
collection "forever".  I know that Eiffel has been used, with such a
garbage collector, in some ample-memory embedded systems, like laser
printers.

[*] That's pretty much the "safe" languages that don't let you muck about
with pointers as though they were integers, or make up pointers with
integer maths: the lisps & schemes, the Pascal family (including ADA?
dunno) and Eiffel, the ml family, Java, C#, etc.  Almost the set {not C, C++}...

-- 
Andrew

Steve at fivetrees wrote:
> "Darin Johnson" <darin_@_usa_._net> wrote in message
> news:cu1k6pwoqaa.fsf@nokia.com...
>> pm940@yahoo.com writes:
>> Exceptions can be efficient in comparison to the alternative of
>> putting explicit error checks everywhere.
>
> I see this justification a lot, and in conventional sequential code
> it makes sense. However, anytime I run into these issues I wrap the
> throw scope in a state machine, and put the error check in *one*
> obvious place.

Do you mean that it makes no sense to throw exceptions in state 
machines? If so, why?

> The overhead of "explicit error checks everywhere"
> doesn't apply. I don' need no steenking exceptions ;).

Why are state machines different? An action could very well make a 
deeply nested call, or could it not? So, it makes sense to use 
exceptions there.

Regards,

-- 
Andreas Huber

When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Hi,
I have personally used C++ for an embedded system which is used in a
consumer electronics appliance.We used C when it requires Hardware
interaction and C++ in the application level to generate UI,Menus and
stuff like that.Really We enjoyed the reusability feature of C++ and
did not see any performance problems though.I would prefer a mix of
both ,though depending on the system.If you really want reusable code
and want to maintain good maitainability in the code in the
application perspective(though not on h/w interaction),I feel C++ will
be your best bet.I raised the same query a few days back and was
informed,instead of blaming the language,better learn the language to
use efficiently.I till now have the same opinion.Any language can be
used to best way it can work,if you know how to use it efficiently.If
you feel it does not fit your application,it does not mean,the total
language is useless!I believe totally rejecting C++ for embedded is
not a fair judgement.

P.S:I have no experience with other OO languages,so I will restrict my
opinion only to C++.

Regards,
s.subbarayan

"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message 
news:-dSdnTAWpqXeiGbcRVn-hA@nildram.net...
> "Antti Keskinen" <antti.keskinen@REMOVEME.koti.luukku.com> wrote in 
> message
> news:cteabq$1l40$1@news.cc.tut.fi...
>> C is more popular and more 'streamlined' (doesn't contain anything fancy)
>> for smaller embedded systems. It can't be used for true object-oriented
>> programming, but who needs OO on 8-bit processors ?
>
> I disagree. I consider OO at least as much a design technique as a 
> language
> feature.

This is most obviously a taste issue. 8-bit processors can be whipped to do 
amazing things, but considering the simplest example, like a PWM generator, 
then OO design technique feels a bit like overshoot. To each by their taste, 
however :)

> I agreed with the rest of your post, though ;).

At least we agree on something :)

-Antti Keskinen 

On Mon, 31 Jan 2005 09:58:12 +1100, Andrew Reilly
<andrew-newspost@areilly.bpc-users.org> wrote:

>My understanding is that there are modern coping garbage collection
>systems (for languages that don't mind having things move around at run
>time[*]) 

In order to be able to move the dynamic objects, the object can not be
accessed directly through pointers. Each object must be accessed with
a handle, that is used to index a pointer table to get the final
address. 

The required indirect indexed addressing mode can be quite costly
depending on available addressing modes and available registers and
will cause an increase in code size. Also each active object needs a
pointer in the pointer table, which must be in RAM, since the dynamic
memory manager must be able to update it, when a data block is moved
(reshuffled). 

However, in embedded and/or realtime systems, there are often
interrupts and task switching, which are quite problematic, if dynamic
memory objects can be moved. You either have to disable the interrupts
during dynamic memory data moves, which often is unacceptable due to
the long latencies or the interrupt service routines _must_not_ be
allowed to access any memory allocated dynamically. 

Even if the dynamic memory reshuffling is done in the lowest priority
(NULL) task, in a pre-emptive OS, an interrupt can cause a high
priority task to become runnable, which should suspend any lower
priority tasks. However, if the dynamic memory reshuffle is in
progress, this task switching must be disabled, until the reshuffle is
completed, which may delay the execution of the runnable high priority
task longer than acceptable, even if a single block is reshuffled at a
time.   

>that are supposed to not break as long as there is at least twice
>as much physical memory as the worst-case active memory load.  

Suggesting such huge extra allocations would not be very realistic in
many embedded systems with low resources.

Paul

On Mon, 31 Jan 2005 11:46:34 +0200, Paul Keinanen wrote:
> On Mon, 31 Jan 2005 09:58:12 +1100, Andrew Reilly
> <andrew-newspost@areilly.bpc-users.org> wrote:
> 
>>My understanding is that there are modern coping garbage collection
>>systems (for languages that don't mind having things move around at run
>>time[*]) 
> 
> In order to be able to move the dynamic objects, the object can not be
> accessed directly through pointers. Each object must be accessed with
> a handle, that is used to index a pointer table to get the final
> address. 

No, that's much too strong a requirement.  The real requirement is that
the garbage collection system be able to find every pointer that it needs
to relocate, so that it can be changed to follow the allocation.  Double
indirection through handles is one obvious way to do that, but simply
ensuring that all pointer variables actually point to allocated memory. 
That's a natural consequence of the "safe" languages that I mentioned, and
so those languages get to use normal, one-way pointers, even to memory
objects that can be moved when needed. It's a requirement that can't be
ensured with C or C++.

> However, in embedded and/or realtime systems, there are often interrupts
> and task switching, which are quite problematic, if dynamic memory
> objects can be moved. You either have to disable the interrupts during
> dynamic memory data moves, which often is unacceptable due to the long
> latencies or the interrupt service routines _must_not_ be allowed to
> access any memory allocated dynamically.

I'm prety sure that the last approach is the one usually used, although I
believe that finding ways to relax this constraint is an avenue of active
research.

>>that are supposed to not break as long as there is at least twice as
>>much physical memory as the worst-case active memory load.
> 
> Suggesting such huge extra allocations would not be very realistic in
> many embedded systems with low resources.

True, that's why those systems make do with static allocations, and
languages that support them: C, C++ (if you're careful), Forth, assembly,
etc.

Cheers,

-- 
Andrew

"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message
news:41fd8809$1_1@news.bluewin.ch...
> Steve at fivetrees wrote:
> > "Darin Johnson" <darin_@_usa_._net> wrote in message
> > news:cu1k6pwoqaa.fsf@nokia.com...
> >> pm940@yahoo.com writes:
> >> Exceptions can be efficient in comparison to the alternative of
> >> putting explicit error checks everywhere.
> >
> > I see this justification a lot, and in conventional sequential code
> > it makes sense. However, anytime I run into these issues I wrap the
> > throw scope in a state machine, and put the error check in *one*
> > obvious place.
>
> Do you mean that it makes no sense to throw exceptions in state
> machines? If so, why?

I mean that if the error source and the error handler can be tightly bound
(for instance by turning a sequence into a loop decoding a state machine),
then there simply is no need to use exceptions.

> > The overhead of "explicit error checks everywhere"
> > doesn't apply. I don' need no steenking exceptions ;).
>
> Why are state machines different? An action could very well make a
> deeply nested call, or could it not? So, it makes sense to use
> exceptions there.

Same answer, really. If the deeply-nested call can return a failure code to
the state machine, again there's no need for exceptions. (I generally find I
have to do this anyway, since the state machine needs to know what to do
next...)

Steve
http://www.fivetrees.com