Re: C vs C++ in Embedded Systems?

From: Andrew Reilly (andrew-newspost_at_areilly.bpc-users.org)
Date: 02/01/05 

Date: Tue, 01 Feb 2005 12:22:36 +1100

On Tue, 01 Feb 2005 00:51:06 +0200, Paul Keinanen wrote:

> On Mon, 31 Jan 2005 21:04:57 +1100, Andrew Reilly
> <andrew-newspost@areilly.bpc-users.org> wrote:
>
>
>>> 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++.
>
> Unfortunately, you seem to have missed my point.

Indeed that appears to be the case, sorry. My point above is strictly
related to the paragraph of yours that I quoted.

> I was not discussing
> the problem of garbage collection (if a programmer does not know when
> to delete an object, that programmer should not be hired)

[*] [I'd like to come back to this one, below]

>, but rather
> the problem of dynamic memory squeezing to allow a sufficient amount
> of contiguous memory.
>
> Using some ad-hoc method in which the code is disassembled to find out
> all memory references would not be acceptable due to the memory size
> and CPU power limitation, not to mention some rare cases, in which
> there might be some innocent looking bit patterns that could be
> misinterpreted.

I do not believe that I was talking about an ad-hoc system. In all of the
languages that I mentioned, the language runtime knows exactly where all
of the pointers (references) are, through type information and other
language-based constraints. Random bit patterns aren't in memory
references, by definition, in these languages.

> In an ad-hoc system, you might be able to achieve 99.999 % reliability,
> but in many systems, this is simply not enough. I have written several
> assemblers, linkers and disassemblers and relying on heuristics and
> other ad-hoc methods will sooner or later cause a catastrophe. You must
> have a formally sound method to describe the environment.

Exactly.

Now, whether any of the "safe" languages are suitable for any particular
embedded application or environment is obviously a decision for each
situation. Certainly many embedded platforms are just too small to
support the overhead. Some aren't, though. Certainly some of the issues
relating to real-time behaviour may not be solved in all situations, and
that may be an issue, but there are certainly embedded applications that
involve non-realtime behaviour where some of the benefits of a dynamic OO
language could be of use. Anything with an ethernet port and a
sophisticated TCP/IP control protocol would be a reasonable ball-park, IMO.

[*] [Digression:] It has occurred to me, as I've increased my use of
matlab, scheme and python for various projects, (off-line, usually), that
the apparent increase in "power" of these languages comes from the
structure of the libraries and the usual idioms. These typically revolve
around operating on and returning whole collections (or other "large"
objects) from function calls, rather than scalar values. This allows the
programmer to operate more at the pseudo-code or high-level algorithm
level, and is, IMHO, a consequence of pervasive garbage collection. It is
much harder (if not actually impossible) to use this style in C or C++
because it breaks the usual rules of level-balanced allocation and
de-allocation. In a non-garbage-collected environment, a caller can't
know, in general, whether a particular reference that it has just been
given is unique or not (in which case it should not free it when it's
done), and if unique, whether it points to allocated storage (should be
freed) or static/const storage. So: to answer the statement that prompted
this particular rave: if a hire is worrying about when to delete an
object then (a) they're obviously not operating on real-time code (and
probably not operating on embedded code at all) and (b) they're wasting
effort that could be put into better product or shorter release schedules.
Yes, I might be over-stating the case in the cause of a good argument; I
don't mean to be offensive.

[This is a digression, since the garbage/manual distinction applies
equally to C and C++, and so doesn't bear on the topic itself, other than
as a tangential put-down of C++. Sorry.] 

-- 
Andrew

Relevant Pages

  • Re: memory allocation questions (newbie)
    ... I think this means something like "a pointer that is ... prepared to point to a memory location big enough to hold an int." ... I think having multiple exit points is not a good idea. ... experience writing programs in high-level languages. ...
    (comp.lang.c)
  • Re: More on garbage collection
    ... but adding garbage collection is a disaster. ... on the memory layout. ... Please note that this is a theoretically soluble problem. ... All garbage collection languages that I know of fail ...
    (sci.crypt)
  • Re: single-address-space UNIX?
    ... In another venue I've been arguing about the feasibility of ... to create a copy of process A's memory at a different ... to garbage collection, and if garbage collection is possible, ... the kernel passes the pointer alongside the event ...
    (comp.unix.programmer)
  • Re: C vs C++ in Embedded Systems?
    ... >>systems (for languages that don't mind having things move around at run ... the garbage collection system be able to find every pointer that it needs ... ensuring that all pointer variables actually point to allocated memory. ... True, that's why those systems make do with static allocations, and ...
    (comp.arch.embedded)
  • Re: OT:C/C++ Opinion Poll
    ... GC was to first remove the memory allocation/deallocation ... abstraction entirely in higher level languages. ... Removing references is what was meant. ... Even replacing all calls to free with a null pointer assignment ...
    (comp.arch.embedded)