Object-BasedComputing and the AdaProgramming Language

G. D. Buzzard and T. N. MudgeUniversity of Michigan

Developments in several areas ofcomputer science and engineer-

ing have coalesced during the pastseveral years into a systems designmethodology known as object-basedcomputing. The primary benefit ofthis methodology is that it raises thelevel of abstraction available in the de-sign process. Among the events thathave encouraged the development ofobject-based computing are:

(1) advances in programming lan-guage design, such as program decom-position criteria and abstraction mech-anisms;

(2) advances in operating systemsdesign, particularly those which ad-dress data integrity and programsecurity; and

(3) advances in computer architec-ture that allow direct hardware sup-port for many operating system andlanguage concepts.

Object-based computing is charac-terized by the extensive use of abstrac-tion. Resources such as data, logical orphysical devices, and, in some systems,program segments, may be represen-ted by abstract types. Instances ofabstract types form the objects inobject-based computing. These ob-jects are manipulated exclusively byoperations that are encapsulated in aprotective environment commonlyreferred to as a type manager or pro-tection domain.

This work was supported in part by the Air Force Officeof Scientific Research under contract F4962O-82-C-09and a Kodak Fellowship.

The first step in an object-baseddesign philosophy is the identificationof appropriate objects. The secondstep is the determination of operationson those objects. For example, con-sider a part-sorting system. The ob-jects in such a system may include acamera, a robot, a frame (describingposition), a set of parts, and bins toreceive the parts. For robot objects,the set of available operations may in-clude:

* INITIALIZE-ARM(robotid)* MOVE(robotid, frame)* OPEN(robotid)* CLOSE(robotid)* GET_FRAME(robotid)

Each operation takes as a parameterrobotid, which uniquely identifies in-dividual instances of the type robot,allowing a number of different robotsto be used in the system. All instancesof the same type share some commonbehavioral characteristics-in thiscase, the set of operations that is ap-plicable to all robots.Much of the growing interest in

object-based computing is attributableto the Department of Defense's com-mitment to the Ada language project.Although Ada (DoD's proposed stan-dard system implementation languagefor embedded systems) may not fit alldefinitions of an object-based lan-guage, it does incorporate key con-cepts. We will explain several conceptsthat are central to object-based com-puting and the extent to which they aresupported by the Ada programminglanguage. As part of the discussion,examples are given that have been

0018-9162/85/0300-ODIISOI.00 © 1985 IEEE 11March 1985

drasn fi-om our use of Ada in pro-e,ramminen a robot-based manufactur-inc cell.

Object-based computing coInceptsapply to both hardware and softwaresvstenms. In softws are sy.stems, the termobject-based describes software en-vironnments that incorporate the con-cepts of data abstraction,3 progranmabstraction), and protection domains.Objects are represented as indisiduallyaddressable entities that uniquely iden-tit, their ossn contents as wsell as theoperationis that may be performed onthemlc. In the case ot the robot objecttype, users have the ability to addressspecific robot objects individually andto manipulate their contents in a pro-tectednmannier thi-ouglh operatioins,ssuch as MOVE, that are explicitlycde-fined for Lise oIn robot objects. Usersneed Inot be conicerined with sucth de-tails as object represenitationi.

There are two rmajor goals in devel-oping object-based softsvare. The firstis to redueethe total life-cycle sottwarecost bv increasing programnmer pro-ductPisits and reducinig maintenaneccosts. The second goal is to implementsoftsare svstems that resist both ac-cildenital anid mnalicious corruption at-temapts. Protectioni domains, wnich aredescribed in the next section, are usedto achieve the latter goal. As sill beshown, support for both of these goalsis provided bv the Ada language.

Reductions of total life-cycle soft-ware costs in Ada are aided by the ab-straction imiechaniismiis provided in thelanguage. The high level of abstractionthat can be attained helps to increaseprogrammnCerFproductivity by permit-ting the constructioni of generalized,reu.sable soft are units such as therobot controllci described earlier.Also, once the interfaces of the ab-stractions are defined, program devel-opmaenit ftor t he implemenitation ofeach abstraction cani proceed in-dcependently and in parallel, since theinmplementation details remain hidden(abstracted) from the view of the restof the svstem. Abstraction aids soft-ware nmainitainability as well, by coIn-taiming the efftect ot all changes, exceptthose involving the intertaces, withinthc mllodLelc hOuSitln the abstractionl.

In hardware, the term object-basedrefers to the architectural support pro-Aided for the abstractions mentionedabove. An essential goal in the devel-opment of such systems is to providean efficient execution environment forthe software systern. Among the com-mercially available computer systemsthat provide support for object-basedcomputing are the IBM System/38, 6the Intel iAPX 432,7 and the Plessy

The Ada language providesconstructs to support both dataand program abstraction, as well

as protection domains.

PP250.8 Many of the ideas incor-porated in the commercial systemswere based on the results of severalunisersity projects (a good history ofthis sork is given in Levy9). The mostrecent of these projects include Cm* "'C.mmp,'' and CAP.'2 A commonthread running through all of thesemachiines is the use of capability ad-dressing techniques to implement se-cure protection domains, which cantheni be appropriately structured toprovide data, program, and device ab-stractions.

Object-oriented machines are par-ticularly well suited to applicationsthat have stringent requirements fordata securitv and program integrity ina dynamic environment. The high de-gree of abstraction provided by thesemachines also facilitates the intercon-nectioni of several processors intotightly coupled mnultiprocessor systemsand/or distributed networks. For ex-ample, through the use of process/processor abstraction, Intel hasachieved software-transparent multi-processing in their iAPX 432 system.As a further example, Cm* combinesboth tightly coupled multiprocessingand distributed networking conceptsin one system.As might be expected, the advan-

tages of an object-oriented architec-

ture are not achieved without cost.

Present systems rely on some form ofcapability addressing. In current im-plementations, these addressing mech-anisms greatly increase the addressgeneration and translation times, evenwhen translation "look-aside" andcaching schemes are employed. Themanipulation of capabilities is also ex-pensive. For example, to copy a capa-bility requires 10 memory referenceson Cm*, 13 and between two and 12,depending on the addressing modeused, on the iAPX 432.The Ada language was specifically

designed not to require an object-oriented architecture. Virtually all ofthe support for object-based com-

puting in Ada is static. For example,the type checking required by the Adalanguage specification may be per-formed at compile time. Hence, muchof the burden for providing error de-tection and security is placed on theprogram development system. Whilethis arrangement allows Ada to betargeted for existing "conventional"machines, it also places some restric-tions on the flexibility of the language.

Concepts in object-basedcomputing

As noted earlier, abstraction plays acentral role in object-based comput-ing. The Ada language provides con-structs to support both data and pro-gram abstraction, as well as protectiondomains. Of the two forms of abstrac-tion, data abstraction is the most wide-ly used and understood.

Data abstraction. This term refersto a programming style in which in-stances of abstract data types aremanipulated by operations that are ex-clusively encapsulated within the pro-tective environment of protection do-mains. In a definition borrowed fromShaw, 3 an abstract type is defined as aprogram unit characterized by thefollowing visibility properties:

* Visible outside of the module con-taining the type definition: thename of the type and the namesand semantic specifications of all

COM PUTER1 2

visible operations (procedures andfunctions) that are permitted touse the representation of the type.Some languages (e.g., Ada) alsoinclude formal specifications ofthe values that variables of thistype may assume, and of theproperties of these operations.

* Not visible outside ofthe modulecontaining the type definition: therepresentation of the type in termsof built-in data types or other de-fined types, the bodies of the visi-ble routines, and hidden routinesthat may be called only from with-in the module.

The constructs for implementingabstract data types in Ada are "pack-ages" and "private" (hidden) types. 14The Ada package effectively places awall around a group of declarationsand permits access only to thosedeclarations that are intended to bevisible. Packages actually come in twoparts, the specification and the body.The package specification formallyspecifies the abstract data type and itsinterface to the outside world, alongwith other information that may benecessary to enforce type consistencyacross compilation boundaries (Adasupports the notion of programs thatcomprise several separate compilationunits). The body of the package con-tains the hidden implementationdetails.

Consider, for example, the Adapackage ROBOT, whose specificationis shown in Figure 1. This package canbe used to abstract (hide) the im-plementation details of the typeROBOT-ARM, which has a physicaldevice (a robot arm) associated with it.The operations available for manipu-lating this device, and even its ex-istence, will be hidden by the abstrac-tion (during program development,the physical robot arm may be repre-sented by simulation code). Thus theapplications programmer is freed fromhaving to consider anything other thangenerating the code necessary to con-trol the actions of an abstract device-the robot arm. Furthermore, the com-plete logical description of thisabstract device is provided by the

package specification, which isdelimited by "package ROBOT is"and "end ROBOT;". (Ada reservedwords are shown in bold, while user-defined and predefined packagenames, procedure names, functionnames, types, and variables are shownin upper case.)The types defined in the package

specification are as follows:

* ROBOT_ARM-the abstracteddata type;

* ARM-MODEL-an enumerationtype listing all of the robot armmodels recognized by this system(two common robot models areshown, ASEA and PUMA); and

* FRAME-a 4 x 4 matrix thatrepresents a homogeneous trans-formation. It represents the posi-tion and orientation of the handof the robot arm by indicating thematrix necessary to transform thecoordinate system of the base ofthe arm to the coordinate systemin the hand.

The procedures are as follows:* INITIALIZE_ARM-initializesan instance of the type RO-BOT_ARM and moves the arm toa known starting position. Theoutput of the procedure is of typeROBOT-ARM, and the input isof type ARMvMODEL.

* MOVE-takes as input a RO-BOT_ARM and a FRAME andmoves the arm and its hand to theposition and orientation cor-responding to the transformationgiven by FRAME. The updatedarm is output, and its "hidden"state is changed to reflect its newposition and orientation.

* OPEN and CLOSE control thearm's gripper;

* GET-FRAME is a function thatprovides controlled access to thehidden state, returning a value oftype FRAME.

As noted earlier, the abstracted datatype is ROBOT_ARM. It is the intentof the package ROBOT that this typebe known only through the subpro-grams (procedures and functions)mentioned above and declared in the

F-igure 1. bpecitication tor the pack-age ROBOT.

visible part of the package specifica-tion. The visible or public part of thepackage specification extends up to thereserved word "private." Hiddenfrom public view within the packagebody are all of the other procedures,functions, and data structures that arenecessary to effect movement of thephysical robot arm and to update itsrepresentative data structure.The fact that the type RO-

BOT_ARM is declared to be "limitedprivate," and that its definition isgiven in the private part ofthe packagespecification, means that while sub-programs in packages external toROBOT may possess an object of thetype ROBOT-ARM, they cannot useit in any way other than as a parameterto pass to one ofthe routines defined inthe visible part ofthe ROBOT packagespecification. Even tests for equalitybetween two objects of type RO-BOT_ARM are not allowed outside ofthe ROBOT package. Hence, possibil-ities for programming errors thatdirectly affect the ROBOT-ARM arerestricted to the domain defined by thepackage ROBOT. Moreover, sinceassignments to limited private typesare also not allowed outside of theirdefining domain, the possibility ofhaving inconsistent representations forthe same robot arm (e.g., the logicaldata structure not reflecting the correctlocation of the physical robot) iseliminated.

March 1985 13

In order to use the ROBOT pack-age, the user program must first createinstances of the necessary types in itsdeclarative part, as follows:

ASEA: ROBOT.ROBOT_ARM;ARM: ROBOT.ARM_MODEL

:= RBT;TRANS: ROBOT.FRAME;

Notice the use of explicit qualification("ROBOT.") to name the definingdomain for the types ROBOT-ARM,ARM-MODEL, and FRAME. Thisterminology informs the compilerthat, for instance, the variable RBT isto be of type ROBOT-ARM, which isdefined in the package ROBOT.

In the user program, subprogramsfrom the ROBOT package to initializeand move a robot may be invoked asfollows:

ROBOT.INITIALIZE_ARM(RBT, ARM);* -- compute a value for TRANS,* -- the homogeneous transform* -- describing* -- the movement required.

ROBOT.MOVE(RBT, TRANS);

The first parameter for both of theprocedure calls, RBT, provides thelogical representation of the robot thatis to be manipulated. The secondparameter of INITIALIZE-ARMspecifies that RBT be the logicalrepresentation ofan ASEA robot. Theonly way that any operations on thedata structure RBT may be performedis by passing it as a parameter to a sub-program that appears in the visiblepart of the package ROBOT. Eventhough the user program has full ac-cess to the type FRAME, which is acomponent (not shown) of the limitedprivate type ROBOT-ARM, it stillmay not directly manipulate theFRAME component of ROBOT_ARM. That is, external packages areprevented from directly manipulatingcomponents of hidden record types(private or limited private), regardlessof the visibility of the components'types. The data structures, excludingthose that are explicitly declaredprivate or limited private, along withthe procedures and functions that ap-pear in the public part of the packagespecification, are directly available for

Figure 2. Logical view of data abstrac-tion.

use by packages external to ROBOT.Figure 2 provides a logical concep-tualization of how the package RO-BOT is used to move an instance of anASEA robot. The same "black box"package can also be used to move anyother valid instance of ROBOT_ARM.Through the use of packages and

private types, the Ada language pro-vides easy-to-use constructs to supportdata abstraction. As we have seen,data abstraction is a powerful tool forboth program development and errorconfinement. However, it is not theonly form of abstraction provided bythe Ada language. Program abstrac-tion provides a different and, in somesenses, a more powerful conceptualview.

Program abstraction. Programsand subprograms provide anothercommon level of abstraction. Pro-gram abstraction enables operationson implicit objects. In addition tohiding the representation of and accessto an object, the object's existence isalso hidden. The result is a more com-

plete form of hiding and, usually, amore concise interface than dataabstraction.Program abstraction in Ada is

realized through generic package orsubprogram instantiation. Ada allowsthe declaration of generic programunits that serve as templates for pack-ages or subprograms from which ac-tual pakcages or subprograms can beobtained. Generic program units mayhave actual parameters that provideinstantiation-specific details of thetemplate. These parameters can bedata objects, types, or subprograms.Thus, the parameter associationsallow generic units to do the following:directly manipulate data objects pro-vided by the user; create and managedata structures or logical devices cor-responding to an arbitrary type sup-plied by the user; and use abstract,instantiation-dependent subprogramsmade available by the user.

Through their types, the formalparameters specify the expectationsthat the generic unit makes about theactual parameters that will be suppliedby the user ofthe generic unit at instan-tiation time. For example, a genericpackage that manages stacks mighthave a formal data object parameterof type POSITIVE that indicates themaximum size of the stack. This for-mal parameter will be matched by anyactual parameter whose value at in-stantiation time is an integer greaterthan or equal to one. The same genericpackage may also have a formal typeparameter of type private that allowsthe user to specify the type of elementsthat are to be handled by the instantia-tion of the stack package. This formalparameter will be matched by any ac-tual parameter for which, at least, the(in)equality tests and assignment aredefined; these are the only operationsallowed on data objects whose typesare private.

Generic formal subprogram param-eters, when used, allow the user to pro-vide-or select from a library- sub-programs for use within the genericunit. In the case of a generic terminalhandler, for instance, subprogramparameters for SEND and RECEIVE

COMPUTER14

procedures would free the program-mer from having to accommodate thediffering communication protocolsthat exist for various terminal types.Matching rules for generic formal sub-program parameters are similar tothose for nongeneric subprogramparameters. In effect, the generic for-mal parameters provide a written"contract" between the writer of thegeneric template and the writer of anyprogram that is designed to use thistemplate. The terms of this contractare rigidly enforced by the type-checking facilities present in the com-piler.

Generic units allow a higher level ofabstraction than data abstraction, be-cause the abstracted data type may becompletely hidden within an instanceof the generic package body. The hid-den data structure is accessed throughinternal package variables that arenonlocal to the subprograms withinthe package. Manipulation of the datastructure occurs as a controlled side ef-fect-strictly contained within thepackage body-of the requested oper-ation. Thus generic units support aprogramming style in which the speci-fied (visible) operations either directlyor indirectly transform a hidden inter-nal state that depends only on pastoperations applied to the initial state ofthe system.

The ROBOT package example isrepeated in Figure 3 using programabstraction techniques. The externalpackages are no longer required tosupply the type ROBOT-ARM foreach operation that they invoke on thearm. Instead, the packages specify theelement of the enumeration typeARM-MODEL that corresponds tothe arm that they wish to use when theyinstantiate the generic packageROBOT (the generic package extendsfrom the keyword generic to endROBOT;). The generic template isfilled in based on the value of thegeneric formal parameter ARM at thetime of instantiation. Hence, thestatements:

package RBT_.ASEA Is new ROBOT(ASEA);package RBT_PUMA Is new ROBOT(PUMA);

would create instances of the packageROBOT specifically for an ASEArobot and a PUMA robot, respective-ly. A new instance of the packagewould be created for each robot in thetarget system. Recall that in dataabstraction, only one instance of thepackage existed. The logical view of asystem consisting of one ASEA robotand one PUMA robot is illustrated inFigure 4.

Implementations for both programand data abstraction require that cer-tain procedure bodies contain condi-tionally executed code segments to ac-count for the differences between the

type ARM-MODEL is (ASEA, PUMA,

.

genericARM: ARM-MODEL;

package ROBOT istype FRAME is array (1 .4, 1. .4) of FLOAT;procedure MOVE (DESTINATION: in FRAME);procedure OPEN;procedure CLOSE;function GET-FRAME return FRAME;

end ROBOT;

Figure 3. Specification for the genericpackage ROBOT.

numbers of links and the type ofjointsused in the different robots, and toallow individual robots to communi-cate with their respective device driv-ers. An alternative solution availablein program abstraction is to add sub-program parameters to the formal partof the generic package. The actual sub-programs, which could be madeavailable to the applications pro-grammer in the form of a library,would provide the necessary abstrac-tions for manipulating their corre-

sponding devices. The user would thenselect the appropriate set of actualparameters for each specific genericinstantiation.The biggest difference between data

and program abstraction lies in theprogram unit that possesses the in-stance of the abstracted data type. Indata abstraction, the type is possessedby a program unit that is external tothe unit that manages the type; hence,the unit that manages the type is com-monly referred to as an external typemanager. In program abstraction, thetype is maintained within the unit thatmanages it; hence, the managing unitis commonly referred to as an internaltype manager. External type managers

Figure 4. Logical view of program abstraction.

March 1985 15

support a functional programmingstyle in which the type to be manip-ulated is passed as a parameter to asubprogram that performs its opera-tion without side effects.The chief advantage of this pro-

gramming style is that it can be mod-eled more readily using well-knownmathematical techniques, thus open-ing up greater possiblilities for cor-rectness proof methods. In Ada, it isalso the case that data objects createdat run-time by the dynamic instantia-tion of types can be handled by exter-nal type managers, whereas the instan-tiation of internal type managers andthe creation of their enclosed data ob-jects is static-that is, it must occur atcompile time. It can be argued, how-ever, that internal type managers pro-vide a much more realistic model ofthe real-world objects that the com-puter program is meant to manipulate,and that the protection against errorsboth at run-time and during programdevelopment is much greater. Non-generic packages may also function asinternal type managers. However, indoing so, generality is lost, since theabstraction would be available foronly one instance.

Intel has provided a powerful exten-tion to the Ada language for the iAPX432 processor that allows the program-ming of dynamic internal type man-agers. This has been accomplished byallowing packages to be types, andhence, allowing them to assume as-signable values. For example, we coulddefine a package type ROBOT (Figure5), create instances of ROBOT foreach different physical robot (Figure6), declare an array whose elements areinstances of the package type ROBOT,and then, during program execution,assign values (package bodies) to thearray elements depending upon whichrobots we use (see Figure 7). The pro-cedures and functions that operate onROBOTS are invoked in the mannershown in the last line of Figure 7.

In Smalltalk, a language that takesthe object-based programming phil-osophy further than Ada, the conceptsof data and program abstraction havebeen rationalized so that objects are alltreated alike, regardless of whether the

objects represent program modules ordata structures. 15 It has been proposedthat these concepts be merged togetherin Ada as well.416 In fact, Intel hasalready taken an initial step in thisdirection with their "package type"extension to the Ada language men-tioned above.'7 Extensions such aspackage types and those described inWegner4 and Jessop16 combine thedynamic flexibility of data abstractionwith the conceptual and protectionbenefits of program abstraction, re-sulting in a powerful universal abstrac-tion mechanism. The availability ofsuch a mechanism relieves the softwaredesigner of the restrictive choice be-tween adopting a program-oriented ordata-oriented software design method-ology-a choice that must occur veryearly in the design process.

Protection domains. Protection do-mains, and the inherent security thatthey provide, constitute another keyconcept. The basis for secure, error-tolerant execution environments lies inthe principle of system closure. 5 Thisprinciple states that the effects of alloperations on a closed system shall re-

Figure 5. A package type.

Figure 6. Instances of packagetypes.

main strictly within that system. Onecommon construct used for providingsystem closure is the protection do-main. 18 Briefly stated, a protectiondomain is an environment or contextthat defines the set of access rights andoperations that are currently availableto a specific user for objects containedwithin the domain. The concepts em-bodied in protection domains are sim-ilar to those underlying Ada packages.

Protection domain schemes gener-ally provide facilities for error confine-ment, error detection and categoriza-tion, reconfiguration, and restarting.Error confinement and security strat-egies generally involve both processisolation and resource control. Thebasic premise of process isolation isthat processes are given only thecapabilities necessary to complete theirrequired tasks. By implication, any in-teractions with external objects (e.g.,sending messages to other processes)must be strictly formalized and con-trolled. Resource control refers to thebinding of physical resource units tocomputational objects. Examples in-clude the binding of processes to pro-cessors, or the assignment of memoryto currently executing contexts.

These controls ensure that when theresource units are released or preemp-ted, all of the information containedwithin the unit is returned to a nullstate. Information is thus preventedfrom "leaking" out of a protectiondomain, even if it is left in an area thateventually becomes accessible to otherusers. Error confinement also aids theprogram debugging process, sincebugs will be located in modules whereerrors are detected. Program mainte-nance benefits as well, since the protec-tion domain defines the maximal set ofmodules that can be affected by modi-fying the system. Error detection andcategorization involves dynamicchecking for object type inconsisten-cies and access constraint violationsduring procedure execution. Thecategorization of detected errors canthen be used to aid in restoring thesystem to a known state. Reconfigura-tion facilities attempt to restore thesystem to an operable state by remov-ing the failed component-hardware

COMPUTER16

or software. If the reconfiguration at-tempt is successful, the system isrestarted.

Perhaps the most elegant mechan-ism for implementing protection do-mains is capability addressing. Whilemuch can be done at compile time inlanguages such as Ada to enforce theconcept of protection domains, there

Figure 7. Assignment of packagetype.

are many cases where the dynamic en-forcement of access rights provided bycapability addressing is useful. As anexample, consider a system in which itis desirable to grant different rights(perhaps the ability to invoke a dif-ferent set of operations) to the varioususers of a given object based on infor-mation presented at run-time. Capa-bility addressing permits users todynamically determine whether theyhave indeed been granted the right toperform a requested operation. Deter-minations such as this are not possibleat compile time. Compile-time protec-tion enforcement also lacks the abilityto support the detection of andrecovery from access failures in therun-time system.A capability can be thought of as the

name of an object. An object cannotbe accessed-nor its existence de-termined-unless its name is known.The capability also contains the accessrights to the object (e.g., read, write,or capability copy rights; see Figure 8).The only subsequent modificationallowed outside of the domain inwhich the capability is defined is therestriction of these rights. Capabilitiesare created along with their respective

objects. The initial control of thecapability, and hence of the object,belongs solely to the defining domain.Consider the case of a user-packageUSER in Figure 8-that selects thepackage ROBOT of Figure I in asystem employing capability address-ing. The defining domain for avariable of type ROBOT-ARM isROBOT. In the case of pass-by-reference parameter association, therights of the capability given to the in-stantiating context are restricted to"copy" because ROBOT-ARM is alimited private type. Within the defin-ing domain, the capabilities may beamplified as needed. For example, avariable of type ROBOT ARM ispassed as a parameter to both theMOVE and GET_ FRAME pro-cedures. In the case of MOVE,ROBOT-ARM is a parameter ofmode in out, requiring both read andwrite rights. In case ofGET-FRAME,ROBOT-ARM is an in parameter,and thus requires only read rights.The use of capabilities is not depen-

dent on the particular method of para-meter association used. Rather, in thecase of paramaters passed by refer-ence, the capability is amplified at the

Figure 8. Capabilities and protection domains.

March 1985 17

to a o%

atuIII

%P i11 '1

tilc f

II tI,'cc It

l-H it

IK,t I

AdapoideVIS good SuIpport for-Lbothida ta and pr ogranm abStrac-

c H w(ncr,e iii an et t'ort to alloswVida tI) he used Cifticienltis onl e\istinitlI.I.Ihinc s it h cons entionaI arch'itec

Cs, c latic,uia(c has bheen desieinedU equlire ittle dvinamic chcck'Iniii - C'ect j1 nMOSt noticeable In thechttfco. uipjorl proVsCdCCl tor protecCmm denta'in andc the lack of a nnlified

"I0.~t Ia10ac1miatchanisnn that Wsould in-H2IL e1 fcettac,_e uch as packace t\ypes.

I )\15 lhcsc featUres are LISuiallv

inot requilred iin the applicaition area fors,hich A\da vvas primarily targeted-emibedded svstcrms. Currenit embeddedse stemis typically have mianyv static at-tributets: configurations are not miodi-tied at runlltime; program implemien-tations are niot changed; anid decvicesare not taken on-i and off line. Henice,wsithin its intenided applicati'on areca,the Ada lanouace is suitable for objecct-based computine on consventional ar-ch'IteCCttureS.

otciOIL

L ~Is It- Ptc

IHIH4,I'

References

It Ills~ptehil..n r' I.

Ha ,~~~~~~~~"O Ij

Ile'ts ha, II- Cl t lIa It

ii l cel to III co Li

hit 1 2;K pplt.be

Nia hx cnl thle cdeote( Hi(T

1I I I2 14I1

11I t l i

It 'I *~~~~~~~~~~I0 1

-I4 .1. .1poT-

k.. A~`ol. anid T. N. MIudge, "Ro-tot. are (Nothing N1ore Than) Ab-~tact Data Lvpes,"Proc. SWE Con-crieon Robotic-s Research, A\ug.

Hi Vol/ f' N. MuILdee, and D. A.I mew \da as ai Prograrmming

1I [tHaICt tot1 RZoboi based \Manufac-itvn C: IIJEEF Tr-ans. Siste;ns,11i11116 ClhetneiiwS, Nos It)ec.

11)54 ( t a'pp(2ar).N ha's "The Imipact of Abstrac

ion C oncerius on NModuilar Program-Ii11L L_acumta!ces,"'Pr-oc. IELL, Vol.

6 H, N,I.I9, Sept. 1980, pp. 11 19 1130.I.ll "c,On the Unif'icationi of'

Dta ati ne Proc_rarni Abstractioi ]In.eiL,''IOtl letoalIACvISi'inp. Prt`

/(s o 1 PI-o(,-/IIIIia?ltlf?1 Lan puag,es,In 983. pp 26 -264.

J. I)enn itt,H Fault Toter anit Oper-itI'tsent Colnputing SurreCys,1. N . 4, Dec. 1976, pp. 359 389.

IPX! Svs cot 8 Functional Conceptshiinl,c G 521 9330 1, IBMJ CotLIATIIo hctcr, Nut11 198

7. 11 PX 432 Genieral Data Proc-es sor-Ar-clitecture Ref. M4anual, Resv. 3,1t1860 003, Intel Corporation, SantaClara, Calif., 1983.

8. D. NI. Englanid, "Capability ConceptMechanism anid Structure- in Svstemn250," hIt'! Workshop oni ProtectionIet Operating SystemS, IRIA, Roc-qtuencouirt. Aug. 1974, pp. 63-82.

9. H. Nil. LesV, CapabilitlY-based Cotinp/)eterS.vsteins, Digital Pr-ess, Bedford,INlass., 1983.

10. R. J1. Swsan, S. H. Fuller-, and D. P.Sieswiotek, "Cm*: A NModular Niulti-

/1ic prcssor," AFIPS Contj. Proc.Ndlo. 46, 1977/, NCC, pp. 637-643.

11. Ws A. Wvulf aindC. G. Bell, "C.mmp-A Multi-Mini-Processor," AFIPS

Conif. Proc., Vol. 41, Part II, FJCC1972, pp. 765-777.

12. R. H. Needham and R. D. H. Wlvalker-,"The CAP computer and its protec-tion system,' A CM Si'xth Svinp.Oper-ating System Principles, 1977.

COMPUTER

-

t-I

II

mI

13. A. K. Jones and E. F. Gehringer, eds.,"The cm* Multiprocessor Project: AResearch Review," Carnegie-MellonUniversity Report CMU-CS-80-131,Department of Computer Science,July 1980.

14. J. G. P. Barnes, Programming inAda, 2nd ed., Addison-Wesley, Lon-don, 1984.

15. A. Goldberg and D. Robson, Small-talk-80: The Language and its Im-plementation, Addison-Wesley,Reading, Mass., 1983.

16. W. H. Jessop, "Ada Packages andDistributed Systems, "Sigplan No-tices, Vol. 17, No. 2, Feb. 1982, pp.28-36.

17. Reference Manual for the Intel 432Extensions to Ada,172283-001, IntelCorporation, Santa Clara, Calif.,1981.

18. T. A. Linden, "Operating SystemStructures to Support Security andReliable Software," Comp. Surveys,Vol. 8, No. 4, Dec. 1976, pp. 409-445.

Gregory D. Buzzard received the BS andMS degrees in electrical engineering fromthe University of Michigan, Ann Arbor, in1981 and 1982, respectively. He is currentlypursuing the PhD in electrical engineeringin the area of architectural support for inter-task communication in distributed systems.

Buzzard is a Kodak Fellow and a mem-ber of the University's Robotics ResearchLaboratory. He is also a member of EtaKappa Nu, Tau Beta Pi, ACM and theIEEE Computer Society.

Trevor Mudge received the BSc degree incybernetics from the University ofReading,England, in 1969, and the MS and PhDdegrees in computer science from the Uni-versity of Illinois, Urbana, in 1973 and1977, respectively. He has been with theDepartment of Electrical Engineering andComputer Science at the University ofMichigan since 1977 and currently holds therank of associate professor. His research in-terests include computer architecture, pro-gramming languages, VLSI design, andcomputer vision.

Questions concerning this article can be addressed to the authors at the Center for Roboticsand Integrated Manufacturing, University of Michigan, 2514 E. Engineering Bldg., AnnArbor, MI 48109.

March 1985 19