Formal specification of the ProCoS/safemos instruction set

Formal specification of the ProCoS/safemos

instruction set

Jonathan Bowen previews the work of two European government-sponsored projects investigating design methods for 'provable' computer systems.

As a common interface both projects use subsets of Occam and the transputer instruction set

Two collaborative projects, the European ESPRIT BRA ProCoS project and the UK lED safemos project, are currently investigating methods to prove software and hardware systems correct at a number of different levels of abstraction. Both projects intend to concentrate on subsets of Occam, and the transputer instruction set. The projects wi l l aim to use the same machine language so that results obtained on both projects wi l l be compatible. The init ial selection of the projects (a simple subset of the transputer) is presented using the specification language Z. The role of the specification in the two projects is explained and the benefits and drawbacks of such a specification are discussed.

microprocessors instruction sets verification formal methods transputers Occam

Formal methods are becoming more accepted in both academia and industry as one possible way in which to help improve the quality of both software and hardware systems. It should be remembered, however, that they are not a panacea, but rather one more weapon in the armoury against making design mistakes. To quote from Professor Tony Hoare:

'of course, there is no foolproof methodology or magic formula that will ensure a good, efficient, or even feasible design. For that, the designer needs experience, insight, flair, judgement, invention. Formal methods can only stimulate, guide and discipline our human inspiration, clarify design alternatives, assist in exploring their consequences, formalize and communicate design decisions, and help to ensure that they are correctly carried ouL" (1988)

Thus we should not expect too much from formal methods, but rather use them to advantage where appropriate (e.g. in safety-critical systems).

Oxford University Computing Laboratory, Programming Research Group, 11 Keble Road, Oxford OX1 3QD, UK Paper received: 1 June 1990

0141-9331/90/10631-1 3 © 1990

Even within the formal methods community there are two major camps: those that believe that a formally correct system must be proved correct mechanically, one small step at a time, and those who use the term formal to mean mathematical, using high-level pencil-and-paper style proofs to verify a design is 'correct' with respect to its specification. Sometimes the latter method is known as 'rigorous' to differentiate it from the former; and of course there are positions between these to extremes.

Even if a system is proved correct, there are still many assumptions which may be invalid. The specification must be 'obviously right.' There is no way that this can be formally verified to be what is wanted. It must be simple enough to be understandable and should be acceptable to both the designer and the customer.

Ultimately the computer system will be communicating with the outside world. In a control system, we will probably be dealing with physical laws, continuous mathematics (e.g. differential equations) etc. This will have to be discretized into digital values and approximations will have to be made. Great engineering skill will be needed to ensure that any assumptions made are correct and will not invalidate any formally verified design. It is important to apportion responsibility between the engineers associated with each design task. Mutually agreed interfaces must be drawn up. Ideally these should be formalized to reduce the risk of ambiguity and misunderstanding on each side of the interfaces.

The Programming Research Group (PRG) at Oxford University is currently involved with two collaborative projects working on this. Both intend to investigate methods to help formally verify software/hardware systems at a number of different (but related) levels of abstraction. One project is more software and academically oriented; the other includes an industrial partner who plans to build an actual microprocessor based on the methods explored during the project. The PRG is aiming to ensure that both projects use a compatible machine

ButtenNorth-H einemann Ltd

Vol 14 No 10 December 1990 631

instruction set so that methods and ideas generated on each project can be cross-fertilized to mutual advantage. Inevitably, there is some degree of overlap between the projects and even within each project at different partner's sites. However this is seen as a kind of insurance policy since the methods explored will not be universally applicable.

The rest of this section gives a short introduction to each of the projects mentioned above. The remainder of the paper concentrates on the major interface between the two projects, namely, the processor instruction set. This is a subset of the transputer since both projects wish to concentrate on methods rather than designing new programming and machine languages. The specification of the instruction set is formulated in the Z notation which itself is based on set theory and first-order predicate calculus. This is intended to be sufficiently readable so that it is understandable by all other partners in the projects and, hopefully, a significant number of readers of this paper. Readers unfamiliar with the notation may still gain some benefit by following the accompanying informal description.

ESPRIT BRA ProCoS project

The objectives of the European ESPRIT-funded BRA (Basic Research Action) ProCoS project are to advance the state of the art of systematic design of complex heterogeneous systems, including both software and hardware; in particular, to reduce the risk of error in the specification, design and implementation of embedded safety-critical systems. To approach this goal, the project plans to develop a system consisting of these five major components:

• specification language • programming language • definition of a hardware machine • compiler from the programming language to instructions

of that machine • kernel supportingthe execution of compiled programs

on that machine

The syntax and semantics of these components will be formalized, and their formal interrelationships will be established.

The project is basing its work on the CSP/Occam/ transputer tradition ~-3. In particular, the instruction set of the hardware machine is to be a subset of that of the transputer designed by Inmos. The project started in April 1989 and is due to run for 2 I /2 years; the following partners are participating:

• Technical University of Denmark (DTH) • Christian-Albrechts Universit~it zu Kiel, Germany • Oldenburg University, Germany • Oxford University, UK • Royal Holloway and Bedford New College, UK • Aarhus University, Denmark • University of Manchester, UK

The project is being coordinated at DTH. Briefly, DTH is working on requirements analysis, the programming language syntax and kernel issues. Kiel is involved with compiling specification and compiler development; Oldenburg, who is subcontracted to Kiel, is developing a specification language and program development method.

Oxford is producing the programming and machim language semantics; work is also pro(eeding on a nov~l approach to compiling specification 4 :. Royal Holloway College provides mechanical verificatiorl support, giving a useful check that some of the hand-generated proofs arc. correct. Aarhus is working on compiling verification using an operational semantics approach. Manchester is providing a liaison role with other projects, particularly in the area ol hardware verification where ProCoS is weakest. For a fuller description of the ProCoS project, see Reference 8. A ProCoS project bibliography 9 (in a constant state of change[) is available.

lED safemos project

The UK lED-funded (Information Engineering Directorate) safemos project intends to address some of the problems facing the designers and users of microprocessors and microcontrollers that are arising as the complexity and power of these devices increase. Microprocessors are being used to perform increasingly complex tasks as they become more powerful so that the ability to ensure correct design by traditional design techniques, centred around experimental testing, will become problematic.

The use of formal design methods seems to offer a way out of this situation by providing a design methodology which prevents the introduction of errors into designs through the rigorous use of proof techniques to validate designs against specifications. This project intends to demonstrate the feasibility of these methods in realtime control systems. In the future such realtime controllers will increasingly consist of processors running embedded programs along with specialized interface hardware. Due to this, the project intends to address the problem of verifying mixed hardware/software systems.

The three main goals of the project are

• To demonstrate that it is feasible arid commercially advantageous to verify systems containing both hardware and software by machine-checked formal proof.

• To develop the methodology and tools needed for performing such verifications and for estimating their costs.

• To gain improved scientific understanding of the practical use of existing formal methods and tools, including HOL (Higher Order Logic), Z and CSP.

The project partners are

• Inmos Ltd. • SRI International Cambridge Computer Science

Research Centre • Oxford University Computing Laboratory, Programming

Research Group • Cambridge University Computer Laboratow.

Inmos is working particularly in the area of hardware design. Ultimately it intends to integrate methods developed on the safemos project into the design process. Oxford is concentrating on theoretical aspects and has a liaison role with the ProCoS project, particularly at the instruction set level. The two Cambridge sites, also effectively one, are planning to use the theorem proving system HOL (High Order Logic) to verify the system at a number of levels. The project is being managed by Inmos. The project started at the end of 1989 and is due to run for 3 years.

632 Microprocessors and Microsystems

Machine language

The object code of a compiler in a computer system has to map onto the instruction set of the processor. This in turn is often implemented using microcode. Currently, these are often documented using tables, semiformal formulae and informal text. This is designed to be easily assimilated by the reader. However it is often incomplete or ambiguous because the informality of such methods does not help to check the correctness or completeness of the description.

Microprocessors have already been verified and described at the instruction set level using a variety of formal notations 1°-12. Formal methods are also being applied in safety-critical applications 13. These specifications allow mechanical formal reasoning about the operation of the processor but they are not particularly readable by humans. Attempts to use a formal description in an easily understandable form have resorted to informality in the more difficult areas 3.

Having several incompatible descriptions of an object code (or anything else for that matter) is bound to lead to the possibility of errors. It is possible for an object code to be described formally in a manner which is suitable for design, verification and documentation TM. This means that only one description need be produced.

An example of a suitable notation is the specification language Z 15-19. This is based on set theory and has been developed by the Programming Research Group at Oxford University. It has already been used to define a number of microprocessor instruction sets 2°-22. In addition, the microcode of a processor could also be specified in Z. This could then be proved to implement the object code instructions using refinement techniques. A major advantage of a notation like Z is its expressiveness. Additionally, a type-checker 23 is available to help avoid some mistakes. A related proof assistant, known as the B tool, is also currently under development although it is not yet generally available.

This paper includes extracts from a definition of a subset of the transputer instruction set in Z, referred to as MLo. It is designed to be upwards compatible witla, future versions of the machine language which will be nearer to the full instruction set of the transputer. This specification is based on a partial specification of the transputer instruction set in Z 24. This itself is based on a Z specification of the Motorola 6800 microprocessor 2°' 21 and a description of the transputer instruction set using a Z-like notation produced by Inmos 3.

Instruction set

The safemos project has proposed a transputer-compatible 25 instruction set . This instruction set, and subsequent

expanded versions, are intended to be compatible with (i.e. a subset of) this instruction set. The following instructions are included in the Level 0 Machine:

• pfix val - - prefix value • nfix val - - negative prefix value • Idc con - - load constant • Idl adr - - load local from memory address • stl adr - - store local to memory address • Idlp adr - - load local pointer • adc con - - add constant • eqc con - - equals constant

• cj adr - - conditional jump to a memory address • j adr - - unconditional jump to a memory address • opr - - arithmetic and other operations

Note that a sequence of pfix and nfix instructions is used to increase the size of constant or address available to the next instruction. They are not normally used at an assembly language level. At this level instructions are considered to be of variable length, consisting of one of the above fixed-length instructions (apart from pfix/nfix) possibly prefixed by a number of pfix/nfix instructions.

The opr instruction above performs a number of arithmetic and logical operations, and also the following operations:

• gt - - greater than test • rev - - reverse registers • in - - input a message from a channel • out - - output a message to a channel • seterr - - set error flag true • testerr - - test error flag and clear it • stoperr - - stop if error flag is set • s t o p p - - s t o p p r o c e s s

Formal semantics

The Z syntax used here is as defined in Reference 19 and has been formatted and type-checked using the fuzz package 23. Further information on Z and specification examples may be found in References 15-18. A glossary of the notation is included in Appendix 1. The full specification on which the extracts presented here are based may be found in Reference 26.

An operational semantics of the ML 0 has been produced as an appendix in Reference 26. The main reason for formulating this semantics is that it is compatible with the methods being used by other partners on the ProCoS project. We aim to keep the machine instruction sets used on both projects as compatible as possible so that several strategies for verification are available for the same system. An associated programming language definition 27 and a compatible assembly language operational semantics 28 have been produced for the ProCoS project. One compiling strategy uses a two-stage approach via the assembly language 3°, another more novel approach makes the jump directly S.

BASIC CONCEPTS

Word organization

The basic unit of data manipulated by a microprocessor is the bit.

B/t ::= 011

These are organized into words. Bit positions within a word are numbered consecutively from zero upwards.

Word = = {w : j~ ~ Bit l#w > 0 A dom w = 0 . . # w - 1}

The values of the least significant bit (LSB) and the most significant bit (MSB) of a word are often of special interest

L S B , M S B : W o r d ~ Bit

V w : W o r d •

L S B w = w O A

M S B w = w ( # w - 1 )


Bit values correspond to numeric values

b t t va l : lJ~t ~-* N

b i l va l = { 0 ~ O, 1 ~ 1 }

The u n s i g n e d va lue of a w o r d m a y b e d e f i n e d by

va l : W o r d ~ N

V w : W o r d *

# w = 1 ::¢, v a l w = b i l v a l ( L S B w ) A

# w > 1 => va l w = b i t v a l ( L S B w ) + 2 . v a l ( s u c c ~ w )

val is not an injective function

[- 3 w l , w2 : Word I wl ¢ w2 "va l wl = val w 2

However, if attention is restricted to words of a fixed size the restricted function is injective. Thus a word may be characterized by specifying its value and its size.

I V Wl, W 2 : Word l#w2 • val w l = val w 2 ~ wl = w2

The bits in a word may be set to a particular value

- se._.Z_ : W o r d x B i l ~ W o r d

V w : W o r d ; b : B i t .

w s e . . _ ! t b = w ~ { O ~ b , l ~ b }

Often this value is zero

z e r o : W o r d ~ W o r d

V w : W o r d •

z e r o w = w se.....~l 0

The maximum unsigned value that may be stored in a word is given by maxval

m a z v a l : W o r d ~ N

V w : W o r d ,,

m a z v a l w = va l ( w se t 1)

It ws c o n v e n i e n t to d e f i n e a func t ion to g e n e r a t e w o r d s con ta in ing a par t icular va lue

wrd : N1 ~ l ~ W o r d

V s i z e : N 1 ; va lue : Z ; w : W o r d •

wrd s i ze v a l u e = w ¢:~

( # w = s ize A

( 31 t' : l • val w - - va lue + s u c c ( m a x v a l w) * v ) )

As well as the successor function succ, the inverse predecessor function pred is often useful

pred = = succ

Words may be concatenated to produce a longer word

_ ~ _ : W o r d x W o r d ~ VVord

V W h u~2 : W o r d •

wl ~ w 2 = wl U ( p r e d #~'~ ~ u~)

Note that this definit ion of concatenation together with the definit ion of LSB given earlier mean that the machine is 'l ittle-endian'; for words of any size the least significant bit is always the 0th bit of the word. Generalized concatenation allows a (non-empty) sequence of words to be concatenated into one word.

~ / : s e q l W o r d ~ W o r d

V s : s e q I W o r d •

~ / s = ( h ~ d s)~(~/(t.il ,,))

Sometimes the highest (most significant) bit set in a worci is of interest

l l zghes tSe lb3 i t : W o r d - - N

V w : VVord *

vat w = (} ==> H i g h c , s t , % t l h t w ::: {) A

v a l w # 0 ~ H i g h e s f f , ' e l B i t . , = m , * a ( d o m ( w > { I } ) i

The Level 0 Machine operates on 8-bit bytes of data and also on words each consisting of a small number of bytes. The constant BytesPerWord is left undefined here.

j BytesPerWord : N

From this the number of bits in a word may be derived

W o r d g e n g l h : N

W o r d L e n g t h = 8 * B y l e s P e r W o r d

Bytes and Level 0 Machine words may be defined by

Byte = = { w : W o r d l # w = 8 } Tword = = {w : Word l #w = Wordlength }

Sometimes it is convenient to construct words with a particular value using the abbreviation

Twrd = = (wrd WordLength )

Bitwise logical functions

' - ' simply complements a bit (logical NOT)

~ = { 0 ~ 1 , 1 ~ o }

Bits m a y b e c o m b i n e d by logical A N D ("9 , b i twise logical ( inclusive) OR ( '+ ' ) and b i twise logical (exc lus ive XOR) ('¢').

_ O _ , _ + _ , _ ® _ : B i t x B i l - ~ B i t

(_*_) = { (o,o)~ o,(o, 1)- o,(1,o)~ o,(1,1)~- i } (_+_) = { (0,0) ~--* 0,(0, I)~ I,(I,0) ~ I,(I,I)~ I } (_®_)= { (O,O)~O,(O,l)~l,(i,O)~i,(l,i)~-O }

These definitions are easily upgraded to bitwise logical operations on words. For example, the one's complement of a word is given by

: W o r d ~ W o r d

V w : W o r d •

Shift functions

A word may be shifted left or right. Zeros are shifted into the vacant positions.

_ << _ : W o r d x N ~ W o r d

_ >> _ : W o r d x N ~ W o r d

g w : W o r d •

w < < 0 = w A

w > > 0 = w A

w << 1 = ({ # w } ~ t p r e d ~ w ) U { 0 ~ 0 } A

w 7 > > 1 = { # w - - 1 ~ O } U ( s u e c ~ w ) A

( V n : N • w < < ( u + l ) = ( w < < n ) < < l A

w >> (,~ + :) _ (,, >> ,,) >> ~ )


Arithmetic functions

The Level 0 Machine allows the standard arithmetic operations on integers together with the remainder operator.

Signed integers

The function val maps words to unsigned integers. Some instructions use signed integers. The function num is used to map a word to a signed integer.

h u m : W o r d ~ Z

V w : Word •

M S B w = O ~ n u m w = va l (w) A M S B w = I ~ h u m w = - ( v a l ( - w) )

Signed numbers in a word are rounded off depending on the word length

_ r o u n d o f [ _ : I x Na ~ l

¥ n : l ; l : N l • n ~'oundoff 1 = (n + 2 I -1) mod 21 - 2 I-1

Hence the standard signed arithmetic operators can be defined on Twords. For example

_ + , _ : T w o r d x T w o r d ~ T w o r d

V wl , u~ : T w o r d •

h u m ( w 1 +s w2) = ( n u m ( w l ) + n u m ( u ~ ) ) roundof f WordLeng lh A

LEVEL 0 MACHINE STATE

The state of the Level 0 Machine consists of several components:

• registers • memory • system clock • error flag • status

These components are required for almost all instructions. Other state components of a more specialized nature are introduced in the sections below in which they are used.

Registers

The Level 0 Machine has six principal working registers. Other special-purpose registers are introduced when required. Three of the working registers form an evaluation stack which is used as a workspace by most instructions.

I E V A L UA T I O N - S T A C K Areg : T w o r d Breg : T w o r d

Creg : T w o r d

The other three working registers are the instruction pointer, which points to the next instruction to be executed, the operand register, which is described below, and the workspace pointer. The process running on the Level 0 Machine has a workspace in memory and the workspace pointer references the workspace of the executing process.

I R E G I S T E R S E V A L U A T I O N _ S T A C K Oreg : T w o r d

Wp t r : T w o r d

l p t r : T w o r d

As with a conventional stack, the basic operations on the evaluation stack are pushes and pops.

_ P USH A E V A L U A T I O N _ S T A C K

Breg' = Areg C r e f = Breg

_ P O P

AEVALUATION_STACK

Areg ~ = Breg Breg ~ = Creg

The Areg is at the top of the stack and the result is normally returned in this register as Areg'.

Memow

The memory of the Level 0 Machine may be regarded as a function from addresses to bytes. An address is a Tword. Each address is composed of a word address component and a byte selector component. The byte selector selects a byte within a machine word. To allow each byte within a word to be addressed the number of bits within a Tword allocated to the byte selector is the smallest power of two which is at least as large as BytesPerWord. The byte selector occupies the least significant end of the word.

The number of bits in a word allocated to the byte selector is given by ByteSelectLength:

ByleSe lec tLength : N

2 ByleSelectLength-I < B y l e s P e r W o r d < 2 ByteSelectLength

Using this the functions ByteSelector and WordAddress can be defined

I By teSe lec lor : Tword ~ Word

V w : Tword •

By teSe lec tor w = ( 0 . . By teSe lec tLen f lh - 1) <z w

WordAddres s : T w o r d ~ Word

V w : Tword • Wordmddress w = 81tCC ByteSelectLength ~ w

Using these definitions Address may be defined

Address = = {w : Word l #w = WordLength A val(ByteSelector w) < BytesPerWord}

A subset of these addresses are on word boundaries

TwordAddress = = {a : Address lval(ByteSelector a) = 0}

Each Address is thus composed of a WordAddress part and a ByteSelector part:

[-Va : Address • a = (WordAddress a) ~ (Byte,Selector a)

A consequence of this definition is that if BytesPerWord is not a power of two then there are Tword values which are not Addresses. In this case addresses are not continuous across word boundaries. Two functions, Index and Bytelndex are used to increment through addresses taking account of this feature.

Most instructions consider memory to consist of words and so it is convenient to include both a byte representation

Vol 14 No 10 December "/990 635

and a word representation of memory in the formal definition. Clearly these two definitions must be linked. The link is established by noting that a Tword is a sequence of bytes. Then ~/(Bvtes a) can be seen to be equivalent to WordMem a.

_ M E M O R Y _ R E P B y t e M e m : Address ~ Byte W o r d M e m : TwordAddress ~ Tword Bytes : TwordAddress ~ seq Byte

V a : TwordAddress * Bytes a = { n : N I n < B y t e s P e r W o r d *

n + 1 ~ By t eMem (By te lndez a u) } A

W o r d M e m a = ~ / ( B y t e s a)

An operation changing memory need only update WordMem or ByteMem as appropriate and the other representation of memory gets updated automatically through this schema.

Occasionally it is convenient to refer to word memory relative to the workspace pointer Wptr. The function WorkSpace allows this.

M E M O R Y _ R E P V E M O R Y _ R E P [ WorkSpace : Tword ~ Tword

Wptr : Tword

l val( By teSe lec t°r Wptr) = 0 [dom WorkSpace = { a : Tword ] val(a) < 2 w°'dLength-Byteyelectc'''qth }

[ ( Va : dora WorkBpac, * WorkSpace a = W o r d M e m ( l n d e x Wptr a) )

Note that Wptr must always point to a word boundary. A final point to note about memory is that the address

space will be divided into areas such as ROM, RAM and memory-mapped peripherals (e.g. I/O channels)

f M E M OR Y - M A P R A M , R O M : F 1 Address

-E2~ ~ 5

The ROM area will normally hold the program code and the RAM area will normally hold the program variables. Putting the structure and the representation of memory together gives

MEMORY = MEMORY__REP A MEMORY__MAP

When memory is updated, the memory map (i.e. the RAM and ROM addresses) are unaffected. In addition, the content of ROM is always left unchanged. Some instructions write to memory; these update ByteMem" below which only updates areas of memory address space which contain RAM. Areas outside ROM and RAM contain undefined values.

A M E M O R Y V E M O R Y [ M E M O R Y ' [ E M E M O R Y _ M A P [ M E M O R Y _ R E P ' ~

[ R O M <1 B y t e M e m ' = R O M < By teMem [ R A M <1 ByteMera' = R A M < B y t e M e m "

Wptr r = Wp~r"

Sometimes the contents of RAM are also left unchanged.

E MEMORY -'- [A MEMORY[ RAM <3 ByteMem' = RAM <3 ByteMem]

System clock

The machine contains a clock which controls the timing of the microprocessor. This consists of a sequence of pulses

and may be modelled by the number of clock pulse~ which have occurred since the machine was powered up

v C L O C K _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Clk : N ......

When an instruction is executed it takes a certain number of clock cycles

_ A C L O C K

C L O C K C L O C K ' Cycles : N

Clk' = CIk + Cycles

Inclusion of a clock is not strictly necessary in the specification but it allows reasoning about the timing of combinations of instructions, should this be desirable in the future. The clock cycles given for subsequent instructions are taken from Reference 3.

Errors

The Level 0 Machine provides a single error flag which may be set by a number of instructions.

F E B R O R ErrorFlag : Bit

The error flag may take the values Clear or Set:

Clear = = 0 Set = = 1

Status

The machine may be running or stopped.

Mode :: = running I stopped

S T A T U S

F Status : Mode

For an instruction to be executed, the machine must be running

_ A S T A T U S S T A T U S S TA T US'

Status = r ~ t n n z n 9

After an instruction, the machine may be running or stopped depending on the instruction itself. Most instructions leave the processor running

Status' = Status

Combined state

Putting together the separate state component schema gives

TRANS ~- REGISTERS A MEMORY A CLOCK A ERROR A STATUS

provides a simplified description of the Level 0 Machine.


The change of state is defined as

A TRANS ~- TRANS A TRANS' A ARECISTERS A AMEMORY A ACLOCK A ASTATUS

Many instructions leave the memory and error flag and status unaffected

~TRANS ~ ATRANS A ~ M E M O R Y A ~ERROR A ~STATUS

INSTRUCTIONS

The following basic instructions are included in the Level 0 Machine:

Instruction :: = pfixl nfix I ldcl adc l Idl I stl I Idlp Ij I cj I eqcl opr

The oprinstruction allows furtherALU and other operations which can be expanded as required. For the Level 0 Machine, the following are specified:

Operation :: = add I sub I mul [ d iv l rem I sum I di f f l prod I gt I rev land Iorl not l in Iout l seterr I testerr f stoperr I stopp

Each instruction and operation is allocated some unique opcode

lnstructionOpCode : Instruction ~ N

OperationOpCode : Operation ~ N

InstrnctionOpCode = . . .

OperationOpCode . . . .

All Level 0 Machine instructions are single bytes. The most significant four bits of the byte form an opcode and the least significant four bits form an operand.

OpCode, Operand : Byte ~ N

V b : Byte * OpCode b = val(succ 4 g b) A Operandb = val( (0 . . 3) <I b )

This design of instruction leads to only 16 instructions being available. Other functions are invoked by means of the OPR instruction and are thus operations rather than instructions.

The operand is not operated on directly but instead it is added into the Operand Register (Oreg). The instruction then operates on the contents of Oreg

I D E C O D E R E G I S T E R S M E M O R Y Oreg ° : Tword

Oreg ° = Oreg + Twrd( Operand( ByteMem Iptr) )

It is now possible to define partial schema definitions for instructions and operations.

_ # , INSTR U C T I O N A T R A N S Instr : Instruction D E C O D E

OpCode( ByteMem Iptr) = lnsD'uctzonOpCode Instr

--'$;'OPERA T I O N cblNSTR U C T I O N Opr : Operation

Instr = o p t Oreg ° = Twrd( OperationOpCode Opt)

The instruction pointer (Iptr) points to the current instruction to be executed. Most instructions simply increment Iptr on completion. As was noted previously, addresses are not necessarily continuous and so the function Nextlnst increments Iptr to the next value which is a valid address.

t extlnst : Address ~ Address

V a : Address * Nextlnst a = Bytelndex a 1

Simple instructions are classified as those which increment Iptr and leave Wptr unchanged and set Oreg' to 0

_ da S I M P L E A R E G I S T E R S

Oreg t : 0 Wptr ' = Wptr lpt f f = Nextlnst lptr

d~SIMPLEJNSTRUCTION ~ d~SIMPLE A dPlNSTRUCTION d~SIMPLE_OPERATION ~ ~SIMPLE A dpOPERATION

Instructions using the evaluation stack

Simple manipulation of the evaluation stack using PUSH and POP was covered above. Depending on the number of operands an instruction has it may perform a sequence of POPs and PUSHes. Some of these sequences are common enough to define general framing schemas.

Single operand instructions

Some instructions take one parameter from the evaluation stack, perform some operation on the parameter and return a result to the evaluation stack. These instructions are characterized by ~SINGLE.

• SINGLE ~- POP ~ PUSH

Expanding this schema shows how the registers comprising the evaluation stack are affected

_ • S INGL E Areg, Breg, Creg : Tword Areg', Breg', Creg' : Tword

Breg' = Breg Creg' = Creg

Double operand instructions

Double operand instructions take two parameters from the evaluation stack, perform some operation on them and return a result to the evaluation stack.

• DOUBLE ~ POP ~ POP ~ PUSH

This expands to

_ ,~DOUBLE

Areg, Breg, Creg : Tword Areg j, Breg t, Creg' : Tword

Breg' = Creg

Creg' is not constrained by the predicate and is therefore undefined.


Operat ion creation instructions

The OPR instruction uses the contents of Oreg to determine which operation to execute. Two instructions are provided to manipulate Oreg and set up these operations:

PFIX

~blNSTR UCTION E E VA L UA TI O N_STA CK E TR A NS

Oreg' - Oreg ° << 4 Wptr' = Wptr lpt," = lplr + 1 Cycles - l lnstr = p f i x

__NFIX

dp [NSTR U CTION E EVA L UA TION_STA CK = TRA NS

Oreg' = (~ Oreg °) << 4 W p t r ' - Wplr lplr' = lptr + 1 Cycles = 1 lnslr - - nfix

M e m o r y access instructions

This section describes those instructions which load values from memory to the evaluation stack or store values from the evaluation stack into memory. The timings for instructions which read from or write to memory are applicable to on-chip RAM only.

Idc con instruction

LDC loads a constant into the evaluation stack.

_ LDC

¢bSIMPLE_INSTRUCTION P USH =TRANS

Areg' = Oreg ° Cycles = 1 l n s t r = idc

Idl adr instruction

LDL loads a local variable into the evaluation stack. A local variable is addressed by its offset from Wptr.

_LDI ~SIMPLE_INSTRUCTION P USH ~ T R A N S

Areg'= WorkSpace Oreg ° Cycles = 2

I [nslr = l d l

stl adr instruction

STL stores the value at the top of the evaluation stack into a local variable.

__ S T L

• SIMPLE_INSTR UCTION POP - E R R O R -'-STATUS

Oreg ° E d a m WorkSpace WorkSpace" = WorkSpace • { Oreg ~ ~ Are9 }

Cycles = l Instr = st,]-

Integer ar i thmet ic instructions

Arithmetic operations may lead to overflows. Many of the instructions in this section check for overflow and set the ErrorFlag if required. Instructions make use of the arithmetic operators defined earlier. InRange checks for arithmetic overflow. We just include the ADD operation here.

add operation

ADD sums Areg and Breg writing the result to Areg. __ADD ....

• SIMPLE_OPERA TION 42DOUBLE EMEMORY --STATUS

Areg' = Breg +s Are9 Cycles - - l Opr ~. a d d

( A reg, (_ + ~ _), Breg ) E ln Range ~ ErrorFlag ~ = ErrorFlag (Areg, (_ +~ _), Breg) q~ InRange =¢. ErrorFlag' = Set

Simple test instructions

This section describes a variety of instructions which return Boolean values according to the result obtained from their operations.

eqc con instruction

EQC tests Areg against the operand in Oreg °, returning the result in Areg.

IEQC ~bSIMPLE_INSTR UCTION 42SINGLE E T R A N S

Areg = Oreg ° ::¢" Areg' = True Areg • Oreg ° ::¢, Areg' = False Cycles = 2 l n s t r = e q c

gt operation

GT tests Breg against Areg returning the result in Areg. The operands are treated as signed integers.

_ G T

~SIMPLE_OPERATION cbDOUBLE =TRANS

hum Breg > num Areg ~ Are 9' = True hum Breg < num Areg ~ Areg' False Cycles = l- Opr = gt

Error operat ions

SETERR sets the ErrorFlag. TESTERR tests the ErrorFlag returning the result on the evaluation stack.

stoperr operation STOPERR stops the machine if the ErrorFlag is set.

_STOPERR OPERA TION

=EVAL UA TION_STA CK =MEMORY =ERROR

ErrorFlag = Se~ ~ Slalus ~ = stopped ErrorFlag = Clear ~ Sta tus ~ = Sta tus Cycles = 2 Opr = stoperr


Branch instructions

This section describes the branch instructions. Since all the branch instructions potentially cause a discontinuity in the value of Iptr the schema ~PSIMPLE is no longer appropriate. Instead the schema ~pBRANCH is defined.

f ~ B R A N C H '~INSTR UCTION E TRA NS JumpAddr : Address

Wptr' = Wptr Orey' = 0 JumpAddr = Bytelndex(NeztInst Iptr) Oreg °

j adr instruction

J jumps to an address specified as a byte offset from the instruction following the J instruction.

__J #~BRANCH

E EVA L UA TION_STA CK Iptr' = JumpAddr Cycles = 3 lnslr = j

cj adr instruction

CJ causes a jump to a byte offset from the instruction following the CJ instruction if Areg is O.

__CJ

I #PBRANCH Areg = O :~

( EEVALUATION_STACK A Iptr' .: JumpAddrA Cycles = 4 )

Areg ~ O ~ ( POP A lptr ~ = Neztlnst lptr A Cycles = 2 )

Inslr = c j

Note that Areg', Breg' and Creg' are undefined.

out instruction

OUT writes a sequence of bytes from memory starting at the address specified by Creg. Areg specifies the length of the sequence. Breg defines the channel address being used.

_OUT

#~SIMPLE_OPERA TION ETRANS Output! : s e q Byte ehan! : TwordAddress

Breg E OutChannels chan! = Breg Output! = { i : N I i G 1 .. val A reg • i ~ ByteMem( Bytelndex Creg ( i - 1)) } Cycles > 2 * ((#Output! + WordLength - 1) d i v WordLength) + 20 Opr = out

Miscel laneous instruct ions

REV reverses the registers Areg and Breg.

stopp operation

STOPP stops the processor. Iptr is saved in the work space so it can be analysed later if required.

- -STOPP

q~SIMPLE_OPERA TION ~-E VA L UA TION_STA CK EERROR

Status' = stopped WorkSpace" = WorkSpace ~ { Twrd(-1) ~ lptr'} Cycles = 11 Opt = stopp

Communica t ion instructions

Communication at the instruction set level is carried out using high-level links. The method of communication is based on CSP 1 and avoids the need for complicated communications protocols common in other microprocessors. One hard link is provided on the Level 0 Machine allowing external communication. The link provides two channels, one in each direction.

lnOhannels, OutChannels : F TwordAddress

#lnChannels = 1 #OutChannels = 1

in instruction

IN reads a sequence of bytes into memory starting at the address specified by Creg. Areg specifies the length of the sequence. Breg defines the channel address being used.

&SIMPLE_OPERA TION --ERROR --STATUS Input? : s e q Byte chan! : TwordAddress

#Input? = val Areg Breg G InChannels chan! = Breg ByteMem" = ByteMem

{ i : N [ i E 1. . va lAreg , (Bytelndez Creg (i - 1)) ~ (lnput? i) }

Cycles >_ 2 * ((#Input? + WordLength - 1) d i v WordLenyth ) + 18 Opt = in

POWER UP A N D BOOTSTRAPPING

The start of memory and the reset code are at standard addresses:

MemStart : TwordAddress ResetCode : Address

These should normally be in RAM and ROM respectively for useful operation of the Level 0 Machine. After start-up, the clock is initialized to zero for convenience and the processor is running.

- Init TRANS. TRANS'

Oreg' = 0 Wptr' = MeraSlart lptr' = ResetCode CIk' = 0 Stalus ~ = running

Note in particular that the ErrorFlag is not initialized.

It is assumed that a short bootstrap program is available in ROM to attain the above initialization conditions in an actual transputer. Some instructions which are not in the instruction set defined here will be needed. For example, clrhalterr must be executed to disable halt-on-error mode. Further details Of bootstrapping can be found in Reference 3.


COMBINED OPERATIONS AND INSTRUCTIONS

The Level 0 Machine operations are

OPR -~ ADD v SUB v MUL V DIV v REM v SUM v DIFFV PROD V AND V OR V NOT V GT v REV v IN v OUT V SETERR V TESTERR v STOPERR V STOPP

The Level 0 Machine instructions are

INSTRUCTION ~ PFIX V NFIX v ADC V LDL v STL V LDLP v J v CJ v EQC v OPR

When the state changes, only the main state components of the machine are of interest.

EXEC ~- INSTRUCTION (TRANS A TRANS')

The operation of the Level 0 Machine consists of the initial state InitTRANS followed by a sequence of such instructions controlled by the contents of the memory currently pointed to by the instruction pointer before the execution of each instruction. The sequence continues until the processor is stopped by a STOPP or STOPERR instruction.

CONCLUSIONS

This specification is rather baroque for the size of processor which it describes. This is because it has been produced from a more complete description of the actual transputer instruction set 2a. The technique of factoring out common portions of specification becomes more effective for larger instruction sets.

Additionally, the instructions are specified to the bit level. Whilst this is useful for those wishing to refine this description further down into the levels of hardware, the compiler writer may prefer a more abstract description in a notation more akin to the description of the high-level programming language 28.

Since arithmetic operations are defined in terms of words here, overflow conditions are easily detected. This is an aspect which is easily overlooked in more abstract specifications, but one which can often cause errors in practice. All resources in a real machine are finite whereas in a specification it is easy to include infinite objects (e.g. natural numbers).

Microprocessors are relatively well specified compared to much software, but the memory map and addressing were disambiguated in formulating the formal specification presented here. Another area that can be clarified is interrupts.

Z is a good formalism for producing readable formal specifications (once the basic notation is understood, of course). To quote from Reference 31, which provides a comprehensive and up-to-date survey together with an annotated bibliography on the specification of computer architectures, Reference 20 'is by far the most readable formal architecture specification, and the most formal readable architecture specification I've seen.'

Formal specification of existing systems

Deriving a formal specification from an existing system is a hard task. One common error is to think about how the system is actually implemented rather than what it does; a

specification should be concerned with the latter rathe~ than the former. In some ways it may be a disadvantage to have a knowledge of the inner workings of the system; instead it should be approached from the viewpoint of the user. It is better to look at the user manual rather than the design engineer's notes, diagrams or program.

Subsequently, any formal specifications produced of an existing system could be used to update the informal documentation, or even rewrite it from scratch. Although Z has been developed as a design tool, it is also well suited forpost hoc specifications of existing systems, and for detecting and correcting errors and anomalies in the documentation of such systems TM.

The most important stage of formalizing a system is selecting the right level of abstraction for modelling its state. This is normally an iterative process. On attempting to specify an operation one often needs to backtrack to change the abstract state of the system. In particular, extra state components can be convenient to provide different views of the system depending on the operation involved.

There are likely to be some inconsistencies between a post hoc specification and the actual operation of the system described. This is due to impreciseness and misunderstanding of the informal documentation used to formulate these specifications. This illustrates one of the reasons for using formal specification techniques -- to avoid ambiguity or vagueness and to aid precise communication of ideas. Using a formal notation forces issues to the surface much earlier in the design process than when informal description techniques such as natural language and diagrams are used. Difficult areas of the design cannot be ignored until the implementation stage. This reduces the number of backtracks necessary round the design/implementation cycle (ideally to none!) ~2.

Additionally, using formal specification techniques should reduce maintenance costs since more of the errors in a system will be discovered before it is released into the field. Although specification and design costs will be increased, implementation and maintenance costs should be lowered, reducing overall costs.

Formally specifying an existing system could be particularly useful if it is to be reengineered to comply with modern software and hardware engineering standards. In such cases there could also be cost benefits by taking such an approach 3~.

The future

A drawback of Z is that it does not have any direct mechanical theorem proving support. The B Tool, effectively Z without schemas, is being developed to help check proofs. On the safemos project it is planned to produce a HOL specification which matches the Z specification. For this particular case there should be relatively little difficulty because the full power of the Z type system (which is incompatible with that in HOL) has not been used in the specification of the instruction set.

The machine instructions and operations covered here are a small subset of those in the transputer ~. However the specification should scale up; it is relatively easy to directly specify the semantics of the most ambitious level of machine language for the two projects. Hence, although we have MLo, ML~, etc., the complexity is approximately linear with the number of instructions in


the language. New instructions may easily be added without affecting existing instructions provided unique opcodes are used.

Recent work on a novel style of compiling specification 4-7, where the specification is presented as a set of theorems to be proved, has resulted in the need for an interpreter for the machine instructions written in the high-level programming language (a subset of Occam 2) itself34, 3s. This takes the form of a WHILE loop with a large IF construct to cover all the instructions (equivalent to the Vs in the previously presented Z definition for the INSTRUCTION schema). The interpreter code for each instruction is in practice very close to the Z specification and it may be convenient to embed the Z specification of the instructions within the interpreter, e.g.

InitTRANS ~ WHILE(Iptr < EndCode, EXEC)

The exact approach to be taken is a decision for the future.

ACKNOWLEDGEMENTS

David Shepherd of Inmos provided help on points where the manual 3 was vague and also spotted a number of minor mistakes in earlier drafts of the specification. Parts of the information on the ProCoS and safemos projects have been derived from the respective project proposals. The work for this paper was undertaken partly whilst the author was funded by the SERC Software Engineering Project at the Programming Research Group. The author is grateful for this support, as well as support from the lED safemos project (no. IED3/1/1036) from December 1989. Colleagues on the ESPRIT BRA ProCoS project (no. 3104) have also supplied valuable assistance.

REFERENCES

1 Hoare, C A R Communicating Sequential Processes Prentice-Hall International (1985)

2 Inmos Ltd Occam 2 Reference Manual Prentice-Hall International (1988)

3 Inmos Lid Transputer Instruction Set: A compiler writer's guide Prentice-Hall International (1988)

4 Bowen, J P, He, Jifeng and Pandya, P K'An approach to verifiable compiling specification and prototyping' Proc. PLILP 90, Workshop on Programming Language Implementation and Logic Programming, LinkOping, Sweden Springer-Verlag (1990) pp 45-69

5 He, Jifeng, Pandya, P K and Bowen, J P 'Compiling specification for ProCoS level 0 language' ProCoS Project Document OU HJF 4/3 (May 1990)

6 Hoare, C A R 'Refinement algebra proves correctness of compiling specifications' Technical Report PRG- TR-6-90, Programming Research Group, Oxford University (1990)

7 Hoare, CA R, He, Jifeng, Bowen, J Pand Pandya, P K 'An algebraic approach to verifiable compiling specification and prototyping of the ProCoS Level 0 programming language' ESPRIT Conf. Brussels, Belgium (November 1990)

8 Bjorner, D 'A ProCoS project description' EATCS Bulletin, also ProCoS Project Document ID/DTH DB 3 (October 1989)

9 Rasmussen, A 'ProCoS bibliography' ProCoS Project Document ID/DTH AR 1, Version 3, Technical University of Denmark (April 1990)

10 Hunt, W A 'FM8501: A verified microprocessor' Technical Report 47 Institute for Computing Science, University of Texas at Austin, USA (February 1986)

11 Geser, A 'A specification of the Intel 8085 microprocessor: a case study' in Wirsing, M and Bergstra, J A (eds) Algebraic Methods: Theory, Tools and Applications Springer-Verlag (1989) pp 347-402

12 Joyce, J, Birtwistle, G and Gordon, M 'Proving a computer correct in higher order logic' Technical Report No 100 Computer Laboratory, Cambridge University, UK (1986)

13 Cullyer, W J and Pygott, C H 'Application of formal methods to the VIPER microprocessor' lEE Proc. Part E, Vol 134 No 3 (May 1987) pp 133-141

14 Bowen, J P 'Formal specification in Z as a design and documentation tool' Proc. 2nd IEE/BCS Conf. Software Engineering, Liverpool, UK (1988)

15 Hayes, I J (ed.) Specification Case Studies Prentice- Hall International (1987)

16 King, S, Sorensen, I H and Woodcock, J C P 'Z: grammar and concrete and abstract syntaxes' Technical Monograph PRG-68, Programming Research Group, Oxford University, UK (1988)

17 Loomes, M and Woodcock, l C P Software Engineering Mathematics: Formal Methods Demystified Pitman Publishing, London, UK (1988)

18 Spivey, I M Understanding Z: A Specification Language and its Formal Semantics Cambridge University Press, U K (1988)

19 Spivey, J M The Z Notation -- A Reference Manual Prentice-Hall International (1989)

20 Bowen, J P 'The Formal Specification of a Micro- processor Instruction Set' Technical Monograph PRG- 60, Programming Research Group, Oxford University, UK (January 1987)

21 Bowen, I P'Formal specification and documentation of microprocessor instruction sets' Microprocessing and Microprogramming Vol 21 (1987) pp 223-230

22 Cooper, D 'Some notes on the use of Z' in Bowen, J P (ed.) Proc. Z Users Meeting, Programming Research Group, Oxford University, UK (1987)

23 Spivey, J M The fuzz Manual Computing Science Consultancy, 2 Willow Close, Garsington, Oxford, UK (1988)

24 Farr, J R 'A formal specification of the transputer instruction set' MSc thesis, Programming Research Group, Oxford University, UK (1987)

25 Shepherd, D E 'An instruction set forverified systems' Inmos, Confidential document (October 1989)

26 Bowen, l P and Pandya, P K 'Specification of the ProCoS level 0 instruction set' ProCoS Project Document OU JB 2/3, also 'Specification of the SAFE/0 instruction set' safemos Project Document P-JPB-2/3 (May 1990)

27 Lovengreen, H H and Jensen, K M 'Definition of the ProCoS programming language level O' ProCoS Project Document ID/DTH HHL 2/1.2, Technical University of Denmark (November 1989)

28 Pandya, P K and Bowen, J P 'An operational semantics for the ProCoS level 0 assembly language' ProCoS Project Document OU PKP 1/1.1 (October 1989)


29 Fr~inzle, M and Lakhneche, Y 'Compiling specification for ProCoS programming language level O' ProCoS Project Document Kiel MF 1 (1989)

30 Pandya, P K and lifeng He 'A simulation approach to verification of assembling specification of ProCoS level 0 language' ProCoS Project Document OU PKP 3/1.1 (February 1990)

31 leonard, 1" E 'Specification of computer architectures: a survey and annotated bibliography' Technical Report No 188, Computer Laboratory, University of Cambridge, UK (January" 1990)

32 Shepherd, D E and Wilson, G 'Making chips that work' New Scientist No1664 (13 May 1989) pp 61-64

33 Nix, C J and Collins, B P 'The use of software engineering, including the Z notation' Quality Assurance Vo114 No 3 (1988) pp 103-110

34 Shepherd, D F 'Occam interpreterforSAFEMOS level 0' safemos Project Document I-DES-2/1, Inmos Ltd, UK (April 1990)

35 Shepherd, D E 'Occam interpreterforSAFEMOS level 0: architectural view' safemos Project Document I- DES-3/1, Inmos Ltd, UK (April 1990)

APPENDIX 1 : GLOSSARY OF Z NOTATION

A brief glossary of the Z mathematical and schema notation used in this paper is included here for easy reference. For more information on the notation, see [37].

Names

a,b Identifiers d,e Declarations (e.g. a : A; b . . . . : B . . . ) f,g Functions m, n Numbers p, q Predicates s, t Sequences ss Sequence of sequences x, y Expressions A, B Sets N Set of number Q, R Relations S,T Schemas

Definitions

a ~ = x

a : : = b l . . .

[a] __a__

_ a

a _

Abbreviated definition Data type definition (or a ::= b <<x>>l . . . ) Introduction of a given set (or [a . . . . ]) Infix operator Postfix operator Prefix operator

p ~ q p ~ q V d l p • q 3 d l p • q 31 d l p • q

Sets

x = y x :/: y x C A xCA

A C B A C B

Ix, y,...I {dip •x 1 (x,y,. . .) A x B x . , . gPA FA ArqB A U B A I B #A

Relations

A ~ ~B a ~ b d o m R ran R id A Q ] R A <3R A ~ R A D R A ~ R R (lAD R n R - R* R +

Functions

A I ~B A : : ~B A ~B A ) , B A - - ~ B A ~ B f(x) f o g

Logical implication (--~ p ,~. q) Logical equivalence (p -7 q/~ q -~p) Universal quantification (or V d • q) Existential quantification (or El d • q) Unique existential quantification (or31 doq)

Equality of expressions Inequality (--~(x = y)) Set membership Non-membership Empty set Set inclusion Strict set inclusion Set of elements Set comprehension (or{d IP}) Ordered tuple Cartesian product Power set (set of subsets) Set of finite subsets Set intersection Set union Set difference Size of a finite set

Relation (P(A x B)) Maplet ((a,b)) Domain of relation Range of relation Identify function Forward relational composition Domain restriction Domain anti-restriction Range restriction Range anti-restriction Relational image Relation composed n times Inverse of relation (R -1) Reflexive-transitive closure Transitive closure

Partial function Total function Finite partial function Injective function Surjective function Bijective function Function application (or fx) Functional overriding ((dom g ,~ f) U g)

Logic

- T p

p A q p V q

Logical negation Logical conjunction Logical disjunction

Numbers

IN IN1

Set of natural numbers tO, 1,2 . . . . } Set of non-zero natural numbers (Nit0/)


Z succ n m + n m - n m * n m div n m mod n m < n m . . n min N max N

Set of integers Successor function (n + 1) Addition Subtraction Multiplication Division Modulo arithmetic Less than or equal (also <, > and >) Number range Minimum number Maximum number

Sequences

seq A seql A iseq A

s ~ t head s tail s last s front s rev s s l A ~ / S 5

disjoint s s partition A

Set of finite sequences Set of non-empty sequences Set of injective sequences Empty sequence Sequence {1 ~-~ x,2 ~-~ y, . . . } Sequence concatenation First element of sequence (s(1)) All but the head element of a sequence Last element of sequence (s(#s)) All but the last element of a sequence Reverse a sequence Sequence filtering Distributed sequence concatenation Disjointness Partitions

Schema notation

Vertical schema. New lines denote ';' and %'. The schema name and predicate part are optional. The schema may subsequently be referenced by name in the document

d

P

F [ x . . . . ] =

S --" [ d l P l

[ T ; . . . I . . ] z.a

OS S, s i p S; d S [ a/b . . . . ] S A T S v T V d , S 3 d , S 3 1 d ' S s I (a . . . . ) SrT preS S~T

Axiomatic definition. The definitions may be non-unique. The predicate part is optional. The definitions apply globally in the document

Generic definition. The generic parameters are optional. The definitions must be unique. The definitions apply globally in the document

Horizontal schema Schema inclusion Selection (given z : S) Tuple of components Decoration (after state) Extra schema predicate Extra schema declaration Renaming of components (new/old) Schema conjunction Schema disjunction Universal schema quantification Existential schema quantification Unique schema quantification Hiding of component(s) Projection of components Precondition of schema Schema composition (S then T)

Jonathan Bowen graduated from Oxford University in 7977 with a degree in engineering science. He worked in the computing industry for two years and then joined Imperial College London, UK as a research assistant, latterly in the Wolfson Microprocessor Laboratory. Since 1985 he has been a research officer at the Programming Research Group in the Oxford University Computing Laboratory. He previously worked on the Distributed Computing and

Software Engineering projects in the area of formal methods and, in particular, the Z notation. He is now a senior research officer on the collaborative UK lED safemos project.


Documents

Formal specification of the ProCoS/safemos instruction set