- Email: [email protected]
Real-time functional programming systems
North-Holland
Microprocessing and Microprogrammlng 30 (1990) 491-498
491
REAL-TIME FUNCTIONAL PROGRAMMING SYSTEMS S.C.Winter,
Polytechnic
of Central
D.R.Wilson and D.F.Neale
London,
Faculty
o f E n g i n e e r i n g and S c i e n c e , WIM 8JS, U.K.
115 New Cavendish St, London,
R e a l - t i m e p r o c e s s i n g systems are t y p i c a l l y c h a r a o t e r i s e d by high p r o c e s s i n g rates, high reliability, and h i g h i n p u t / o u t p u t rates. F u n c t i o n a l programming, d e r i v e d from the lambda calculus, is a formal basis for c o m p u t a t i o n which f a c i l i t a t e s the d e s i g n of well-structured, h i g h l y r e l i a b l e programs, and also enables a rigorous i m p l e m e n t a t i o n on p a r a l l e l h a r d w a r e to p r o v i d e high p r o c e s s i n g rates and I/O bandwidth. The p r i n c i p l e s of CTDNet2, a n e w r e d u c t i o n m e c h a n i s m for r e a l - t i m e a p p l i c a t i o n s based on g r a p h reduction, and a combination of eager and lazy evaluation, are presented. CTDNet2 has been d e s i g n e d with r e a l - t i m e p r o c e s s i n g in mind, and is intended for h i g h l y p a r a l l e l m u l t i p r o c e s s o r implementation. It is p a r t i c u l a r l y s u i t a b l e for t r a n s p u t e r networks. 1.
Introduction
In [KALI89] it is o b s e r v e d t h a t a realtime system s h o u l d exhibit the charact e r i s t i c s of liveness (it m u s t r e s p o n d to e v e r y r e q u i r e d stimulus), safety (it m u s t p r o v i d e the c o r r e c t response), and timeliness (it m u s t respond w i t h i n the r e q u i r e d t i m e constraints). To achieve t h e s e characteristics, it follows t h a t a r e a l - t i m e s y s t e m m u s t he capable of °
a c h i e v i n g v e r y high c o m p u t a t i o n a l rates when the s i t u a t i o n d e m a n d s it
°
be able to i n t e r a c t easily and frequ e n t l y w i t h devices, i n c l u d i n g realt i m e clocks, in the external w o r l d
°
be c o n s t r u c t e d w i t h a high d e g r e e of i n t e g r i t y and reliability.
High speed of r e s p o n s e in a r e a l - t i m e s y s t e m could m o s t e f f e c t i v e l y be p r o v ided by a h i g h l y p a r a l l e l set of evaluators, such as a n e t w o r k of t r a n s puters, and e n s u r i n g that the application p r o g r a m can f u l l y exploit the a v a i l a b l e p r o c e s s i n g power. This is not e a s i l y a c h i e v e d with c o n v e n t i o n a l imperative programming, since much effort is r e q u i r e d to d e v i s e a m a p p i n g p o l i c y p r i o r to execution, and a load balancing s t r a t e g y d u r i n g execution, to m a i n t a i n e f f i c i e n t u t i l i s a t i o n of p r o c e s s o r resources. Part of this e f f o r t is related to the d i f f i c u l t y of m o d e l l i n g v a r i a b l e s and a s s i g n m e n t statements, u s e d w i d e l y in i m p e r a t i v e programs, in a form s u i t a b l e for parallel execution.
F u n c t i o n a l p r o g r a m m i n g however, is concerned almost e n t i r e l y w i t h the m e c h a n ical e v a l u a t i o n of f u n c t i o n s based on the lambda calculus, a p r o c e s s known as reduction [LAND64]. All v a r i a b l e s in functional p r o g r a m s are f o r m a l l y bound by an e n c l o s i n g function, and it is easier to find schemes for m a n i p u l a t i n g the v a l u e of a v a r i a b l e in several contexts simultaneously, w i t h o u t fear of e n c o u n t e r i n g errors of d a t a consistency. This v e r y useful p r o p e r t y is termed referential transparency. A n o t h e r m a j o r a d v a n t a g e of functional p r o g r a m m i n g relates to c o r r e c t n e s s and safety. Since functional languages are based on the lambda calculus, rigorous methods of s o f t w a r e d e s i g n and validation can be developed, thus a l l o w i n g m o r e r e l i a b l e p r o g r a m s to be developed. Furthermore, as will be shown in this paper, this f o r m a l i t y may be e x t e n d e d to I/O and event processing, a crucial feature of r e a l - t i m e processing. One of the issues faced by d e s i g n e r s of the first r e d u c t i o n m a c h i n e s was how to e f f i c i e n t l y h a n d l e e x p r e s s i o n s which are the arguments of functions. One of the e a r l i e s t i m p l e m e n t a t i o n s was Mago's string reduction m a c h i n e [MAGO80], in which a full copy of the a r g u m e n t is i n s t a n t i a t e d in the b o d y of the function. In graph reduction [WADS71], p o i n t e r s to shared a r g u m e n t s are subs t i t u t e d for the formal arguments of a function d u r i n g reduction. This is more e f f i c i e n t than string reduction. The first g r a p h r e d u c t i o n m a c h i n e in the UK was A l i c e [DARLgl]. This was s u p e r s e d e d by F l a g s h i p [GREE89], w h i c h was in turn i n c o r p o r a t e d w i t h i n the E u r o p e a n
S.C. Winter et al. / Real-time functional programming systems
492
(ie. formally testable) implementations of I/O to be constructed.
Declarative System (EDS) project. A typical engineering system is modelled by the transformation of a stream of input data (continuous or sampled values) into a stream of output values. In classical linear systems theory, this transformation is the t r a n s f e r f u n c t i o n , and the situation is depicted in Figure I. A control system is a paradigm of this model. In it, the input values represent measurements taken from a plant and the output values are control signals which modify the plant's behaviour.
input I transfer . . . . . . . . . . >I f u n c t i o n
I
output
F
Figure i. A system block diagram In functional programming, I/O is modelled by s t r e a m s : partiallyevaluated infinite lists whose elements are time ordered [LAND65]. A stream is treated as a single operand, and the control system paradigm considered earlier may be modelled as a function which maps the whole input stream into the output stream, as shown in Fig. 2.
I . . . . . . . . . . . . . >~
. . . . . . . . . . . . . . . .
>
= F()
Figure 2. Functional model of streams
Time is of central importance to realtime systems, but a b s o l u t e time is not a feature of the stream model. Rather, the elements of a stream are temporally ordered, and instantiated lazily, ie. when the computation has reached an appropriate stage. Thus, the model of external interaction is based on mutual participation in events, by both the system, and its environment. A similar modelling approach is used in the process calculi, eg. CSP [HOAR85]. E x a c t time (if it is needed) can be determined by reference to the occurrence of a particular event (such as a clock interrupt), which is controlled by the environment. Clock programs can then be built from such events, which as a type of input, are also modelled by streams. Eliminating absolute time in favour of ordered events has the major advantage of simplifying the whole programming model, which in turn enables rigorous
The implementation of streams depends crucially on an implementation scheme known as l a z y e v a l u a t i o n , in which the arguments of a function are allowed to remain unevaluated until their values are actually required by the function. Unfortunately, lazy evaluation is a predominantly sequential scheme, with limited potential for the exploitation of parallelism, which in turn detracts from the timeliness and liveness requirements of real-time systems. An alternative reduction scheme is e a g e r e v a l u a t i o n , in which an argument is always evaluated b e f o r e being passed to a function. Eager reduction presents many opportunities for parallelism, but unfortunately, is totally unable to handle streams. An optimal strategy for real-time applications thus appears to be a judicious mixture of both lazy and eager evaluation: combining the best, and avoiding the worst, aspects of both. This approach is taken in most dataflow machine designs, in which primitive actors such as c h o i c e are lazy, and also in some functional languages. Hope, for example, is basically eager, but has a lazy I/O sub-system [BURS80]. In summary, it has been argued that models of real-time systems have a natural affinity with functional models of computation; that precedents for implementing real-time systems as a functional architecture exist; and that the engineering requirements of realtime systems are strongly matched to the properties of functional programming systems. It is concluded that the requirements of real-time systems make it realistic to study implementations of functional programming systems on parallel processing hardware as a suitable basis for the design of real-time computer architectures. The graph reduction machine presented in this paper, CTDNet2, employs a mixed evaluation strategy. The underlying framework is eager, to provide high speed of response, but lazy e v a l u a t i o n is employed selectively to deal with vital real-time aspects such as I/O. CTDNet2 is implemented as a process model suitable for parallel implementation. This combination was developed experimentally in an early prototype known as CTDNet [GUPT85, GUPT89]. CTDNet has quite a cumbersome messagepassing scheme, and is based on string reduction.
S.C. Winter et al. I Real-t/me functional programming systems
493
2. The P r o c e s s M o d e l of G r a p h R e d u a t i o n
t i c e it m u s t also b e c o m e s t r a t e g i c a l l y eligible.
In common w i t h m a n y other g r a p h r e d u c t i o n systems [PEYT87], p r o g r a m s are r e p r e s e n t e d as a set of u n i q u e l y labelled, c o n n e c t e d p r o c e s s e s c a l l e d APPLYnodes. An A P P L Y - n o d e is t y p i c a l l y conn e c t e d to 3 others: its r a t o r , its r a n d and its p a r e n t . The rator and rand nodes are the roots of the rator and rand expressions; t h e p a r e n t n o d e is the root of the i m m e d i a t e l y e n c l o s i n g a p p l i c a t i o n expression. Thus, the g r a p h
For a r e d e x to be s t r a t e g i c a l l y elig i b l e in CTDNet2 it is n e c e s s a r y t h a t it should be c o n t e x t - f r e e , and t h a t its rand s h o u l d c o n t a i n no s t r a t e g i c a l l y e l i g i b l e redexes. Any r e d u c t i o n of this kind is called c o n t e x t - f r e e a p p l i c a t i v e r e d u c t i o n (CFAR). A p a r t i c u l a r l y s i m p l e C F A R strategy, in w h i c h the rator is also r e q u i r e d to contain no s t r a t e g i c ally e l i g i b l e redexes, is called i n n e r -
square
most context-free applicative reduction (ICFAR). Here, the i n n e r m o s t c o n t e x t -
= ~x. (*~ X X) = kx.(@
(@ .o x) x)
is r e p r e s e n t e d by two APPLY-nodes, A and B, in w h i c h A is B's parent, and B is A's rator: null
° A r e d e x is s t r a t e g i c a l l y e l i g i b l e in ICFAR ( I C F A R - e l i g i b l e ) if and only if the r e d e x is context-free, the rator is a c o n t e x t - n o r m a l function (abstraction or primitive) and the rand is a c o n t e x t - n o r m a l a p p l i c a b l e a r g u m e n t (function or value).
^A. or
~x.A /\ / \ ^B X
B /\ / "o
free redexes (those n e a r e s t the leaves of the graph) are always reduced first; w h i l s t t h o s e n e a r e s t the root are inhibited. The ICFAR e l i g i b i l i t y criterion is as follows:
\ X
e x p r e s s i o n is c h a r a c t e r ised in the f o l l o w i n g terms:
A context-free
A simple p r o g r a m to c o m p u t e the square of 2 is i m p l e m e n t e d as Definitions: nu I1
square
^~A. or
= ~x.A~ IX I \ ^B
B I\ I x
*=
\ x
^~square
In d i r e c t o r string terms, a r e d e x is c o n t e x t - f r e e iff its d i r e c t o r string is empty. e x p r e s s i o n is one cont a i n i n g no e l i g i b l e redexes u n d e r a CFAR strategy. Since any normal graph must also be c o n t e x t - n o r m a l (a normal graph is one c o n t a i n i n g no redexes at all), c o n t e x t - n o r m a l i t y of a node can be e s t a b l i s h e d locally in a c c o r d a n c e with the f o l l o w i n g criteria:
CO /
A r e d e x is c o n t e x t - f r e e if and only if it has no free v a r i a b l e s a n d it is not the root of an a b s t r a c t i o n expression.
A context-normal
Principal A~lication: /
A n o n - r e d u c i b l e e x p r e s s i o n is c o n t e x t - f r e e if and only if it contains no free variables.
\ \ 2
The symbol '&' d e n o t e s that the n o d e is the root of an a b s t r a c t i o n expression, ie. a f u n c t i o n definition.
° A n o d e is c o n t e x t - n o r m a l normal.
3. C o n t e x t - F r e e (CFAR)
° A n o d e is c o n t e x t - n o r m a l if its rator and rand are c o n t e x t - n o r m a l and it is not an e l i g i b l e redex u n d e r a C F A R - e l i g i b i l i t y criterion.
Applicative
Reduction
In the lambda calculus, a r e d e x is a n y r e d u c i b l e expression. However, in a g i v e n r e d u c t i o n scheme, a r e d e x is not s t r a t e g i c a l l y e l i g i b l e to reduce, until s e l e c t e d in a c c o r d a n c e with the r e d u c tion strategy. In o t h e r words, a r e d e x is only p o t e n t i a l l y reducible; in prac-
if it is
These rules allow a w a v e f r o n t of cont e x t - n o r m a l i t y tokens to p r o p a g a t e u p w a r d s from the leaves to the root. In CTDNet2, the symbol '%' is used to d e n o t e context-normality.
S.C. Winter et a L / Real-time functional programming systems
494
of the program.
4. Lazy Reduc~tion Mechanisms
@
A g r a p h w h i c h does not e v a l u a t e until n e e d e d is t e r m e d lazy. In CTDNet2, e v a l u a t i o n of a lazy g r a p h is i n h i b i t e d by m a r k i n g the p o i n t e r s to it (the symbol '£' is used). The lazy g r a p h itself is not marked, a l t h o u g h any node inhibited by a lazy p o i n t e r is still d e s c r i b e d as 'lazy'. Ordinary, u n m a r k e d graphs are eager, B e c a u s e lazy s u b g r a p h s can m a k e no c o n t r i b u t i o n to a computation, c o n t e x t n o r m a l i t y is a l l o w e d to extend above a lazy node. The f o l l o w i n g c r i t e r i o n is thus a p p e n d e d to the o h a r a c t e r i s a t i o n of c o n t e x t - n o r m a l i t y : " a n o d e is context-1~ormal lazy
if it is
This e x t e n s i o n of c o n t e x t - n o r m a l i t y allows c o m p u t a t i o n to p r o c e e d a b o v e a lazy node; it also permits a lazy g r a p h to be passed, unevaluated, as an argument, w h e r e the v a l u e of the g r a p h is not required. However, since lazy nodes are not a c t u a l l y c o n s c i o u s of t h e i r lazy status, the c r i t e r i o n is a p p l i e d to the pointers to lazy nodes.
.5.
/\ /
\
Output
@
/\ / Ma i n
\ I_.~Rq...t..
Note that the s t r e a m I ~ t . , rather than the f u n c t i o n Input has been included in the canonical model. This is d e f e n d e d on the g r o u n d s t h a t the input to the main f u n c t i o n is likely to be implem e n t e d as a folded stream, rather than as the result of a p p l y i n g a function to a null argument. Actually, Input was i n t r o d u c e d s o l e l y as a functional 'bridge' b e t w e e n the p r o g r a m and the p h y s i c a l input channel; formally, I [ ~ . u t . = (Input n i l ) .
~a.~..~.. Input
I ......
I
>
Main
.....
>
Output
I/O M o d e l s
In a typical f u n c t i o n a l program, the m a i n f u n c t i o n (Main) accepts an input s t r e a m of v a l u e s (Ip_/~_u.t.) as its argument, and the result of this a p p l i c ation is a n o t h e r s t r e a m (Main), as shown in F i g u r e 3.
~.~
I
. . . . . . . . . . . >1 Main
l
U aJLn..
:
F i g u r e 3. B a s i c I/O model of a f u n c t i o n a l program.
The s t r e a m ! Z , ~ A can be m o d e l l e d as the v a l u e of a f u n c t i o n Input applied to a null argument, w h i c h samples the p h y s ical input channel as a side-effect. The Mg_.i~.. s t r e a m can be p a s s e d as an a r g u m e n t to a n o t h e r function, Output, w h i c h has no formal result, but as a side-effect, sends the elements of its a r g u m e n t s t r e a m to the p h y s i c a l output channel. This is shown in F i g u r e 4. In the lambda calculus, the essential c a n o n i c a l model d e s c r i b i n g this situat i o n is as shown below. This model may be taken as the p r i n c i p a l a p p l i c a t i o n
F i g u r e 4. E x t e n d e d I/O model of a functional program.
Since streams are t i m e - o r d e r e d infinit a r y objects, one of the roles of r e f e r e n t i a l t r a n s p a r e n c y in the I/O model is to ensure that the sense of t i m e - o r d e r i n g is e v e r y w h e r e p r e s e r v e d t h r o u g h o u t the program. This model is e x t e n d e d to all streams, and so it is n e c e s s a r y to
(a) e n s u r e t h a t every s t r e a m is unique, ie. only one, shared, o c c u r r e n c e of each s t r e a m may appear in the program.
(b) ensure t h a t the event of e x t r a c t i n g the head of a s t r e a m occurs before the event of e x t r a c t i n g the tail of the stream.
(c) m a n i p u l a t e the w h o l e stream, even t h o u g h it may only be in a state of partial existence. Rule (a) is e n f o r c e d by a d o p t i n g a uniqueness r u l e for streams, w h e r e b y the name of a s t r e a m m a y appear in an a p p l i c a t i o n at most twice: once only in the p r o g r a m d e c l a r a t i o n outside the
S.C. Winter et al. / Real-rime functional programming systems
stream's definition, and once only within the definition. Sharing of the object is an intrinsic feature of graph reduction, implemented in CTDNet2 by weighted reference counting. Rule (b) is called the Access Law of Streams, and is enforced by the stream constructor itself, which is where requests for head and tail values are resolved. Rule (c) precludes applicative styles of evaluation, which are not generally suitable for dealing with folded (ie. infinitary) structures. As a footnote, it is reassuring to observe that physical input and output streams naturally satisfy the three rules of streams!
6. Stream Constructors Stream constructors are implemented as processes, called S T R E A M - n o d e s , having two children: the left child representing the head; and the right child representing the tail. Three types of STREAM-node are defined in CTDNet2: eager (both head and tail are eager); lazy-tail (only the head is eager); and lazy (neither head nor tail are eager). They are denoted by !!!, !! and ! respectively. For example, Stream
=
!! / / Stream~
\ \ Stream"
denotes a lazy-tail stream constructed from its (eager) head (Stream~) and its (lazy) tail (Stream'). Since a stream is strictly unique, unique meanings may be attached to each of its instantiations: the ith instance denotes the tail of the (i-l)th instance, ie. Streaml
denotes the whole of Stream
Stream2
denotes the tail of Streaml
Stream3
denotes the tail of S t r e a m 2
etc. The only permitted operations on streams are of two types: (i) extraction of the head (CAR-type) (ii) extraction of the tail (CDR-type) Since the primitive operations of head and tail extraction (CAR a n d CDR) are implemented by request to the STREAM-
495
node, the Access Law of Streams is enforced by the STREAM-node itself. Thus, at least one CAR-request must be received, accepted and despatched by the constructor, before a CDR-request may be dealt with; subsequently, requests may be processed in any order. It is the first request for the head (rather than the last), which is used to trigger access to the tail. This is justified since once the head has been fetched, the Access Law is sat!fled, and there is no further reason to delay the tail. Previously evaluated head and tail expressions may be despatched without delay to the requestor. When all outstanding requests have been received and processed, the current stream may annihilate - although the tail of the current stream, represented by the right child process, is not destroyed by this action. However, future contact with the tail would only be possible if at least one CDR-request had been processed by its parent before annihilating. It is assumed that the tail of a stream reduces to another stream, or to nil. Lazy tails are evaluated by removing the laziness at the root of the tail, and the tail is deemed to be evaluated when it attains context-normality. Of course, the tail may contain lazy subgraphs, since the extended criterion of context-normality takes account of laziness. Messages for lazy branches are held by the STREAM-node until evaluation is forced by the arrival of head and tail requests. For example, in a lazy-tail implementation of Stream, instant!at!on of S t r e a m 2 is inhibited until receipt and acceptance of a tail request (which must not, of course, precede despatch of a head request) by Strea=l; however, evaluation of the head is not inhibited. A lazy stream will also inhibit head extraction until receipt of the head request. Sharing of streams is implemented by the standard technique (weighted reference counting) of CTDNet2.
7.
Implementing the
I/O Nodel
Since the Access Law of streams holds naturally for physical input, there is only one relevant operation for the Input process to perform: GET, which samples the input channel and returns a value. The Input process must repeatedly perform this operation, but not prematurely; thus a natural implementation of input is as a lazy stream:
S.C. Winter et aL / Real-time functional programming systems
496
=
Input
! %
result is delivered internally, signifying completion (recall, Output technically delivers no result). This signal may then be used to annihilate the process representing the current instantiation of Output.
/\ /
\
/
V' ~ !n_~_u t
GET ~
GET is a function of zero arity and normally fires spontaneously. Making it lazy version inhibits its action until the laziness is explicitly removed by the lazy STREAM-node. The implementation above is designed to ensure that the GET operation remains unfired until a value is actually required by the Main function, and also that the recursire tail remains folded until the Main function requests its value. Although GET is nondeterministic (it returns an arbitrary value each time it is called), and thus not consistent with the property of referential transparency, the ~ 2 ~ . stream itself is referentially transparent, since by the Uniqueness rule it can only be invoked once - whereupon it delivers the entire stream (by virtue of lazy evaluation), whose value (albeit determined at run time) is the same everywhere in the program. An additional implementation rule may be introduced here, which is to permit only one declared call of the GET primitive: this rule is respected in the concrete implementation of !X~M£. given above. The purpose of the Output stream function is to repeatedly send the values of the Main stream as they emerge to the physical output channel. Thus, the Output stream is always ready to receive values, and it may be implemented as an eager stream, without risk of running-away uncontrollably:
No restrictions are placed on the implementation of the Main stream function. 8. I n t e r r u p t s For real-time systems, a facility for externally-generated interrupts is essential. In a functional environment, interrupts can be modelled in the same way as other inputs: by streams. In this case, firing of the primitive GET corresponds to enabling the interrupt: the environment always decides when an input value (including an interrupt) will be returned to the program. This delay does not affect the CTDNet2 reduction model, which is not timesynchronised, ie. the precise moment of arrival of a result to some part of a program does not affect the validity of the program. The sequence of actions triggered by the eventual arrival of the enabled interrupt is then the equivalent of an interrupt service routine. The following program prints the value 'i' on the Output stream each time an interrupt arrives on the Interrupt stream. D@~initions:
!_E£e r..K.u~.t..
=
!
/\ /
\
GET ~
V L~
.!~.t_e_t:_.r.q~.~:.
Output
=
!!!
/
\
/
Output
\
/ /
{as before}
\
@
@
/\
/\
I
=
\ Main
ks.
/ \ @ V''' \ / \ Output @
/ CAI~
\ / CDH
\ \
/
\
II
V '~:
/\
/\ s
!!
/
\
PUT
/
I
\
li
\
I
s
e I
I
\
/
/ \ The primitive PUT sends a value to the physical output device. To preserve referential transparency in the definition of Output, only one declared call of PUT is permitted. When PUT is applied to its argument, and the value sent to the physical channel, a n i l
I\ 1
\ @
Mair,
IX
\
I
\
SECOND
I @
CDH
/\
/ CAR
\ s
\ s
S.C. Winter et al. / Real-time funcUonal programming systems
497
~ C E S Princinal APPlication: BuRseo R.M. Burstall, D.B. MacQueen and D.T. Sanella: HOPE: an experimental applicative language, 1980 LISP Conf. Rec,, Stanford, CA, pp.138-143, 1980.
@
IX I
\
I
\
Output
@
/\ / / Main
\ \ In ter!u_uRt
DARL81 J.Darlington and M. Reeve: ALICE - a multi-processor reduction machine for the parallel evaluation of applicative languages, Proc. ACM Conf. Functional
Prog.
pp.65-75, The primitive SECOND used here is similar to Turner's K combinator: it takes the value of its second argument. It is strict on both its arguments, and is therefore forced to wait for the arrival of the interrupt, before delivering its result, i.
Lang.
Arch.,
GRKI¢89
M. Greenberg and V. Woods, F L A G SHIP - A Parallel R e d u c t i o n Machine for D e c l a r a t i v e P r o g r a m m i n g , Int. Report, Dept. Comp. 1989. GUPT85
Sol., Manchester Univ.,
J.P.Gupta,
CTD M u l t i p r o c e s s o r
9. Conclusions
and Comput.
1981.
Thesis, 1985.
The R e a l i s a t i o n of a Architecture, PhD
Polytechnic of Central London,
The feasibility of embedding the technologies of functional programming and parallel processing into the design of real-time systems has been demonstrated through t h e CTDNet2 reduction machine. The desirability of functional programming for real-time applications stems firstly from its formal, declarative nature, and secondly its amenability to parallel implementation. The former property leads to increased system integrity and safety; the latter has a beneficial effect on liveness and timeliness, through the increased computational rates.
GOIPT89 J.P.Gupta, S.C. Winter and D.R. Wilson: CTDNet - A mechanism for the concurrent execution of lambda graphs, IEEE Trans. S o f t w a r e Eng., Vol. C-15, No. ll, Nov. 1989.
It has been shown how some major constructs required for real time processing, notably I/O handling and interrupt processing, are implemented in CTDNet2. Other aspects not presented here, such as multitasking, multiple I/O channels and non-determinism, are discussed in [TINT90].
LAND64 P.J.Landin: The mechanical evaluation of expressions, Computer Journal, VoI.6, pp. S08-S20, 1964.
CTDNet2 has been validated through detailed simulated execution of several problems. Based on 2 benchmark examples, the number of messages sent, and the number of processes instantiated in the system, shows a reduction of the order of 25%, when compared with CTDNet. The improved efficiency is due partly to the adoption of graph, rather than string, reduction. In particular, the implementation of lazy evaluation in CTDNet2, when combined with graph reduction prevents much unnecessary process instantiation.
MAGO80 G.A. Mago: A cellular computer architecture for functional programming, Proc. IEEE COMPCON, pp.179-187, 1980.
CTDNet2 is currently being implemented on a transputer network.
HOAR85
C.A.R. Hoare, C o m m u n i c a t i n g Processes, Prentice-Hall,
Sequential
1985. KALI89 D. Kalinsky and J.Ready: Realtime operating system kernel technology for the 21st Century, Proc. 2nd IEE Int. Conf. on S o f t w a r e Eng. for Realtime Systems, Cirencester, Sept. 1989.
LAND85 P.J.Landin: A correspondence between Algol 60 and Church's lambda notation: Part I, Comm. ACM, Vol.8, pp.89-100, Feb. 1965.
I~T87
S.L.Peyton-Jones, The I m p l e m e n tation of F u n c t i o n a l P r o g r a m m i n g Languages, Prentice-Hall, 1987. WADS71
C.P. Wadsworth,
Pragmatics
Thesis,
S e m a n t i c s and of the Lambda Calculus, PhD
Oxford University,
1971.
WINTgO S.C. Winter, A d i s t r i b u t e d reduction a r c h i t e c t u r e for r e a l - t i m e computing, Research Report, Polytechnic of Central London,
1980.
Microprocessing and Microprogrammlng 30 (1990) 491-498
491
REAL-TIME FUNCTIONAL PROGRAMMING SYSTEMS S.C.Winter,
Polytechnic
of Central
D.R.Wilson and D.F.Neale
London,
Faculty
o f E n g i n e e r i n g and S c i e n c e , WIM 8JS, U.K.
115 New Cavendish St, London,
R e a l - t i m e p r o c e s s i n g systems are t y p i c a l l y c h a r a o t e r i s e d by high p r o c e s s i n g rates, high reliability, and h i g h i n p u t / o u t p u t rates. F u n c t i o n a l programming, d e r i v e d from the lambda calculus, is a formal basis for c o m p u t a t i o n which f a c i l i t a t e s the d e s i g n of well-structured, h i g h l y r e l i a b l e programs, and also enables a rigorous i m p l e m e n t a t i o n on p a r a l l e l h a r d w a r e to p r o v i d e high p r o c e s s i n g rates and I/O bandwidth. The p r i n c i p l e s of CTDNet2, a n e w r e d u c t i o n m e c h a n i s m for r e a l - t i m e a p p l i c a t i o n s based on g r a p h reduction, and a combination of eager and lazy evaluation, are presented. CTDNet2 has been d e s i g n e d with r e a l - t i m e p r o c e s s i n g in mind, and is intended for h i g h l y p a r a l l e l m u l t i p r o c e s s o r implementation. It is p a r t i c u l a r l y s u i t a b l e for t r a n s p u t e r networks. 1.
Introduction
In [KALI89] it is o b s e r v e d t h a t a realtime system s h o u l d exhibit the charact e r i s t i c s of liveness (it m u s t r e s p o n d to e v e r y r e q u i r e d stimulus), safety (it m u s t p r o v i d e the c o r r e c t response), and timeliness (it m u s t respond w i t h i n the r e q u i r e d t i m e constraints). To achieve t h e s e characteristics, it follows t h a t a r e a l - t i m e s y s t e m m u s t he capable of °
a c h i e v i n g v e r y high c o m p u t a t i o n a l rates when the s i t u a t i o n d e m a n d s it
°
be able to i n t e r a c t easily and frequ e n t l y w i t h devices, i n c l u d i n g realt i m e clocks, in the external w o r l d
°
be c o n s t r u c t e d w i t h a high d e g r e e of i n t e g r i t y and reliability.
High speed of r e s p o n s e in a r e a l - t i m e s y s t e m could m o s t e f f e c t i v e l y be p r o v ided by a h i g h l y p a r a l l e l set of evaluators, such as a n e t w o r k of t r a n s puters, and e n s u r i n g that the application p r o g r a m can f u l l y exploit the a v a i l a b l e p r o c e s s i n g power. This is not e a s i l y a c h i e v e d with c o n v e n t i o n a l imperative programming, since much effort is r e q u i r e d to d e v i s e a m a p p i n g p o l i c y p r i o r to execution, and a load balancing s t r a t e g y d u r i n g execution, to m a i n t a i n e f f i c i e n t u t i l i s a t i o n of p r o c e s s o r resources. Part of this e f f o r t is related to the d i f f i c u l t y of m o d e l l i n g v a r i a b l e s and a s s i g n m e n t statements, u s e d w i d e l y in i m p e r a t i v e programs, in a form s u i t a b l e for parallel execution.
F u n c t i o n a l p r o g r a m m i n g however, is concerned almost e n t i r e l y w i t h the m e c h a n ical e v a l u a t i o n of f u n c t i o n s based on the lambda calculus, a p r o c e s s known as reduction [LAND64]. All v a r i a b l e s in functional p r o g r a m s are f o r m a l l y bound by an e n c l o s i n g function, and it is easier to find schemes for m a n i p u l a t i n g the v a l u e of a v a r i a b l e in several contexts simultaneously, w i t h o u t fear of e n c o u n t e r i n g errors of d a t a consistency. This v e r y useful p r o p e r t y is termed referential transparency. A n o t h e r m a j o r a d v a n t a g e of functional p r o g r a m m i n g relates to c o r r e c t n e s s and safety. Since functional languages are based on the lambda calculus, rigorous methods of s o f t w a r e d e s i g n and validation can be developed, thus a l l o w i n g m o r e r e l i a b l e p r o g r a m s to be developed. Furthermore, as will be shown in this paper, this f o r m a l i t y may be e x t e n d e d to I/O and event processing, a crucial feature of r e a l - t i m e processing. One of the issues faced by d e s i g n e r s of the first r e d u c t i o n m a c h i n e s was how to e f f i c i e n t l y h a n d l e e x p r e s s i o n s which are the arguments of functions. One of the e a r l i e s t i m p l e m e n t a t i o n s was Mago's string reduction m a c h i n e [MAGO80], in which a full copy of the a r g u m e n t is i n s t a n t i a t e d in the b o d y of the function. In graph reduction [WADS71], p o i n t e r s to shared a r g u m e n t s are subs t i t u t e d for the formal arguments of a function d u r i n g reduction. This is more e f f i c i e n t than string reduction. The first g r a p h r e d u c t i o n m a c h i n e in the UK was A l i c e [DARLgl]. This was s u p e r s e d e d by F l a g s h i p [GREE89], w h i c h was in turn i n c o r p o r a t e d w i t h i n the E u r o p e a n
S.C. Winter et al. / Real-time functional programming systems
492
(ie. formally testable) implementations of I/O to be constructed.
Declarative System (EDS) project. A typical engineering system is modelled by the transformation of a stream of input data (continuous or sampled values) into a stream of output values. In classical linear systems theory, this transformation is the t r a n s f e r f u n c t i o n , and the situation is depicted in Figure I. A control system is a paradigm of this model. In it, the input values represent measurements taken from a plant and the output values are control signals which modify the plant's behaviour.
input I transfer . . . . . . . . . . >I f u n c t i o n
I
output
F
Figure i. A system block diagram In functional programming, I/O is modelled by s t r e a m s : partiallyevaluated infinite lists whose elements are time ordered [LAND65]. A stream is treated as a single operand, and the control system paradigm considered earlier may be modelled as a function which maps the whole input stream into the output stream, as shown in Fig. 2.
>
= F(
Figure 2. Functional model of streams
Time is of central importance to realtime systems, but a b s o l u t e time is not a feature of the stream model. Rather, the elements of a stream are temporally ordered, and instantiated lazily, ie. when the computation has reached an appropriate stage. Thus, the model of external interaction is based on mutual participation in events, by both the system, and its environment. A similar modelling approach is used in the process calculi, eg. CSP [HOAR85]. E x a c t time (if it is needed) can be determined by reference to the occurrence of a particular event (such as a clock interrupt), which is controlled by the environment. Clock programs can then be built from such events, which as a type of input, are also modelled by streams. Eliminating absolute time in favour of ordered events has the major advantage of simplifying the whole programming model, which in turn enables rigorous
The implementation of streams depends crucially on an implementation scheme known as l a z y e v a l u a t i o n , in which the arguments of a function are allowed to remain unevaluated until their values are actually required by the function. Unfortunately, lazy evaluation is a predominantly sequential scheme, with limited potential for the exploitation of parallelism, which in turn detracts from the timeliness and liveness requirements of real-time systems. An alternative reduction scheme is e a g e r e v a l u a t i o n , in which an argument is always evaluated b e f o r e being passed to a function. Eager reduction presents many opportunities for parallelism, but unfortunately, is totally unable to handle streams. An optimal strategy for real-time applications thus appears to be a judicious mixture of both lazy and eager evaluation: combining the best, and avoiding the worst, aspects of both. This approach is taken in most dataflow machine designs, in which primitive actors such as c h o i c e are lazy, and also in some functional languages. Hope, for example, is basically eager, but has a lazy I/O sub-system [BURS80]. In summary, it has been argued that models of real-time systems have a natural affinity with functional models of computation; that precedents for implementing real-time systems as a functional architecture exist; and that the engineering requirements of realtime systems are strongly matched to the properties of functional programming systems. It is concluded that the requirements of real-time systems make it realistic to study implementations of functional programming systems on parallel processing hardware as a suitable basis for the design of real-time computer architectures. The graph reduction machine presented in this paper, CTDNet2, employs a mixed evaluation strategy. The underlying framework is eager, to provide high speed of response, but lazy e v a l u a t i o n is employed selectively to deal with vital real-time aspects such as I/O. CTDNet2 is implemented as a process model suitable for parallel implementation. This combination was developed experimentally in an early prototype known as CTDNet [GUPT85, GUPT89]. CTDNet has quite a cumbersome messagepassing scheme, and is based on string reduction.
S.C. Winter et al. I Real-t/me functional programming systems
493
2. The P r o c e s s M o d e l of G r a p h R e d u a t i o n
t i c e it m u s t also b e c o m e s t r a t e g i c a l l y eligible.
In common w i t h m a n y other g r a p h r e d u c t i o n systems [PEYT87], p r o g r a m s are r e p r e s e n t e d as a set of u n i q u e l y labelled, c o n n e c t e d p r o c e s s e s c a l l e d APPLYnodes. An A P P L Y - n o d e is t y p i c a l l y conn e c t e d to 3 others: its r a t o r , its r a n d and its p a r e n t . The rator and rand nodes are the roots of the rator and rand expressions; t h e p a r e n t n o d e is the root of the i m m e d i a t e l y e n c l o s i n g a p p l i c a t i o n expression. Thus, the g r a p h
For a r e d e x to be s t r a t e g i c a l l y elig i b l e in CTDNet2 it is n e c e s s a r y t h a t it should be c o n t e x t - f r e e , and t h a t its rand s h o u l d c o n t a i n no s t r a t e g i c a l l y e l i g i b l e redexes. Any r e d u c t i o n of this kind is called c o n t e x t - f r e e a p p l i c a t i v e r e d u c t i o n (CFAR). A p a r t i c u l a r l y s i m p l e C F A R strategy, in w h i c h the rator is also r e q u i r e d to contain no s t r a t e g i c ally e l i g i b l e redexes, is called i n n e r -
square
most context-free applicative reduction (ICFAR). Here, the i n n e r m o s t c o n t e x t -
= ~x. (*~ X X) = kx.(@
(@ .o x) x)
is r e p r e s e n t e d by two APPLY-nodes, A and B, in w h i c h A is B's parent, and B is A's rator: null
° A r e d e x is s t r a t e g i c a l l y e l i g i b l e in ICFAR ( I C F A R - e l i g i b l e ) if and only if the r e d e x is context-free, the rator is a c o n t e x t - n o r m a l function (abstraction or primitive) and the rand is a c o n t e x t - n o r m a l a p p l i c a b l e a r g u m e n t (function or value).
^A. or
~x.A /\ / \ ^B X
B /\ / "o
free redexes (those n e a r e s t the leaves of the graph) are always reduced first; w h i l s t t h o s e n e a r e s t the root are inhibited. The ICFAR e l i g i b i l i t y criterion is as follows:
\ X
e x p r e s s i o n is c h a r a c t e r ised in the f o l l o w i n g terms:
A context-free
A simple p r o g r a m to c o m p u t e the square of 2 is i m p l e m e n t e d as Definitions: nu I1
square
^~A. or
= ~x.A~ IX I \ ^B
B I\ I x
*=
\ x
^~square
In d i r e c t o r string terms, a r e d e x is c o n t e x t - f r e e iff its d i r e c t o r string is empty. e x p r e s s i o n is one cont a i n i n g no e l i g i b l e redexes u n d e r a CFAR strategy. Since any normal graph must also be c o n t e x t - n o r m a l (a normal graph is one c o n t a i n i n g no redexes at all), c o n t e x t - n o r m a l i t y of a node can be e s t a b l i s h e d locally in a c c o r d a n c e with the f o l l o w i n g criteria:
CO /
A r e d e x is c o n t e x t - f r e e if and only if it has no free v a r i a b l e s a n d it is not the root of an a b s t r a c t i o n expression.
A context-normal
Principal A~lication: /
A n o n - r e d u c i b l e e x p r e s s i o n is c o n t e x t - f r e e if and only if it contains no free variables.
\ \ 2
The symbol '&' d e n o t e s that the n o d e is the root of an a b s t r a c t i o n expression, ie. a f u n c t i o n definition.
° A n o d e is c o n t e x t - n o r m a l normal.
3. C o n t e x t - F r e e (CFAR)
° A n o d e is c o n t e x t - n o r m a l if its rator and rand are c o n t e x t - n o r m a l and it is not an e l i g i b l e redex u n d e r a C F A R - e l i g i b i l i t y criterion.
Applicative
Reduction
In the lambda calculus, a r e d e x is a n y r e d u c i b l e expression. However, in a g i v e n r e d u c t i o n scheme, a r e d e x is not s t r a t e g i c a l l y e l i g i b l e to reduce, until s e l e c t e d in a c c o r d a n c e with the r e d u c tion strategy. In o t h e r words, a r e d e x is only p o t e n t i a l l y reducible; in prac-
if it is
These rules allow a w a v e f r o n t of cont e x t - n o r m a l i t y tokens to p r o p a g a t e u p w a r d s from the leaves to the root. In CTDNet2, the symbol '%' is used to d e n o t e context-normality.
S.C. Winter et a L / Real-time functional programming systems
494
of the program.
4. Lazy Reduc~tion Mechanisms
@
A g r a p h w h i c h does not e v a l u a t e until n e e d e d is t e r m e d lazy. In CTDNet2, e v a l u a t i o n of a lazy g r a p h is i n h i b i t e d by m a r k i n g the p o i n t e r s to it (the symbol '£' is used). The lazy g r a p h itself is not marked, a l t h o u g h any node inhibited by a lazy p o i n t e r is still d e s c r i b e d as 'lazy'. Ordinary, u n m a r k e d graphs are eager, B e c a u s e lazy s u b g r a p h s can m a k e no c o n t r i b u t i o n to a computation, c o n t e x t n o r m a l i t y is a l l o w e d to extend above a lazy node. The f o l l o w i n g c r i t e r i o n is thus a p p e n d e d to the o h a r a c t e r i s a t i o n of c o n t e x t - n o r m a l i t y : " a n o d e is context-1~ormal lazy
if it is
This e x t e n s i o n of c o n t e x t - n o r m a l i t y allows c o m p u t a t i o n to p r o c e e d a b o v e a lazy node; it also permits a lazy g r a p h to be passed, unevaluated, as an argument, w h e r e the v a l u e of the g r a p h is not required. However, since lazy nodes are not a c t u a l l y c o n s c i o u s of t h e i r lazy status, the c r i t e r i o n is a p p l i e d to the pointers to lazy nodes.
.5.
/\ /
\
Output
@
/\ / Ma i n
\ I_.~Rq...t..
Note that the s t r e a m I ~ t . , rather than the f u n c t i o n Input has been included in the canonical model. This is d e f e n d e d on the g r o u n d s t h a t the input to the main f u n c t i o n is likely to be implem e n t e d as a folded stream, rather than as the result of a p p l y i n g a function to a null argument. Actually, Input was i n t r o d u c e d s o l e l y as a functional 'bridge' b e t w e e n the p r o g r a m and the p h y s i c a l input channel; formally, I [ ~ . u t . = (Input n i l ) .
~a.~..~.. Input
I ......
I
>
Main
.....
>
Output
I/O M o d e l s
In a typical f u n c t i o n a l program, the m a i n f u n c t i o n (Main) accepts an input s t r e a m of v a l u e s (Ip_/~_u.t.) as its argument, and the result of this a p p l i c ation is a n o t h e r s t r e a m (Main), as shown in F i g u r e 3.
~.~
I
. . . . . . . . . . . >1 Main
l
U aJLn..
:
F i g u r e 3. B a s i c I/O model of a f u n c t i o n a l program.
The s t r e a m ! Z , ~ A can be m o d e l l e d as the v a l u e of a f u n c t i o n Input applied to a null argument, w h i c h samples the p h y s ical input channel as a side-effect. The Mg_.i~.. s t r e a m can be p a s s e d as an a r g u m e n t to a n o t h e r function, Output, w h i c h has no formal result, but as a side-effect, sends the elements of its a r g u m e n t s t r e a m to the p h y s i c a l output channel. This is shown in F i g u r e 4. In the lambda calculus, the essential c a n o n i c a l model d e s c r i b i n g this situat i o n is as shown below. This model may be taken as the p r i n c i p a l a p p l i c a t i o n
F i g u r e 4. E x t e n d e d I/O model of a functional program.
Since streams are t i m e - o r d e r e d infinit a r y objects, one of the roles of r e f e r e n t i a l t r a n s p a r e n c y in the I/O model is to ensure that the sense of t i m e - o r d e r i n g is e v e r y w h e r e p r e s e r v e d t h r o u g h o u t the program. This model is e x t e n d e d to all streams, and so it is n e c e s s a r y to
(a) e n s u r e t h a t every s t r e a m is unique, ie. only one, shared, o c c u r r e n c e of each s t r e a m may appear in the program.
(b) ensure t h a t the event of e x t r a c t i n g the head of a s t r e a m occurs before the event of e x t r a c t i n g the tail of the stream.
(c) m a n i p u l a t e the w h o l e stream, even t h o u g h it may only be in a state of partial existence. Rule (a) is e n f o r c e d by a d o p t i n g a uniqueness r u l e for streams, w h e r e b y the name of a s t r e a m m a y appear in an a p p l i c a t i o n at most twice: once only in the p r o g r a m d e c l a r a t i o n outside the
S.C. Winter et al. / Real-rime functional programming systems
stream's definition, and once only within the definition. Sharing of the object is an intrinsic feature of graph reduction, implemented in CTDNet2 by weighted reference counting. Rule (b) is called the Access Law of Streams, and is enforced by the stream constructor itself, which is where requests for head and tail values are resolved. Rule (c) precludes applicative styles of evaluation, which are not generally suitable for dealing with folded (ie. infinitary) structures. As a footnote, it is reassuring to observe that physical input and output streams naturally satisfy the three rules of streams!
6. Stream Constructors Stream constructors are implemented as processes, called S T R E A M - n o d e s , having two children: the left child representing the head; and the right child representing the tail. Three types of STREAM-node are defined in CTDNet2: eager (both head and tail are eager); lazy-tail (only the head is eager); and lazy (neither head nor tail are eager). They are denoted by !!!, !! and ! respectively. For example, Stream
=
!! / / Stream~
\ \ Stream"
denotes a lazy-tail stream constructed from its (eager) head (Stream~) and its (lazy) tail (Stream'). Since a stream is strictly unique, unique meanings may be attached to each of its instantiations: the ith instance denotes the tail of the (i-l)th instance, ie. Streaml
denotes the whole of Stream
Stream2
denotes the tail of Streaml
Stream3
denotes the tail of S t r e a m 2
etc. The only permitted operations on streams are of two types: (i) extraction of the head (CAR-type) (ii) extraction of the tail (CDR-type) Since the primitive operations of head and tail extraction (CAR a n d CDR) are implemented by request to the STREAM-
495
node, the Access Law of Streams is enforced by the STREAM-node itself. Thus, at least one CAR-request must be received, accepted and despatched by the constructor, before a CDR-request may be dealt with; subsequently, requests may be processed in any order. It is the first request for the head (rather than the last), which is used to trigger access to the tail. This is justified since once the head has been fetched, the Access Law is sat!fled, and there is no further reason to delay the tail. Previously evaluated head and tail expressions may be despatched without delay to the requestor. When all outstanding requests have been received and processed, the current stream may annihilate - although the tail of the current stream, represented by the right child process, is not destroyed by this action. However, future contact with the tail would only be possible if at least one CDR-request had been processed by its parent before annihilating. It is assumed that the tail of a stream reduces to another stream, or to nil. Lazy tails are evaluated by removing the laziness at the root of the tail, and the tail is deemed to be evaluated when it attains context-normality. Of course, the tail may contain lazy subgraphs, since the extended criterion of context-normality takes account of laziness. Messages for lazy branches are held by the STREAM-node until evaluation is forced by the arrival of head and tail requests. For example, in a lazy-tail implementation of Stream, instant!at!on of S t r e a m 2 is inhibited until receipt and acceptance of a tail request (which must not, of course, precede despatch of a head request) by Strea=l; however, evaluation of the head is not inhibited. A lazy stream will also inhibit head extraction until receipt of the head request. Sharing of streams is implemented by the standard technique (weighted reference counting) of CTDNet2.
7.
Implementing the
I/O Nodel
Since the Access Law of streams holds naturally for physical input, there is only one relevant operation for the Input process to perform: GET, which samples the input channel and returns a value. The Input process must repeatedly perform this operation, but not prematurely; thus a natural implementation of input is as a lazy stream:
S.C. Winter et aL / Real-time functional programming systems
496
=
Input
! %
result is delivered internally, signifying completion (recall, Output technically delivers no result). This signal may then be used to annihilate the process representing the current instantiation of Output.
/\ /
\
/
V' ~ !n_~_u t
GET ~
GET is a function of zero arity and normally fires spontaneously. Making it lazy version inhibits its action until the laziness is explicitly removed by the lazy STREAM-node. The implementation above is designed to ensure that the GET operation remains unfired until a value is actually required by the Main function, and also that the recursire tail remains folded until the Main function requests its value. Although GET is nondeterministic (it returns an arbitrary value each time it is called), and thus not consistent with the property of referential transparency, the ~ 2 ~ . stream itself is referentially transparent, since by the Uniqueness rule it can only be invoked once - whereupon it delivers the entire stream (by virtue of lazy evaluation), whose value (albeit determined at run time) is the same everywhere in the program. An additional implementation rule may be introduced here, which is to permit only one declared call of the GET primitive: this rule is respected in the concrete implementation of !X~M£. given above. The purpose of the Output stream function is to repeatedly send the values of the Main stream as they emerge to the physical output channel. Thus, the Output stream is always ready to receive values, and it may be implemented as an eager stream, without risk of running-away uncontrollably:
No restrictions are placed on the implementation of the Main stream function. 8. I n t e r r u p t s For real-time systems, a facility for externally-generated interrupts is essential. In a functional environment, interrupts can be modelled in the same way as other inputs: by streams. In this case, firing of the primitive GET corresponds to enabling the interrupt: the environment always decides when an input value (including an interrupt) will be returned to the program. This delay does not affect the CTDNet2 reduction model, which is not timesynchronised, ie. the precise moment of arrival of a result to some part of a program does not affect the validity of the program. The sequence of actions triggered by the eventual arrival of the enabled interrupt is then the equivalent of an interrupt service routine. The following program prints the value 'i' on the Output stream each time an interrupt arrives on the Interrupt stream. D@~initions:
!_E£e r..K.u~.t..
=
!
/\ /
\
GET ~
V L~
.!~.t_e_t:_.r.q~.~:.
Output
=
!!!
/
\
/
Output
\
/ /
{as before}
\
@
@
/\
/\
I
=
\ Main
ks.
/ \ @ V''' \ / \ Output @
/ CAI~
\ / CDH
\ \
/
\
II
V '~:
/\
/\ s
!!
/
\
PUT
/
I
\
li
\
I
s
e I
I
\
/
/ \ The primitive PUT sends a value to the physical output device. To preserve referential transparency in the definition of Output, only one declared call of PUT is permitted. When PUT is applied to its argument, and the value sent to the physical channel, a n i l
I\ 1
\ @
Mair,
IX
\
I
\
SECOND
I @
CDH
/\
/ CAR
\ s
\ s
S.C. Winter et al. / Real-time funcUonal programming systems
497
~ C E S Princinal APPlication: BuRseo R.M. Burstall, D.B. MacQueen and D.T. Sanella: HOPE: an experimental applicative language, 1980 LISP Conf. Rec,, Stanford, CA, pp.138-143, 1980.
@
IX I
\
I
\
Output
@
/\ / / Main
\ \ In ter!u_uRt
DARL81 J.Darlington and M. Reeve: ALICE - a multi-processor reduction machine for the parallel evaluation of applicative languages, Proc. ACM Conf. Functional
Prog.
pp.65-75, The primitive SECOND used here is similar to Turner's K combinator: it takes the value of its second argument. It is strict on both its arguments, and is therefore forced to wait for the arrival of the interrupt, before delivering its result, i.
Lang.
Arch.,
GRKI¢89
M. Greenberg and V. Woods, F L A G SHIP - A Parallel R e d u c t i o n Machine for D e c l a r a t i v e P r o g r a m m i n g , Int. Report, Dept. Comp. 1989. GUPT85
Sol., Manchester Univ.,
J.P.Gupta,
CTD M u l t i p r o c e s s o r
9. Conclusions
and Comput.
1981.
Thesis, 1985.
The R e a l i s a t i o n of a Architecture, PhD
Polytechnic of Central London,
The feasibility of embedding the technologies of functional programming and parallel processing into the design of real-time systems has been demonstrated through t h e CTDNet2 reduction machine. The desirability of functional programming for real-time applications stems firstly from its formal, declarative nature, and secondly its amenability to parallel implementation. The former property leads to increased system integrity and safety; the latter has a beneficial effect on liveness and timeliness, through the increased computational rates.
GOIPT89 J.P.Gupta, S.C. Winter and D.R. Wilson: CTDNet - A mechanism for the concurrent execution of lambda graphs, IEEE Trans. S o f t w a r e Eng., Vol. C-15, No. ll, Nov. 1989.
It has been shown how some major constructs required for real time processing, notably I/O handling and interrupt processing, are implemented in CTDNet2. Other aspects not presented here, such as multitasking, multiple I/O channels and non-determinism, are discussed in [TINT90].
LAND64 P.J.Landin: The mechanical evaluation of expressions, Computer Journal, VoI.6, pp. S08-S20, 1964.
CTDNet2 has been validated through detailed simulated execution of several problems. Based on 2 benchmark examples, the number of messages sent, and the number of processes instantiated in the system, shows a reduction of the order of 25%, when compared with CTDNet. The improved efficiency is due partly to the adoption of graph, rather than string, reduction. In particular, the implementation of lazy evaluation in CTDNet2, when combined with graph reduction prevents much unnecessary process instantiation.
MAGO80 G.A. Mago: A cellular computer architecture for functional programming, Proc. IEEE COMPCON, pp.179-187, 1980.
CTDNet2 is currently being implemented on a transputer network.
HOAR85
C.A.R. Hoare, C o m m u n i c a t i n g Processes, Prentice-Hall,
Sequential
1985. KALI89 D. Kalinsky and J.Ready: Realtime operating system kernel technology for the 21st Century, Proc. 2nd IEE Int. Conf. on S o f t w a r e Eng. for Realtime Systems, Cirencester, Sept. 1989.
LAND85 P.J.Landin: A correspondence between Algol 60 and Church's lambda notation: Part I, Comm. ACM, Vol.8, pp.89-100, Feb. 1965.
I~T87
S.L.Peyton-Jones, The I m p l e m e n tation of F u n c t i o n a l P r o g r a m m i n g Languages, Prentice-Hall, 1987. WADS71
C.P. Wadsworth,
Pragmatics
Thesis,
S e m a n t i c s and of the Lambda Calculus, PhD
Oxford University,
1971.
WINTgO S.C. Winter, A d i s t r i b u t e d reduction a r c h i t e c t u r e for r e a l - t i m e computing, Research Report, Polytechnic of Central London,
1980.