dharris@entec.Wichita.NCR.COM (Dale Harris) (05/02/89)
I am looking for honest educated opinions based upon practical
experience regarding the applicability of Object-Oriented
Programming in the areas of operating system and peripheral
controller (subsystem) development. It seems that OOP is another
esoteric concept which some folks (non-programmers in particular)
regard as the panacea for all programming. We programmer-types
know better than to jump onto any passing bandwagon without
investigating it first :-).
I realize that OOP has its place in applications programming.
What I don't know about is the appropriateness of OOP in systems
and controller (firmware) work. The issues I and countless
others are concerned about are:
1. Does OOP work below the application, particularly in real-
time general-purpose operating systems and in event-driven
peripheral controllers?
2. Can OOP be effectively integrated at those levels into
existing non-OOP architectures?
3. How well can the concepts of OOP be applied without actually
implementing in one of the OOLanguages such as Objective C,
C++ or Eiffel?
4. How severely is performance impacted in using OOP? (For
controllers, performance on low-cost processors is more
important than elegance. Can we have both?)
5. Is dynamic configuration (runtime binding) practical in
systems and subsystems developed under C++ without
recompilation? (It is not practical to distribute compilers
in subsystems if new objects are added.)
6. Is there any available literature dealing with OOP in other
than application programming?
--
Dale Harris Software Engineering, NCR E&M Wichita
NCR:654-8025 <Dale.Harris@Wichita.NCR.COM>
(316)636-8025 <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!dale.harris>
<{ucsd,pyramid,nosc.ARPA}!ncr-sd!ncrwic!dale.harris>stoppani@hpcupt1.HP.COM (Peter Stoppani) (05/04/89)
>I am looking for honest educated opinions based upon practical >experience regarding the applicability of Object-Oriented >Programming in the areas of operating system and peripheral >controller (subsystem) development. It seems that OOP is another >esoteric concept which some folks (non-programmers in particular) >regard as the panacea for all programming. We programmer-types >know better than to jump onto any passing bandwagon without >investigating it first :-). > >I realize that OOP has its place in applications programming. >What I don't know about is the appropriateness of OOP in systems >and controller (firmware) work. The issues I and countless >others are concerned about are: > >1. Does OOP work below the application, particularly in real- > time general-purpose operating systems and in event-driven > peripheral controllers? Sure. In fact, operating system by nature tend to posses many OOP properties (ie- message passing, dynamic binding of managers). However, most current operating system designs also have several important OOP concepts missing from their architecture (ie- support for a class structure and inheritance). What OOP contributes to systems programming is a formalized way of designing and implement system modules. *AND*, if you are able to use an OOP language then you don't have to implement alot of the framework to support classes, dynamic binding and message passing in the OS! In other words, if you use an OOP language you'll get a 'more pure' implementation; if you implement everything yourself then you'll get a 'hybrid' implementation which may or may not contain all of the OOP concepts. There are already several examples of OOP technology in system code: X/Windows, OS/2 Presentation Manager, the Hydra OS (I think that's the right name?!) and I am sure that you'll be seeing most new code for UN*X in C++. Also, Apple's Mac OS and HP's MPE XL OS use OOP technology heavily. Some people might argue whether or not any or all of these are good examples of OOP, but I think the point is that they all utilize several important features of OOP the best way that they can. > >2. Can OOP be effectively integrated at those levels into > existing non-OOP architectures? Yes. Just as you can intermix C modules with C++ (and other OOP languages) classes, you can design the parts of the OS that benefit the most from OOP techniques. > >3. How well can the concepts of OOP be applied without actually > implementing in one of the OOLanguages such as Objective C, > C++ or Eiffel? It is very doable. The important thing to do is to come up with a good architectural framework and ensure that all components adhere to it. The drawback of not using an OOP language is that you have implement ways of maintaining class hierachies, dynamic binding and message passing (and more...) in the OS. This is not terribly difficult but it is the sort of thing you would rather have the compiler take care of. > >4. How severely is performance impacted in using OOP? (For > controllers, performance on low-cost processors is more > important than elegance. Can we have both?) This depends a lot on the language your using. But in general there does not need to be a performance penalty (in fact, it is possible to get better performance from object-oriented design than from a traditional design due to better modularity and shorter code paths; especially if you have to handle several types of an object -- like device managers). > >5. Is dynamic configuration (runtime binding) practical in > systems and subsystems developed under C++ without > recompilation? (It is not practical to distribute compilers > in subsystems if new objects are added.) > >6. Is there any available literature dealing with OOP in other > than application programming? Yes. Look into the ACM SIGOP Newletters, there have been articles on the subject in the past (I believe that there is an applicable article in the current issue). I'm not sure, but I think Hydra is the name of a heavily object- oriented operating system for which you should be able to find articles in technical journals. The Journal of OOP and IEEE Software are also good sources. > > >-- >Dale Harris Software Engineering, NCR E&M Wichita > NCR:654-8025 <Dale.Harris@Wichita.NCR.COM> >(316)636-8025 <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!dale.harris> > <{ucsd,pyramid,nosc.ARPA}!ncr-sd!ncrwic!dale.harris> >----------
jans@tekgvs.LABS.TEK.COM (Jan Steinman) (05/06/89)
<<I am looking for honest educated opinions based upon practical experience regarding the applicability of Object-Oriented Programming in the areas of operating system and peripheral controller (subsystem) development... Does OOP work below the application, particularly in real-time general-purpose operating systems and in event-driven peripheral controllers? >> <Sure... There are already several examples of OOP technology in system code: (examples deleted)> On the Xerox Dorado, all those things were done in Smalltalk (with the exception of some really basic primitives, which were microcoded). I routinely use Smalltalk for event-driven peripheral control in the sub-millisecond arena without resorting to primitives -- it keeps up with a 9600 baud serial port in the background without noticeable slowing of the user interface. Because it has a "just" scheduler, it is ideally suited for *modeling* real-time systems, although significant primitive support is needed to approach latency in the tens of nanoseconds. It is particularly handy to rapidly whip a device driver up in Smalltalk, debug and refine the algorighms, then translate into C or C++. :::::: Jan Steinman - N7JDB Electronic Systems Laboratory :::::: :::::: jans@tekgvs.LABS.TEK.COM Box 500, MS 50-370 (w)503/627-5881 :::::: :::::: jsteinma@caip.RUTGERS.EDU Beaverton, OR 97077 (h)503/657-7703 ::::::