At this point, the programming model for the machines remained pretty much as it had been in 1982. A program running on the host computer loaded an application into the hypercube nodes, and then passed data back and forth with routines similar in nature to the rdIH and wtIH calls described earlier. This remained the only method through which the nodes could communicate with the outside world.
During the Mark II period, it had quickly become apparent that most users were writing host programs that, while differing in detail, were identical in outline and function. An early effort to remove from the user the burden of writing yet another host program was a system called C3PO [Meier:84b], which had a generic host program providing a shell in which subroutines could be executed in the nodes. Essentially, this model freed the user from writing an explicit host program, but still kept the locus of control in the host.
Cubix [Salmon:87a] reversed this. The basic idea was that the parallel computer, being more powerful than its host, should play the dominant role. Programs running in the nodes should decide for themselves what actions to take and merely instruct the host machine to intercede on their behalf. If, for example, the node program wished to read from a file, it should be able to tell the host program to perform the appropriate actions to open the file and read data, package it up into messages, and transmit it back to the appropriate node. This was a sharp contrast to the older method in which the user was effectively responsible for each of these actions.
The basic outcome was that the user's host programs were replaced with a standard ``file-server'' program called cubix. A set of library routines were then created with a single protocol for transactions between the node programs and cubix, which related to such common activities as opening, reading and writing files, interfacing with the user, and so on.
This change produced dramatic results. Now, the node programs could contain calls to such useful functions as printf, scanf, and fopen, which had previously been forbidden. Debugging was much easier, albeit in the old-fashioned way of ``let's print everything and look at it.'' Furthermore, programs no longer needed to be broken down into ``host'' and ``node'' pieces and, as a result, parallel programs began to look almost like the original sequential programs.
Once file I/O was possible from the individual nodes of the machine, graphics
soon followed through Plotix [Flower:86c], resulting
in the development system shown in the heart of the family tree (5.3).
The ideas embodied in this set of tools-CrOS III, Cubix, and Plotix-form
the basis of the vast majority of C
P parallel programs.
Figure 5.3: The C
P ``Message-passing'' Family Tree