www.digitalmars.com         C & C++   DMDScript  

D - D vs EC++

reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Nearly a decade ago, when the Japanese auto industry started embedding
16-bit and 32-bit controllers wholesale into cars, the need arose for
both an OS and a language to improve both the ease of implementation and
reliability of these systems.  Initially, many of these controllers used
no OS ("bare metal" programming), or they used any of a wide array of
tiny kernels, each incompatible with the other.

To resolve the OS issue, the uITRON OS was defined.  Like the POSIX
definitions, it has several "layers" of definition and implementation,
allowing its use to scale across a broad range of CPU power and
available memory.  While uITRON does not "own" the Japanese car market,
it certainly has a respectable slice of it.

The language issue was much harder to resolve.  C's usefulness over an
immense application range was recognized, but it was showing limitations
for larger embedded applications.  C++ removed all these limitations,
but did so in a way that was hostile to use on any deeply embedded
system with constrained CPU and/or memory resources.

The consensus was to try to create an embedded version of C++, one that
is a strict subset of the C++ spec (so it may be compiled by any
C++ compiler, and be debugged using C++ tools), but also one that would
exclude those C++ language features that imposed large run-time
penalties in either CPU time or memory space, which would allow an
efficient EC++ compiler to be produced.  (This applied both to the C++
language itself and to the C++ standard libraries.)  The Japanese
solicited input from the world, and the world responded.  The new
language was called "EC++", for EmbeddedC++, and a consortium was
established.

Among the participants were are wide array of C/C++ luminaries,
including individuals such as P.J. Plaugher, and compiler builders such
as Cygnus (pre-RedHat).  I was fortunate to have been working (as a
volunteer) on the periphery of this effort.  Lots of language analysis
was done to see what features may be removed (in whole or in part) from
C++ and still have a language that was 100% upwardly compatible with C++
and that was still useful.

My own contribution was to create my own personal agenda:  I wanted to
add *new* rules to EC++ to prevent many of the more common embedded
systems coding errors that were so difficult to detect and correct.
Well, the committee was focused exclusively on editing down the C++ spec
to an embedable form, and not at all interested in creating a "better"
language.  One that would *still* be 100% upwardly compatible with C++!
I simply wanted the compiler to enforce some basic coding rules, and
exclude the sloppier modes of expression, sort of like GCC's "-Wall",
but on steroids.

Well, my interest soon faded.  But not simply because my ideas were
rejected.  The real reason was that C++ compiler writers were getting
better and better at creating code that gradually eased (but never
eliminated) the heavy burden of C++.  For example, EC++ excluded
templates.  But when at least one compiler vendor managed to create an
efficient implementation (not MS!), the EC++ committee refused to
backtrack and allow templates back in to the EC++ spec.  Amazingly
enough, the same situation soon applied to about 90% of the uses for
RTTI, another excluded feature.

Sure, the EC++ effort fizzled away.  Today, I believe only Dinkum
software (P.J. Plaugher's company) still actively markets EC++ standard
libraries.  And his libraries do include efficient implementations of
features previously excluded from the EC++ standard libraries.  The only
EC++ compiler I've actually used is GCC (yes, the switches are deeply
hidden and seldom used, but they are there).  GreenHills made one, but I
don't know if was ever marketed.

I believe D may be the language the EC++ committee should have tried to
create.  (Well, if we can get 100% control over the GC, that is.)  The
cleanliness of the D language eliminates entire classes of
implementation errors.  It's "friendliness" with code written in other
languages encourages the reuse of legacy libraries.  And D's enhanced
"compilability" should permit every known space and time optimization to
be utilized.

But for D to become suitable for use in deeply embedded systems, it
needs to consider situations where everything is run from ROM.  Where
initialized static objects can be in ROM, and not need to be copied to
RAM.  (Yes, that means objects residing other than on the heap.)  Where
the GC can be completely disabled (and its code deleted) where its use
is not needed or warranted.  (Which means an "on/off" switch as well,
for when you do need GC, but not much or often.)  Many embedded systems
can reboot faster than a GC can run!

Other embedded implementation issues need to be examined, such as
program startup time (independent of OS), and the minimum size of a D
executable. If these can be addressed and resolved in a way that makes D
"embedable", then D's success may be guaranteed (at lest with
developers).

After all, there is more new code (by percentage) in any embedded system
than there is in any higher-level application (making legacy and reuse
issues less important).  And the vast majority of the world's software
is running inside embedded systems.  (Did you know that less than 10% of
the world's microprocessor production goes into PC's?)  And the minimal
retraining needed would make a switch to D for new embedded systems a
"no-brainer".

If D can be pushed just a little bit further down the "system ladder",
it may truly become as "general-purpose" as C, while also being useful
almost everywhere C++ is (excluding only those solutions that *must*
have MI ;^).

What do you say, Walter?  Let's see if we can put a D program into ROM,
on a system that lacks much of an OS!


-BobC
Jan 25 2002
parent reply "Walter" <walter digitalmars.com> writes:
----- Original Message -----
From: "Robert W. Cunningham" <rwc_2001 yahoo.com>
Newsgroups: D
Sent: Friday, January 25, 2002 7:26 PM
Subject: D vs EC++
| But for D to become suitable for use in deeply embedded systems, it
| needs to consider situations where everything is run from ROM.  Where
| initialized static objects can be in ROM, and not need to be copied to
| RAM.  (Yes, that means objects residing other than on the heap.)

D fully supports struct instances in ROM.

|  Where
| the GC can be completely disabled (and its code deleted) where its use
| is not needed or warranted.  (Which means an "on/off" switch as well,
| for when you do need GC, but not much or often.)  Many embedded systems
| can reboot faster than a GC can run!

Sure, there's nothing preventing that in D.


| Other embedded implementation issues need to be examined, such as
| program startup time (independent of OS), and the minimum size of a D
| executable. If these can be addressed and resolved in a way that makes D
| "embedable", then D's success may be guaranteed (at lest with
| developers).

The only reason a D executable is larger than the equivalent C one is
because of the extra chunk of code belonging to the GC implementation.


| What do you say, Walter?  Let's see if we can put a D program into ROM,
| on a system that lacks much of an OS!

I think D is well suited to embedded systems. I also have no heartburn if a
D implementor wants to extend or customize the language for their particular
application. After all, D is designed to solve problems, it is not a
religion.
Jan 26 2002
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 ----- Original Message -----
 From: "Robert W. Cunningham" <rwc_2001 yahoo.com>
 Newsgroups: D
 Sent: Friday, January 25, 2002 7:26 PM
 Subject: D vs EC++
 | But for D to become suitable for use in deeply embedded systems, it
 | needs to consider situations where everything is run from ROM.  Where
 | initialized static objects can be in ROM, and not need to be copied to
 | RAM.  (Yes, that means objects residing other than on the heap.)

 D fully supports struct instances in ROM.

And class instances? I've been using C++ for embedded work, but mainly as a "smarter C". I do nothing fancy with classes, and use them only in simple ways (decrease coupling, increase cohesion). I don't (yet) do any OO heavy lifting in my deeply embedded projects. I avoid vtables and RTTI and all the other C++ "features" that can lead to RAM and runtime bloat. But C++ does allow me to place fully instantiated objects into ROM. And if they are properly behaved (for example, all internal data being consts or statics), I can even use them from ROM, and avoid copying them to RAM. And avoid heap use (for objects, at least). Some of my systems don't have time to initialize objects after a reset: They need to be up and running immediately. So a means for having fully instantiated objects available in ROM is necessary if OO is to be pushed to the bare metal. Yes, I have had to do some gymnastics with compilers and binaries to make this work, but the gains from even a limited OO implementation make it worth it.
 |  Where
 | the GC can be completely disabled (and its code deleted) where its use
 | is not needed or warranted.  (Which means an "on/off" switch as well,
 | for when you do need GC, but not much or often.)  Many embedded systems
 | can reboot faster than a GC can run!

 Sure, there's nothing preventing that in D.

 | Other embedded implementation issues need to be examined, such as
 | program startup time (independent of OS), and the minimum size of a D
 | executable. If these can be addressed and resolved in a way that makes D
 | "embedable", then D's success may be guaranteed (at lest with
 | developers).

 The only reason a D executable is larger than the equivalent C one is
 because of the extra chunk of code belonging to the GC implementation.

Then D really should be strongly pitched as an embedded tool, in addition to all its other uses. I'd love to see the old EC++ crowd give D a thorough going-over.
 | What do you say, Walter?  Let's see if we can put a D program into ROM,
 | on a system that lacks much of an OS!

 I think D is well suited to embedded systems. I also have no heartburn if a
 D implementor wants to extend or customize the language for their particular
 application. After all, D is designed to solve problems, it is not a
 religion.

I can hardly wait for D-front! I'm not much of a compiler builder (from scratch), but I've done lots of compiler hacking. You build the frame, and I'll help hang the drywall and paint it in nice deeply embedded colors. -BobC
Jan 26 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C52F95F.FF43B907 yahoo.com...
 Walter wrote:

 ----- Original Message -----
 From: "Robert W. Cunningham" <rwc_2001 yahoo.com>
 Newsgroups: D
 Sent: Friday, January 25, 2002 7:26 PM
 Subject: D vs EC++
 | But for D to become suitable for use in deeply embedded systems, it
 | needs to consider situations where everything is run from ROM.  Where
 | initialized static objects can be in ROM, and not need to be copied to
 | RAM.  (Yes, that means objects residing other than on the heap.)

 D fully supports struct instances in ROM.


No.
 I've been using C++ for embedded work, but mainly as a "smarter C".  I do
 nothing fancy with classes, and use them only in simple ways (decrease
 coupling, increase cohesion).  I don't (yet) do any OO heavy lifting in my
 deeply embedded projects.  I avoid vtables and RTTI and all the other C++
 "features" that can lead to RAM and runtime bloat.

 But C++ does allow me to place fully instantiated objects into ROM.  And

 they are properly behaved (for example, all internal data being consts or
 statics), I can even use them from ROM, and avoid copying them to RAM.

 avoid heap use (for objects, at least).  Some of my systems don't have

 initialize objects after a reset:  They need to be up and running

 So a means for having fully instantiated objects available in ROM is

 if OO is to be pushed to the bare metal.

 Yes, I have had to do some gymnastics with compilers and binaries to make

 work, but the gains from even a limited OO implementation make it worth

If you're not using vtables, etc., then aren't you really just using structs?
 |  Where
 | the GC can be completely disabled (and its code deleted) where its use
 | is not needed or warranted.  (Which means an "on/off" switch as well,
 | for when you do need GC, but not much or often.)  Many embedded


 | can reboot faster than a GC can run!

 Sure, there's nothing preventing that in D.

 | Other embedded implementation issues need to be examined, such as
 | program startup time (independent of OS), and the minimum size of a D
 | executable. If these can be addressed and resolved in a way that makes


 | "embedable", then D's success may be guaranteed (at lest with
 | developers).

 The only reason a D executable is larger than the equivalent C one is
 because of the extra chunk of code belonging to the GC implementation.

Then D really should be strongly pitched as an embedded tool, in addition

 all its other uses.  I'd love to see the old EC++ crowd give D a thorough
 going-over.

I'd love to see it pitched as an embedded systems language. I'm not the guy to do it, however, since it's been decades since I've done embedded systems work.
 | What do you say, Walter?  Let's see if we can put a D program into


 | on a system that lacks much of an OS!

 I think D is well suited to embedded systems. I also have no heartburn


 D implementor wants to extend or customize the language for their


 application. After all, D is designed to solve problems, it is not a
 religion.

I can hardly wait for D-front! I'm not much of a compiler builder (from scratch), but I've done lots of compiler hacking. You build the frame, and I'll help hang the drywall and paint it in nice

 embedded colors.

OK!
Jan 26 2002
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 "Robert W. Cunningham"
 I can hardly wait for D-front!  I'm not much of a compiler builder (from
 scratch), but I've done lots of compiler hacking.

 You build the frame, and I'll help hang the drywall and paint it in nice

 embedded colors.

OK!

Well, then, let's go! First, I'd recommend tailoring D-front to GCC (if it makes a difference): That will instantly open up the greatest number of target platforms. I already use several customized GCC versions for various embedded processors. This will also allow a common development and deployment environment, since CygWin is available for Windows, and most RTOSes look more like UNIX anyhow. Best of all, it will instantly get D onto just about every possible target without abandoning Windows. Second, I'd recommend specifying what it takes to properly start and run a D program, much along the lines of the imfamous "cstart.a" code. That is, assume there is no OS or anything on the target system: What minimum support must be provided for D's "Hello World" to run? If we assume COFF/ELF executable file loaders and initializers, what more is needed by D? For example, will D provide its own heap management? Where does the GC live? Is a single GC expected to be shared by all D programs, or must each D program have its own GC instance? Think Bare Metal. Third, the issue of debugging needs to be addressed. The gdb stub is easy to insert in any target (even if no target OS is present, just bare metal). But the real issue is to map all debug info back to the D source (though not necessarily automagically, at least not at first). D-front should consider littering the C code it generates with suitable "bread crumbs" to facilitate this process (such as labels for D line numbers). This will be especially important if D-front does optimization. Once targeted to GCC/GDB, moving D-front to other compilers should be straight forward. I would not be surprised to see folks like Green Hills jump on the D bandwagon sooner rather than later. Anyway, a few things to think about before D-front approaches reality. -BobC
Jan 27 2002
parent "Walter" <walter digitalmars.com> writes:
Some great ideas. Clearly, gcc is the C compiler to target for
non-Windows. -Walter

"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C546290.F0384E08 yahoo.com...
 Walter wrote:

 "Robert W. Cunningham"
 I can hardly wait for D-front!  I'm not much of a compiler builder



 scratch), but I've done lots of compiler hacking.

 You build the frame, and I'll help hang the drywall and paint it in



 deeply
 embedded colors.

OK!

Well, then, let's go! First, I'd recommend tailoring D-front to GCC (if it makes a difference):

 will instantly open up the greatest number of target platforms.  I already

 several customized GCC versions for various embedded processors.  This

 also allow a common development and deployment environment, since CygWin

 available for Windows, and most RTOSes look more like UNIX anyhow.  Best

 all, it will instantly get D onto just about every possible target without
 abandoning Windows.

 Second, I'd recommend specifying what it takes to properly start and run a

 program, much along the lines of the imfamous "cstart.a" code.  That is,

 there is no OS or anything on the target system:  What minimum support

 provided for D's "Hello World" to run?  If we assume COFF/ELF executable

 loaders and initializers, what more is needed by D?  For example, will D
 provide its own heap management?  Where does the GC live?  Is a single GC
 expected to be shared by all D programs, or must each D program have its

 instance?  Think Bare Metal.

 Third, the issue of debugging needs to be addressed.  The gdb stub is easy

 insert in any target (even if no target OS is present, just bare metal).

 the real issue is to map all debug info back to the D source (though not
 necessarily automagically, at least not at first).  D-front should

 littering the C code it generates with suitable "bread crumbs" to

 this process (such as labels for D line numbers).  This will be especially
 important if D-front does optimization.

 Once targeted to GCC/GDB, moving D-front to other compilers should be

 forward.  I would not be surprised to see folks like Green Hills jump on

 bandwagon sooner rather than later.

 Anyway, a few things to think about before D-front approaches reality.


 -BobC

Jan 28 2002