Can OO be successful in real-time embedded systems?
Brad Rodriguez
> 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
Frank Sergeant
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
My latest thinking is that OOP is primarily "factoring
writ large." That is, it is the action of properly
segregating commonalities and removing redundancy. In that
spirit, OOP could, indeed, produce smaller applications. In
cache-dominated systems, that might also translate into
faster applications. (Speculation without hard measurements
is easy!)
On the other hand, OOH (object oriented hype) may be
the bain of our existencies (or should I say
instantiations?).
-- Frank
py...@pobox.com (permanent)
http://www.eskimo.com/~pygmy
Zsoter Andras
>> 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
Dave Baldwin
: 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
: 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.
--
-=-=-=-=-=-=-=-=-=-=-=- 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. -=-=-=-=-=-
Peter Hermann
: 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
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 --------------------
Elizabeth Rather
>
>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/
Marc de Groot
>
> 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.
AMSAT, the ham radio satellite organization, also uses Forth for the software on
its satellites. The language they use is has an acronym for a name. The acronym stands
for the German equivalent of "language for satellites" or something like that. I can't
remember exactly what it is anymore...
--
----
Marc de Groot | Immersive Systems, Inc.
<ma...@immersive.com> | http://www.immersive.com
| Real VR for the net!
"Under the most strictly controlled conditions of temperature,
lighting and pH, the organism does as it damn well pleases."
Russell R. Nell
>> 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?
Why should any but the lowest level code know about hardware?
Even without OO would you not put an abstraction layer around
the hardware? Or is that abstraction layer just treating that
hardware like the object it is???
Hello by the way, long time listener, first time poster.
Will be starting an OO re-design of a 10 year old product
soon. When I have the time to devote I will be posting
a description of the project and a lot of questions. OO
is a new (and overdue) idea for this company!!!
--
Rusty Nail (Russell R. Nell) +============================+ /`-_
ne...@norland.icdnet.com || Wisconsin Cheese-Head || { }/
(414) 563-8456 ext. 214 || and Damn Proud of it!!! || \ * /
Norland Corporation +============================+ |___|
W6340 Hackbarth Road, Fort Atkinson, WI 53538-8999
Paul E. Bennett
>
> 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:.....Chorus in C++ ........
> ........................... 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?
Forth, according to an item I have read somewhere (I think it was MPE's
catalogue), is apparently on three out of four systems on the Shuttle (perhaps
our NASA guys could confirm this one) and is often the base programming level
for the embedded systems on a number of Satelites (mainly amatuer satelites).
The benefit is an interactive operating system and programming environment that
enables new programming from remote resources. Forth has been doing this for
quite a long time. there has always been something that seems "Object Oriented"
about Forth without being a full OO system. I prefer to think of Forth as more
"Function Oriented". Is this perhaps a better strategy for control systems.
--
Paul E. Bennett <p...@transcontech.co.uk>
Transport Control Technology Ltd.
Tel: +44 (0)117-9499861
Going Forth Safely
Marc de Groot
>
> Forth, according to an item I have read somewhere (I think it was MPE's
> catalogue), is apparently on three out of four systems on the Shuttle (perhaps
> our NASA guys could confirm this one) and is often the base programming level
> for the embedded systems on a number of Satelites (mainly amatuer satelites).
> The benefit is an interactive operating system and programming environment that
> enables new programming from remote resources. Forth has been doing this for
> quite a long time. there has always been something that seems "Object Oriented"
> about Forth without being a full OO system. I prefer to think of Forth as more
> "Function Oriented". Is this perhaps a better strategy for control systems.
IMO, the essence of object-oriented programming is the explicit declaration
of the relationship between a data structure and the algorithms that operate
on it--which is what a class declaration is.
Forth's CREATE...DOES>... construct embodies this essence neatly and simply.
The code following CREATE allocates the data structure, and the code
following DOES> operates on it. A Forth defining word is both
a class declaration and an implementation of its methods. Executing the
defining word constructs an object of that class.
One powerful and unique aspect of Forth is that all words are members
of a single metaclass. That class has a uniform structure, consisting
(in an indirect-threaded system) of a pointer to native code followed
by an arbitrary data structure. This structure allows very high
efficiency at run time. The uniformity facilitates the implementation
of such tools as debuggers and decompilers. It also makes LISP-like
programming techniques more tractable, such as code creating and
modifying other code.
Dave Baldwin
and large embedded systems are. Maybe the things I was referring to are
just considered 'tiny' to you.
Robert A Duff
Marc de Groot <ma...@immersive.com> wrote:
>IMO, the essence of object-oriented programming is the explicit declaration
>of the relationship between a data structure and the algorithms that operate
>on it--which is what a class declaration is.
Nah. That's just plain old abstract data types. Modula-2 modules can
do this. Ada 83 packages can do this. Neither are "object oriented",
in the usual sense. OO requires polymorphism, in addition to that other
good stuff.
- Bob
Paul E. Bennett
ma...@immersive.com "Marc de Groot" writes:
> Forth's CREATE...DOES>... construct embodies this essence neatly and simply.
> The code following CREATE allocates the data structure, and the code
> following DOES> operates on it. A Forth defining word is both
> a class declaration and an implementation of its methods. Executing the
> defining word constructs an object of that class.
>
> One powerful and unique aspect of Forth is that all words are members
> of a single metaclass. That class has a uniform structure, consisting
> (in an indirect-threaded system) of a pointer to native code followed
> by an arbitrary data structure. This structure allows very high
> efficiency at run time. The uniformity facilitates the implementation
> of such tools as debuggers and decompilers. It also makes LISP-like
> programming techniques more tractable, such as code creating and
> modifying other code.
With all that you state above, do you mean to say I have been doing "Object
Oriented Design and Programming" all this time without realising it?. Wow!.
You realise of course that it will now be just about impossible for me to
consider programming systems with anything other than Forth. :)
Chris Savage
|After reading all of this, I wonder what you people think small, medium,
|and large embedded systems are. Maybe the things I was referring to are
|just considered 'tiny' to you.
|--
I'm with you there. How many people use / would think of using OO in a
highly cost-constrained _small_ microcontroller application (e.g.
engine management, vcr, toaster, fork lift truck ?)
|-=-=-=-=-=-=-=-=-=-=-=- 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. -=-=-=-=-=-
=================================================
Chris Savage MSc Applications Software Engineer
Sevcon Ltd. Kingsway Gateshead NE11 0QA UK
Tel: +44 191 487 8516 Fax: +44 191 482 4223
=================================================
Piercarlo Grandi
>>> Duff) said:
bobduff> In article <31783C...@immersive.com>,
bobduff> Marc de Groot <ma...@immersive.com> wrote:
marc> IMO, the essence of object-oriented programming is the explicit
marc> declaration of the relationship between a data structure and the
marc> algorithms that operate on it--which is what a class declaration
marc> is.
bobduff> Nah. That's just plain old abstract data types. Modula-2
bobduff> modules can do this. Ada 83 packages can do this. Neither are
bobduff> "object oriented", in the usual sense. OO requires
^^^^^^^^
bobduff> polymorphism, in addition to that other good stuff.
Therefore as program which just does not happen to use polymorphism
cannot be called an OO program :-/.
David Taylor
ch...@nihilist.demon.co.uk (Chris Savage) wrote:
> dib...@netcom.com (Dave Baldwin) wrote:
>
> |After reading all of this, I wonder what you people think small, medium,
> |and large embedded systems are. Maybe the things I was referring to are
> |just considered 'tiny' to you.
> |--
> I'm with you there. How many people use / would think of using OO in a
> highly cost-constrained _small_ microcontroller application (e.g.
> engine management, vcr, toaster, fork lift truck ?)
The engine management systems I know of run 300K+ in size and are
highly cost constrained--production in the millions. Is this small??
--
-- Dave
Zsoter Andras
>> One powerful and unique aspect of Forth is that all words are members
>> of a single metaclass. That class has a uniform structure, consisting
>> (in an indirect-threaded system) of a pointer to native code followed
>> by an arbitrary data structure. This structure allows very high
>> efficiency at run time. The uniformity facilitates the implementation
>> of such tools as debuggers and decompilers. It also makes LISP-like
>> programming techniques more tractable, such as code creating and
>> modifying other code.
>
>With all that you state above, do you mean to say I have been doing "Object
>Oriented Design and Programming" all this time without realising it?. Wow!.
Whether you believe it or not some programmers actually think so. :-(
Some even claim that OOP is unnecessary because "we had it all the
time as CREATE DOES>". :-(((
Andras
Lee Webber
>
> dib...@netcom.com (Dave Baldwin) wrote:
>
> |After reading all of this, I wonder what you people think small, medium,
> |and large embedded systems are. Maybe the things I was referring to are
> |just considered 'tiny' to you.
> |--
> I'm with you there. How many people use / would think of using OO in a
> highly cost-constrained _small_ microcontroller application (e.g.
> engine management, vcr, toaster, fork lift truck ?)
Hardly anyone. What's amazing to me is how few people would use OO in
a somewhat larger system, say 128K to 1 Meg of memory, 16-bit processor
-- and how few OO language vendors think such targets are worth
supporting.
larry kollar
>After reading all of this, I wonder what you people think small, medium,
>and large embedded systems are. Maybe the things I was referring to are
>just considered 'tiny' to you.
A company I *used* to work for made a terminal server by embedding a
stripped-down UNIX, plus TCP/IP, in ROM. To me, that would be a large
embedded system.
I once hung a Rat Shack motion detector off the joystick port of my
Amiga and used JForth to monitor (and react to) someone tripping the
detector. That would have been a medium system, if I'd taken it beyond
that point and actually made it into something useful. :-)
As for small... well, what would a small system have been in the days
when 16K of RAM was a lot of memory in a computer? Times change, and so
does the capability of the hardware.
--
Larry Kollar, Dawsonville GA | *** Hatred is murder *** (1 Jn 3:15)
leko...@nyx.net | http://www.nyx.net/~lekollar/
"So don't try to turn my head away
Flirtin' with disaster every day"
Bruce R. McFarling
>In article <31783C...@immersive.com>,
>Marc de Groot <ma...@immersive.com> wrote:
>> IMO, the essence of object-oriented programming is the explicit >> declaration of the relationship between a data structure and the
>> algorithms that operate on it--which is what a class declaration is.
>
> Nah. That's just plain old abstract data types. Modula-2 modules
> can do this. Ada 83 packages can do this. Neither are object
> oriented", in the usual sense. OO requires polymorphism, in
>addition to that other good stuff.
I'm always amazed to see how a semantic quibble can be raised
even when the point raised is *explicitly* allowed for in the original
comment. Marc de Groot offers his opinion of the 'essense' of object
oriented programming. Robert Duff offers a checklist to qualify as
object oriented 'in the usual sense'.
But if something covers all the bases, its not an 'essence', is
it? We can see that it is not a substantial disagreement but only a
semantic quibble since the two points can be combined in one statement
with any conflict whatsoever:
"Although they lack some of the features normally expected in
object oriented programming, notably polymorphism, Forth, Modula-2 and
Ada-83 capture the essence of objective programming, which is the
declaration of a specific relationship between a data structure and the
algorithms that operate on it. Forth does this with CREATE DOES>,
Modula-2 with modules, and Ada-83 with packages."
Perfectly coherent combination of all the information contained
in both statements. That doesn't imply that both or either author
agrees, but it does imply that these specific statements of theirs are
not fundamentally contradictory.
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
Zsoter Andras
>ch...@nihilist.demon.co.uk (Chris Savage) wrote:
>>
>> dib...@netcom.com (Dave Baldwin) wrote:
>>
>> |and large embedded systems are. Maybe the things I was referring to are
>> |just considered 'tiny' to you.
>> I'm with you there. How many people use / would think of using OO in a
>> highly cost-constrained _small_ microcontroller application (e.g.
>> engine management, vcr, toaster, fork lift truck ?)
>Hardly anyone. What's amazing to me is how few people would use OO in
^^^^^^^^^^^^^^^^^^ ?
>a somewhat larger system, say 128K to 1 Meg of memory, 16-bit processor
>-- and how few OO language vendors think such targets are worth
>supporting.
I guess with OOP you can actually SAVE space because of the improved
code reusability. Well, if your whole application is 256 bytes long
than OOP or any other fancy stuff is out of question.
But if you have at least two kilobytes you should consider OOP.
Andras
Paul E. Bennett
leko...@nyx10.cs.du.edu "larry kollar" writes:
> Thus spake Dave Baldwin:
>
> >After reading all of this, I wonder what you people think small, medium,
> >and large embedded systems are. Maybe the things I was referring to are
> >just considered 'tiny' to you.
>
> A company I *used* to work for made a terminal server by embedding a
> stripped-down UNIX, plus TCP/IP, in ROM. To me, that would be a large
> embedded system.
Perhaps we could agree the following classification:
Micro Embedded - Less than 4Kb total memory requirements
Small Embedded - Greater than 4kb and Less than 64kb total memory requirement
Medium Embedded - Greater than 64kb and Less than 1Mb total memory requirement
Large embedded - Greater than 1Mb total memory requirement
Almost all of my systems are in the small category.
Bob Kitzberger
: After reading all of this, I wonder what you people think small, medium,
: just considered 'tiny' to you.
tiny 0 -- 1k lines
small 1k -- 10k lines
medium 10k -- 100k lines
large 100k -- 1M lines
enormous 1M++
Just my humble opinion.
--
Bob Kitzberger Rational Software Corporation r...@rational.com
Scott Wheeler
>highly cost constrained--production in the millions. Is this small??
Isn't that almost entirely data (maps) rather than executable?
Scott
C. T. Nadovich
>dib...@netcom.com (Dave Baldwin) wrote:
>|After reading all of this, I wonder what you people think small, medium,
>|and large embedded systems are. Maybe the things I was referring to are
>|just considered 'tiny' to you.
>|--
>I'm with you there. How many people use / would think of using OO in a
>highly cost-constrained _small_ microcontroller application (e.g.
>engine management, vcr, toaster, fork lift truck ?)
Today, or in the future?
Even in highly cost-constrained commercial applications, HARDWARE design
is usually OO. Often the economics of build vs. buy favor "buy",
especially for commodity items, like resistors and bolts. Companies
simply can't vertically integrate every technology.
Why won't software go that way? Why won't managers eventually see the
advantage of OO? A manager can pay a co-op to click and drag together a
toaster's embedded control system in a few minutes using third-party OO
widgets. Sure, a high priced engineer can code the same thing in less RAM,
bumming instructions or hacking FORTH, but is bumming instructions a
useful skill with megabit DRAMS selling for less than $2. If the toaster
costs $0.10 more with OO, but I can get it to market 6 months earlier, my
bottom line tells me what to do.
Get rid of the software tailor. That's one less high-priced craftsman I
need on staff --- not to mention one less schedule that slips because of
endless delays as the software is hand coded and hand debugged. Sure,
hand made stuff can be better than "from the rack", but one look at the
price tag on a custom suit and most of us head to JC Penny.
I know that point of view may rub some embedded SW gurus the wrong way, and
I'm not saying it's true today, but the dumbing down of software design is
coming at all levels IMHO. Fortunately, those high priced engineers can
all get jobs designing objects --- although they may have to move to
Russia or India.
--
73 de KD3BJ SK .. http://www.kd3bj.ampr.org
+1 215 257 0635 (voice) +1 215 257 2744 (data/fax)
Zsoter Andras
>Perhaps we could agree the following classification:
>Micro Embedded - Less than 4Kb total memory requirements
>Small Embedded - Greater than 4kb and Less than 64kb total memory requirement
>Medium Embedded - Greater than 64kb and Less than 1Mb total memory requirement
>Large embedded - Greater than 1Mb total memory requirement
>Almost all of my systems are in the small category.
You mean memory size between 4kb and 64 kb.
Looks like an ideal size to fit my OOF model into.
Andras
Bruce R. McFarling
>As for small... well, what would a small system have been in the days
>when 16K of RAM was a lot of memory in a computer? Times change, and so
>does the capability of the hardware.
Would 192 bytes RAM, 16K ROM qualify as a small system? That's
the 6502-derived micro-controller I've been looking at, if they would
only get around to making it a 16K EPROM, to free up the 3 8-bit ports
that has to go to data and address lines when the ROM is external.
And would the OO techniques we've been talking about be useful?
And which aspect? Data type <-> method association? Polymorphism?
Zsoter Andras
>Dave Baldwin (dib...@netcom.com) wrote:
>: After reading all of this, I wonder what you people think small, medium,
>: and large embedded systems are. Maybe the things I was referring to are
>: just considered 'tiny' to you.
> tiny 0 -- 1k lines
> small 1k -- 10k lines
^^^^^^^^^^
Are we still living in the FORTRAN age?
Andras
Todd Hoff
> A manager can pay a co-op to click and drag together a
> toaster's embedded control system in a few minutes using third-party OO
> widgets.
The reason i don't see this happening is that
every embedded target, for cost and other reasons,
is very custom. Devices are swapped in at the last
minute, a lot of ASICs and FPGAs are used, PIOs and
serial protocols vary hugely. Not to mention switching
OSs to get a smaller cost per copy. It's a very difficult
environment to automate for.
> useful skill with megabit DRAMS selling for less than $2. If the toaster
It's not $2, not even close. And yes, people will kill
over $2. And don't forget PROM will probably have to
scale up as RAM increases.
> costs $0.10 more with OO, but I can get it to market 6 months earlier, my
> bottom line tells me what to do.
There's a lot more to making a system than generating
a few classes, but yes, it would be nice to automate
more of it. You seem to be confusing OO with automation.
OO may or may not cut the per unit cost, but automation
would. And if you are automating the style of generated code
is not critical.
> I know that point of view may rub some embedded SW gurus the wrong way,
No, not all, many of us aggresively push for automation.
But automation implies a degree of standardization.
And standardization doesn't exist in the embedded world.
Lawrence M. Gearhart
> bobduff> Nah. That's just plain old abstract data types. Modula-2
> bobduff> modules can do this. Ada 83 packages can do this. Neither are
> bobduff> "object oriented", in the usual sense. OO requires
> ^^^^^^^^
> bobduff> polymorphism, in addition to that other good stuff.
>
> Therefore as program which just does not happen to use polymorphism
> cannot be called an OO program :-/.
I disagree. The essence of object-oriented programming is that it
extends the notion of abstract data types in two ways:
1) It introduces inheritance, allowing you to create a new class that
extends the capabilities of an existing class. Polymorphism is simply an
additional feature that adds flexibility to inheritance.
2) It enlarges the concept of abstract data type to include classes whose
resources include more than just data, but reach out into the environment
beyond the computer in a fundamental way.
It is really the 2nd characteristic of object-oriented programming which
has made the greatest impact in software architectures, whether real-time
or not. The greatest impact of the 1st characteristic has been in code
reuse, and because of that, indirectly a profound effect on software
architectures. Microsoft invented OLE based on the 2nd characteristic,
but its own software product line is based upon reusable and extensible
classes, which is based on the 1st characteristic.
Mike Albaugh
: ch...@nihilist.demon.co.uk (Chris Savage) writes:
: >I'm with you there. How many people use / would think of using OO in a
: >highly cost-constrained _small_ microcontroller application (e.g.
: >engine management, vcr, toaster, fork lift truck ?)
: Today, or in the future?
: Even in highly cost-constrained commercial applications, HARDWARE design
: is usually OO. Often the economics of build vs. buy favor "buy",
: especially for commodity items, like resistors and bolts. Companies
: simply can't vertically integrate every technology.
Strange, I had exactly the opposite notion. The hardware I see,
reading things like MicroProcessor Report, is less "OO" than the stuff I
was doing 20 years ago. How's That? 20 years ago one built a design out
of 8-bit latch chips, 4-bit counters, ALUs with clearly-defined
functionality, etc. Nowadays hardware seems to be heading down the same
two paths as software: quick-hack stuff done in a FPGA's or their ilk,
using software-like tools like VHDL in a development environment that
would cause Fred Brooks to shudder with flashbacks, and mega-designs
like the P6 with nasty little sections hand-tweaked by layout gurus.
Sure, in both cases one is "putting the blocks together", but the blocks
are significantly larger, less tested, and less "reusable", in the sense
of "applicable to other uses."
: Why won't software go that way? Why won't managers eventually see the
: advantage of OO? A manager can pay a co-op to click and drag together a
: toaster's embedded control system in a few minutes using third-party OO
: widgets.
I can confidently buy resistors and bolts because they are
commodity items with well-understood specifications and (in the case of
bolts) criminal penalties for mis-specification. In the software world,
the folks most likely to be providing the "objects" can't even get
things like strtol() and memcmp() right, and have legions of lawyers
making sure that if they slag down your machine the most they are liable
for is a replacment copy of the CDROM you bought their class-library on.
Your manager-type may _love_ to get the software process dumbed-down,
but the head of production wants no surprises with 5K toasters DOA and
the legal department wants no class-action suits from people injured by
flaming toast ejected at Mach 3 when they tried to toast during the
changeover from Standard to daylight-savings time :-)
: Sure, a high priced engineer can code the same thing in less RAM,
: bumming instructions or hacking FORTH, but is bumming instructions a
: useful skill with megabit DRAMS selling for less than $2. If the toaster
: costs $0.10 more with OO, but I can get it to market 6 months earlier, my
: bottom line tells me what to do.
Just be sure your bottom line includes adequate reserves for
returns and lawsuits. I am _not_ saying that the average assembly-hacker
is a better programmer than the average C++ hacker, but I'm saying that
he/she typically needs to design, rather than hack, if the project is to
work at all. The barriers to commercial use of OO are commercial ones,
and will require all of the following to be true before they fall:
1) a _huge_ increase in the reliability of purchased code.
2) Traceable responsibility, with legal teeth, for the mistakes that
will still occur.
3) Standards for software objects, and a method by which a purchaser
can verify that the purchased objects meet these standards.
Please note that just watching the rise of NetScape, following the
MicroSoft business model of "Dazzle them with glitz and they won't notice
the bugs", seems to argue against holding your breath for #1. Also that
the Nuclear Energy industry, with _much_ less money than the software
industry, managed to get themselves legally exempted for responsibility
for even _death_, so much for #2. And techniques like statistical
sampling which work fine for detecting, say, counterfeit grade-8 bolts
are meaningless with software. It takes only _one_ error in the wrong
place to moot most of the function of a software package. One need only
look at the stream of security bugs in Java, an OO language supposedly
designed with security in mind, for an illustration of this effect.
We will also need convincing proof that Fisher's Fundamental
Theorem ("The better adapted an organism is to its environment, the less
able to adapt to changes in environment, and vice versa" somehow does
not apply to software, alone in the universe of complex objects :-) This
theorem is roughly paraphrased: "Generality and efficiency are
inherently in oppostion" in Gerald Weinberg's "The Psychology of
Computer Programming" which I heartily recommend. The refusal of average
programmers to believe this is what, IMHO, blinds them to the gratuitous
complexity they introduce, and the bugs which _inherently_ follow.
That's what makes them average programmers :-) The point where this
becomes a problem for OO is that large aglomerations of really general
objects give rise to "epiphenomena", aka "emergent behavior. Verifying
such complex interactions, to the point where one could achieve #3, is
going to take quite a while. Leaving the question of liablity when
un-verified objects interact badly to be resolved by #2 (lawyers and
courts) or #1 (buy only from reputable vendors). But reputable vendors
are already taking a beating at the hands of "get it done now", else
quick-fix software development "silver-bullets" would not be so popular.
"Math is hard": Barbie :-)
: Get rid of the software tailor. That's one less high-priced craftsman I
: need on staff --- not to mention one less schedule that slips because of
: endless delays as the software is hand coded and hand debugged. Sure,
: hand made stuff can be better than "from the rack", but one look at the
: price tag on a custom suit and most of us head to JC Penny.
I own no suits at all, except for a tuxedo. It's a long story,
but the principle is: "If you don't need it, or it doesn't work, it's
not a bargain no matter how cheap it is." The point where real "software
tailors" (I'm not talking about the legions of wannabes who _should_ be
writing Doom-clones in Visual C++ to keep them out of trouble) earn
their keep is in understanding what the problem is, and picking the best
way to solve it. That way may very well be some sort of OO. It will
almost certainly involve decomposition into tractable sub-problems. It
will also involve taking things like product-life-cycle costs into account.
: I know that point of view may rub some embedded SW gurus the wrong way, and
: I'm not saying it's true today, but the dumbing down of software design is
: coming at all levels IMHO.
Has already come. The price is ever-increasing complexity resting
on ever-shakier foundations. I hear those apocolyptic woodpeckers coming :-)
: Fortunately, those high priced engineers can
: all get jobs designing objects --- although they may have to move to
: Russia or India.
Why? If I'm going to sit hunched over a workstation all day
hacking the One True String Class, why should my customer care where
I am?
Ending rant: The thing that distinguishes embedded programming
from the rest is not size or complexity, but the potential for harm,
either physical or fiscal :-) It shares these considerations with
"boring" things like airline reservation systems. By assuming away
the need for robustness, many folks free themselves to pursue really
attractive shiny toys :-)
Mike
| Mike Albaugh (alb...@agames.com) Atari Games (now owned by Williams)
| (No connection to any company owned by the Tramiel family)
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)
Piercarlo Grandi
>>> <ec...@cc.newcastle.edu.au> said:
ecbm> bob...@world.std.com (Robert A Duff) wrote:
>> In article <31783C...@immersive.com>,
>> Marc de Groot <ma...@immersive.com> wrote:
marc> IMO, the essence of object-oriented programming is the explicit
marc> declaration of the relationship between a data structure and the
marc> algorithms that operate on it--which is what a class declaration is.
Entirely correct if worded a bit clumsily.
bobduff> Nah. That's just plain old abstract data types.
No. For plain old ADTs imply only this relationship, they don't make it
explicit in a class relationship.
bobduff> Modula-2 modules can do this. Ada 83 packages can do this.
No, they cannot make that relationship *explicit*, because while in a
class declaration it is explicit that the functions in the class have
something to do with the type of the class, modules and packages have no
such explicit relationship, it is implicit if one follows it as a matter
of convention.
Unfortunately, as I have already remarked in this group, most proper
OO languages support but don't enforce the OO decomposition paradigm,
for while they provide a notion of module that is explicitly and
directly oriented at making clear the relationship between a data type
representation and operators defined over it, for *all* such operators
must be in the class, they don't enforce it, for it is usually
perfectly legal to put in a class entities totally unrelated to the
type representation it defines.
bobduff> Neither are object oriented", in the usual sense.
Let's agree on this... :-)
bobduff> OO requires polymorphism, in addition to that other good stuff.
OO does not require any specific language feature apart from direct and
explicit support and enforcement of its decomposition paradigm. Too bad
that no existing OO language enforces it...
ecbm> I'm always amazed to see how a semantic quibble can be raised
ecbm> even when the point raised is *explicitly* allowed for in the
ecbm> original comment. Marc de Groot offers his opinion of the
ecbm> 'essense' of object oriented programming. Robert Duff offers a
ecbm> checklist to qualify as object oriented 'in the usual sense'.
And his checklist is not a good way to catpure the essence.
ecbm> But if something covers all the bases, its not an 'essence', is
ecbm> it? We can see that it is not a substantial disagreement but only
ecbm> a semantic quibble since the two points can be combined in one
ecbm> statement with any conflict whatsoever:
ecbm> "Although they lack some of the features normally expected in
ecbm> object oriented programming, notably polymorphism, Forth, Modula-2 and
ecbm> Ada-83 capture the essence of objective programming, which is the
ecbm> declaration of a specific relationship between a data structure and the
ecbm> algorithms that operate on it. Forth does this with CREATE DOES>,
ecbm> Modula-2 with modules, and Ada-83 with packages."
But I disagree here too. For Forth, Modula-2 and Ada-83 do not make that
relationship explicit, but only as a matter of implicit convention. OO
languages are those language that _directly_ and _explicitly_ support
the OO decompositionb paradigm. One can use modules as if they were
classes, but this is just, if adopted, as implicit convention.
Lee Webber
>
> Lee Webber (le...@micrologic.com) wrote:
> >ch...@nihilist.demon.co.uk (Chris Savage) wrote:
> >> highly cost-constrained _small_ microcontroller application (e.g.
> >> engine management, vcr, toaster, fork lift truck ?)
>
> ^^^^^^^^^^^^^^^^^^ ?
> >a somewhat larger system, say 128K to 1 Meg of memory, 16-bit processor
> >-- and how few OO language vendors think such targets are worth
> >supporting.
>
> I guess with OOP you can actually SAVE space because of the improved
> code reusability. Well, if your whole application is 256 bytes long
> than OOP or any other fancy stuff is out of question.
> But if you have at least two kilobytes you should consider OOP.
>
> Andras
>
And I thought I was an OOP partisan! To me, OOP means polymorphism
(i.e., computed dispatch) and code/data encapsulation. And you're
going to get more than a toy system into 2K+?? I just finished a
12K (code size) system, written in C and assembler, and I needed
(literally!) every byte. Any reuse I got (and I got a lot), I
accomplished by hand-tuning.
For a realistic system, I wouldn't even try to put true OO into
anything less than 64K -- and double that if I were using a general-
purpose commercial development environment.
Zsoter Andras
>>
>> I guess with OOP you can actually SAVE space because of the improved
>> code reusability. Well, if your whole application is 256 bytes long
>> than OOP or any other fancy stuff is out of question.
>> But if you have at least two kilobytes you should consider OOP.
>>
>> Andras
>>
>And I thought I was an OOP partisan! To me, OOP means polymorphism
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>(i.e., computed dispatch) and code/data encapsulation. And you're
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For me OOP means exactly the same.
>going to get more than a toy system into 2K+?? I just finished a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, 2K might be a bit tight (although I have never thought about
the minimal size of a system, I usually use a 486 machine with
megabytes of memory. It also depends whether the compiler has to be
on the target system or just the executable code is to be put into
that 2K.
For the executable code even 1K would do (well you need a VMT table
for each class but they can be small if you don't have too many
methods) and almost nothing more. For an embedded system which
turn a toaster on and off you will not have a huge class hierarchy
anyway.
>12K (code size) system, written in C and assembler, and I needed
^^^^^^
C compiler output usually occupies a lot of space (and C++ even more).
Eg. my OOF (written in assembly) is around 32K while DOOF (in C++)
is around 120K (+ uses shared libraries).
>(literally!) every byte. Any reuse I got (and I got a lot), I
>accomplished by hand-tuning.
>For a realistic system, I wouldn't even try to put true OO into
>anything less than 64K -- and double that if I were using a general-
>purpose commercial development environment.
For a general purpose development environment even 64K can be tight.
But for a system written for ONLY ONE task the insides of an OOP
implementation can be fairly small.
Andras
Piercarlo Grandi
>>> <larry.g...@trw.com> said:
larry.gearhart> Piercarlo Grandi wrote:
bobduff> Nah. That's just plain old abstract data types. Modula-2
bobduff> modules can do this. Ada 83 packages can do this. Neither are
bobduff> "object oriented", in the usual sense. OO requires
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ^^^^^^^^
bobduff> polymorphism, in addition to that other good stuff.
pcg> Therefore as program which just does not happen to use polymorphism
pcg> cannot be called an OO program :-/.
larry.gearhart> I disagree.
I disagree too :-).
larry.gearhart> The essence of object-oriented programming is that it
larry.gearhart> extends the notion of abstract data types in two ways:
larry.gearhart> 1) It introduces inheritance, allowing you to create a
larry.gearhart> new class that extends the capabilities of an existing
larry.gearhart> class.
Therefore Self, and all prototype based systems, and all actor based
systems, cannot be OO :-/, for they have no classes, and some no
inheritance to speak of.
larry.gearhart> Polymorphism is simply an additional feature that adds
larry.gearhart> flexibility to inheritance.
Uhmmmm. So for example polymorphism in non "OO" languages is useless,
because there are no classes and no inheritance :-/.
larry.gearhart> 2) It enlarges the concept of abstract data type to
larry.gearhart> include classes whose resources include more than just
larry.gearhart> data,
Well, the concept of ADT as I hve read it described includes data and
operations. Perhaps, given the following paragraph, instead of writing
"more than just data" you meant "more than just computer representation
of data and operations".
larry.gearhart> but reach out into the environment beyond the computer
larry.gearhart> in a fundamental way.
This on the face of it sounds a bit like those sci-fi "virtual reality"
films/novels that have become popular lately. Perhaps you would like to
define more precisely what is the "fundamental way" and how OO can
"reach into the environment".
larry.gearhart> It is really the 2nd characteristic of object-oriented
larry.gearhart> programming which has made the greatest impact in
larry.gearhart> software architectures, whether real-time or not. The
larry.gearhart> greatest impact of the 1st characteristic has been in
larry.gearhart> code reuse, and because of that, indirectly a profound
larry.gearhart> effect on software architectures. Microsoft invented
larry.gearhart> OLE based on the 2nd characteristic, but its own
larry.gearhart> software product line is based upon reusable and
larry.gearhart> extensible classes, which is based on the 1st
larry.gearhart> characteristic.
Not much clearer: how does OLE "reach into the environment beyond the
computer", and what is the "fundamental way" it does so? As far as I can
see OLE incorporates twenty years old technology, being optimistic, and
it is just computer technology.
Paul E. Bennett
> C. T. Nadovich (ch...@kd3bj.ampr.org) wrote:
>
> : Why won't software go that way? Why won't managers eventually see the
> : advantage of OO? A manager can pay a co-op to click and drag together a
> : toaster's embedded control system in a few minutes using third-party OO
> : widgets.
>
> I can confidently buy resistors and bolts because they are
> commodity items with well-understood specifications and (in the case of
> bolts) criminal penalties for mis-specification. In the software world,
> the folks most likely to be providing the "objects" can't even get
> things like strtol() and memcmp() right, and have legions of lawyers
> making sure that if they slag down your machine the most they are liable
> for is a replacment copy of the CDROM you bought their class-library on.
> Your manager-type may _love_ to get the software process dumbed-down,
> but the head of production wants no surprises with 5K toasters DOA and
> the legal department wants no class-action suits from people injured by
> flaming toast ejected at Mach 3 when they tried to toast during the
> changeover from Standard to daylight-savings time :-)
This is, for the forseeable future going to remain the case. Whilst I am
already into re-use of code this is for code I have written on one project and
can re-use on another because it fitsthe rquirements. I also know the quality
factors of the code because the certification process I use declares that for
me.
> Just be sure your bottom line includes adequate reserves for
> returns and lawsuits.
This should always be the case. No-one is perfect yet and that is what
insurance is for.
> ................I am _not_ saying that the average assembly-hacker
> is a better programmer than the average C++ hacker, but I'm saying that
> he/she typically needs to design, rather than hack, if the project is to
> work at all.
I should hope all programmers spend some of their effort in design.
> ...........The barriers to commercial use of OO are commercial ones,
> and will require all of the following to be true before they fall:
>
> 1) a _huge_ increase in the reliability of purchased code.
>
> 2) Traceable responsibility, with legal teeth, for the mistakes that
> will still occur.
>
> 3) Standards for software objects, and a method by which a purchaser
> can verify that the purchased objects meet these standards.
These same barriers are the ones against re-use generally.
>
> Ending rant: The thing that distinguishes embedded programming
> from the rest is not size or complexity, but the potential for harm,
> either physical or fiscal :-) It shares these considerations with
> "boring" things like airline reservation systems. By assuming away
> the need for robustness, many folks free themselves to pursue really
> attractive shiny toys :-)
Consider also that a robust system (one that does not crash at the first
opportunity) is likely to last in service a very long time. This fact is on the
usually premise that if it ain't bust don't fix it. Such system will therefore
endure until there is a real change in the requirements.
Bruce R. McFarling
p...@aber.ac.uk (Piercarlo Grandi) wrote:
>But I disagree here too. For Forth, Modula-2 and Ada-83 do not make that
>relationship explicit, but only as a matter of implicit convention. OO
>languages are those language that _directly_ and _explicitly_ support
>the OO decompositionb paradigm. One can use modules as if they were
>classes, but this is just, if adopted, as implicit convention.
I wasn't setting out any claim for my own part, I was just
pointing out that the objection to the original claim was a semantic
quibble. Just because the two comments can be combined without conflict
does *not* prove that one, the other, or both are right!
Bruce R. McFarling
Bob Kitzberger
Zsoter Andras (h929...@hkuxa.hku.hk) wrote:
: Bob Kitzberger (r...@rational.com) wrote:
: > tiny 0 -- 1k lines
: > small 1k -- 10k lines
: ^^^^^^^^^^
: Are we still living in the FORTRAN age?
No doubt you object to "lines" of code metric. I agree that SLOC
is a poor metric for most uses, but for our purposes (a very rough
feel for what small/medium/large systems are) I think it is acceptable.
--
Bob Kitzberger Rational Software Corporation r...@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html
Bob Kitzberger
Lee Webber (le...@micrologic.com) wrote:
: And I thought I was an OOP partisan! To me, OOP means polymorphism
: (i.e., computed dispatch) and code/data encapsulation. And you're
: going to get more than a toy system into 2K+?? I just finished a
: 12K (code size) system, written in C and assembler, and I needed
: (literally!) every byte. Any reuse I got (and I got a lot), I
: accomplished by hand-tuning.
If you limit your view of OO to only those systems that include
computed/dynamic dispatch, then I think you are needlessly limiting
the number of embedded systems that can benefit from OO. IMHO, you
get a very large payback for merely using object-based programming
techniques, and an OO design. OO-based features such as encapsulation
and a contract-based programming model shouldn't necessarily bloat
your code nor slow your system's speed, but can bring great benefits
(the "ilities" : maintainbility, testability, etc.)
Dwight Elvey
In article <chris.8...@kd3bj.ampr.org>, ch...@kd3bj.ampr.org (C. T. Nadovich) writes:
..... much stuff .....
|>
|> Why won't software go that way? Why won't managers eventually see the
|> advantage of OO? A manager can pay a co-op to click and drag together a
|> toaster's embedded control system in a few minutes using third-party OO
|> bumming instructions or hacking FORTH, but is bumming instructions a
|> useful skill with megabit DRAMS selling for less than $2. If the toaster
|> costs $0.10 more with OO, but I can get it to market 6 months earlier, my
|> bottom line tells me what to do.
|>
|> need on staff --- not to mention one less schedule that slips because of
|> endless delays as the software is hand coded and hand debugged. Sure,
|> hand made stuff can be better than "from the rack", but one look at the
|> price tag on a custom suit and most of us head to JC Penny.
|>
I find it interesting that I saw and work with an exeample of
the "pay a co-op to click and drag together" concept once. I'll
pass on what happened. Two identical projects were started to meet
a design specification for a product. I and another at another
company started the project, not realizing that we would eventually
meet in a business sense. Anyhow, the other
company hired a sharp kid that quickly hacked to gether a preliminary
software demonstration using one of the popular OO tools. I started
my design with the klunky old procedural Forth. After 3 weeks,
we both did a quick demonstation for the customer of the basic
operations. Mine was real pretty but showed that I had a good
understnading of the problem at hand. The other fellows was impressive
from the user interface standpoint but missed the specifications
in many aspects. Neither of us realize that we were competing against
a third party. I spent the next 3 weeks polishing up the user interface
and general improvements in speed. I verified that it met the
specifications and having a good understanding of the problem,
made it so I could make quike changes to fix problems with the
customers specification ( that I knew wouldn't work as desired )
and made the next trip to the customer. We both got there only
to find that the customer had desided to go with off the shelf
product that only met their spec in a few reguards. Oh well!!
I check with the other fellow to see how he was coming along.
He hadn't proceeded much more than the original. It seemed
the many of the tools he had used didn't have the proper
modifiable properties to make them work quite as require.
He was in the process of writing classes from scratch ( with
some barrowing ) to solve the incompability problems.
What I learned from this was that:
1. Never count you're chickens before they hatch.
2. One-size-fits-all rarely fits well.
3. There is no replacement for understanding the problem.
One of the things that Forth touted as a feature years
ago was the potential for reusable code. We found that really
what was needed was reusable simple tools and not complex
tools. OO hasn't solved any of the problems that the
Forth community came up against when looking at the problems
of reusablity. When one sees things like Smalltalk and how
well things seem to be structured, one misses the fact that
Smalltalk is a language and not the application. Applications
have complexities that can't have been understood by the
language writer or the writer of the library. The more one
depends on the language to handle the complexities of the
application, the more likely the application will fail in
unexpected ways. This comes back to point number 3, understanding
the problem is you're best way to go. The biggest problem with
these kind of bugs is that they are the most costly to find.
All this isn't to say that reusability isn't important. I reuse
a lot of my code. I never reuse it blindly. Remember,
" A good engineer never redesigns the same wheel, he designs a
proper wheel."
IMHO
Dwight
David Taylor
Scott Wheeler (sco...@bmtech.demon.co.uk) wrote:
No, it isn't. Two (typical-I think) samples break down as
A B
Executable code 79% 75%
Tables (your maps?) 14% 18%
Program constants 5% 5%
Data and stack 3% 2%
Example A is production-ready and totals 366,000 bytes, while example B
totalled 412,000 bytes at two weeks into development (when these stats
were taken).
--
-- Dave
Zsoter Andras
Piercarlo Grandi (p...@aber.ac.uk) wrote:
>Therefore Self, and all prototype based systems, and all actor based
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>systems, cannot be OO :-/, for they have no classes, and some no
>inheritance to speak of.
I do not know about Self but I know about Dreams which is prototype-based.
I do not know -- however -- why it is called OOP.
I like the idea but it seems to be something else, not OOP as we know that.
There should be abother name for it.
Andras
Chris Savage
deta...@holli.com (David Taylor) wrote:
|
|The engine management systems I know of run 300K+ in size and are
|highly cost constrained--production in the millions. Is this small??
|
|--
|
|
| -- Dave
Ok so I chose a bad example out of thin air early in the morning. Now
please address the point I was making.
=================================================
Chris Savage MSc Applications Software Engineer
Sevcon Ltd. Kingsway Gateshead NE11 0QA UK
Tel: +44 191 487 8516 Fax: +44 191 482 4223
=================================================
Chris Savage
ch...@kd3bj.ampr.org (C. T. Nadovich) wrote:
|
|Even in highly cost-constrained commercial applications, HARDWARE design
|is usually OO. Often the economics of build vs. buy favor "buy",
|especially for commodity items, like resistors and bolts. Companies
|simply can't vertically integrate every technology.
|
|Why won't software go that way? Why won't managers eventually see the
|advantage of OO? A manager can pay a co-op to click and drag together a
|toaster's embedded control system in a few minutes using third-party OO
|widgets. Sure, a high priced engineer can code the same thing in less RAM,
|bumming instructions or hacking FORTH, but is bumming instructions a
|useful skill with megabit DRAMS selling for less than $2. If the toaster
|costs $0.10 more with OO, but I can get it to market 6 months earlier, my
|bottom line tells me what to do.
|
|Get rid of the software tailor. That's one less high-priced craftsman I
|need on staff --- not to mention one less schedule that slips because of
|endless delays as the software is hand coded and hand debugged. Sure,
|hand made stuff can be better than "from the rack", but one look at the
|price tag on a custom suit and most of us head to JC Penny.
|
|I know that point of view may rub some embedded SW gurus the wrong way, and
|I'm not saying it's true today, but the dumbing down of software design is
|coming at all levels IMHO. Fortunately, those high priced engineers can
|all get jobs designing objects --- although they may have to move to
|Russia or India.
|
|--
|73 de KD3BJ SK .. http://www.kd3bj.ampr.org
|+1 215 257 0635 (voice) +1 215 257 2744 (data/fax)
Your bottom line will get you in court with a personal injury suit
within six weeks of your first fork lift controller hitting the
market. By neatly avoiding the endless delays those terrible engineers
introduce your toaster will happily burn someone's kitchen down
because of something the guy two steps removed who sold you your
software widgets didn't foresee.
Please tell me what company you work for and what they make. I want to
be sure of never buying any.
Bob Kitzberger
ch...@kd3bj.ampr.org (C. T. Nadovich) wrote:
|Why won't software go that way? Why won't managers eventually see the
|advantage of OO? A manager can pay a co-op to click and drag together a
|toaster's embedded control system in a few minutes using third-party OO
|widgets. Sure, a high priced engineer can code the same thing in less RAM,
|bumming instructions or hacking FORTH, but is bumming instructions a
|useful skill with megabit DRAMS selling for less than $2. If the toaster
|costs $0.10 more with OO, but I can get it to market 6 months earlier, my
|bottom line tells me what to do.
The "widgets" of which you speak -- where can I get some? ;-)
I ask that with a bit of sarcasm; generally reusable components
are not designed for real-time applications (your high-priced
engineers would know that, but alas, you've fired them :-)
As I've worked in and around the real-time embedded market these past
12 years, I've seen it's resistance to change, and in general there is
_good reason_ for this resistance. The stakes are often very high in
embedded systems development, and jettisoning proven development
methods is high-risk. Switching from time-sliced periodic scheduling
to event-driven scheduling approaches for avionics applications (for
example) is something people take very seriously. The risks
range from the expensive (cutting a new release of enginer controller
software, burning it in PROMs, shipping it to all car service
departments, recalling the cars, etc.) to the life-critical
risks of avionics and medical applications.
Switching from assembler to C took a long time. Switching from
in-house kernels to third-party kernels is still happening at many
sites. Switching to Ada or C++ is slowly happening (admittedly the
pitfalls of C++ are still tripping up people). Switching from
structural to OO methods is slowly happening. And despite all the
hype, I would expect there to be a _long_ lag before Java is embraced,
if ever.
Are embedded systems developers missing out on not embracing OO
design and development methods? Perhaps, but they're the ones who
know what the risks and rewards are for their particular domain.
|I know that point of view may rub some embedded SW gurus the wrong way, and
|I'm not saying it's true today, but the dumbing down of software design is
|coming at all levels IMHO. Fortunately, those high priced engineers can
|all get jobs designing objects --- although they may have to move to
|Russia or India.
At one level, the software development world is dividing between
those that make frameworks, class libraries, domain-specific
architectures, etc. and those that implement real systems using
those components. This is a good thing, IMHO, and there is nothing
inherently "better" about framework designers vs. application
designers.
Even as these components start becoming available, this does not
mean that the competence level of those using the components
can decrease.
And I certainly see no evidence that framework development is
moving to India or Russia in droves.
Zsoter Andras
Bob Kitzberger (r...@rational.com) wrote:
>Zsoter Andras (h929...@hkuxa.hku.hk) wrote:
>: Bob Kitzberger (r...@rational.com) wrote:
>: > tiny 0 -- 1k lines
>: > small 1k -- 10k lines
>: ^^^^^^^^^^
>: Are we still living in the FORTRAN age?
>No doubt you object to "lines" of code metric. I agree that SLOC
>is a poor metric for most uses, but for our purposes (a very rough
>feel for what small/medium/large systems are) I think it is acceptable.
Well, so which one of the following is one LINE:
OVER + SWAP DUP *
or
OVER
+
SWAP
DUP
*
The functionality is the same!
Andras
Bob Kitzberger
: >No doubt you object to "lines" of code metric. I agree that SLOC
: >is a poor metric for most uses, but for our purposes (a very rough
: >feel for what small/medium/large systems are) I think it is acceptable.
: Well, so which one of the following is one LINE:
[...]
Can we drop this now? Every reasonably experienced developer
understands that SLOC is usually a poor metric.
Paul Long
Lawrence M. Gearhart wrote:
[snip]
> I disagree. The essence of object-oriented programming is that it
> extends the notion of abstract data types in two ways:[snip]
I agree with you that object-oriented programming is based on the ADT;
however, many people use the definition of "object-oriented" that was
established by Dr. Peter Wegner several years ago in a paper published in
the ACM's _SIGPLAN Notices_ called something like "Dimensions of
Object-Oriented Languages." He subsequently wrote a more pedestrian version
as an article for _Byte_ magazine.
In the paper and article, Dr. Wegner says that an "object-based" language
supports the unification of data and code. Examples are Ada 83 and
Modula-II. A "class-based" language allows a programmer to incorporate
common behavior (and state variables) for a _set_ of entities into a
"class." The only class-based languages are academic (e.g., CLU?). An
"object-oriented" language allows the programmer to define a new class based
on another class--inheritance. Examples are, of course, Smalltalk, C++, and
Java. In other words:
object-based = data + code
class-based = object-based + classes
object-oriented = class-based + inheritance
Since it is obvious from this thread that there is no concensus on what, in
particular, "object-oriented" means, and since not one of these definitions
is any more correct than another, how about adopting Dr. Wegner's
definitions and hierarchy? If no definition is more correct than another and
since his have a history in the literature and the industry, how about let's
all just accept his definitions and move on to something more interesting
such as what comes after OO?
BTW, although his paper and article are about programming languages, I have
found them useful for describing other things such as coding style and
development environments. For example, I have written an object-based symbol
table for a compiler, a class-based file-transfer stack over X.25, and a
real-time object-oriented performance monitor for a DS3 repeater. All were
written in C, not C++. I also published a table in _Object Magazine_ that
categorizes development environments using Dr. Wegner's terminology.
--
Paul Long mailto:pl...@perf.com Smith Micro Video Products
http://www.teleport.com/~pciwww/ http://www.smithmicro.com/
"I hate quotations." - Ralph Waldo Emerson
Bruce R. McFarling
>|design is usually OO. Often the economics of build vs. buy favor
>|"buy", especially for commodity items, like resistors and bolts.
>|Companies simply can't vertically integrate every technology.
>|Why won't software go that way? Why won't managers eventually see the
>|advantage of OO? ...
>Your bottom line will get you in court with a personal injury suit
>within six weeks of your first fork lift controller hitting the
>market. By neatly avoiding the endless delays those terrible
>engineers introduce your toaster will happily burn someone's
>kitchen down because of something the guy two steps removed
>who sold you your software widgets didn't foresee.
If there is going to be an appeal to conventional producer
commodities, it might be useful to consider their history. Firms
did not start at hand crafting each nut to fit each bolt, and jump
immediately in the next step to buying nuts and bolts as commodities.
Instead, after the stage of hand crafting fasteners came the
standardization of the production process of individual firms.
And sometimes there was a third step where firms that were skilled
in making the machinary to make standardized parts sold the
machinery. But in any event, the initial customers were using
internally standardized parts before the parts started to
become available as commodities. And in each step in the
process, the lessons of the previous stage were relied upon,
and in each stage unexpected problems arose that had to be
solved.
Is there any reason to expect this to be any different?
When firms find that there is are some standardized software
components that they have developed that can be sold without
giving away any of their core competence, and other firms find
that the reliability is as good or better as they can do on their
own, commodification of software components will proceed. But
internal standardization and breakdown into components may well
be crucial first steps toward commodity software components, since
monolithic hand crafted applications may have too much of the core
competences embedded inside to sell without selling the store.
xian the desk lisard
thus spake Zsoter Andras in comp.lang.forth...
. Piercarlo Grandi (p...@aber.ac.uk) wrote:
. >Therefore Self, and all prototype based systems, and all actor based
. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
. >systems, cannot be OO :-/, for they have no classes, and some no
. >inheritance to speak of.
. I do not know about Self but I know about Dreams which is prototype-based.
. I do not know -- however -- why it is called OOP.
. I like the idea but it seems to be something else, not OOP as we know that.
. There should be abother name for it.
it's called OOP because it's about objects, not classes. objects
don't need to belong to classes to be objects. besides, the work on
prototype-based obejct oriented systems dates back at least as far as
smalltalk.
--
xian the desk lisard -- cdah...@comp.brad.ac.uk
[ red, pink and blue, but mainly purple ribbons ]
thirty years ago how the words would flow with passion and precision
--- you had them all on your side, didn't you?
Emil P. Rojas
stop
Piercarlo Grandi
>>> On 29 Apr 1996 16:04:41 GMT, cdah...@comp.brad.ac.uk (xian the desk
>>> lisard) said:
cdahello> thus spake Zsoter Andras in comp.lang.forth...
cdahello> . Piercarlo Grandi (p...@aber.ac.uk) wrote:
pcg> Therefore Self, and all prototype based systems, and all actor based
pcg> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
pcg> systems, cannot be OO :-/, for they have no classes, and some no
pcg> inheritance to speak of.
Zsoter> I do not know about Self but I know about Dreams which is
Zsoter> prototype-based. I do not know -- however -- why it is called
Zsoter> OOP. I like the idea but it seems to be something else, not OOP
Zsoter> as we know that. There should be abother name for it.
cdahello> it's called OOP because it's about objects, not classes.
Well, actually "Object Oriented" is a terrible misnomer, for OO is
really about encapsulation of ADTs (some call, for some mysterious
reason, ADT-oriented programming as "object based"), not objects or
classes as such.
cdahello> objects don't need to belong to classes to be objects.
Rather: encapsulation of ADTs can be done in (prototype) objects as well
as in classes.
cdahello> besides, the work on prototype-based obejct oriented systems
cdahello> dates back at least as far as smalltalk.
Even worse :->, work on actor systems by Hewitt inspired directly the
design of early PARC Smalltalk (in particular Smalltalk-72), and such
inspiration is vestigial in the terminology used for Smalltalk-80, which
uses the same terms for it as for actor systems, rather inappropriately,
which has proven rather unfortunate, as a lot of people tend to take
labels ("Object Oriented", "Message Sending") rather too literally
Zsoter Andras
Bruce R. McFarling (ec...@cc.newcastle.edu.au) wrote:
> If there is going to be an appeal to conventional producer
>commodities, it might be useful to consider their history. Firms
>did not start at hand crafting each nut to fit each bolt, and jump
>immediately in the next step to buying nuts and bolts as commodities.
>Instead, after the stage of hand crafting fasteners came the
>standardization of the production process of individual firms.
^^^^^^^^^^^^^^^^^^^^^
>And sometimes there was a third step where firms that were skilled
>in making the machinary to make standardized parts sold the
>machinery. But in any event, the initial customers were using
>internally standardized parts before the parts started to
>become available as commodities. And in each step in the
>process, the lessons of the previous stage were relied upon,
>and in each stage unexpected problems arose that had to be
>solved.
> Is there any reason to expect this to be any different?
>When firms find that there is are some standardized software
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>components that they have developed that can be sold without
>giving away any of their core competence, and other firms find
>that the reliability is as good or better as they can do on their
>own, commodification of software components will proceed. But
>internal standardization and breakdown into components may well
>be crucial first steps toward commodity software components, since
>monolithic hand crafted applications may have too much of the core
>competences embedded inside to sell without selling the store.
Well, the keyword is STANDARDIZATION and the software world lacks it.
How else could such thing happen that Win95 sells miilions of copies.
Up to what standard it is? (I mean in the OS world there is such
thing as POSIX, which is definitly something else than Win95!)
As long as customers are HAPPY to buy such products you have
no choice but to hand craft.
If even your hardware is custom made (as in embedded controllers)
you really have no choice.
One day we might have the bolts and nuts of SW but first there must
be a demand for them in the market.
Today there are no relyable standard components out there. :-(
[IMHO STANDARD means that the specification is available
for anyone and the parts from different vendors are interchangable.
"X.Y. Corp's products are very relyable" have nothing to do with
standard.]
Andras
Elliott N Hughes
Zsoter Andras wrote:
>
> I do not know about Self but I know about Dreams which is prototype-based.
> I do not know -- however -- why it is called OOP.
Self's probably called object-oriented because everything's an object. In
my opinion, the prototype-based languages are *more* OO than the class-based
oddities. What is a class? It's not an object, is it?
> I like the idea but it seems to be something else, not OOP as we know that.
> There should be abother name for it.
Nah, "OOP as [you] know it" should change its name.
- enh
Matt Kennel
Elliott N Hughes (en...@minster.york.ac.uk) wrote:
: Zsoter Andras wrote:
: >
: > I do not know about Self but I know about Dreams which is prototype-based.
: > I do not know -- however -- why it is called OOP.
: Self's probably called object-oriented because everything's an object. In
: my opinion, the prototype-based languages are *more* OO than the class-based
: oddities. What is a class? It's not an object, is it?
What do you mean "every" "thing" is an object?
Is every character of program source "an object"?
Is the current "state" of the memory 'an object'? Is the current
stack and execution point 'an object'?
Stephen J Bevan
In article <4m6pq4$6...@seagoon.newcastle.edu.au> "Bruce R. McFarling" <ec...@cc.newcastle.edu.au> writes:
Paul Long <pl...@computek.net> wrote:
>... In other words:
> object-based = data + code
> class-based = object-based + classes
> object-oriented = class-based + inheritance
... The original argument that attracted my attention
to this thread was that Forth's CREATE ... DOES> provides the
'essence' of object oriented programming, and on the definitions
above, we can see that it is literally true. ...
Could you clarify what 'essence' CREATE ... DOES> provides and/or how
it relates to the three kinds Paul gives?
Bruce R. McFarling
Paul Long <pl...@computek.net> wrote:
>... In other words:
> object-based = data + code
> class-based = object-based + classes
> object-oriented = class-based + inheritance
Speaking as a layman on the topic, this is an excellent
way to get beyond semantic quibbling and look at the issue involved.
It makes it far easier to follow whether someone is disagreeing about
substance or expression of the substance.
And the most important point is this:
>BTW, although his paper and article are about programming languages,
>I have found them useful for describing other things such as coding
>style and development environments. For example, ... [examples]
>All were written in C, not C++.
Whether or not a problem can be solved efficiently using
object-oriented *programming*, and whether or not it can be solved
efficiently using a particular object-oriented *language*, or even
more specifically a particular object-oriented language implementation
are not identical questions. A language can be not-entirely object
oriented (as defined above), but still support object oriented
programming. The original argument that attracted my attention
to this thread was that Forth's CREATE ... DOES> provides the
'essence' of object oriented programming, and on the definitions
above, we can see that it is literally true. CREATE ... DOES> ...
is an object based programming construct, and object base is the
common core of the three levels of object programming. And OOP
requires more than just this base, which someone programming in
FORTH will have to provide in the normal way, by defining words
that provide these capabilities.
Zsoter Andras
Elliott N Hughes (en...@minster.york.ac.uk) wrote:
>Zsoter Andras wrote:
>>
>> I do not know about Self but I know about Dreams which is prototype-based.
>> I do not know -- however -- why it is called OOP.
>Self's probably called object-oriented because everything's an object. In
>my opinion, the prototype-based languages are *more* OO than the class-based
>oddities. What is a class? It's not an object, is it?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In my DOOF it is. ;-) (Although not EVERYTHING is an object in it.)
>Nah, "OOP as [you] know it" should change its name.
Or OOP as me, C++ -ists, Turbo Pascal programmers, etc. know it
should change its name. ;-)
Andras
Ell
Matt Kennel (m...@caffeine.engr.utk.edu) wrote:
: Elliott N Hughes (en...@minster.york.ac.uk) wrote:
::Self's probably called object-oriented because everything's an object. In
::my opinion, the prototype-based languages are *more* OO than the class-based
::oddities. What is a class? It's not an object, is it?
:
: Is every character of program source "an object"?
:
: Is the current "state" of the memory 'an object'? Is the current
: stack and execution point 'an object'?
I do not if Self considers them so, but from a larger OO perspective, yes
on all counts.
Elliott
Julian V. Noble
> >
> > > The engine management systems I know of run 300K+ in size and are
> > > highly cost constrained--production in the millions. Is this small??
> >
>
> No, it isn't. Two (typical-I think) samples break down as
>
> A B
>
> Executable code 79% 75%
> Tables (your maps?) 14% 18%
> Program constants 5% 5%
> Data and stack 3% 2%
>
> Example A is production-ready and totals 366,000 bytes, while example B
> totalled 412,000 bytes at two weeks into development (when these stats
> were taken).
>
Speaking as a theoretical physicist with a lifelong interest in
engines, I am appalled. I think there can be no excuse for 300 Kb of
executable to control an engine. There just aren't that many vari-
ables being controlled. Off the top of my head I count
Fuel intake
Air intake
Coolant flow
ignition energy
as control variables, and
RPM
Output torque (load)
Exhaust chemistry
Exhaust temp
Exhaust pressure
Combustion chamber temp
Combustion chamber pressure
as measured variables. Unless one has separate sensors for each
cylinder, one has 7 measured variables to control 4 input variables.
How complex can such an algorithm be, for heaven's sake?
Let us be generous and imagine it is a fancy 12-cylinder Jaguar engine
with individual measurements at the cylinders, and individual cylinder
controls: one still has but 29 measured and 48 input variables. So
the algorithm becomes a matrix but since one cylinder does not much
influence another, the matrix elements are strongly clumped.
If I am missing something essential and obvious, pray instruct me.
But from where I sit it looks as though the executable code could
greatly benefit from a little factoring. Maybe the system could
then get by with an 8-bit chip and 64K of memory.
Now, if the original code had been written in Forth... :-))
--
Julian V. Noble
j...@virginia.edu
Matt Kennel
Julian V. Noble (j...@faraday.clas.Virginia.EDU) wrote:
: Speaking as a theoretical physicist with a lifelong interest in
: executable to control an engine. There just aren't that many vari-
: ables being controlled. Off the top of my head I count
: Fuel intake
: Air intake
: Coolant flow
: ignition energy
ignition timing.
: as control variables, and
: RPM
: Output torque (load)
: Exhaust chemistry
: Exhaust temp
: Exhaust pressure
: Combustion chamber temp
: Combustion chamber pressure
RPM, coolant temperature, combustion area temperature, manifold absolute
pressure, O2 sensor, knock sensor, transmission gear,
: as measured variables.
Well, there's lots of smog things and all sorts of electrical things that can
go wrong. (some of those pressure things are not actually measured on
current production engines but we do measure them for research)
: Unless one has separate sensors for each
: cylinder, one has 7 measured variables to control 4 input variables.
: How complex can such an algorithm be, for heaven's sake?
: Let us be generous and imagine it is a fancy 12-cylinder Jaguar engine
: with individual measurements at the cylinders, and individual cylinder
: controls: one still has but 29 measured and 48 input variables. So
: the algorithm becomes a matrix but since one cylinder does not much
: influence another, the matrix elements are strongly clumped.
I'm another physicist just starting to get involved with engine dynamics.
I don't think the 300 kb is at all unreasonable, especially considering
the new OBD-II diagnostics being mandated by DOT for 96 models. Take
a look some time at all the 'codes' that a new sophisticated OBD-II
engine might return.
Here is an excerpt from an *OLD* car, 3.8 L Ford EEC-IV *'88 to '92*
list of error codes:
There are a total of *69* codes. A few examples:
542 "Fuel Pump secondary circuit failure"
565 "Canister purge (CANP) circuit failure"
411 "Cannot control RPM during KOER low RPM test"
219 "Spark timing defaulted to 10 degrees-SPOUT circuit open"
192 "Fuel system at lean adaptive limit at IDLE, system rich (LEFT SIDE)"
186 "Injector pulse width higher than expected"
et cetera. (No I don't know what they mean).
There is a whole lot devoted to sensor analysis
and sensor failure, and being able to record and playback all the various
'codes' upon demand. There are multiple 'modes' of operation (open loop
closed loop, warm vs. cold, light vs heavy throttle)
depending on what sensors it thinks are working
and what the engine is. There are
all the interface issues so that you can plug in a shop analyzer and tell
it do do certain things. There are sensor 'adaptation' issues: if the
sensor's voltage output drop over time is that a real drift in the physics or
just in the sensor gain?
You forgot absolute speed for controlling the electronic transmission.
Finally ABS and traction control are a whole 'nother ball of wax.
In the beginning (85 or so) yes engine controllers were pretty dumb and
small.
: If I am missing something essential and obvious, pray instruct me.
: But from where I sit it looks as though the executable code could
: greatly benefit from a little factoring. Maybe the system could
: then get by with an 8-bit chip and 64K of memory.
But most likely the engine control software needs to be reasonably "modular"
to fit various applications across the product line---it saves more money
to develop software once per major engine family and then spend a little
extra for ROM instead of doing each one from ground zero.
The economic impetus is not to minimize ROM size no matter what--that
induces but a small parts cost---but to minimize total lifecycle cost.
For that I imagine that creating more modular, more high level understandable
and low-bug-rate software is a primary goal, and getting it into minimal ROM is
not.
: --
: Julian V. Noble
: j...@virginia.edu
Bruce R. McFarling
h929...@hkuxa.hku.hk (Zsoter Andras) wrote:
>[IMHO STANDARD means that the specification is available
>for anyone and the parts from different vendors are interchangable.
>"X.Y. Corp's products are very relyable" have nothing to do with
>standard.]
This changes the wording of my account but not the argument.
'Standardization internal' to individual producers often
came before the items became available as standardized
commodities (actually standardized, as defined above) in
a market. This is important on both sides of the market:
experience producing standardized items for internal use
is important to the development of items that are suitable
to sell as commodity products; relience on internally
standardized items in production "pre-adapts" the firm
as a potential customer for buying the commodity product.
So it shouldn't surprise us if a period of
development of in-house standardized objects precedes
te emergence of a serious software commodity market.
xian the desk lisard
thus spake Zsoter Andras in comp.lang.forth...
. >Nah, "OOP as [you] know it" should change its name.
. Or OOP as me, C++ -ists, Turbo Pascal programmers, etc. know it
. should change its name. ;-)
well, considering that these languages are far from pure oop - indeed,
oo features were bolted on to them as an afterthought to increase
market share - then yes, that sounds like a fair proposition.
--
xian the desk lisard -- cdah...@comp.brad.ac.uk
[ red, pink and blue, but mainly purple ribbons ]
thirty years ago how the words would flow with passion and precision
you know soft spoken changes nothing view so cruel
Matt Kennel
There's some measure of human discipline necessary.
Managers want to "outsource" and "buy" these 'pre-fab' parts, but
the market and technology is not yet mature enough.
Now, if you want 'in-house' standardized objects there's but one way
to do it:
Hire a *PERSON* to be the ``object librarian''.
This person would ask various groups about the structure of their
particular projects and ask them if they had any class systems to donate,
if they had any particular needs, et cetera.
Then they would take these classes, make them more "generic", write test
routines, put them in standardized categores, standardized name conventions,
*HTML documentation*, write new classes that various other groups all wanted
but didn't have, and then publicize the results and maintain them.
This person could also be in charge of buying commercial, or downloading
free or academic class libraries and reviewing them.
mbk
: Virtually,
C. T. Nadovich
e...@access5.digex.net (Ell) writes:
What about the object that references all objects that don't reference
themselves?
--
73 de KD3BJ SK .. http://www.kd3bj.ampr.org/chris
Bill...@xchelsys.servelan.co.uk
Church
Alex Dean x7842
: > Example A is production-ready and totals 366,000 bytes, while example B
: > were taken).
: >
: > -- Dave
: Speaking as a theoretical physicist with a lifelong interest in
: engines, I am appalled. I think there can be no excuse for 300 Kb of
: executable to control an engine. There just aren't that many vari-
: ables being controlled. Off the top of my head I count
: How complex can such an algorithm be, for heaven's sake?
: If I am missing something essential and obvious, pray instruct me.
: Julian V. Noble
: j...@virginia.edu
Speaking as a grad student on leave in the metal-bending "real-world,"
you might want code to
- Measure component wear
- Predict sensor and actuator failures
- Handle sensor and actuator failures
- Record operating history
- Use a software engine model for use in complex control systems
Expanding the field a little bit past automotive engines, in some industries
it is well worth it to spend an extra 300 KB code to get 0.5% better fuel
efficiency. Let's see now, United Airlines flew 108,000,000,000 passenger
miles in 1994.... (thousand..., million..., BILLION. Hmmm.)
Alex Dean
Speaking for Myself, NOT
United Technologies Research Center
East Hartford, CT
Elliott N Hughes
Matt Kennel wrote:
>
> What do you mean "every" "thing" is an object?
>
> Is every character of program source "an object"?
>
> Is the current "state" of the memory 'an object'? Is the current
> stack and execution point 'an object'?
You aren't allowed to see the stack or program counter. Everything you can
see is (part of) an object. Objects are collections of slots. A slot can
be code or data. You can't necessarily tell which. You can clone or take
a reference to anything.
If you want a pretend class, you create an object with the necessary
properties and then use that as a template (ie prototype) for creating
"instances". But a prototype has exactly the same status as any other
object.
Unlike being able to "new" a class despite the fact you don't have
class variables.
My vaugeness and lack of knowledge of Self doesn't alter the fact that
prototype-based languages have no less validity than class-based ones.
- enh
(What I know of Self comes from NewtonScript, which doesn't necessary
reflect Self's true self.)
Elliott N Hughes
Zsoter Andras wrote:
>
> >Nah, "OOP as [you] know it" should change its name.
>
You might have numbers on your side, but the point was that it's
unreasonable to expect either side to change. Neither is the one
true way. Functional programming is... ;-)
- enh
David Taylor
In article <DqqJr...@murdoch.acc.Virginia.EDU>,
j...@faraday.clas.Virginia.EDU (Julian V. Noble) wrote:
> deta...@holli.com writes (in reference to engine management systems):
> >
> > No, it isn't. Two (typical-I think) samples break down as
> >
> > A B
> >
> > Executable code 79% 75%
> > Tables (your maps?) 14% 18%
> > Program constants 5% 5%
> > Data and stack 3% 2%
> >
> > Example A is production-ready and totals 366,000 bytes, while example B
> > totalled 412,000 bytes at two weeks into development (when these stats
> > were taken).
>
> Speaking as a theoretical physicist with a lifelong interest in
> engines, I am appalled. I think there can be no excuse for 300 Kb of
> executable to control an engine.
I think there are "no excuses"--there are reasons. Yes, engines can
be controlled with less code--my lawnmower and '62 Ferrari both
manage nicely with no code. Example A happens to control half a
dozen different engines on two dozen different car models. And it
controls the six different transmissions available for those cars.
Have you heard of the California Air Resources Board (CARB),
On-Board Diagnostics (OBD), or OBD II? You should have--a large
portion of the code is required to meet California or national
regulations (CARB requirements generally migrate to the national
level).
The code incorporates several communications protocols (e.g. SAE
J1850) which allow it to communicate with other systems on the car.
J1850 also allows a mechanic to plug in a tester and not only read
fault codes, but also run tests and selectively disable or exercise
certain systems.
There are 30+ systems which can set fault codes; there are 200++
different fault codes. A single oxygen sensor can set 9 different
fault codes (and there are up to 6 oxygen sensors).
This engine controller (code + hardware) is _much_ more than just a
simple replacement for a distributor and carburetor.
> There just aren't that many vari-
> ables being controlled. Off the top of my head I count
>
> Fuel intake
> Air intake
> Coolant flow
> ignition energy
>
> as control variables, and
>
> RPM
> Output torque (load)
> Exhaust chemistry
> Exhaust temp
> Exhaust pressure
> Combustion chamber temp
> Combustion chamber pressure
>
> as measured variables. Unless one has separate sensors for each
> cylinder, one has 7 measured variables to control 4 input variables.
> How complex can such an algorithm be, for heaven's sake?
Naive and very simplistic. You grossly underestimate the number of
inputs, the number of outputs, the number of controlled systems,
the number of different algorithms used, and the level of
sophistication of those algorithms.
As one example, consider fuel intake. I can think of seven
independent algorithms (at last count) which can decide to disable
one to six fuel injectors. These decisions are then combined to
decide how many fuel injectors to actually enable. Then there are
the algorithms to determine when, and for how long, to open each of
the enabled injectors. And don't forget the code which performs
diagnostics on the individual injectors.
There are 5 different air/fuel ratio modes, and 15-20 different
inputs to the code deciding just the _mode_. The inputs range from
air temp, cylinder air mass, and barometric pressure, to coolant
temp, RPM, engine run time, throttle position, and filtered speed.
Consider spark timing. There are three different and separate
sensors from which engine timing info is derived (not even one made
your list). There are separate algorithms to interpret the data
from each sensor and diagnose possible failures on an individual
basis. The data is then combined to further diagnose possible
failures. I'm sure you'd rather not walk home because we eliminated
two of the algorithms and sensors and you had a failure in the one
remaining. :-)
What else is controlled? Air conditioner, alternator, EGR, IAC (5
different modes), TCS (8 different modes), cruise control, CCR,
CCP, fuel pump, ..., supercharger, and even the fan. Inputs to the
fan algorithms range from air temp, air conditioner state, and
coolant temp, to filtered speed, overrides (remember the mechanic
running diagnostics?), and even whether it's dark or not (!!).
You mentioned torque. Torque losses due to friction have three
components: base, accessory, and air conditioning (AC). The base
torque loss depends on manifold vacuum and RPM and an oil friction
modifier which depends on oil temp and RPM. Accessory torque loss
depends on RPM. AC torque loss depends on AC pressure, RPM, and
air temperature.
There are over 300 different timed events (timing either the
duration of an event, the duration between events, or the duration
of a non-occurrence). A number of the individual algorithms have
multiple timers in use simultaneously.
Some of the different algorithms execute synchronously with the
engine in response to interrupts, some execute periodically (with
different periods for different algorithms), some execute both
synchronously and periodically, and some execute synchronously or
periodically (e.g. synchronously below a specified RPM and
periodically above it).
> Let us be generous and imagine it is a fancy 12-cylinder Jaguar
> engine with <text elided>
> If I am missing something essential and obvious, pray instruct me.
> But from where I sit it looks as though the executable code could
> greatly benefit from a little factoring. Maybe the system could
> then get by with an 8-bit chip and 64K of memory.
OK. Ummmm, _fancy_. Perhaps we should leave in the theft
deterrence code so it's still there in the parking lot when you
finish work (as a car theft victim I really do appreciate this
code!). Perhaps we should remove the code which communicates
engine speed and RPM to your radio (yes, the radio!) so the radio
can _automatically_ perform volume adjustments.
Or perhaps we should remove the code which reads the oil pressure
sensor (another notable omission from your list), or the oil level
sensor, and warns you of problems with either. Or perhaps the code
which ...
As I said at the start: This engine controller (code + hardware) is
_much_ more than just a simple replacement for a distributor and
carburetor.
-- Dave
Zsoter Andras
Just to give some hints why I am saying that OOP can be very fast here
is a brand new pointer to the html version of my FD paper about it:
http://www.forth.org/fig/oopf.html
Well, it will not be that smooth on very small microcontrollers
but I guess an old 8086 or 8088 would be enough.
(Or would they??)
Andras
Mike Guttman
In article <detaylor-030...@kok-ts0-16.holli.com>,
David Taylor <deta...@holli.com> wrote:
>In article <DqqJr...@murdoch.acc.Virginia.EDU>,
>j...@faraday.clas.Virginia.EDU (Julian V. Noble) wrote:
>
>> deta...@holli.com writes (in reference to engine management systems):
>> > totalled 412,000 bytes at two weeks into development (when these stats
>> > were taken).
>>
>> Speaking as a theoretical physicist with a lifelong interest in
>> engines, I am appalled. I think there can be no excuse for 300 Kb of
>> executable to control an engine.
>
>I think there are "no excuses"--there are reasons.
[several reasons omitted]
>> as measured variables. Unless one has separate sensors for each
>> cylinder, one has 7 measured variables to control 4 input variables.
>> How complex can such an algorithm be, for heaven's sake?
>
>Naive and very simplistic. You grossly underestimate the number of
>inputs, the number of outputs, the number of controlled systems,
>the number of different algorithms used, and the level of
>sophistication of those algorithms.
>...
[several more reasons omitted]
>> Let us be generous and imagine it is a fancy 12-cylinder Jaguar
>> engine with <text elided>
>> If I am missing something essential and obvious, pray instruct me.
>> But from where I sit it looks as though the executable code could
>> greatly benefit from a little factoring. Maybe the system could
>> then get by with an 8-bit chip and 64K of memory.
>
>OK. Ummmm, _fancy_.
>...
[even more reasons omitted]
>As I said at the start: This engine controller (code + hardware) is
>_much_ more than just a simple replacement for a distributor and
>carburetor.
A beautiful example of idealism vs. real world!! Theory of operation
vs. consumer product. Of course, in this case, the theorist
apparently needed to add a few variables.
Seems that, for autos, memory cost isn't your biggest problem, and
being able to use the same PROMs for several different model
variations, modes, operating environments, testing, etc. is *very*
important. Sounds like an interesting (and maybe nerve-wracking)
project to work on.
I used to work at a company developing bio-lab intrumentation, writing
embedded code for several different seemingly simple devices (some
physically small, some large). We always ran into the same thing that
you just explained so well. The support of interchangeable parts, new
(but similar) models, modes of operation and compatiblity with older
equipment can mean several algorithms and/or tables to do the same
thing. Thorough in-house, or out-house :-) diagnostics/testing
(including communication of the results and remote adjustment of
operating parameters) sometimes require more code than your most
complicated control algorithm!
Let's not even consider dreaded feature creep...
Speaking of which, why don't you add another PROM with a verbal chess
program, and project the chess board up on the windshield! Just don't
program it to lock up the steering or send exhaust into the cabin if
you beat it. :-)
- Mike
--
Mike Guttman
mgut...@mri.jhu.edu
Jonah Thomas
>I don't think the 300 kb is at all unreasonable, especially considering
>the new OBD-II diagnostics being mandated by DOT for 96 models. Take
>a look some time at all the 'codes' that a new sophisticated OBD-II
>engine might return.
Well, that explains it. The government mandates an interface, it could take
300K just for that.
>Here is an excerpt from an *OLD* car, 3.8 L Ford EEC-IV *'88 to '92*
>list of error codes:
>There are a total of *69* codes. A few examples:
>542 "Fuel Pump secondary circuit failure"
>565 "Canister purge (CANP) circuit failure"
>411 "Cannot control RPM during KOER low RPM test"
>219 "Spark timing defaulted to 10 degrees-SPOUT circuit open"
>192 "Fuel system at lean adaptive limit at IDLE, system rich (LEFT SIDE)"
>186 "Injector pulse width higher than expected"
>et cetera. (No I don't know what they mean).
Sounds like a complex interface problem. It might be possible to make the
whole thing simpler. You have a lot of error codes with random numbers assigned
to them. Presumably when you find an error you return the code, and a giant
error-control module takes the code and decides what to do with it. I'm not
sure this is the best way to divide up the problem. But then, I'm not sure I'd
come up with something much better -- I just want to think so. And one possible
advantage of this approach is that it breaks up the *human understanding* into
small modules. The guy who thinks about how to detect a fuel pump secondary
circuit failure can completely ignore the question of what to do about it, and
know that his work will hook up with that of the guy who works on the response.
And anything that goes wrong gets assigned a standard error code, and if you
don't know what it means then you immediately _know_ that you don't know what it
means. There's an art to designing a system that can be built and maintained by
people who each focus on his own little part, with nobody having to understand
the whole thing. If a system built that way even sort-of _works_ it's an
achievement, whether it takes 300K or not.
>: If I am missing something essential and obvious, pray instruct me.
>: But from where I sit it looks as though the executable code could
>: greatly benefit from a little factoring. Maybe the system could
>: then get by with an 8-bit chip and 64K of memory.
>But most likely the engine control software needs to be reasonably "modular"
>to fit various applications across the product line---it saves more money
>to develop software once per major engine family and then spend a little
>extra for ROM instead of doing each one from ground zero.
Yes, particularly the money saved for diagnostics guys. If each one is a
variation on a theme, then you can figure that you mostly understand them all
when you understand one. Then the trick is to avoid the designs that make
something peculiar happen. You'd better make sure that each engine opens its
SPOUT circuit under the same circumstances, or some engines will develop new,
weird errors that people haven't seen before. Engines that vary from the norm
will be hard to diagnose and fix, and they'll get a reputation for being buggy
-- even when they're a big improvement. If each set of software was optimised
for its engine the designs would be _able_ to vary more widely, which would lead
to new expense in itself.
>The economic impetus is not to minimize ROM size no matter what--that
>induces but a small parts cost---but to minimize total lifecycle cost.
Yes. So the best thing is to make only small variations on engines that require
hardly any tweaking of the software. Ideally you'd arrange it so you never have
to modify the software at all, but that's a hard ideal to reach.
>For that I imagine that creating more modular, more high level understandable
>and low-bug-rate software is a primary goal, and getting it into minimal ROM is
>not.
Yes. And if it does have bugs, it may be better to document them than to fix
them -- less expensive to deal with a consistent problem than with multiple
versions.
Which reminds me of something Dennis Ruffer said, "...I don't think we're in
Kansas anymore."
Timothy Jordan
In article <detaylor-030...@kok-ts0-16.holli.com>, deta...@holli.com (David Taylor) writes:
Lots of wonderful stuff on the current stat of automobile engine controllers
that I thank him for, and didn't need to repeat.
I've lost track of the attribution for the following out of that ( I know it wasn't David):
>> Let us be generous and imagine it is a fancy 12-cylinder Jaguar
>> engine with <text elided>
>> If I am missing something essential and obvious, pray instruct me.
>> But from where I sit it looks as though the executable code could
>> greatly benefit from a little factoring. Maybe the system could
>> then get by with an 8-bit chip and 64K of memory.
>
This is showing some lack of domain knowldege just in the controls realm. I worked on
gas turbine engine controllers in the late 70's. Then, a 16 bit processor and 8K of memory
was just barely enough to run a Pratt & Whitney JT-9D. And that was only three major
control loops. There's no way 8 bits will give you enough accuracy.
Tim Jordan
Once in controls
Now a CAE jock
Matt Kennel
Jonah Thomas (JETh...@ix.netcom.com) wrote:
: Yes. So the best thing is to make only small variations on engines that require
: hardly any tweaking of the software. Ideally you'd arrange it so you never have
: to modify the software at all, but that's a hard ideal to reach.
Now that's a real theoretician for you. ;-)
"Sorry, I know your transmission and axle and suspension is for
rear wheel drive, but we standardized on front wheel drive engine software,
so that's why your car doesn't go."
: >For that I imagine that creating more modular, more high level understandable
: >and low-bug-rate software is a primary goal, and getting it into minimal ROM is
: >not.
: Yes. And if it does have bugs, it may be better to document them than to fix
: them -- less expensive to deal with a consistent problem than with multiple
: versions.
A `bug' might mean gazillions of dollars of warranty repairs and ticked
off people yelling "I'm getting a Toyota, none of this freaking detroit
garbage!"
A bug might mean a federal recall and lawsuits.
Some bugs
: Which reminds me of something Dennis Ruffer said, "...I don't think we're in
: Kansas anymore."
xian the desk lisard
thus spake Timothy Jordan in comp.lang.forth...
. In article <detaylor-030...@kok-ts0-16.holli.com>, deta...@holli.com (David Taylor) writes:
. This is showing some lack of domain knowldege just in the controls
. realm. I worked on gas turbine engine controllers in the late 70's.
. Then, a 16 bit processor and 8K of memory was just barely enough to run
. a Pratt & Whitney JT-9D. And that was only three major control loops.
. There's no way 8 bits will give you enough accuracy.
was the limiting factor size (of ram) or speed (of processor)? as i
recall, the 16 bit processors available in the late 70s weren't
exactly speed demons, and it's possible that a modern 8 bit
microcontroller, even having to do higher precision maths in multiple
operations, might outpace it.
of course, if you were using a bare mini board, things might have been
a little different |:>
--
xian the desk lisard -- cdah...@comp.brad.ac.uk
[ red, pink and blue, but mainly purple ribbons ]
we both know it was a girl back in bethlehem