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.


 And class instances?


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


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.

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




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.


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




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.


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


 deeply

 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






(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.


 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 28 2002