Abstract

machines have been specified using transition systems [22], informal descriptions [73], an imperative programming style [47, 63] and functional languages [41], to name but a few. The best known contributions from the concrete side are probably ISPS [68] and register transfer languages, for example three address code [1]. These methods all have their drawbacks, lacking either a formal definition, or being impractical in that they are not easy to realise as, or translate to concrete implementations. The drawbacks of informal specifications are well known --- it could be said that `informal specification' is an oxymoron, and that nothing better than a description can be given informally. Transition systems have a well defined semantics, but quickly become unwieldy as the complexity of the system being specified increases. Even expressing a simple JUMP instruction leads, at best, to an inelegant use of the formalism. Functional languages also have a well defined formal semantics, but are also in general too far from concrete architectures to allow for intuitive specifications. Most current implementations of functional languages are also too inefficient for realistic prototyping. At the other end of the scale, a specification in some imperative language will be easy to implement with reasonable efficiency, but will suffer from a lack of a flexible and useful formal semantics. The same is true, possibly to a lesser extent, of ISPS and register transfer languages. Indeed, despite the existence of an ISP specification [19], early models of the PDP-11 had differing semantics for commands such as the MOV (R6)+ \Gamma(R6) from example 1, and the semantics of an instruction such as ADD (R6)+ \Gamma(R6) was not even unambiguously defined. Most of these methods have been used as a ...

Citations