North-Holland Microprocessing and Mlcroprogramming 30 (1990) 457-466 457

D e s i g n i n g a P a r a l l e l O b j e c t - O r i e n t e d C o m p i l e r T a r g e t L a n g u a g e ( T O O L )

A. T. Balou & A. N. Refenes D e p a r t m e n t o f C o m p u t e r S c i e n c e

U n i v e r s i t y C o l l e g e L o n d o n

G o w e r S t r ee t L o n d o n W C 1 6 B T A B S T R A C T

As the level of interface between software and hardware is continuously shifting, the requirement for standard points of reference becomes increasingly important. TOOL is an intermediate-level parallel language aspiring to meet this requirement by establishing a common target for compilation of a wide range of high-level object-oriented languages and also, of process-oriented languages. TOOL exhibits the major object-oriented features, including data abstraction, multiple inheritance and dynamic binding. In addition, parallelism, although inherent in the computational model, is further supported by providing: (a) asynchronous message passing and synchronization mechanisms, 0a) support for "autonomous" objects (ie. permanently active), and (c) special facilities for object allocation and migration.

1. I N T R O D U C T I O N

O v e r the past f ew years the objec t -or iented p a r a d i g m has gained increasing popular i ty within the comput ing communi ty . Mos t o f the efforts have been put towards the des ign o f h igh- leve l l anguages and sof tware env i ronments . Impor tan t examples include Smal l ta lk-80 [6], C + + [11], as wel l as Or ient84 [13], P O O L [3], F lavors [8], Actors [1] etc. Arguab ly , the trend is that objects will supersede processes as the ma jo r m e c h a n i s m for structuring p rograms , especia l ly paral lel p rog rams , in the near future. In this respect portability o f object- or iented languages is an issue o f increasing impor tance .

Objec t -or ien ted compi l e r target languages , br idging the gap be tween high level languages and architectures, s eem to const i tute a useful tool to increase the avai labi l i ty o f objec t -or iented and procedura l languages , espec ia l ly on future paral lel computers . B y prov id ing a c o m m o n target for compi la t ion they bring the benefi ts o f portability to a wide range o f t-ILLs.

In order to check whe ther T O O L is suitable as a m o r e genera l in termedia te step in the t ranslat ion o f other h igh- leve l languages onto paral lel c o m p u t e r architectures, we

imp lemen ted a p ro to type compi l e r kit f r o m a process or iented language (PARLE) [9] onto an ear ly vers ion o f T O O L and then onto a Transpute r system. The top level compi l e r a imed to demons t ra te h o w to t rans form high- level process-or ien ted languages to low- leve l objec t -or iented languages. This invo lved a change o f mode l and a change o f level at the same time. It has been argued that the complex i ty o f address ing both p rob l ems at the same t ime is ve ry h igh [5]. W e demons t ra ted that it is poss ib le to define and imp lemen t s imple but power fu l t ransformat ion techniques which are adequate and which p rese rve the static m a p p i n g o f logical p rocessors in the process- or iented mode l to phys ica l p rocessors in the object or iented m o d e l and still not exploi t near ly as m u c h as all the express ive p o w e r in the object or iented m o d e l The code genera tor for these t ransformat ions is i tself ve ry s imple and is 2 7 K o f C p rogram.

In this pape r we discuss the des ign issues arising in the p rocedure o f creat ing a c o m m o n parallel , objec t -or iented target language. The des ign requi rements include: (1) abil i ty to support a wide range o f object- or iented languages (2) explici t representa t ion f o r paral lel ism, and (3) static and dynamic al locat ion o f objects on the nodes o f a paral lel

458 AT. Balou, AN. Refenes / TOOL

processor. The paper is organised as follows: Section 2 outlines the principles leading to the l anguage ' s design. Section 3 highlights the basic design choices fo l lowed b y an informal presentat ion o f the language. The features o f the language which raise the degree o f exploitable parallelism are examined in Section 4. In Section 5, we discuss the t ransformation of process-oriented languages into the object-oriented m o d e l Related work is presented and compared with T O O L in Section 6. Finally, the conclusions are presented in Section 7.

2. D E S I G N P H I L O S O P H Y

The design of T O O L reflects a basic t rade-off dictated by the conflicting requirements for an intermediate language: on one hand, there is the requirement to be sufficiently low-level to allow the mapping of a wide spectrum of HLLs; and on the other hand, there is the antagonistic requirement to be o f adequately high-level to be portable to a wide range o f architectures. In this respect, T O O L stands in the middle ground, not commit t ing to a specific I-ILL or architecture.

Two main approaches can be anticipated: one is to define a small vocabulary o f primitive functions f rom which the more complex ones could be synthesized. This approach usually leads to simple but s low implementat ions. The other, is to define a larger set o f higher level functions, corresponding to all possible features o f languages to be supported. The resulting implementat ions are more complex but faster. The dividing line cannot be clearly drawn as the design decisions involve a variety o f often conflicting criteria such as the level o f abstraction, efficiency considerations, enabling technologies etc.

T O O L ' s design has been guided by the fol lowing principles:

(a) Features c o m m o n to the set o f I-ILLs under consideration, or in terms of which more complex ones can be expressed, have been identified and incorporated directly in the language. For example, the existence o f objects, as

encapsulated entities, is a c o m m o n characteristic among object oriented languages and therefore, constitute the basic T O O L units.

(b) For controversial features, one o f the fol lowing approaches has been fol lowed: (i) the introduction o f simple and flexible concepts, f rom which higher level ones can be synthesized. In this respect, classes in TOOL, exist only conceptual ly and not as special objects; (ii) the .generalisation o f a mechanism, so that possible variations can be expressed as different subcases o f the same basic one. Message passing constitutes such a general mechanism, consistent both in its syntax and semantics.

Finally, at every step, the intention was to ensure clarity and consis tency o f the introduced language features with the computat ional model .

3. T A R G E T O B J E C T - O R I E N T E D L A N G U A G E ( T O O L )

3 . 1 E x e c u t i o n m o d e l - G e n e r a l C o n c e p t s

The central concept in an Object Oriented p rogramming system is the grouping of a set o f data items and the relevant operations into a single entity called an object. Execut ion o f a T O O L program is described in terms of interactions between objects, which take place through message passing.

Objects are entities o f a dynamic nature. They can be created and deleted dynamical ly, while their data structure can be modified as a result o f message processing. T O O L objects can be servers or au tonomous entities. Server objects axe active only when answering messages, whereas au tonomous objects have an independent activity expressed by a body. The existence o f the body converts the object into an active entity with selective capabilities as to which message(s) it will accept.

Objects consist o f instance variables, methods and (optionally) a body, while, during

A.T. Balou, A.N. Refenes / TOOL 459

execut ion, messages are dynamica l ly routed be tween them.

" i n s t a n c e v a r i a b l e s "

represent the internal data o f an object (and part o f its state). A u t o n o m o u s objects p rov ide the p r o g r a m m e r / c o m p i l e r with the capabi l i ty for explici t select ion and sequencing o f mes sage execut ion, whilst server objects delegate this task to the run- t ime system.

" m e t h o d s "

represent the computa t iona l capabil i t ies o f the objec t and f o r m its interface to the other objects. T h e y have direct access to the internal state o f the object and are responsible for its modif icat ion.

" e n v i r o n m e n t "

mainta ins the execu t ion state o f the object and is crea ted upon m es s age generat ion. The env i ronmen t contains pa ramete r s and other in format ion about the object o f origin. The run- t ime sys t em associa tes the env i ronmen t with the addressed object and a process is started with the initial execut ion state conta ined in the envi ronment .

" m e s s a g e s "

are the only means o f interact ion be tween objects . T h e y are used to p rov ide an execu t ion state to the addressed objects by associa t ing them with their envi ronment . Then a p rocess can be started. Messages are executed a t o m i c a l l y without interruption. N e w messages c a n n o t b e processed by the same instance while execut ing. They can on ly be p roces sed by idle objects , by suspended objec ts or i f expl ic i t ly s e l e c t e d . A n

idle object can execute any message , whereas a suspended one, can only process a m es s age match ing one o f its specif ied pa t t ems .

A c o m m o n approach in object or iented sys tems is that objects are of ten grouped into c l a s s e s , so that subclasses can i n h e r i t

methods and behav iou r f r o m their paren t class(es). Inher i tance can be defined as a hierarchical incrementa l modif ica t ion mechan i sm, that a l lows objects to be defined

in te rms o f other objects . E c o n o m y in code is the immedia te benefi t o f such factorizat ion. The impor tance o f inheri tance however , lies ma in ly in its role as an organiz ing factor for t axonomizh tg and grouping objects into hierarchies reflecting their interrelations. The concept o f inheri tance is c lose ly related to classes. Drawing the analogy, it can be argued that as classes organize objects wi th s imilar propert ies , inheri tance hierarchy organizes classes with re levant behav iour [14].

T O O L itself is a low- leve l (assembly- l ike) , paral lel language, in which the mos t pr imi t ive e lements are the objects. Objec ts represent un i fo rmly all p rog ram entities. Hence c l a s s e s

a n d i n s t a n c e s are represented b y objects and the character izat ion o f each enti ty is def ined by the role p layed at p r o g r a m execut ion. Dist inct ion be tween these two is a run- t ime characterist ic. The adopted scheme for classif ication and code-shar ing is mul t ip le inheri tance while p o l y m o r p h i s m is suppor ted by dynamic binding. This set o f s imple and flexible pr inciples enable T O O L to m a p languages exhibi t ing divers i ty o f bo th features and level.

3.2 T O O L O V E R V I E W

A T O O L virtual compu te r sys t em consists o f three pr imi t ive objects: a m e m o r y object , an a l u object, and a c o n t r o l object. Each pr imi t ive object, in accordance with the general object mode l , is a g rouping o f data and pr imi t ive methods (see Tab le 3.1). The three pr imi t ive objects , conceptual ly , interact by exchanging messages , which, in reali ty consti tute the T O O L instruction set. A message has the fo l lowing format:

ob jec t .method a rg l ... a rgn

The first field specifies the dest inat ion object, the second specifies the target me thod to be executed and the remain ing fields are a rguments for the me thod (eg. a l u . a d d a c l

a c 2 ) . At any t ime dur ing execut ion, each object has access to the env i ronment that contains the or iginal a c t i v a t i o n message which carries the pa ramete r s (denoted by $)

460 AT. Balou, AN. Refenes / TOOL

P R I M I T I V E O B J E C T S I N S T A N C E P R I M I T I V E D E S C R I P T I O N V A R I A B L E S M E T H O D S

memory cells store store into a memory cell load load from a memory cell instance allocate memory for instance method allocate memory for methods

alu accumulators add, sub the usual ari thmetic mul, div. etc and logic operat ions

control program br branch - change PC counter brf branch on false

brt branch on true ret return

root object computer select select message system new create object

delete delete object b ind b ind to node

T a b l e 3.1 Pr imit ive Objects with their instance variables and pr imit ive methods. Pr imit ive objects interact by exchanging messages. All programs in TOOL are built f rom message interactions between the pr imit ive and user-defined objects.

to the ob j ec t . I n the c a s e o f a reply m e s s a g e the r e su l t s a re s t o r e d in the a lu r e g i s t e r s 01:

02: ( d e n o t e d b y %) , w h e r e t h e y c a n be a c c e s s e d .

03:

T h e m e s s a g e f o r m a t is u n i f o r m w h e t h e r i t 04: a d d r e s s e s p r i m i t i v e o r u s e r - d e f i n e d ob j ec t s . 05:

06: U s e r - d e f i n e d m e t h o d s , b y a n a l o g y to 07: p r i m i t i v e m e t h o d s , e x p r e s s the c o m p u t a t i o n a l 08: c a p a b i l i t i e s o f u s e r - d e f i n e d o b j e c t s . T h e y c a n 09: b e f o r m e d as c o l l e c t i o n s o f p r i m i t i v e a n d 10:

u s e r - d e f i n e d m e s s a g e s , c o m b i n e d b y the u se ) o f s o - c a l l e d m e s s a g e c o n s t r u c t o r s . T h e r e a re t w o p r i m i t i v e m e s s a g e c o n s t r u c t o r s :

C O N S T - FORMAT DESCRIPTION RUCT ; ml;m2 send ml---->wait-->send m2 & ml&m2 send ml---->skip---~send m2

T h e i n t e r a c t i o n b e t w e e n o b j e c t s a n d the u s e o f m e s s a g e - p a s s i n g is i l l u s t r a t e d w i t h the e x a m p l e o f the b o u n d e d - b u f f e r in f igu re 3.1. A b u f f e r has a n i n s t a n c e v a r i a b l e to s to re i ts e lements a n d t w o fu r t he r i n s t a n c e v a r i a b l e s to p o i n t at i t s f r o n t and back e l e m e n t s . T h e s e i n s t a n c e v a r i a b l e s a re a c c e s s e d a n d m o d i f i e d b y the m e t h o d s apnd and rm.

T h e i n t e r a c t i o n o f the p r o d u c e r a n d c o n s u m e r o b j e c t s w i t h the b u f f e r o b j e c t is c o n t r o l l e d b y the B O D Y o f the buf fe r . I f the b u f f e r is fu l l , the b o d y w i l l s e l ec t o n l y the remove m e s s a g e s : ~

buffer:: BODY( .SUB back 10; .BRF %1 07; .SUB 1 front; .BRF %1 09; .select apnd rm; .BR 01; .select rm; .BR 03; .select apnd; .BR 01;

w h i l e true do _check i f buffer full _select "rm" message _check buffer empty _goto 09 _else select either _repeat loop _only "rm" messages r e p e a t loop _only "apnd" message _repeat loop

M e a n w h i l e , the apnd m e s s a g e s a re b l o c k e d ( l ine 07) . C o n v e r s e l y , i f the b u f f e r is empty o n l y apnd m e s s a g e s are s e l e c t e d ( l ine 09) . I f the b u f f e r has at l e a s t o n e e l e m e n t , b u t is n o t fu l l , t hen e i t h e r o f the m e s s a g e t y p e c a n be s e l e c t e d n o n - d e t e r m i n i s t i c a l l y , bu t n o t b o t h at the s a m e t i m e ( l ine 05) .

4. P A R A L L E L I S M

C o n c u r r e n t e x e c u t i o n o f o b j e c t s is i n h e r e n t in the o b j e c t o r i e n t e d m o d e l , s u g g e s t i n g a h i g h p o t e n t i a l fo r p a r a l l e l i s m . M o s t o f the e x i s t i n g o b j e c t o r i e n t e d s y s t e m s d e f i n e the o b j e c t s as un i t s o f c o n c u r r e n c y a n d t he r e fo r e , c a n c r e a t e o n l y o b j e c t - g r a i n e d p a r a l l e l i s m . T h e i d e a l g r a n u l a r i t y is a p p l i c a t i o n d e p e n d e n t ; in o u r m o d e l the g r a n u l a r i t y is p r o g r a m m a b l e , r a n g i n g f r o m c o a r s e ( o b j e c t - w i d e ) to f ine- g r a i n e d .

A.T. Balou, A.N. Refenes / TOOL 461

BUFFER:

I I ' ° ' " ' = [

buffer ( elem..instance 10; front.instance 1;

buffer::apnd ( ] back.instance 1; elem[back].STORE %1;]~. apnd.method;

ADD 1 back; rm.method; .back.STORE %1; )

CONSUMER:

buffer::rra( ADD I front;

_ front.STORE %1; " [I) .PET dem[front];

Figure 3.1 Interaction between the objects buffer, producer and consumer by exchanging messages. Here, the producer continuously appends items to the buffer, while the consumer removes them sequentially. In practice, there will be more than one instances of producer/consumer objects.

Parallelism is highly supported in the fol lowing ways:

In te r Ob jec t concurrency: Accord ing to the object-oriented model many active objects coexist, executing in parallel. TOOL, as already explained, supports two types o f objects: servers (ie. passive objects) and au tonomous objects. Servers, are activated only by requests o f clients, whereas au tonomous objects, are characterized by an independent activity expressed by a body. A special instruction, namely select , is used to denote their selective capabilities, which takes as arguments one or more method names. The presence of au tonomous objects, obviously, increases the degree o f inter-object concurrency.

l n t ra O b j e c t concur rency : Concurrency within the objects (cf. dynamic process creation) is realised in T O O L by supporting non-blocking message sends, in which case sender and receiver can proceed in parallel. The granularity o f the intra- object concur rency is thus p rogrammable and can be as fine as one message. In this way, the message passing mechanism can contribute substantially to the increase o f exploitable concurrency in a system. In

addition, it constitutes the basic synchron i za t ion mechanism. Au tonomous objects, however , override this mechanism by synchronizing by means of the se lec t instruction.

D y n a m i c ob jec t m a n a g e m e n t : As object- oriented systems are more likely than not, to run in mult i -processor environments, objects are expected to move between processors during run-time. One good reason for this, is to achieve the highest degree o f parallelism by adjusting dynamical ly the load on the nodes. On the other hand, locality o f communica t ion is an important counter-factor. In this respect, object migrat ion takes place on the basis of a dynamic procedure, which serves the purpose o f optimising efficiency/cost by compromis ing two conflicting criteria: balancing of load between nodes and minimizat ion o f inter node communicat ion. The realisation o f this procedure is assisted by T O O L by means of a directive and a method, namely: b ind and rebind. T h e directive b ind is used to indicate the node to which the object or method will be initially allocated (static mapping). The role o f the method rebind,

462 A.T. Balou, A.N. Refenes / TOOL

proc producer (out):

def { seed: 999 }

{produce 0----~ res:

res := seed + l; }

yea do true I out? := produce() od

corp

% process and channel definition

% local variable definition

% local procedure definition

% procedure result

% end of local definitions

% proc body definition

F i g u r e 5.2 A producer process in P A R L E - consists of a local variable (seed), a local procedure (produce), and a body. Local variables are much the same as in Occam, and local procedures can be thought of as macro expansions to primit ive processes (cf. Occam).

on the o t h e r hand , is to m o v e ob jec t s b e t w e e n

n o d e s at r u n - t i m e , w i t h i n the f r a m e w o r k o f

a d y n a m i c l o a d - b a l a n c i n g s t r a t egy

( d y n a m i c m a p p i n g ) .

5. T R A N S F O R M I N G P R O C E S S -

O R I E N T E D T O O B J E C T - O R I E N T E D

C O N S T R U C T S

In o r d e r to assess the su i t ab i l i t y o f T O O L as a

t r a n s f o r m a t i o n s tep in the c o m p i l a t i o n o f n o n

o b j e c t - o r i e n t e d sy s t ems , w e wro t e a c o m p i l e r

b a c k - e n d to t r a n s f o r m the p r o c e s s - o r i e n t e d

l a n g u a g e P A R L E in to T O O L . T h e m a i n

cons t ruc t s o f P A R L E are t yp i ca l o f p r o c e s s -

o r i e n t e d l a n g u a g e s and they fal l into t w o

g roups : p r o c e s s c o n t r o l and s y n c h r o n i s a t i o n

con t ro l .

5.1 P r o c e s s c o n t r o l

In p r inc ip l e , a p r o c e s s - o r i e n t e d p r o g r a m is a

c o l l e c t i o n o f p r o c e s s e s that ope ra t e

c o n c u r r e n t l y and c o m m u n i c a t e by m e s s a g e

p a s s i n g v i a channe l s . A l l p r o g r a m s are bui l t

f r o m a r e s t r i c t ed n u m b e r o f p r i m i t i v e

p r o c e s s e s . In P A R L E there are f o u r p r i m i t i v e

p r o c e s s e s (see f igure 5.1).

PROCESS D E S C R I P T I O N

(c? := e ) output e to c

(v := c?) input from c and assign to v.

(o? := i?) receive from i and send to o.

(v := e ) assign e to v;

T h e s e p r i m i t i v e p r o c e s s e s m a y be c o m b i n e d

us ing s o - c a l l e d p r o c e s s cons t ruc to r s to f o r m

o the r p r o c e s s e s . C o n s t r u c t o r s are de f ined fo r

s equen t i a l C), pa ra l l e l (11), and c o n d i t i o n a l

(if-fi) e x e c u t i o n . B e s i d e s the p r i m i t i v e

p r o c e s s e s s u p p o r t e d d i r ec t l y by the sys t em,

the users can def ine the i r o w n p a r a m e t e r i s e d

p r o c e s s e s u s ing c o n v e n t i o n a l p r o c e d u r a l

abs t r ac t ion t e c h n i q u e s . It is p o s s i b l e to g r o u p

t o g e t h e r m a n y p r i m i t i v e o r u s e r - d e f i n e d

p r o c e s s e s and m a p t h e m o n t o a s ing le

p r o c e s s i n g e l e m e n t by us ing the proc-corp c o n s t r u c t o r (cf. O c c a m ' s p l a c e d par). A user-

de f i ned p r o c e s s cons i s t s o f a n u m b e r o f loca l

v a r i a b l e s to ho ld its in te rna l state, a n u m b e r

o f c h a n n e l s to c o n n e c t it to o t h e r p r o c e s s e s in

the sys t em, and a n u m b e r o f l oca l p r o c e d u r e s

(see f igure 5.2).

P r o c e s s e s start e x e c u t i o n a s y n c h r o n o u s l y as

s o o n as they are l o a d e d on to the sys tem. N o t

w i t h s t a n d i n g the m e t h o d o f i n t e rp roce s s

c o m m u n i c a t i o n , there is a d i rec t

t r a n s f o r m a t i o n b e t w e e n a p r o c e s s in P A R L E

(or in O c c a m ) and an ob j ec t in T O O L . L o c a l

v a r i a b l e s are m a p p e d o n t o i n s t ance va r i ab l e s ,

procedures are m a p p e d o n t o m e t h o d s , and

loca l p r o c e s s e s (i.e. s i m u l a t e d p a r a l l e l i s m in

O c c a m ) are m a p p e d on to a s y n c h r o n o u s

m e s s a g e p a s s i n g to self. F i g u r e 5.3 s h o w s the

p r o d u c e r p roce s s in P A R L E and the

c o r r e s p o n d i n g T O O L m a p p i n g . In the latter,

the p r o c e s s has b e e n t r a n s f o r m e d in to the

o b j e c t producer, w h i c h con t a in s an ins t ance

v a r i a b l e i.e. seed, and a m e t h o d i.e. produce. T h e p r o d u c e r o b j e c t a l so a has a b o d y

A.T. Balou, A.N. Refenes / TOOL 463

F i g u r e 5.3 Process to Object Translat ion - the producer process maps onto an autonomous object , with instance variables corresponding to local, methods corresponding to local procedures, and bodies corresponding to bodies.

c o r r e s p o n d i n g to the b o d y o f the o r i g i n a l P A R L E p r o c e s s .

T h e f irst l ine in the b o d y spec i f i e s that the o b j e c t i n h e r i t s a l l p r o p e r t i e s o f s o m e _global o b j e c t (i.e. a l i b r a r y o b j e c t fo r p r o v i d i n g run - t i m e s u p p o r t e .g. as m e s s a g e t h r o u g h rou t ing , a l l o c a t i o n e tc) . T h e s e c o n d l ine in the b o d y o f the p r o d u c e r o b j e c t d e c l a r e s a l o c a l i n s t a n c e v a r i a b l e (_t48). L i n e 14 i n i t i a l i s e s the seed; a n d l i nes 31 t h r o u g h to 50 i m p l e m e n t the d o -

o d l o o p . T h e ca l l to the p r o c e d u r e p r o d u c e is t r e a t e d as s y n c h r o n o u s m e s s a g e p a s s i n g to self. In fac t the c o m p l e m e n t o f th is ( i .e. a s y n c h r o n o u s s e l f m e s s a g e - p a s s i n g ) is the m e c h a n i s m u s e d to i m p l e m e n t i n t e r n a l o r s i m u l a t e d p a r a l l e l i s m (cf. II in P A R L E , a n d n o n - p l a c e d P A R in O c c a m ) . F i n a l l y , l ine 49 is r e s p o n s i b l e fo r the s y n c h r o n i s a t i o n .

T h i s t r a n s f o r m a t i o n i l l u s t r a t e s h o w to c h a n g e b o t h l e v e l a n d m o d e l at the s a m e t ime . T h e c h a n g e o f l e v e l is a s t r a i g h t f o r w a r d c o m p i l a t i o n . L i k e w i s e , no t w i t h s t a n d i n g the p r o b l e m o f s y n c h r o n i s a t i o n , the c h a n g e o f m o d e l is a l so a d i r e c t t r a n s f o r m a t i o n o f p r o c e s s e s in to o b j e c t s .

5 .2 S y n c h r o n l s a t i o n b y m e s s a g e - p a s s i n g

A c o m m o n m e c h a n i s m fo r s y n c h r o n i s i n g i n t e r - o b j e c t c o m m u n i c a t i o n is to d i s t r i b u t e the s y n c h r o n i s a t i o n o v e r an e n s e m b l e o f

ob j ec t s . E a c h o b j e c t is t hen r e s p o n s i b l e fo r e n s u r i n g the d e s i r e d s e q u e n c e o f e v e n t s b y a p p r o p r i a t e use o f i ts select o p e r a t i o n to c h o o s e w h i c h m e s s a g e ( s ) i t is w i l l i n g to a c c e p t at a n y one t ime . U s i n g th is t y p e o f s y n c h r o n i s a t i o n a p r o d u c e r o b j e c t w o u l d o n l y " p r o d u c e " on-demand:

producer: :BODY( 31: .BRF 1 52; 32: .select produce;

33: t48.STORE %1; 34: .RIET t 4 8 & 52: .BR 31;

% do true % wait here till there is % a demand to produce; % block other messages % pick-up the result % return result & skip % do true

In f igure 5.4, the s t a t e m e n t " .select p r o d u c e " in l ine 32 is the m a i n s y n c h r o n i s a t i o n p o i n t b e t w e e n the p r o d u c e r a n d i ts e n v i r o n m e n t . M e s s a g e s m a y s t i l l b e a r r i v i n g f a s t e r t han the c o n s u m e r c a n s e r v i c e t hem. T h e s e are q u e u e d . T h e a b i l i t y o f o b j e c t s to b e in fu l l c o n t r o l o f w h i c h m e s s a g e s to se lec t at a n y one t ime is a g r e a t a d v a n t a g e fo r p r o g r a m m i n g d i s t r i b u t e d s y s t e m s in g e n e r a l a n d fo r s u p p o r t i n g o b j e c t - o r i e n t e d s y s t e m s in p a r t i c u l a r . H o w e v e r , o n c o n v e n t i o n a l c o m p u t e r s y s t e m s , the i m p l e m e n t a t i o n o f the select o p e r a t i o n i n v o l v e s e x t e n s i v e s e a r c h i n g a n d q u e u e m a n a g e m e n t . N o v e l p a r a l l e l m i c r o c o m p u t e r s l i ke the T r a n s p u t e r [7] h a v e

464 A.T. Balou, A.N. Refenes / TOOL

demonstrated that direct hardware implementat ions o f channels are both feasible and efficient. It is possible to support this type o f synchronisat ion in T O O L equally efficiently, by extending the definition o f the primitive object for m e m o r y cells so that besides the primitive methods for loading and storing T O O L m e m o r y cells would support two additional primitive methods: get and put.

cell ( s tore .method; load.method; pu t .method; get .method;

)

The p u t and get operations are described as follows: When an instance o f a m e m o r y cell executes the get operation it first checks to s e e if there is a value in self. I f the value is there, the value is returned and self is re-set to empty. Conversely, the pu t operat ion polls the cell until it is empty and overwrites the empty contents.

It fol lows that the primitive input and output processes of P A R L E and Occam are easily mapped onto get and pu t operations. The input process v := c? (i.e. v?c in Occam) compiles to:

c .GET ; v . S T O R E % 1;

% msg ----> c to execute get % store the re tum value in v

Likewise, the primitive output process v? := e (i.e. v!e in Occam) compiles to:

.eval e ;

v .PUT %1; % T O O L code to evaluate e % put result in v

The first t ransformation in this section illustrates how to map synchronisation, based on message-pass ing via channels (process- or iented sys tems) onto equivalent synchronisat ion based on message-passing by call (objec t -or iented systems). Message- passing by call is similar to remote procedure calls with the recipient object being able to select which messages to answer. This has the advantages o f simplicity and flexibility

combined in a single operation. The main disadvantage is that the overheads of implement ing the message passing on convent ional microprocessors would be higher. This becomes important when the application is characterised by fine-grain parallelism with intense communica t ion between objects. For this type o f applications we have demonstrated how to extend the definition o f T O O L to take advantage o f underlying hardware structures that may support more efficient forms of communica t ion . The mapping o f the extended definition onto any particular architecture is a trivial problem for the T O O L compi ler back-end, since only a few (in this case one) primitive objects are effected.

6. Re la ted W o r k

The only language, known so far, having a purpose analogous to TOOL, is the ESPRIT- Project 415 COIL[4] . The primary usage of COIL, and the origin o f its definition, is the implementat ion o f the object oriented language P O O L 2 on the D O O M distributed machine architecture. The P O O L 2 to D O O M compiler will use C O I L as an intermediate language. C O I L is a strongly typed language, while a set o f pre-defined classes is also provided. Classes are supported but not any scheme of inheritance. Al though the standard way for communica t ion and synchronizat ion is message exchange, objects can also synchronize through globally available semaphores . In general, COIL, al though it provides the user with considerable capabilities, has some high-level features p lugged in a rather ad hoc way whereas some aspects o f the object-oriented model are not supported.

Sina/st [2] has been considered while investigating the inheritance problem. The attractiveness of its scheme consists in its flexibility o f supporting various code-sharing mechanisms. However , this is not achieved in terms o f the language, but through the introduction o f an external interface, expressed in terms o f predicates.

A.T. Balou, A.N. Refenes / TOOL 465

F i n a l l y , A c t o r s [ I ] , a l t h o u g h they are low-

l eve l o b j e c t - o r i e n t e d l a n g u a g e s and a good

bas i s to b u i l d u p o n , they are ra the r u n s u i t a b l e c a n d i d a t e s as ta rge ts for c o m p i l a t i o n .

7. C O N C L U S I O N S

A s the l eve l o f in te r face b e t w e e n sof tware and h a r d w a r e is c o n t i n u o u s l y shi f t ing , the

r e q u i r e m e n t for s t anda rd p o i n t s o f r e f e r ence b e c o m e s i n c r e a s i n g l y impor t an t . Pas t

e x p e r i e n c e [12] sugges t s that it is no t an easy task to d e s i g n a u n i v e r s a l i n t e r m e d i a t e

l a n g u a g e ab le to suppor t al l c o m p u t a t i o n a l

s ty les wi th e q u a l (high) e f f ic iency . T O O L

restr ic ts its d o m a i n to the suppor t o f Ob jec t - O r i e n t e d H i g h L e v e l L a n g u a g e s . H o w e v e r ,

we h a v e s h o w n in c o n s i d e r a b l e detai l , that

apar t f r o m O b j e c t - O r i e n t e d , it is p o s s i b l e to

m a p P r o c e s s - O r i e n t e d L a n g u a g e s on to T O O L wi th m i n i m a l effort .

I n con t ras t , an e x t e n s i v e d i s c u s s i o n on w h e t h e r T O O L can suppor t all f l avours of

O b j e c t - O r i e n t e d l a n g u a g e s , has b e e n omi t t ed in this p a p e r as it c a n be eas i ly seen that the

m a j o r fea tu res of the O b j e c t - O r i e n t e d c o m p u t a t i o n a l m o d e l m a p d i rec t ly on to the

T O O L cons t ruc t s . W h e r e v e r it was j u d g e d

that specif ic fea tures we re e i ther res t r ic t ing

the e f f i c i ency o f T O O L or p e n a l i z i n g its f lex ib i l i ty , they were left out . V e r y

spec i a l i zed fea tures , no t c o m m o n to the m a j o r i t y o f l a n g u a g e s , c an be bu i l t o n top o f

T O O L .

W e are cu r r en t l y e x p e r i m e n t i n g wi th T O O L

in two d i rec t ions : First , as a c o m p i l e r target

l a n g u a g e for va r ious c o m p u t a t i o n a l s tyles . F o r this pu rpose , there have b e e n cons t ruc t ed c o m p i l e r f r o n t - e n d s f r o m P A R L E and a

pa ra l l e l v e r s i o n o f P ro log on to T O O L a n d a b a c k - e n d for T r a n s p u t e r T 8 0 0 b a s e d sys tems ; (b) Second , as a veh ic l e for i nves t i ga t i ng

O b j e c t - O r i e n t e d a rch i tec tures .

A C K N O W L E D G E M E N T S

W e w o u l d l ike to t hank Car lo Ol ive i ra , and Ph i l i p T r e l e a v e n u s e f u l c o m m e n t s d u r i n g the d e s i g n and i m p l e m e n t a t i o n o f the T O O L .

R E F E R E N C E S

[1] Agha G., "An Overview of Actor Languages", SIGPLAN Notices 21 (10)pp. 58-67 (Oct. 1986).

[2] Aks i t M. and Tripathi A., "Data Abstraction Mechanisms in Sina/st, OOPSLA Procs, '88 , pp. 267-275 Proc. of Int. Symp on Computer Architecture, June 1984, pp. 188-197.

[3] America P., "POOL-T- a Parallel Object-Oriented Language", "Object-Oriented Concurrent Programming", Yonezawa and Tokoro (eds), pp. 199-220, MIT Press 1987

[4] Augusteijn A., den Haan P., Morrison J.P., "Definition of COIL, a Concurrent Intermediate Language", Doc. No 0362, ESPRIT Project-415- A, Sept. 1988

[5] Delgado J., Carvalho C., and Osorio L., Research Note, Parallel Computer Architectures Group, INESC, Rua Alves Redol 9, 1000 Lisboa

[6] Goldberg A. and Robson D., "Smalltalk-80 - The Language and its Implementation", Addison- Wesley, Reading, MA, (1983).

[7] Homewood M., et al, "The IMS T800 Transputer", IEEE Micro, Oct. 1987, pp. 10-26.

[8] Moon, D.A., "Object-Oriented Programming with Flavors", OOPSLA86 Proceedings, (1986), pp. 1-8.

[9] Refenes A. N. et al "PARLE: A Parallel Target Language for Integrating Symbolic and Numeric Processing", Lecture Notes in Computer Science Vol. 366, Springer-Verlag, pp. 181-198, (1989).

[10] Steftk M. K. and Bobrow D. G., "Object-Oriented Programming: Themes and Variations", The AI Magazine, 1986

[ 11 ] Stroustrup B. "The C++ Programming Language", Addison-Wesley, Reading, MA, (1986).

[12] Tanenbaum A.S., van Staveren H., Kiezer E.G., Stevenson J.W., "A Practical Toolkit for Making Portable Compilers", Comm ACM, vol. 26(9), Oct. 1983, pp. 654-660

[13] Tokoro M. and Ishikawa Y., "An object-oriented Approach to Knowledge Systems", Proc. of the International Conference on Fifth Generation Computer Systems, ICOT, Nov. 1984, pp. 623- 631.

[ 14] Wegner P., "Dimensions of Object-Based Language Design", OOPSLA Proceedings '88, pp 168-182.