Some Aspects of the Symbolic Manipulation of Computer Descriptions #

Traditionally computer descriptive languages have been designed primarily for human communication and/or simulation. Due to this narrow range of applications the existing languages have taken on a strong degree of similarity. In this paper we present some applications in the realm of automatic design of both hardware and software where a computer description language could serve as the information exchange media between the user and the design automation system. The paper discusses an environment for research on the applications of computer descriptive languages, emphasizing the multiplicity of of users and tasks that may coexist an any point in time. Some properties needed in a computer descriptive language are presented. A structured programming approach to hardware design is presented by example. * This paper describes a current research effort at Carnegie-Mellon University. The authors wish to make clear the active role being played in this research project by many other members of the CMU community: Samuel Fuller, Paul Hilfinger, David Jefferson, Karla Martin, Joseph Newcomer, Allen Newell, John Oakley, Mary Shaw, Richard Swan, and William Wulf. This work is supported in part by the Advanced Research Projects Agency (ARPA) of the Department of Defense, under contract F44620-73-C-0074, monitored by the Air Force Office of Scientific Research and by the National Science Foundation under grant GJ 32758X. Some Aspects of the Symbolic Manipulation of Computer Descriptions 1


ent programmi
g languages which manipulate machine descriptions given in different computer description languages.One of the key issues is the specification of adequate computer description languages.We Some Aspects of the Symbolic Manipulation of Computer Descriptions 2 discuss some properties desired in such notations and, finally an example in a structured programming approach to top-down computer design is used to, present some of our ideas in just one of the several areas of our research interests, albeit a crutial one.


MACHINE RELATIVE SOFTWARE

There is a continual stream of new machines spurred by the advent of minicomputers and microprocessors.Each machine has a different Instruction Set Processor (ISP) [Bell, 1971].The emergence of microcoded systems with the option of user defined instructions has increased this flow of ISPs.Each new system requires supporting software and the amount of software grows for any individual system as user requirements grow.

There are a number of directions in which to seek a solution to ease the burden of software development.Standardization of software packages written in high level languages such as Algol, FORTRAN, and COBOL is one approach.It reduces the amount of software needed for each new machine.A second direction is in terms of better software production systems.This may be sought either in terms of implementation systems (high level languages specifically designed to aid implementation) or in terms of better software methodologies (e.g., structured programming).Another direction, which we will consider in detail, is to relativize the production of software to the description of the machine. of Computer Descriptions


APPLICATIONS OF COMPUTER DESCRIPTIONS

To be clear about the multipurpose character of a computer description, let us list several kinds of problems that one might want to solve, each of which requires an abstract description of a compu

r.


1) Compiler-Compiler.
A system that takes as input a description of a language and a description of a machine and outputs a compiler for that computer.Given the state of the art, the language would probably be restricted to be Algol-like.[Miller, 1971] is an early attempt at a solution to this problem.

2) Verification of I/O programs.-Givenan I/O program, such as a device handler, and a description of both the computer and the hardware dev ce controller, verify that the program works.This problem has some special features that set it apart from the general program verification problem, besides its importance as an applied task: (a) its strong dependence on the description of computer systems in classic form (i.e., at the Register Transfer level) rather than in some abstract semantics, (b) the programs themselves may not be very complex in terms of their algorithms; rather the complexity of the task arises from the openness of the environmental states that have to cope with (timing, concurrency, etc.)


3) Programming of Micro coded Special Computers.-

The ability to create specialized computers to perform particular narr

one-time programming tasks

The centra
ingredient of this latter approach is the description of computer systems in a symbolic form, such that a range of problems can be solved by manipulation of these descriptions.We stress the need for di

rsity in the problem do
ain if we are really to understand how to operate relative to computer descriptions.

The next section will illustrate some points in the problem domain.

that poses an immense problem.These systems attempt to optimize performance; their organization cannot be dictated by considerati ns of programming ease.Their programming will become difficult in the extreme, especially when no opportunity will exists for the growth of programming know-how.This suggests that what the human will do is to program relative to a machine description that he has barely assimilated.Hence it is reasonable to construct programming systems that operate relative to machine descriptions of a class of machines.

4) Design of Modular Systems.-Given a desired machine described in terms of some specification language, and given a space of machines defined by a class of Register Transfer [Bell, 1971] level modules, design a machine according to various constraints and criterion functions.This is a classic design sit

tion which is worth studying, both in terms of und
rstanding the nature of design and in terms of automating computer design.The feasibility of this approach has been demonstrated by the EXPL system [Barbacci, 1973b].

5) Design to specification.-Given a functional specification for a computer and a space of computer systems defined by a computer description language, design a computer that performs to the specification.This is another form of the classical design task.It differs from (4) above.A typical task here is: given some general func ions, create an ISP for a computer.A typical task in (4) is: given a ISP, design it in terms of Register Transfer level modules.Formally they may seem identical, but the design spaces look quite different.6) Design Verification.-Givena specification for a computer and a description of that computer in the language, verify that the computer satisfies the specification.We can also include here the automatic generation of testing and diagnostic programs.7) Manual generation.-Given a computer defined in the language, create the documentation for the computer.This task is quite different from the ones above, but also involves understanding and manipulating a computer descript

n.The applications li
ted above place a variety of demands on the computer descriptive language and it is hardly clear whether a single language can cover the entire spectrum.The next sub-sections give some examples of the requirements for two rather different tasks and an outline of a possible system to meet the variety of requirements. of Computer Descriptions Machine Relative Compiler-Compilers.-By"machine relative" we imply an extension to the traditional definition of a compiler-compiler, in which a specific target ma

ine is assumed.Due to this li
itation, compiler-compilers have solved only part of the automatic programming problem and as a result they have not been very succesful.A better approach has been to produce a compiler that generates pseudo-machine code.

For each new ISP the programmer simply provides the equivalent of the pseudo-machine instructions in terms of macros written in the target machine language [Feldman, 1966].While runnable programs are produced by this technique they are poor in terms of size and run time efficiency.There are several reasons for this lack of efficiency: built-in preconceptions about existing instructions, the introduction of an extra level of abstraction that must be hand translated, the lack of consideration for specific machine features that can do certain things more efficiently that others, etc.

Hence we are primarily interested in generating an optimizing compiler.In order to generate machine code that will rival that of a good programmer, a compiler-compiler must extract the idiosyncrasies of the machine.For example, one way to add four to a register in the PDP-11 [DEC, 1973] is to use the instruction "ADD tt4,Rr\ This requires two 16-bit words, one for the instruction and one for the immediate operand 4.However, the autoincrement addressing mode adds two to a designated register after using its contents as

that effectively is a No-
peration code and uses the autoincrement mode on the register for both source and destination operands can achieve the effect of adding 4 to the register.Thus "CMP (R1) + ,(R1)+ M will add 4 to Rl and requires only one 16-bit word.Note that the compare instruction is not a true NOOP since it will set the of Computer Descriptions condition code registers according to the result of the comparison.The compiler has to in ure that this side effect is not critical.One such critical case would be if the contents of Rl is used as a loop index and a loop exiting branch was to follow the addition* Note further that Knowledge of the relative speed of instructions and addressing modes may be necessary to make a choice on the basis of speed* Some of the information that needs to be extracted from the machine description is: the data types (address, integers, floating point, etc), operations on the data types (add, subtract, multiply, etc), location of data types (memory, register, etc), and instruction side e fects (condition codes, use of hidden operands, etc).Instruction side effects are particularly important.The following PDP-11 code sequence is a good One of the desired goals of a compiler is to produce the minimum cost code sequence which evaluates a given program.It is therefore necessary to explore all possible sequences that represent the evaluation and are semantically equivalent and eliminate those that exceed the least-cost criteria.This semantic equivalence is Some Aspects of the Symbolic Manipulation of Computer Descriptions 7 related to the effect on the global program state in the context in which the sequence is to be executed.It is therefore necessary to express the global program state conditions under which a code sequence can be applied, as well as the resulting transformations on the state.This synergistic effect of machine language instructions has not been considered part of the realm of traditional computer description languages.

The cost of compile time generation of cases must be weighted against the advantages of finding the best code sequences.An intermediate solution is the exhaustive generation of templates to guide the code generation, as in traditional compilers.This once-only exhaustive generation process is more likely to find all the obscure cases and discover unspected semantic equivalences than hand-designed templates [Newcomer, 1974].


Modular Designs

Now consider a modular design program that produces a finished machine design in terms of a predescribed module set.A modular implementation of a system can usually be divided into a data part and a control part that directs the actions of the data part [Bell, 1972].The data types and their operations can be implemented via templates of modules.Again, as in the case of the compiler-compiler, synergistic eff in order to produce the most efficient network of modules for a given machine description.This implies certain commonality of information required by this two applications.However, there are many details of a module set that the compiler-compiler does not need to know.Assume that the modules are commercially available s miconductor chips and that the output from the design program is a printed circuit board layout.Knowledge of chip orientation, power requirements, Some Aspects of the Symbolic Manipulation S of Computer Descriptions
1 1 1 1 1 1 1 1 1 1 1 1 LI L2 L3 ... 1 1 1 1 1 1 1 data base Figure 1. The environment
The user inputs information into the data base via one or more computer description languages.The application programs manipulate the global data base to extract information in the format desired by the application.

The data base and its manipulation programs must be able to support many and chip spacing is needed by the design automation system to produce a wiring list.

Hence there is information contained in the computer description that is required by two or more applications while some other information s particular to a single application.

A research environment for the symbolic manipulation of machine descriptions.-Thesimilar requirements among the several applications of computer description languages suggest a research environment centered around a data base in which machine descriptions and manipulation programs are maintained, as depicted in Figure 1.simulation compiler-compiler design-automation . . .


Some Aspects

the Symbolic Ma
ipulation of Computer Descriptions 9

different notations and areas of application.This can be expressed by the following set of required features:

1) Must hold all computer descriptions for the different applications.

2) Must be reasonably independent of any particular programming language.This is necessary to allow researchers the flexibility to implement application programs (i.e. computer description manipulators) in a programming language of their choice (e.g., FORTRAN, Algol, APL, LISP, BLISS, etc.)

3) Must be independent of any particular computer description language.The reason is that the computer descriptive language used to create elements of the date base is a moving target.It is also the case that some notations may be more suitable than others for specific parts of a machine description.This implies an evolutionary process, during which many different notations can be in use simultaneously.

4) Must be interactive to allow casual and non-casual use.This requires a set of facilities for interaction in at least one language.

5) Must allow incremental use by many simultaneous users.By incremental use we mean the ability to carry a design through stages of completenes during which different users add application dependant details to a computer description.This is needed for experimentation.

The features outlined above present a set of requirements that may be conflicting.One of the reasons for this generality, not addressed in previous applications, is that the objects we want to manipulate, namely computer descriptions represent a tremendously large domain.We are talking not only about hardware (Logic, Register Transfer, and PM levels [Bell, 1971]) but also about algorithms (Instruction Set Processors and programs).It is also the case that we are trying to apply a coherent methodology to hardware design, a domain characterized by rather abrupt transitions between its descriptive levels (more so than among software levels).

Ideally we would like to converge on a single computer descriptive language so of Computer Descriptions tha

peo
le in the environment can interact more easily among themselves.On the other hand, we recognize the fact that notations go through e olutions and the research

environment must be open along this dimension.Any kind of tight association between a computer description language and the data base will reduce the latter's usefulness.

The next section describes some thoughts about the requirements of a comp ter descriptive language.At this point in time, however, we hold no commitments to any particular existing language or combination of languages.This allows us the freedom to speculate and experiment with several, perhaps conflicting ideas.Therefore, our use of a particular syntax in the example given as a structured programming approach should not be construed as a language definition.


REQUIREMENTS OF A COMPUTER DESCRIPTIVE LANGUAGE

One of the problems with existing hardware descriptive languages is that they tend to bind the user to a view of the world that is rigid and difficult to modify.We feel that the semantics of the language should be under control of the designer.The following are a desireable, but by no means exhaustive, set of properties for the language:

1) Neutrality.-The language should not make any assumptions about the physical implementation.The control primitives available in the language determine the control structures that are easy to describe.If the language control primitives are too rigid they will limit the implementation alternatives.For instance, CASSANDRE [Anceau, 1969]  The description shoul make the intentions of the designers transparent to the users.This is somewhat in conflict with the neutrality property.


2.1) Timing Fidelity.-

Existing languages such as ISP [Bell.1971] describe algorithms with no reference to timing.Thus it becomes difficult to express the behavior of low level components.Another example is the description of cooperating parallel processes, such as interrupt systems, where timing is critical.


2.2) Structural

Fidelity.-D

apaths can be inferred from the description but
hese may be a maximal set and may not reflect the actual structure of the machine.At some level of description the transfer operation, usually denoted by "«-", means "by whatever path available".For a more detailed description the "<-" correspond one-to-one with physical data paths.The same remarks can be applied to the specification of the

unctional units
n the system.The presence of a "+" operator in a register transfer expression does not indicate which of possibly many functional units is to carry out the operation.

3) Hierarchy."Frequently systems design is conducted in a top down manner.The various portions of the system are first described at a high level.Then the designer specifies one subsystem in more detail, then another, and so forth.At any given time a systems design might consist of some subsystems designed down to the gate level, some less detailed designed at the register transfer level, and some merely described as algorithms.The coexistance of multiple le

where top down refinem
nts, if possible at all, are performed on a global basis by ad-hoc manual procedures.The addition of a clock at some level of detail, for instance, requires the rewriting of the entire description.Any validation that has been performed on part of the description would have to be redone.

Th

final section in
roduces, via examples, some thoughts on new mechanisms for a computer descriptive language that attempt to satisfy some of the above requirements.The objective is to design a PDP-8 like minicomputer, starting from a high level description and carrying the design down to a level in which the specific implementation of the machine is described.We will make use of some structured programming concepts that allow us to define entities of the machine (e.g., memories, registers, functional units) independently from the use of the entities in the description.These concepts will be added to the de criptive language ISP [Bell, 1971].The choice of ISP as a framework is based on the authors familiarity with the notation and not, on a commitment to addopt an ISP derived notation as the only vehicle for our research.Our concern for allowing evolutionary notations is also reflected in certain liberties we have taken with respect to the syntax of the language as published in [Bell, 1971].


Some Aspects of the Symbolic Manipulation

The concept of form [Wulf, 1974] allows us to define the data types available in the language by specifying not only the representation of the typed objects but also the operations that can be performed on these objects.A typical form declaration consists of a header and a body.The form header specifies the form name and the formal parameters used inside the form body.The form body consists of a declaration par

in which variables to be used in the form functions can be defined, and a s
t of functions and operations describing the operations that can be performed on variables declared as instances of the form. of Computer Descriptions * In order to keep the examples within a reasonable size, we are appealing to the intuition of the readers to supply some of the missing details concerning the semantics of the fauns* In order to make the process easier, we have taken some liberties with the syntax of ALPHARD and its farm* [Wulf, 1974].

For instance, we can define a form "memory" that describes a particular hardware component.At some early point in the design process a memory can be considered as a vector of integers, thus avoiding the specification of things like word length, number representation, addressing, etc.The following example is an instance of such high level memory definition*.Two functions (operations), "read" and "write" deer i from r.size t& 1 d& begin r[i] <-val mod 2; val <-val * 2; end* expo

+ .-,*,*.read, write };

In the example a
ove, the register is defined as a vector of bits and the value of the register is encoded using the two's complement representation.The function "value" is not exported, thus the real nature of the register as a bit vector is hidden.
[i + l]«-a[i]©b[i]©carry[i + l]; carry [i] <-a[i] Ab[i] va[i] Acarry[i + 1 ] vb[i] Acarry[i +1 ];
end;

x With the last example the power of the form mechanism is more apparent.We can define and redefine data types and operations without disturbing the rest of the description.The example also shows a possible way of implementing the adder.If the description is taking literally, it implies that every register is in fact a functional unit, capable of performing any arithmetic operation.For a first approximation this may be an acceptable definition.A better definition would declare a single functional unit and all register operations could then be defined using this unit.It is clear also that we can declare othe types of registers, for instance, counters that would look like any other register but with the property that some simple operations (e.g., add 1, subtract 1, set to 0, etc) would be performed directly in the register.of Computer Descriptions


Signals and Control Expressions.-

Let us assume that we are satisfied with our previous description (it is by no means complete, but for the sake of brevity let us accept it).The sequencing of operations as expressed in the description does not indicate how the control passes through the machine description, i.e., the semantics of "next" and ";" is specified only to the point

f k
owing that certain actions are performed concurrently or that some actions must be completed before others can start.

We can formalize the sequencing of the operation by using control expressions, based on an underlying finite state machine, of the following type:



instruction serves only to clear the overflow condition code.If the Branch on Less or Equal instruction (which is conditioned by the overflow condition code) is r placed by a Branch on Equal instruction (not dependant on the overflow condition) then the test instruction is superfluous and can be deleted.




, via examples, some aspects of the use of new computer description concepts.We will present our ideas as an exercise in top down design.




are defined as accesses to a vector of integers: ffiLHL memory (integer s ze) = {declare m = integer vector (size); function read (integer addr) = ceJtuin m[addr]; function write (integer addrfval) s m[addr] *-val; export read, write } The export statement is used to indicate the form entities (variables and operations) that are accessible to the rest of the program.Thus we can restrict the access to certain elements of the form by not exporting them.The read and write functions are evoked automatically, depending on the context in wich the memories appear, i.e., as a source (read) or a destination (write) in a statement.Similarly, we can define a form "register" that behaves like an integer: form register = {dfì£ia££ r= integer; infix + (register afb) = return a+bj infix -(register a,b) = return a-b; infix * (register a,b) = i^iuia a*b; infix 7 (register a.b) = return a4b« function read = return r; tundlaa write (integer vai) = r«-val; export +i-i*t*f read, write} 14 The infix declaration is used to define binary infix operations on instances of the form.Notice that the

is nothin
in this definition that reveals the nature of the register and its structure.A more realistic definition would be the following: form register (integer size) = {declare r = bit vector (size); function value = begin declare integer sum; sum*--r[l]; incr i from 2 ta r.size da sum«-sum#2 + r[i]; Lelmn sum; end; infix + (register afb) = naluoi a.va ue+b.value;infix -(register a,b) = Lsiuin a.value-b.value;Loik * (register a,b) = ceiuoi a.value*b.value;infix 7 (register afb) = L£luin a.valuerb.value;function read = return r .value*fUDLtifln write (integer val) =




The read and write functions are redefined to allow the transfer of values in and out of Some Aspects of the Symbolic Manipulation of Computer Descriptions 15 the register.The "dot" notation is used here to indicate the access to an attribute of a register.Thus r.size is the register size, as specified in the declaration.Top Level Description.-Thefollowing description of the PDP-8 assumes the register and memory forms defined previously.For the sake of brevity we are not defining the IO_EXECUTE and OPR_EXECUTE processes evoked by the EXECUTE process.declare memory M[0:4096]j declare register AC<0:(FETCH;next DFETCH ;next EXECUTE;next INTERPRETER); IFETCH := (IR <-M[PC