Can OO be successful in real-time embedded systems?

0 views
Skip to first unread message

Henning Rietz

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
To whom it may concern:

For the last couple of weeks I have been involved in a major survey on
the use of object oriented techniques in the area of telecommunications
(mainly in the German speaking region).
I can say "everybody" is using OO in some areas (mainly network
management, switch provisioning, customer care), BUT there are (almost)
no examples in the area of (small) embedded systems, main reasons for
that being:

- "OO systems are too slow"
- "OO systems eat up too much memory"

I believe, that this is not necessarily true but heavily related to
experience. Now I=B4m asking you:

How far "down" does the application of OO really go?
How far will it go in the future?
Who develops commercial(!) embedded real-time systems
using OO methods and languages?
Will OO ever be of major importance in that area?

If you have an opinion concerning these questions please share it with
me! Even those who think they=B4ll "never use that OO-stuff".

Regards,

Henning
-- =

Henning Rietz c/o
Condat GmbH Telephone: +49.30.39094-179
Alt-Moabit 91D Fax: +49.30.39094-300
10559 Berlin, Germany E-Mail: ri...@condat.de

Dave Baldwin

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
Henning Rietz (ri...@condat.de) wrote:

: I can say "everybody" is using OO in some areas (mainly network


: management, switch provisioning, customer care), BUT there are (almost)
: no examples in the area of (small) embedded systems, main reasons for
: that being:

: - "OO systems are too slow"
: - "OO systems eat up too much memory"

Object-dis-oriented programming is (like some others) intended to hide
the hardware from the programmer. How useful can this possibly be when
small embedded systems are expressly for dealing with the hardware? Some
of the techniques can be useful, but the overhead and 'hiding' is exactly
what you don't need in hardware control.

There is no universal programming method. Even the examples you cite are
misleading because they're the 'desk-top / paperwork' end of the software.
I'd bet that the software that operates the networks and switches isn't
done in 'OO' for the same reasons. Last time I looked at the cards in a
telephone network bay, I saw thousands of 8032's doing the hardware
control. There were one or two of them on each interface card in a
network terminal that had tens-of-thousands of telephone lines passing
thru it.

--
-=-=-=-=-=-=-=-=-=-=-=- Check out 'alt.tcj' -=-=-=-=-=-=-=-=-=-=-=-=-=-
Dave Baldwin: dib...@netcom.com | The Computer Journal 1(800)424-8825
DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/"
Voice : (916) 722-3877 | Hands-on hardware and software
TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480
-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-

Barry Kauler

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to Henning Rietz
Henning Rietz wrote:
>
> For the last couple of weeks I have been involved in a major survey on
> the use of object oriented techniques in the area of telecommunications
> (mainly in the German speaking region).
> I can say "everybody" is using OO in some areas (mainly network
> management, switch provisioning, customer care), BUT there are (almost)
> no examples in the area of (small) embedded systems, main reasons for
> that being:
>
> - "OO systems are too slow"
> - "OO systems eat up too much memory"
>
> I believe, that this is not necessarily true but heavily related to
> experience. Now I´m asking you:

>
> How far "down" does the application of OO really go?
> How far will it go in the future?
> Who develops commercial(!) embedded real-time systems
> using OO methods and languages?
> Will OO ever be of major importance in that area?
> Henning,
I think part of the problem is a lack of software tools down at
this end, such as C++.
This is just a wild thought, but I noticed that what is considered
to be the "best" OO language, Eiffel, produces plain old C as output
-- reason is to make it as cross-platform as possible
-- I wonder if that cross-platform capability will extend down
to microcontrollers?
One problem is that C compilers at this level tend to have non
standard features.
Anyway, it's a thought. I am tempted to buy Eiffel just for
checking it out, as the "Personal Eiffel for Windows" is just
US$69.95 .... BUT, only the full professional version gives
the C output, and I can't remember what that costs.
The address is:
http://www.eiffel.com
Anyone had any Eiffel experience? (unfortunately, that
rhymes with "awful"!)
regards,
Barry Kauler
........................................................
........................................................
........................................................

Steven Perryman

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <316BF0...@condat.de> Henning Rietz <ri...@condat.de> writes:

> For the last couple of weeks I have been involved in a major survey on
> the use of object oriented techniques in the area of telecommunications
> (mainly in the German speaking region).

> I can say "everybody" is using OO in some areas (mainly network
> management, switch provisioning, customer care), BUT there are (almost)
> no examples in the area of (small) embedded systems, main reasons for
> that being:

Yeah, everyone is using OO to build TMN management systems, the Alcatel SEL
and Siemens notably in Germany. But Network Elements are being built with OO
on embedded systems. Nokia have done so, and have deployed products. I believe
Siemens in Belgium are building SDH muxes with OO. Alcatel are bound to be
doing so too. I think GPT in the UK also use OO/C++ for their muxes too.

> - "OO systems are too slow"
> - "OO systems eat up too much memory"

I not sure about that. These issues are valid for all embedded systems IMHO,
and not just those developed using OO techniques. I guess it would depend on
your target platform, RTOS facilities (memory mgmt, IPC etc) , and the vendor
compilers you are using.

OOD for embedded systems seems to be the challenge.
You can come up with a HW platform-free OOA for your system quite easily, but
then taking that thru an OOD without losing any of the OO expressiveness and
also addressing the particular constraints/issues of the target embedded sys,
that is the challenge.


Regards,
Steven Perryman
perr...@cpd.ntc.nokia.com


ra...@ix.netcom.com

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In <dibaldDp...@netcom.com>, dib...@netcom.com (Dave Baldwin) writes:

>Object-dis-oriented programming is (like some others) intended to hide
>the hardware from the programmer. How useful can this possibly be when
>small embedded systems are expressly for dealing with the hardware?

Tremendously. It makes it much easier to add new features, delete unused
ones, and recycle old firmware modules when the hardware changes.
Example: I'm working on a special-purpose PROM for some equipment my
employer manufactures. It has oodles of features (both optional and non-)
and lots of hardware that won't be used in this specific application. I
was able to strip the code I wouldn't be using, and reduce the object
file from well over 100K, to about 24K, in less than 8 hours. There
were a few low-level routines that called other low-level routines for
performance reasons, but more than 90% of that code came out with no more
work than dropping the module's file name from the make file, and removing
its entries in the inter-object message dispatcher and/or software timer
dispatcher tables.

>I'd bet that the software that operates the networks and switches isn't
>done in 'OO' for the same reasons. Last time I looked at the cards in a
>telephone network bay, I saw thousands of 8032's doing the hardware
>control.

Or, in other words, they used modules with a clearly-defined interface
to hide the low-level work from the high-level code. That's pretty much
the essence of "object-oriented design". If it'd been a snake, it woulda
bit ya ;-)

Ran


Larry Baker

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to Henning Rietz
Henning Rietz wrote:
> - "OO systems are too slow"
> - "OO systems eat up too much memory"

Based on what my Telecom friends have been telling me back in
the US, C++ (and object-oriented techniques) are alive and well
in the switching industry. I know of one company that's implemented
an ATM switch using a complete C++ development environment.

IMHO the biggest impediment to using OO techniques for "hard" RT
work is an understanding of how to apply them in a resource-
intensive environment. The straight "party line" answers don't
always work.

In particular, many people that have been disappointed with
C++ performance seem to lack an understanding of the implications
of implicit calls to constructors/copy-constructors/destructors,
memory framentation, or inline vs. non-inline procedure calls.

Then they turn around and blame the language, rather than their
use of it.

Cheers,

Larry Baker
l...@sdt.com

John Hunnell P840

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to

> I'd bet that the software that operates the networks and switches isn't
> done in 'OO' for the same reasons. Last time I looked at the cards in a
> telephone network bay, I saw thousands of 8032's doing the hardware
> control. There were one or two of them on each interface card in a
> network terminal that had tens-of-thousands of telephone lines passing
> thru it.

How much would you like to bet. I am working on my second large
switch product at Nortel using OO with C++. Our product handles
hundreds of lines or trunks. The first product I worked on is
adding OO to a non OO environment while the second is being
designed from the bottom up and using OO extensively. It
is using a PPC603 (and other 32 bit processors), not an 8 bit
processor. I might add that it is using a third party multitasking
OS with many different tasks. Some of the tasks are designed
using various OO tools while others are non-OO. They can coexist
in the same system.

A couple quick impressions of OO in embedded systems:
- Yes the tools are lacking.
- If you think OO slows down your product, then you are not
experienced enough in OO and are poorly designing your product.
If you try to instantiate 300 objects every time you try to
place a phone call, control a motor, etc. something is drastically
wrong with your design. Reatime requirements sometimes require
you to modify your OO design from the "ideal" design just like
it does with procedural design. Even virtual function calls only
require an extra table lookup to make the method call (can you
say pointer to function call in C).
- I would agree that very small embedded systems may not benefit
from OO. OO is just a tool. The larger the design, the more your
design can benefit from OO. If the design is small enough, OO
may be overcomplicating things that are not very complex but if
you have a large design, it can help manage the complexity.

Eddie Hunnell
--
Eddie Hunnell
Bell Northern Research
hun...@bnr.ca


Ron M. Cole

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
Henning Rietz (ri...@condat.de) wrote:
: To whom it may concern:

: For the last couple of weeks I have been involved in a major survey on


: the use of object oriented techniques in the area of telecommunications
: (mainly in the German speaking region).
: I can say "everybody" is using OO in some areas (mainly network
: management, switch provisioning, customer care), BUT there are (almost)
: no examples in the area of (small) embedded systems, main reasons for
: that being:

: - "OO systems are too slow"


: - "OO systems eat up too much memory"

: I believe, that this is not necessarily true but heavily related to
: experience. Now I=B4m asking you:

: How far "down" does the application of OO really go?
: How far will it go in the future?
: Who develops commercial(!) embedded real-time systems
: using OO methods and languages?
: Will OO ever be of major importance in that area?

There was a good talk/paper at OOPSLA last fall about a realtime telecom
switch system build in Smalltalk on top of the psos+ realtime os. The
speaker said that it was by far his most productive project yet with the
lowest level of defects (his early designs had been done in C and C++). It
was a VME based system running on something like up to 100 68040 based
switch cards. And yes they did have to spend some time timing the code and
being careful of what they did but it sounded like a resonable amount of
effort given the result.

The paper is "Implementing a Real-Time, Embedded, Telecommunication
Swithcing System in Smalltalk" John Radford.


--
Ron Cole e-mail: co...@spk.hp.com
Hewlett Packard
Spokane Division Bell: 509-921-3839
24001 E Mission Ave
Liberty Lake, WA 99019-9599

Robert C. Martin

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <316BF0...@condat.de> Henning Rietz <ri...@condat.de> writes:

For the last couple of weeks I have been involved in a major survey on
the use of object oriented techniques in the area of telecommunications
(mainly in the German speaking region).
I can say "everybody" is using OO in some areas (mainly network
management, switch provisioning, customer care), BUT there are (almost)
no examples in the area of (small) embedded systems, main reasons for
that being:

- "OO systems are too slow"
- "OO systems eat up too much memory"

More than one of my clients are using OO and C++ in embedded,
multi-threaded, real time systems, and they are getting along quite
nicely. The systems I am talking about are extremely constrained.
There are dozens of real time tasks with millisecond response times.
There is a very limitted amount of memory. etc. They are concerned
for every wasted microsecond. Yet they are finding that C++ and OOD
are more than adequate to the task.

What is it that would make OO slow? Some people contend that it is
the time required for polymorphic dispatch. (i.e. figuring out which
method to call when a message is recieved.) In C++ this is very very
fast. Indeed I recently benchmarked a 486-33 using a popular
compiler and found that the polymorphic dispatch time was 140ns.

Moreover, polymorphic dispatch in OO applications replaces
if-else or switch statements in equivalent procedural applications.
So the comparison is probably moot. Neither is faster or slower than
the other given a decent compiler.

As to memory, C++ requires a bit more memory for managing the virtual
tables. This amounts to one pointer per object, and one virtual table
per class. Each virtual table contains one pointer per virtual
function and probably a few other bytes for miscellaneous stuff.
These tables can be placed in ROM.

However, these tables and the virtual pointers replace switch/case
tables or if/else code that would exist in the procedural counterpart.
So the difference is probably moot.

How far "down" does the application of OO really go?

As far down as you like. C++ code in interrupt heads is not out of
the question.

How far will it go in the future?

I anticipate no lower bound.

Who develops commercial(!) embedded real-time systems
using OO methods and languages?

If you would like to contact me, I will ask my clients if they would
be willing to share their experiences with you.

Will OO ever be of major importance in that area?

It already is.
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com


Robert C. Martin

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <316D1D...@cowan.edu.au> Barry Kauler <b.ka...@cowan.edu.au> writes:

This is just a wild thought, but I noticed that what is considered
to be the "best" OO language, Eiffel, produces plain old C as output

I can't let that one slip. Eiffel is considered "by some" to be the
"best" OOPL. Others rather like Java. Still others are sworn to
uphold Objective-C. And then there are those of us who think C++ is
somewhat usable.

Robert C. Martin

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <dibaldDp...@netcom.com> dib...@netcom.com (Dave Baldwin) writes:

Object-dis-oriented programming is (like some others) intended to hide
the hardware from the programmer.

This is not quite correct. The intention of OO is not to hide the
hardware from the programmer. The intention of OO is to provide tools
to the programmer whereby he can manipulate the hardware at varying
levels of abstraction. If he wants to twiddle the bits, he can
go right ahead and do so, even in OO. If he would rather deal at a
higher level of abstraction, he can use OO to create that level.

OO is a tool, not a religion, and not a philosophy.

How useful can this possibly be when

small embedded systems are expressly for dealing with the hardware? Some
of the techniques can be useful, but the overhead and 'hiding' is exactly
what you don't need in hardware control.

Incorrect. The overhead is minimal (arguably zero), and if the
engineer chooses to hide something, he must feel there is something to
hide. Example: When controlling a modem in order to dial a phone
number, one could twiddle the bits every time you need to dial, or one
can hide the bit twiddling in a function, and call the function
whenever you need to dial.

If you have two different kinds of modems, one could always check a
flag to make sure you are calling the right function, or one could
create an OO interface so that you don't care which type of modem you
are controlling.

There is no universal programming method.

Granted.

I'd bet that the software that operates the networks and switches isn't
done in 'OO' for the same reasons.

Actually, a lot of it is. I have clients in the telecom industry who
are using OO/C++ in their switches and network managers, etc.

Last time I looked at the cards in a
telephone network bay, I saw thousands of 8032's doing the hardware
control. There were one or two of them on each interface card in a
network terminal that had tens-of-thousands of telephone lines passing
thru it.

I don't know about 8032's. However, some of my clients are using
C++/OOD in motorola based microcontrollers (68000 based)....

Tim Dugan

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <RMARTIN.96...@rcm.oma.com>,

Robert C. Martin <rma...@oma.com> wrote:
>In article <316BF0...@condat.de> Henning Rietz <ri...@condat.de> writes:
>[...]

> - "OO systems are too slow"
> - "OO systems eat up too much memory"
>[...]
>
>What is it that would make OO slow? [...]

>
>As to memory, C++ requires a bit more memory for managing the virtual
>tables. [...]

Although I have no figures or measurements, I would have to say
that I suspect that the one area where C++ is slower is that
there is something about C++ that encourages programmers to
perform a great deal more allocation and de-allocation of
memory, causing memory fragmentation and slowing the allocation/
deallocation process.

This is partially a problem of style, using pointers and
performing "new" when a non-pointer will work. As classes
are constructed of classes which are constructed...etc...
a constructor call can cause numerous allocations of small
bits of memory.

I know that some groups try to restrict real time software in
Ada to not allocating heap space but only stack space. I suppose
you could do this in C++, too. But, generally, that doesn't
seem necessary.

-t
--
Tim Dugan
mailto:ti...@starbase.neosoft.com
http://starbase.neosoft.com/~timd

Robert C. Martin

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to

OOD for embedded systems seems to be the challenge. You can come
up with a HW platform-free OOA for your system quite easily, but
then taking that thru an OOD without losing any of the OO
expressiveness and also addressing the particular
constraints/issues of the target embedded sys, that is the
challenge.

But not a particularly difficult challenge. Probably the hardest part
is finding the appropriate cross tools. These tools *do* exist for
C++, but they are not plentiful yet.

However, once you have an acceptable cross environment, creating an OO
solution for an embedded real-time problem is no more challenging than
creating a procedural solution to the same problem. And it comes with
the traditional benefits of OO: maintainability and reusability.

Dave Baldwin

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
ra...@ix.netcom.com wrote:

: Tremendously. It makes it much easier to add new features, delete unused


: ones, and recycle old firmware modules when the hardware changes.
: Example: I'm working on a special-purpose PROM for some equipment my
: employer manufactures. It has oodles of features (both optional and non-)
: and lots of hardware that won't be used in this specific application. I
: was able to strip the code I wouldn't be using, and reduce the object
: file from well over 100K, to about 24K, in less than 8 hours. There
: were a few low-level routines that called other low-level routines for
: performance reasons, but more than 90% of that code came out with no more
: work than dropping the module's file name from the make file, and removing
: its entries in the inter-object message dispatcher and/or software timer
: dispatcher tables.

: Or, in other words, they used modules with a clearly-defined interface

: to hide the low-level work from the high-level code. That's pretty much
: the essence of "object-oriented design". If it'd been a snake, it woulda
: bit ya ;-)

That's very nice, but it sounds to me like you're confusing modularity
with 'object-oriented'. They are not the same. I can do (and have done)
what you're describing with the assembly langauge libraries I've
written. Comment out a few macros and includes and I have a 'new'
program. No sense in writing everything from scratch every time.

You would be hard-pressed to put a 100k binary into a 8032 application.
It would require special bank-switching hardware external to the 8032
since it only has a code space of 64k. At that point, most would go to a
different CPU. Also, the 8032 is limited to about 128 bytes of stack
because you have to use the chip's internal memory which is 256 bytes
total. This memory space also includes the chip's registers and on-chip
I/O control.

Jon S Anthony

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
In article <316BF0...@condat.de> Henning Rietz <ri...@condat.de> writes:

I would believe that Ada folk have more to say on this than most. So,
I am crossing it over to c.l.a too...

/Jon


> To whom it may concern:
>

> For the last couple of weeks I have been involved in a major survey on
> the use of object oriented techniques in the area of telecommunications
> (mainly in the German speaking region).
> I can say "everybody" is using OO in some areas (mainly network
> management, switch provisioning, customer care), BUT there are (almost)
> no examples in the area of (small) embedded systems, main reasons for
> that being:
>

> - "OO systems are too slow"
> - "OO systems eat up too much memory"
>

> I believe, that this is not necessarily true but heavily related to
> experience. Now I=B4m asking you:
>

> How far "down" does the application of OO really go?

> How far will it go in the future?

> Who develops commercial(!) embedded real-time systems
> using OO methods and languages?

> Will OO ever be of major importance in that area?
>

> If you have an opinion concerning these questions please share it with
> me! Even those who think they=B4ll "never use that OO-stuff".
>
> Regards,
>
> Henning
> -- =
>
> Henning Rietz c/o
> Condat GmbH Telephone: +49.30.39094-179
> Alt-Moabit 91D Fax: +49.30.39094-300
> 10559 Berlin, Germany E-Mail: ri...@condat.de

--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
j...@organon.com


Ell

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
Robert C. Martin (rma...@oma.com) wrote:
: dib...@netcom.com (Dave Baldwin) writes:
: This is not quite correct. The intention of OO is not to hide the

: hardware from the programmer. The intention of OO is to provide tools
: to the programmer whereby he can manipulate the hardware at varying
: levels of abstraction. If he wants to twiddle the bits, he can
: go right ahead and do so, even in OO. If he would rather deal at a
: higher level of abstraction, he can use OO to create that level.

: OO is a tool, not a religion, and not a philosophy.

OO"T" is a tool, OO should NOT be a religion, but there IS a "philosophy"
(or more accurately a philosophical viewpoint) beneath the most efficient
and "intuitive" OO, in my opinion. I have spoken to this philosophy on
the Usenet since 1990 (comp.object, and comp.lang.c++), Booch does so in
the early chapters of OOA&D, and Whitmire has done so recently here in
comp.object.

Elliott

Ell

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
Robert C. Martin (rma...@oma.com) wrote:
: dib...@netcom.com (Dave Baldwin) writes:

: Object-dis-oriented programming is (like some others) intended to hide
: the hardware from the programmer.

: This is not quite correct. The intention of OO is not to hide the
: hardware from the programmer. The intention of OO is to provide tools
: to the programmer whereby he can manipulate the hardware at varying
: levels of abstraction.

This is possible using Structured Analysis Design, and Programming (SADP),
though not generally polymorphically, as with OO. The intention of
Simula, the historically acknowledged first OOPL, (as I understand it) was
to simulate, or model, a fleet ship distribution network. And in doing
so, Simula processed information which was useful to the ship fleet
clients, and owners.

Elliott

Jens Coldewey

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
Steven Perryman wrote:

> ...Yeah, everyone is using OO to build TMN management systems, the Alcatel
> SEL and Siemens notably in Germany...

Well Siemens uses C++ but in a classical C/S architecture. Clients and data-
base servers are HP-UX (at least they were two years ago when I was in-
volved). The switches are connected as 'legacy' systems using either the
standard MML language or a 'Q3 interface' that is defined by Deutsche
Telekom. The database is a relational database. I think that limits the
OO statement to certain extent.

As far as I know Alcatel does it the same way. Concerning to
my knowledge both still use CHILL to program the switches.

BTW most of the TMN software was written by Siemens Austria in Vienna.

Jens

--
Jens Coldewey |s |d &|m | software design & management gmbh&CoKG
| | | | Thomas-Dehler-Str. 27
jens.c...@sdm.de | | | | 81737 Munich, Germany.

Roger Barnett

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to

We have customers using our Object Request Broker on networked
embedded systems running pSOS and OS/9 (amongst others), so I
suspect the answer to the question in the thread title is yes.

--
Roger Barnett
Object Oriented Technologies Ltd, Leamington Spa, England
email: ro...@oot.co.uk OR ro...@natron.demon.co.uk
Web: http://www.octacon.co.uk/onyx/external/oot.co.uk

Steven Perryman

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
In article <RMARTIN.96...@rcm.oma.com> rma...@oma.com (Robert C. Martin) writes:

>> OOD for embedded systems seems to be the challenge.

> But not a particularly difficult challenge.

I wouldn't make such a sweeping statement as that. :-)

> Probably the hardest part is finding the appropriate cross tools. These
> tools *do* exist for C++, but they are not plentiful yet.

> However, once you have an acceptable cross environment, creating an OO
> solution for an embedded real-time problem is no more challenging than
> creating a procedural solution to the same problem

I think in more general terms than just C++ tools. Environment IMHO transcends
more than mere compilers.

For example :

What is your distribution mechanism ?? Your persistence mech ??
And so on.

I could for example use CORBA and/or ODMG ODL etc to completely abstract these
issues. But then, are they supported by vendor products on the target
platforms ??

Could you write your own if needed ?? Maybe.
Can it even be done on the target platform ?? Maybe.

These issues seem to become more pressing on embedded systems than on say
UNIX platforms (especially wrt getting off-the-shelf vendor products) .


Regards,
Steven Perryman
perr...@cpd.ntc.nokia.com

Bhargav P. Upender

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
> Anyone had any Eiffel experience? (unfortunately, that
> rhymes with "awful"!)

I have "Personal Eiffel for Windows". I am not too impressed with the
maturity of the product.
* It is a memory hog. You need atleast 16M to run it on windows.
* The application that I have developed runs slow (personal version does
not have optimizer).
* I wouldn't use it for embedded systems yet!

The professional version might be better, but its more money.

I like the language: especially the pre/post conditions that can help in
reducing SW errors. These enable "programming by contract" method.

I like to hear other opinions.

Bhargav Upender
My opinions only!

Steve Lee

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to Dave Baldwin
>
> That's very nice, but it sounds to me like you're confusing modularity
> with 'object-oriented'. They are not the same. I can do (and have done)
> what you're describing with the assembly langauge libraries I've
> written. Comment out a few macros and includes and I have a 'new'
> program. No sense in writing everything from scratch every time.
>

I think there is a little difference between "comment out a few macros
and includes" and the power of polymorphism and abstraction.

> You would be hard-pressed to put a 100k binary into a 8032 application.
> It would require special bank-switching hardware external to the 8032
> since it only has a code space of 64k. At that point, most would go to a
> different CPU. Also, the 8032 is limited to about 128 bytes of stack
> because you have to use the chip's internal memory which is 256 bytes
> total. This memory space also includes the chip's registers and on-chip
> I/O control.
>

Isn't the title of this thread hint towards real-time embedded systems,
and not just the 8032?

--
Steve Lee
Computer Engineering/Computer Science
Iowa State University
email -> sj...@iastate.edu
WWW -> http://www.cs.iastate.edu/~sjlee/homepage.html

Steve Lee

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to Larry Baker
>
> In particular, many people that have been disappointed with
> C++ performance seem to lack an understanding of the implications
> of implicit calls to constructors/copy-constructors/destructors,
> memory framentation, or inline vs. non-inline procedure calls.
>
> Then they turn around and blame the language, rather than their
> use of it.
>

Exactly.

Lee Webber

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
(I have quoted more than usual of the previous postings because I
am adding comp.lang.eiffel to the newsgroups, while deleting comp.
lang.c++.)

Barry Kauler <b.ka...@cowan.edu.au> wrote:


>
> Henning Rietz wrote:
> >
> > For the last couple of weeks I have been involved in a major survey on
> > the use of object oriented techniques in the area of telecommunications
> > (mainly in the German speaking region).
> > I can say "everybody" is using OO in some areas (mainly network
> > management, switch provisioning, customer care), BUT there are (almost)
> > no examples in the area of (small) embedded systems, main reasons for
> > that being:
> >
> > - "OO systems are too slow"
> > - "OO systems eat up too much memory"
> >
> > I believe, that this is not necessarily true but heavily related to

> > experience. Now I´m asking you:


> >
> > How far "down" does the application of OO really go?
> > How far will it go in the future?
> > Who develops commercial(!) embedded real-time systems
> > using OO methods and languages?
> > Will OO ever be of major importance in that area?

> > Henning,
> I think part of the problem is a lack of software tools down at
> this end, such as C++.

> This is just a wild thought, but I noticed that what is considered
> to be the "best" OO language, Eiffel,

Agreed.

> produces plain old C as output

> -- reason is to make it as cross-platform as possible
> -- I wonder if that cross-platform capability will extend down
> to microcontrollers?
> One problem is that C compilers at this level tend to have non
> standard features.
> Anyway, it's a thought. I am tempted to buy Eiffel just for
> checking it out, as the "Personal Eiffel for Windows" is just
> US$69.95 .... BUT, only the full professional version gives
> the C output, and I can't remember what that costs.
> The address is:
> http://www.eiffel.com

> Anyone had any Eiffel experience? (unfortunately, that
> rhymes with "awful"!)

> regards,
> Barry Kauler

Thank you for pressing my hot button. :-)

Yes, Eiffel should be ideal for embedded systems, for the reasons
given above. Unfortunately, the big 3 Eiffel vendors, while all
emitting C from their compilers, all interface to proprietary run-
time systems. Furthermore, their run-time systems all seem to be
platform-dependent.

You can get an Eiffel release from someone for just about any personal
computer or workstation and every major operating system you can name,
from DOS (Eon, SIG) to Windows (just about everyone) to various forms
of Unix (universal), to Mac, OS/2 and even (I believe) Intel/Next.
But that's as far as it goes; you can't use Eiffel for any environment
that doesn't have a user interface (this is a heuristic, not a causal
relationship), or that doesn't have a really large user base. To the
best of my knowledge, none of the Eiffel implementations has a garbage
collector that has even soft real-time characteristics on a slow
processor.

I have had on my wish list for some time an Eiffel compiler that would
emit C code that interfaced to an RTS in a *publically defined* way;
this would allow the RTS to be implemented for any platform. I have
made moves toward writing such a compiler, but it's just too big a
job and I haven't the time (or possibly the skills).

It's my opinion that if available Eiffel would eat Ada alive in the
real-time arena. But why dream...

Sid Johnson

unread,
Apr 12, 1996, 3:00:00 AM4/12/96
to
Henning Rietz wrote:
>

>
> - "OO systems are too slow"
> - "OO systems eat up too much memory"
>
> I believe, that this is not necessarily true but heavily related to
> experience. Now I´m asking you:
>
> How far "down" does the application of OO really go?
> How far will it go in the future?
> Who develops commercial(!) embedded real-time systems
> using OO methods and languages?
> Will OO ever be of major importance in that area?
>
>
>

>The trick is to remember that C++ is just doing what you would like to do in C, but
doing it with better looking source code. It provides modularity and extensibility without
cluttering source code with pointers and it avoids global data without the call overhead of "get"
functions (inline fns). These are great maintainability advantages.

As for being a resource hog, that is a matter of self-discipline. If you avoid exceptions
and templates, are reasonable with inheritance, and hit a happy medium on what you call an
object, there is very little overhead. In addition, for "single-instance" objects, you can make
the data and fns static and avoid the "this" pointer. Even with virtual fns, if the objects are
named at compile time instead of run-time, the virtual table is avoided altogether.

We are currently reengineering two existing products (similar but different) into one product
line using C++. These products are characterized by several choices of optional peripherals, and
very complex interactions of internal features. We have found C++ to be just the tool for
creating an architecture which simplifies the view of this software and gives the flexibility to
mix and match peripherals.

As for tools, there seems to be nothing below 32-bit except in the x86 family. This is because
the Microsoft and Borland compilers support it. Several other vendors provide linkers, locaters,
and debuggers to support these compilers. With this approach, you can go as low as the x86
family goes. As for OOA/D, the Rose tool supports these compilers.

I think the industry is really missing an opportunity to turn out much better software without
serious performance degradation -- even in the 8/16-bit market. :-)


--
__________________________________________________________________
Sid sjoh...@vantek.net

Come visit @ the Philosopher's Corner - http://www.vantek.net/pages/sjohnson/

In thinking, keep to the simple. In conflict, be fair and generous.
In governing, don't try to control. In work do what you enjoy.
In family life, be completely present.
Lao-Tzu
___________________________________________________________________

Brad Rodriguez

unread,
Apr 14, 1996, 3:00:00 AM4/14/96
to
Dave Baldwin wrote:
> Henning Rietz (ri...@condat.de) wrote:[snip]
>
> : - "OO systems are too slow"
> : - "OO systems eat up too much memory"[snip]

> Object-dis-oriented programming is (like some others) intended to hide
> the hardware from the programmer. How useful can this possibly be when

> small embedded systems are expressly for dealing with the hardware?

OK, Dave, I now know what my next article for TCJ will be. I've started
adding object-oriented extensions to Forth for my current project, a
distributed control system using relatively small embedded controllers
(68HC16s). It is neither a memory nor a CPU hog; dynamic binding takes
something like five machine instructions. (A similar scheme was
described in a recent ACM SIGPlan Notices.) It's also far from mature;
e.g., I've neglected encapsulation because I can work without it for the
time being. But I'm sure it will fit in an 8051. :-)

(You can hear about the entire project at the Rochester Forth Conference
this June. Advt.)

On the philosophical side...I've adopted OOP because it was the right
tool to solve the particular problems I'm facing. It's not always the
right tool. "If all you have is a hammer, everything looks like a nail."

(This message cross-posted to comp.lang.forth, and some inappropriate
cross-postings deleted.)
--
Brad Rodriguez b...@headwaters.com Computers on the Small Scale
Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj
Director, Forth Interest Group........... http://www.forth.org/fig.html
1996 Rochester Forth Conference: June 19-22 in Toronto, Ontario
http://maccs.dcss.mcmaster.ca/~ns/96roch.html

Zsoter Andras

unread,
Apr 15, 1996, 3:00:00 AM4/15/96
to
>Dave Baldwin wrote:
>> Henning Rietz (ri...@condat.de) wrote:[snip]
>>
>> : - "OO systems are too slow"
>> : - "OO systems eat up too much memory"[snip]
>> Object-dis-oriented programming is (like some others) intended to hide
>> the hardware from the programmer. How useful can this possibly be when
>> small embedded systems are expressly for dealing with the hardware?

Well, I am not doing embedded systems, but my OOF (and DOOF) is built
on a VERY FAST OOP implementation.
My paper about it is in the coming(?) issue of FD.
In my system a late bound call or a field access takes the same time
as an ordinary call of a global variable access (at least on a 486
CPU -- of course caches can mess things up).
The only thing that takes extra time is to change the object-in-use, but
even that one is not too long.

On CPU-s with more restricted addressing modes it is not 100% true
but the penalty should be quite low.
If you can afford to use Forth instead of assembly you can afford
OOP.

Andras


Matt Kennel

unread,
Apr 15, 1996, 3:00:00 AM4/15/96
to
Larry Baker (l...@sdt.com) wrote:

: Henning Rietz wrote:
: > - "OO systems are too slow"
: > - "OO systems eat up too much memory"

: Based on what my Telecom friends have been telling me back in


: the US, C++ (and object-oriented techniques) are alive and well
: in the switching industry. I know of one company that's implemented
: an ATM switch using a complete C++ development environment.

: IMHO the biggest impediment to using OO techniques for "hard" RT
: work is an understanding of how to apply them in a resource-
: intensive environment. The straight "party line" answers don't
: always work.

: In particular, many people that have been disappointed with


: C++ performance seem to lack an understanding of the implications
: of implicit calls to constructors/copy-constructors/destructors,
: memory framentation, or inline vs. non-inline procedure calls.

: Then they turn around and blame the language, rather than their
: use of it.

I think it's suitable to assign some of the blame to the langauge when
alternative languages of equal capability not have such tricky implicit
semantic issues.

More mature fields of engineering do not blame humans for being human.

They strive to create technology and creative and clever and profound
design which adapts to humans and serves their needs. (have you ever used
those new guillotine-style bagel slicers? Safe, quick and easy. Would
you blame people for being incompetent at evenly slicing bagels with a knife)

Would you blame people for being stupid for not knowing the complex and
subtle implicit rules in the tax code? Or would you consider the tax
code ill-designed.

Unlike tax law, you should not need an act of Congress to change your
programming language.

(happy April 15th!)


: Cheers,

: Larry Baker
: l...@sdt.com

Matt Kennel

unread,
Apr 15, 1996, 3:00:00 AM4/15/96
to
Bhargav P. Upender (ba...@utrc.utc.com) wrote:
: > Anyone had any Eiffel experience? (unfortunately, that
: > rhymes with "awful"!)

: I have "Personal Eiffel for Windows". I am not too impressed with the

: maturity of the product.
: * It is a memory hog. You need atleast 16M to run it on windows.
: * The application that I have developed runs slow (personal version does
: not have optimizer).
: * I wouldn't use it for embedded systems yet!

: The professional version might be better, but its more money.

The personal eiffel for windows is an interpreter. It will be
much slower than the professional version.

16 MB of memory is not very much.

: I like the language: especially the pre/post conditions that can help in

Dave Baldwin

unread,
Apr 15, 1996, 3:00:00 AM4/15/96
to
Brad Rodriguez (b...@headwaters.com) wrote:
: OK, Dave, I now know what my next article for TCJ will be. I've started
: adding object-oriented extensions to Forth for my current project, a
: distributed control system using relatively small embedded controllers
: (68HC16s). It is neither a memory nor a CPU hog; dynamic binding takes
: something like five machine instructions. (A similar scheme was
: described in a recent ACM SIGPlan Notices.) It's also far from mature;
: e.g., I've neglected encapsulation because I can work without it for the
: time being. But I'm sure it will fit in an 8051. :-)

It will be interesting to hear about 'OO' at a lower or smaller level
than C++ or other 'big' machine languages.

Peter Hermann

unread,
Apr 16, 1996, 3:00:00 AM4/16/96
to
Zsoter Andras (h929...@hkuxa.hku.hk) wrote:
: Well, I am not doing embedded systems, but my OOF (and DOOF) is built

BTW, The German word "DOOF" means "stupid". ;-)

--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 p...@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Jack Campin

unread,
Apr 16, 1996, 3:00:00 AM4/16/96
to

Brad Rodriguez <b...@headwaters.com> writes:
Dave Baldwin wrote:
> Henning Rietz (ri...@condat.de) wrote:[snip]
>> - "OO systems are too slow"
>> - "OO systems eat up too much memory"[snip]
> Object-dis-oriented programming is (like some others) intended to hide
> the hardware from the programmer. How useful can this possibly be when
> small embedded systems are expressly for dealing with the hardware?

A non-Forth example from several years back: the system software for one
of the more successful deep-space probes was done by Chorus in C++ (this
somewhat before C++ took over the universe); this stuff was somehow related
to their semi-OO microkernel. The dynamic linking meant they could download
modules and install them into the running system from tens of millions of
miles away, and this couldn't have been a large-memory system. I'd have
thought an OO Forth would have been a lot easier, but I don't think there
was a mature one back then.

Which makes me wonder: has Forth made it into space yet?

-----------------------------------------------------------------------------
Jack Campin ja...@purr.demon.co.uk
T/L, 2 Haddington Place, Edinburgh EH7 4AE, Scotland (+44) 131 556 5272
-------------------- FERMAN PADiSAHIN, DAGLAR BiZiMDiR --------------------


Ralph Hibbs

unread,
Apr 16, 1996, 3:00:00 AM4/16/96
to
Hello All Shlaer-Mellor Method Enthusiasts and OO Novices,

The report titled "Shlaer-Mellor Method: The OOA96 Report" is available
for free downloading at the Project Technology web site
(http://www.projtech.com).

This report is an extension the Shlaer-Mellor OOA Method, based on an
additional 5 years of real-world experience by Sally Shlaer, Stephen J.
Mellor and co-collaborator Neil Lang. Over the past 5 years the method
has been successfully applied to thousands of projects. This widespread
application surfaced some minor clarification and method enhancements.
These have been captured in the OOA96 Report.

Project Technology, home of methodologists Sally Shlaer and Stephen J.
Mellor, is proud to offer this exciting report via the internet. We
want to make our method available to the widest possible audience in the
most efficient manner.


----------------- Home of the Shlaer-Mellor Method --------------------
Ralph Hibbs Tel: (510) 845-1484
Director of Marketing Fax: (510) 845-1075
Project Technology, Inc. URL: http://www.projtech.com
Berkeley, CA 94710


Elizabeth Rather

unread,
Apr 16, 1996, 3:00:00 AM4/16/96
to
ja...@purr.demon.co.uk (Jack Campin) wrote:

>
>Which makes me wonder: has Forth made it into space yet?
>

Yes! A list compiled by folks at NASA/GSFC a few years ago listed over 40
space projects (including Shuttle experiments and satellites) coded in Forth.
There have presumably been more since. Some are described in our web site
(addr. below). NASA is presently developing a whole generation of systems for
interfacing "guest" payloads to the shuttle computing systems based on the
RTX2000 and programmed in Forth.

Elizabeth D. Rather
FORTH, Inc. Products and services for
111 N. Sepulveda Blvd. professional Forth programmers
Manhattan Beach, CA 90266 since 1973. See us at:
310-372-8493/fax 318-7130 http://home.earthlink.net/~forth/

Robert C. Martin

unread,
Apr 16, 1996, 3:00:00 AM4/16/96