Developing a Customisable Programming ... - Semantic Scholar

Developing a Customisable Programming Environment for Message Passing based Systems Mats Aspnas

Thomas Langbacka

 Abo Akademi University Department of Computer Science Lemminkainengatan 14{18 SF{20520  Abo, Finland fmats,[email protected]

Ivan Porres Paltor Universidad Politecnica de Valencia Escuela Universitaria de Informatica Camino de Vera s/n 46020 Valencia, Spain [email protected]

Abstract

We describe DiGraph, a customisable graph editor that has been built using the Tcl/Tk programming system. We show how DiGraph can be customised to act as a programming environment for the Hathi-2 transputer machine. We also discuss how DiGraph could be used as a base for building programming environments to other parallel/distributed systems that use point-to-point message passing.

1 Introduction Already starting from the Poker [17] programming environment, graphs have been a very popular visual basis for tools supporting development of parallel/distributed programs. The tools described in the literature have supported dierent aspects of parallel/distributed program development, like process-toprocessor mapping [18], program debugging and monitoring [9] or more generally program coding and structuring [4{6,18]. Indeed, graphs can be used to visualize many dierent aspects of parallel/distributed systems and programs. One diculty when discussing programming tools for parallel/distributed systems, is the (implicit) assumptions made of the underlying hardware. For  Erasmus exchange student at the Department of Computer Science at  Abo Akademi University 1.10 1994 { 31.3 1995.

1

instance, in the paper describing the Enterprise [14] environment, some good arguments are given for why graphs aren't always the best solution when describing distributed/parallel programs. The process of explicitly connecting nodes together using pointing and clicking, required in most graph based systems, can be time consuming. However, the programming model of Enterprise is such that it really couldn't make much use of a graph-based representation. Our experiences with the Millipede environment [1] suggests that graphs are a very convenient abstraction mechanism in tools designed for systems based on point-to-point message passing. Millipede was built for the transputer [11] machine, Hathi-2 [2], and the underlying programming model was the CSP/Occam model [8, 10]. Millipede was an ambitious project where we tried to develop an environment that would provide a uni ed user interface to all tools that are used in program construction. It was based on the use of hierarchical attributed graphs. With an attributed graph we mean a graph whose nodes and edges may have attributes associated with them. Attributes associated with a node could be it's name etc. A hierarchical graph is a graph where a node may contain a subgraph. In Millipede, hierarchical attributed graphs were used as a representation of distributed programs. Thus it was the idea that activities like mapping, performance monitoring, debugging of a program, as well as the construction of the program itself in the rst place, could make use of this one graph based framework. Millipede had some drawbacks. It was inecient and supported only bottomup construction of graphs. Furthermore, there was no support for replicating nodes. These problems will be described in more detail in section 2. These drawbacks motivated us to redesign the Millipede environment. The result, DiGraph (see section 3 for a thorough description), is a customisable graph editor for designing hierarchical attributed graphs. We have customised it to be used as a programming environment for the Hathi-2 system (see section 4). Section 5 describes how it could be customised to act as a programming environment for a transputer network running the virtual channel router (VCR) [7]. An environment like this could be thought of as a user interface to the new T9000 generation of transputers as well.

2 Experiences with the Millipede environment The Millipede programming environment was our rst implementation of a programming environment based on hierarchical attributed graphs. Our current work is strongly in uenced by the experiences gathered from working with the Millipede environment. The most important conclusion drawn from these experiences is that the program representation that we based the environment on, i.e. hierarchical attributed graphs, is an ecient and intuitive way of representing distributed programs that communicate using message passing. However, the Millipede environment had a number of problems, which we have tried to solve by developing the DiGraph environment. The Millipede environment was speci cally built to be used for writing pro2

grams in Occam-2 on the Hathi-2 multiprocessor. The environment did not support any other hardware architectures than the Hathi-2 system, nor any other languages or message passing systems than the Occam-2 toolkit. Moreover, the environment was to a large extent designed for this particular combination of hardware and software, and would not have been easy to modify for other systems, although the ideas could have been applied to other environments as well. The Millipede environment was implemented using Design/ML, a programmable graph editor. This system provided a graphical user interface for creating and manipulating graphs. It also allowed a user to extended its functionality using the programming language Standard ML [13]. This system was chosen after many unsuccessful experiments with other tools, and at that point of time Design/ML seemed like an ideal solution. However, during the implementation of Millipede it turned out that the Design/ML system was not as easy to customize for our particular need as was expected. The set of basic SML functions that were available for extending the functionality was relatively small and in many cases insucient. For instance, the notion of graph hierarchies was poorly supported. This feature had to be implemented using various tricks, which made the traversal of the graph hierarchies unnecessary slow. Our representation of graph hierarchies also made it impossible to construct graphs in a top-down fashion. Based on these experiences we wanted to build DiGraph using a more convenient tool than Design/ML. We wanted a general yet powerful tool allowing implementational freedom but still making quick results possible. We were also concerned about eciency issues. Furthermore, we wanted DiGraph itself to be an open system that can be adapted to dierent uses. The choice of using the Tcl/Tk programming system seems to have been the right decision given the above, to some extent con icting, criteria of choice.

3 DiGraph DiGraph is a general purpose visual graph editor. It is implemented using the Tcl/Tk [12] programming system and is highly customisable. It has a menudriven user interface where the user can create directed graphs using the mouse and keyboard of his/her workstation in a WYSIWYG fashion. It supports the construction of hierarchical and attributed graphs, concepts which will be described below. DiGraph oers a procedural interface that can be accessed by means of Tcl/Tk programming.

Attributed hierarchical graphs DiGraph implements a hierarchical graph

structure. There are two basic types of nodes: simple and compound nodes. A compound node contains a reference to a subgraph whereas a simple node doesn't. The subgraph of a compound node can contain another compound node, and so on, allowing the creation of multi-level hierarchical graphs. This helps the user to structure big graphs. The nodes and edges in DiGraph are attributed. That is, the objects, i.e. 3

Figure 1: A sample view of the user interface of DiGraph nodes and edges, of the graph can have values associated to them. These values can be, for example, integers, le names etc. The only default attribute of both nodes and edges is it's label, a text string containing the name of the object. New attributes can be added through a con guration le. As mentioned above there are two basic types of nodes: simple and compound nodes. One can divide the simple nodes into a set of distinct subtypes. This means that two nodes that belong to dierent subtypes are both simple nodes, but with a dierent set of default attributes. The dierent node types are associated with a bitmap, making it possible to visually recognise the type of any node.

The user interface The user interface of DiGraph has the general appear-

ance shown in Figure 1. When DiGraph is started, the user is presented with an empty graph window. Within this window the user can create and move nodes using the mouse. An edge connecting two nodes can be created by clicking on the source and target nodes. DiGraph automatically arranges the edges to tidy up the graph. Deleting and copying nodes are also simple mouse operations. Attributes of a node or a edge can be edited by means of a dialog box that pops up on a mouse click. There is also a set of le operations for saving and loading graphs. Graphs are stored as Tcl/Tk code, which means that they don't need 4

much storage space. Compound nodes are created by using the zoom in command on a simple node and creating a new graph into the new empty graph window that the zoom in operation creates. In the same way a user can at any time zoom into a compound node to view and edit it's subgraph. The user can drag a node, simple or compound, and drop it into a compound node or lift nodes out from compound nodes. This way the graph can be manipulated in both top-down and bottom-up fashion, whichever is more suitable for the user. As an example graph consider the graph in Figure 1. The graph in the displayed window contains six nodes. The nodes come from three dierent classes, each de ning it's own bitmap for display. The node labeled Process is a compound node. By selecting this node and zooming in on it the graph in the window disappears and is replaced by the subgraph that Process refers to. After zooming in one can zoom out, recreating the original graph. Edges going into and coming out from a compound node (like NOT Sensor1 and Sensor2 in the example graph) are normally further connected to some node in the subgraph of the compound node. Connections from a subgraph to the level above it are represented using small squares, called connectors, such as the ones that can be seen in Figure 3. Edges connected to a compound node in practice consist of two separate edges linked together through a connector. If the subgraph of a compound node is lifted up to the higher level, the compound node is destroyed and the subgraph is displayed in it's place. The edges that have been linked via a connector are united and the connectors removed. Sometimes there are edges in the graph where either end of the edge is loose, i.e. not connected to any node. The loose end of such an edge is then connected to a connector instead. The connector can be dragged to a node to establish the connection, after which the connector is removed. Loose ends can be created when the node on either end of an edge is deleted or when nodes are duplicated. It is also possible for a user to create loose ends deliberately, a feature that can be used for example in an early stage of the graph design.

The procedural interface DiGraph provides a set of Tcl/Tk procedures

for extending it's functionality. There are commands for creating and deleting nodes and edges. There are procedures for reading and modifying attributes. An important procedure performs recursive traversal of a graph. This procedure takes an other procedure as a parameter. The supplied procedure is called every time the traversal algorithm visits a new node. There is a procedure for retrieving the type of any node, so that dierent actions can be performed for dierent types. Thus, it is possible to traverse the graph and perform modi cations to it, or extract information from it, or do whatever else the user wants. The user interface of DiGraph can easily be enriched with new menus, command buttons and other widgets using Tcl/Tk programming. These widgets can then be associated with procedures built using the procedural interface (but they can of course be any command allowed by Tcl/Tk). Also the basic editor itself can freely be modi ed by means of Tcl/Tk programming, although this 5

requires knowledge of the internal workings of DiGraph.

4 A programming environment for Hathi-2 In this section we will show how DiGraph can be customised to be used as a programming environment for the Hathi-2 transputer machine. We begin by brie y describing the Hathi-2 architecture speci cs. We then proceed by describing the customisations done to DiGraph. Finally, we show, using an example, how a graph constructed using this customised version of DiGraph can be turned into an executable program.

4.1 The Hathi-2 system

Architecture Hathi-2 is a recon gurable transputer-based multiprocessor consisting of 25 identical boards, each containing 4 T800 transputers, one C004 crossbar switch and one controlling T212 transputer. The T800 transputers are used for running user programs. The hardware elements on each board are organised so that the system can be con gured in numerous dierent ways (see [2,3] for details of the hardware organisation). Users access Hathi-2 via a Sun workstation (the host computer), which is equipped with a host transputer (also a T800). Hathi-2 can be seen as consisting of two separate subsystems: a network of 100 T800 transputers and a control system, which (among other things) controls how the processors in the network are connected to each other. System software The system software for Hathi-2 that is of interest for the scope of this paper consists of two components: a con guration tool and a mapping tool. The con guration tool de nes a simple language for describing how the T800 transputers should be connected. A description of a network given using this language is then translated into an appropriate set of commands to the control system, which establishes the requested connections. The mapping tool is based on a heuristic process-to-processor mapping algorithm [15] which has been implemented in Occam-2 [16]. The algorithm guarantees that a successful mapping is always found, by further joining processes, if a mapping cannot be found otherwise.

4.2 DiGraph as a programming environment for Hathi-2

Graphs as programs Customising DiGraph to be used as a programming environment to the Hathi-2 system is quite straightforward. Basically the nodes in a graph constructed using DiGraph are interpreted as a set of parallel Occam2 procedures. We add an extra attribute to all simple nodes that gives a pointer to a text le containing the source code for a procedure. DiGraph is then equipped with a command for starting an editor on the le a particular node is associated with. Compound nodes are just interpreted as a set of parallel calls to the procedures denoted by the nodes in its subgraph. The edges describe communication 6

channels between procedures. To the edges we add an attribute that de ne the protocol used for communication between the processes connected by the edge.

host

results

commands

tmp

pass2

pass1

Figure 2: A very simple program With these additions, a DiGraph top-level graph (constructed in a way described below) can actually be transformed to an Occam-2 program in a relatively straighthforward way. The nodes in the top-level graph describe procedures that are assumed to be run on separate processors. To distinguish the host transputer from the rest, a speci c node class denoting the host transputer is introduced. Below we will, using Figures 2 and 3 as illustrations, show in more detail how this transformation takes place. Figure 2 shows a top-level graph consisting of three nodes. The node named host is the specialised node that denotes the host transputer of the described transputer network. The Node pass1 is a compound node containing a subgraph. Lastly, pass2 is a simple node. The three edges commands, tmp and results connect the graph circularly. The two simple nodes have associated with them source code les, which contain an Occam-2 process. In the code the two simple nodes can use the names of the edges as logical channel names. Thus, in the code for pass2 it is possible to input data over the channel tmp.in and output data over the channel results.out (observe the extensions .in and .out to the name of the edge depending on the direction). The subgraph of the compound node pass1 is shown in Figure 3. This graph consists of just two simple nodes pre and post connected to each other via the edge middle. The edges commands and tmp are the connections to the 7

commands

pre middle

post

tmp

Figure 3: The subgraph of the compound node in Figure 2 upper level of this subgraph.

Additions to DiGraph's interface The interface of DiGraph is modi ed

by adding commands for code generation from graphs as well as compilation and execution of generated code. When code is generated the top-level graph is recursively traversed, and for each simple node that is found a source code le, in the form of an Occam-2 procedure, is created. The procedure head is constructed from the process name attribute giving the procedure name. The formal parameter list of the procedure is constructed using the name and protocol of the edges associated with the process. The procedure body is simply constructed from the user-provided source code associated with the node. For each compound node, a similar source code le is generated. The procedure head is constructed as above. The procedure body is constructed by parsing the subgraph and invoking all the procedures de ned in this subgraph in parallel with an Occam-2 PAR statement. To generate actual channel parameters for the procedure invocations, the environment has to parse the subgraph and extract information about how the constituting processes are interconnected. The top-level graph describes a partitioning of the process graph onto a logical processor network. The process-to-processor mapping tool (see section 4.1) automatically allocates the logical processor network onto physical processors in a way that can be realized on the target multiprocessor. The result of the mapping is a source code le (in Occam toolset terms a .pgm le) that exactly describes how the logical processor network is mapped 8

onto the target processor network. This le speci es exactly on which physical processors the logical processors are placed, and which physical communication channels are used to connect the processors to each other. When compiled, this produces an executable image that can be loaded onto the target multiprocessor system and executed. The mapping of the top-level graph onto the physical processor network also de nes the required con guration of the target network. This information is used to automatically recon gure the target multiprocessor system. The environment builds a text le describing how the target network should be connected in order to match the top-level graph de ned by the user. This le is given as input to the con guration tool (see section 4.1).

5 Looking to the Future { an environment for VCR In this section we present an example of how DiGraph could be customised for another type of parallel hardware and software. We now assume that our parallel system provides automatic message routing and multiplexing. This is exactly the programming model supported by the T9000 transputer, together with the C104 routing chip.

The Virtual Channel Router The programming environment will be based

on VCR, the Virtual Channel Router, a software package developed at the University of Southampton. VCR gives the user access to unrestricted channel communication across an arbitrary network of T8-series (or T4-series) transputers. Occam-2 programs based on VCR are independent of the network topology, and thus portable between dierent transputer systems. The routing and multiplexing mechanism in VCR is embedded within the compiler and preserves the Occam-2 syntax and semantics. Since the programming system provides automatic message routing and multiplexing, it is possible to connect any two transputers in a network with an arbitrary number of channels. It is no longer necessary to exactly specify how processes are placed onto processors and channels to communication links. Instead, the user declares a number of virtual processors and the code associated with these, and the virtual channels connecting the processors. In VCR, the virtual processors are placed onto physical processors by a very simple mapping scheme, which starts by placing virtual node zero on processor zero, virtual node one on processor one, and so on. If there are more nodes than physical processors, a modulo-style wrap-around occurs and more than one node will be executed on the same processor. This mapping, unlike the mapping tool developed for Hathi-2, assumes that we have a xed network topology.

A programming environment for VCR A programming environment for use with VCR is very similar to the one described earlier in section 4. The main dierence is that now the top-level graph of the program does not necessarily describe the processor network that will be used to execute the program. The program described by the top-level graph will be mapped onto the transputer 9

network as described above. This automatic mapping, together with the routing, hides the placement of processes and channels to processors and links from the user. This means that the mapping tool used in the programming environment for Hathi-2 is no longer needed in order to generate an executable program from the labeled graph representation. To generate executable code from a program described in DiGraph, the graph is parsed and code for the individual processes is generated as before. The top-level graph is described by a .pgm le, which can directly be compiled. However, the mapping scheme of VCR is very simple and does not take any advantage from the information about which nodes in the graph are neighbours. This means that the produced executable program might be placed onto processors in an inecient way. The mapping can be improved by placing neighbouring nodes (i.e., nodes that in the top-level graph are directly connected to each other) on neighbouring processors. This can be done in two dierent ways. Firstly, we can use the same mapping tool that was used in the environment for Hathi-2, and map the program onto a xed hardware topology. This can be done using a VCR device le, which speci es that a particular process should be executed on a speci ed physical processor. The mapping tool we use is dependent on the Hathi-2 architecture, but in a dierent transputer network any other suitable mapping tool could be used. Secondly, we could also let the user manually map the program onto the processor network. The environment would then present the hardware structure, using a special type of graph. The user designs the program in the same way as before. Mapping would then be done simply by dragging and dropping processes of the program graph onto the hardware graph.

6 Conclusions In this paper we have presented the customizable graph editor DiGraph. We have shown that it can be customised to act as a programming environment for the Hathi-2 transputer machine. The programming environment generated is a re-implementation of an earlier system, Millipede. The current system doesn't yet have all the functionality of Millipede, but the parts that are implemented are more general and ecient than in Millipede. We also showed how DiGraph could be customised for use as a programming environment for the T9000 generation of transputers. In the near future we hope to be able to start working on a version of DiGraph for VCR according to the description in section 5. We will continue the development of the Hathi-2 programming environment, for example by adding support for presentation of performance monitoring data, a function which was available in Millipede. Furthermore, we have plans to use the graph based interface as a frontend to the Occam Toolset debugger. We will also add support for constructing large graphs, by adding functions for building common replicated structures, a feature present in many existing systems [4, 5, 14]. 10

The DiGraph editor, as well as extensions which can be of general interest, will be made available by anonymous FTP.

Acknowledements We wuold like to thank Michael Butler for his comments on this paper.

References [1] M. Aspnas, R.J.R Back, and T. Langbacka. Millipede: A programming environment providing visual support for parallel programming. In Wouter Joosen and Elie Milgrom, editors, Parallel Computing: From Theory to Sound Practice - Proceedings of EWPC'92, pages 236{247. IOS, 1992. [2] M. Aspnas, R.J.R. Back, and T-E. Malen. Hathi-2 multiprocessor system. Microprocessors and Microsystems, 14(7):457{466, September 1990. [3] M. Aspnas and T. Langbacka. Using a graphical environment to program transputer networks. In Lars Annell and Martin Torngren, editors, Nordic Transputer Applications - Proceedings of the 1st and 2nd Nordic Transputer Seminars, pages 1{18. IOS, 1991. [4] D.A. Bailey, J.E. Cuny, and C.P. Loomis. ParaGraph: Graph editor support for parallel programming environments. International Journal of Parallel Programming, 19(2):75{110, 1990. [5] A. Beguelin, J. Dongarra, G.A. Geist, R. Manchek, K. Moore, P. Newton, and V. Sunderam. HeNCE: A Users Guide v. 2.0, 1994. Available by anonymous ftp from ftp.netlib.org. [6] J.C. Browne, M. Azam, and S. Sobek. CODE: A uni ed approach to parallel programming. IEEE Software, pages 10{18, July 1989. [7] Mark Debbage, Mark Hill, and Dennis Nicole. Virtual Channel Router Version 2.0 User Guide. Department of Electronics & Computer Science, University of Southampton, 1990. [8] C.A.R. Hoare. Communicating Sequential Processes. Prentice{Hall, 1985. [9] A. Hough and J. Cuny. Initial experiences with a pattern-oriented parallel debugger. SIGPLAN Notices, 24(1):195{205, January 1989. [10] Inmos Ltd. Occam2 Reference Manual. Prentice{Hall, 1988. [11] Inmos Ltd. Transputer Reference Manual. Prentice{Hall, 1988. [12] John K. Ousterhout. Tcl and the Tk Toolkit. Addison{Wesley, 1994. [13] L. C. Paulson. ML for the working programmer. Cambridge Univ. Press, 1991. 11

[14] J. Schaeer, D. Szafron, G. Lobe, and I. Parsons. The Enterprise Model for Developing Distributed Applications. IEEE Parallel and Distributed Technology, 1(3):85{96, 1993. [15] H. Shen. Self-adjusting mapping: a heuristic mapping algorithm for mapping parallel programs onto transputer networks. In J. Wexler, editor, Developing Transputer Applications (Proc. 11th Occam User Group Technical Meeting), pages 89{98. IOS, 1989. [16] H. Shen. Occam implementation of process-to-processor mapping on the Hathi-2 transputer system. In Peter Welch, Dyke Stiles, Tosiyasu L. Kunii, and Andre' Bakkers, editors, Transputing '91 - Proceedings of the World Transputer User Group Conference, Volume 1, pages 139{158. IOS, 1991. [17] L. Snyder. Parallel programming and the Poker programming environment. IEEE Computer, 17(7):27{36, July 1984. [18] M. Stephenson and O. Boudillet. GECKO: A graphical tool for the modelling and manipulation of occam software and transputer hardware topologies. In Charlie Askew, editor, Occam and the Transputer - Research and Applications (Proc. 9th Occam User Group Technical Meeting), pages 139{ 144. IOS, 1988.

12