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

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

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

"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!

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

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