APLSlMUL: A Simulation based Universal 16-bit Microprocessor Software Development System

Ogan Gurel Stuyvesant High School New York, New York

Westinghouse Science Talent Search 1981-82

ABSTRAGr

APLSIMUL -fA a wuveJt6al and .inteJr.acu.ve ~o&twaJte deve1.opment ¢lJ~tem &0Jr.. 16-bU m-iCltopJr..Oc.eMoM. The bas-cc: ~:tJtuc.tu.Jr..e 0& APLSIMUL C.On6-fAu 0& &0uJr.. paJt:U: the S.imU£atoJr..!M~embleJr.,the InteJr.acu.ve Vebugg.ing Fac.ilU.{_u, the File Management Fac.ilU.{_u and the Vevetopment Contltol Language wh-ic.h .integJr..atu aLe. 06 the 60Jr..ego.ing paJt:U. Un.-iveJt6al ex-ten6.ibaulj to mMt 16-bU mtc.Jr..opJr..OC.U~OM -fA ac.h-ieved t~ough the h-igh degJr..ee 06 modulaJr..itlj .in the S.imU£atoJr..! M~ embleJr.. ThM, the .s lj~t~ pJr..ogJr..ammeJr. c.an .implement a total ~lj~tem ~olu.,Uon 60Jr.. anq 16-bU mtCltOp'LOC.U~O!t whetheJr. a.l!teadlj .in Me OJr.. bung planned blj malUng ~Ught mod.i6ic.a.ilon6 to the S.imuR..a.toJr..!M~embleJt. The pJr..ototljpe c.on6.iguJr..a.ilon 00 the ~ootwaJte devetopment ~lj~tem -fA wJr..dten to ~.imU£ate the. Te.xCUJ In6tJtume.nU TMS 9900 M.ing the. IBM 5110 APL ~lj~tem CUJ a hos«,

CDNTENT'S

Abstract

I. INI'RODUCTION AND BACKGroUND

II. GENERAL DESIGN CRITERIA
III. DESIGN METHOOOLOGY
1. Basic APLSlMUL Structure
2. Simulator/Assembler
3. Debugging Facilities
4. File ~mnagement Facilities
5. Developrrent Control Language
IV. DISCUSSION ON ASPECI'S OF IMPLEMENTATlOO
V. SUMMARY AND CDNCLUSION Acknowledgements References

-1-

I • INrRODTLTION AND BACXGIDUND

Wi thin the last two years a number of new 16-bi t microprocessors

have been introduced by several semiconductor manufacturers.

These

microprocessors represent the latest generation in semiconductor technology and microcomputer architecture. The new 16-bi t microprocessors are a significant part of the advanced applications of torrorrow such as advanced personal computers, industrial process control, robotics, I/O and peripheral control, intelligent terminals, advanced graphics, data base management systems, distributed processing and local nenrorks.

Unfortunately these microprocessors are much nore complicated than their 8-bi t predecessors. Consequently, with the decrease in hardware cost, the cost of software developrrent becomes much rmre significant in total systems planning. For this reason, the importance of the software development process cannot be underestimated. In order to meet these needs a variety of software development tools have been produced.

specialized hardware. at a considerable cost.

Some of these are very complex and involve very 1bst of these are offered by the rranuracturer

In addition, these software development sys-

tems are quite primitive and offer only a limited set of facilities. The design process is further hampered by the fact that these systems are dedicated towards only one microprocessor and are thus limited in their scope.

-2-

However, as system needs get rmre sophisticated, a universal software development system can be extremely helpful. Particularly important, are applications which use custom-made microprocessors that are not currently being produced. Thus the software developrrent system can be used effectively to evaluate and optimize the instruction set and hardware architecture to fit the application. Furthermore, the present software development systems often do not utilize a master control language to guide the debugging process, and if they do, the language is often not sui ted for debugging purposes and is thus cumbersome to use.

APISIMUL is intended to fill this gap by achieving a comprehensive system solution through many powerful and unique features. For instance, the high degree of rrodul.ar-Lty of APISlMUL allows it to be llDdified easily so that it can simulate virtually any other 16-bit microprocessor. As a prototype system APISIMUL has been written to simulate the Texas Instruments TMS9900 on the IBM 5110 APL system. In this way programs written for the TMS9900 can be assembled, executed, edited, evaluated and debugged on the IBM 5110. Several. unique features make APISIMUL particularly easy to use and powerful The Qomp~~h~n6iv~ and int~ct{v~ Simulator/Assembler effectively emulates all aspects of the TMS9900 including I/O, interrupts and execution timing parameters. The instruction set accepted by the fully symbolic assembler is the same as is documented in the 9900 Family System Design rvIanual. In addition several macro-assembler directives are suppor-ted as well as all addressing rrodes , The as-

-3-

serrbler when invoked through the simulator, produces an object code nodule that can be loaded on to a disk with the rest of the CPU configuration file assembly. API.SlMUL also has a host of powerful and fully interactive debugging facilities that significantly simplify

the software development process. A set of File Management Facilities provides the APL functions to edit and process the various system data structures. An extranely inportant part of API.SlMUL is the Development Control Language (DCL). The Developrrent Control Language is an algorithmic language that effectively integrates the software development process, provides a tool for the expression of powerful debugging procedures and serves as a test language to verify source programs.

This paper will first discuss the basic requirements for the system that played an Impor-tant part in the overall system planning. The bulk of the paper describes the fundamental design of the various parts of APLSlMUL and provides numerous examples to elucidate this design rrethodology. Finally, some aspects of the implementation and use of API.SIMUL are discussed and further research is suggested.

-4-

I I. GENERAL DESIGN CRITERIA

The following basic requirements provide the major goals that influenced the many system design decisions. Each criteria represents a concept that has been implemented in the system. The use of such requirements to develope complex systems is very unique and only recently being used.

1. Univ~ality - It shall be possible to simulate all 16-bit microprocessors in the system without significantly altering the Simulator/Assembler structure.

2. Comp~ehen6~ven~~ - The Simulator/Assembler shall completely simulate all aspects of the target CPU. The system shall include a comprehensive set of debugging facilities that perform a broad variety of debugging tasks.

3. 1 YLteJr.a.c,Uvel1eM - All functions of the system shall conmmicate directly with the user such that the user has direct control over all system processes. All system messages and output shall be understandable and user oriented.

4. S~mpUc.,Uy - The system shall not contain unnecessary complexity.

The Development Control Language should have a consistent semantic conventions that minimizes the number of underlying concepts. The relationships between the various system components and the functions of these components should be unambiguous.

-5-

5. ReLUtbUdy - The system should aid the design and development of reliable programs. The system shall rraximize the autorrat Ic detection of all errors and produce explanatory diagnostic and warning messages , but shall not attempt to correct the errors.

6. McUl'ltcUna.bUdy - The design of the system should prorrnte ease of system naf.ntenance . The system shall be highly structured so as to prorrnte ease of updating and altering system rrndules.

7. PoJtta.bUdy - The host language used shall make the system machine independent such that the system can be easily implemented on a munber of computer systems.

-6-

III. DESIGN MEIHOOOLOGY

1. Basic APISlMUL Structure

The APISlMUL systan consists of four key el.ererrts : a Simulator/ Assembler (S/A), a set of Interactive Debugging Facilities (IDF) , a set of File ~.Janaganent Facilities (FMF) and a Developnent Control language (DCL). The elanents are related as depicted in Figure 1.

The Simulator/Assembler (S/A) simulates all aspects of the target processor, in the present case the ~~9900. Thus the simulator executes all source programs for the TMS9900 on the host system. The assembler assembles all TIv~9900 source programs and produces an object code rrodule of the assembled code. The simulator and assembler functions are concurrent, that is there are no separate functions for each. However, it is possible to exclusively simulate or exclusively assemble the code in addition to doing both simultaneously. The assembler is fully syrrbolic and operates on its own symbol table.

The Interactive Debugging Facilities (IDF) are a set of very powerful debugging tools that can be invoked under the APL system execution rrode

or under DCL. IDF performs a number of useful functions that ease the software development process. IDF can be invoked in an interactive or noninteractive mode.

The File Management Facilities (FMF) are a general set of APL functions that process and rratrrtatn the various data structures used by APISlMUL.

-7-

I-I I I

I I I

I

I

L _

DeL

S / A

I D F

SOURCE PRCX1RAM

FMF

DEBUG RESULTS

Figure 1. Structure of APLSlMUL

!XL PR:XJRAM

-8-

FMF is flexible enough to operate on all the different types of data structures and to load and serve from and on to the disk.

The Development Control Language (OCL) integrates all the previous parts of APLSlMUL and provides a general language structure for algorithmic debugging. The OCL conmand structure incorporates many of the comrands

from the SIA, IDF and FMF. Included with the OCL package is unique APL interpretive compiler and the various secondary data structures such as

the syniJoI tables, tag label lists, and nodule lists.

As can be seen the various elements of the system overlaps to a degree depending on what context the element is being used. In general each APL function can be invoked during the APL system execution rmde , However, these functions can also be invoked during a OCL run.

2. Simulator/Assembler (S/A)

The Simulator I Assembler is the rmin tool used to develop microprocessor software. It allows the user to take full advantage of a larger computer, in this case the APL system thereby significantly reducing the number of rranhours in program development. A critical advantage of such simulation is that program development and testing rmy begin before receipt of the actual target hardware system .. In addition, a simllator can simulate those facilities of the target machine that are invisible to real programmer. In this way internal registers can be simllated and examined readily. A simllator can also control the execution of the source program externally without affecting the program itself.

-9-

As the program is being simulated/executed, it is also being assenbled.

At the end of the program execution an object code nodule in the form of a sequential vector is produced. Essentially the Assembler is an integral part of the simulator, although the system can be run under three nodes depending on the ASM flag.

1) ASM = 0 simulate only,

2) ASM = 1 simulate and asserml,e ,

3) ASM = 2 asserrble only.

The basic outline and functioning of the S/A system can be dia~ med in Figure 2. The most important concept of the S/A is that its structure resembles the basic sequence of process in a typical CPU as in Figure 3. CPUCDNI'IDL is analogous to the "I" sequence and the following instruction execution, operand preparation and starter register functions are analogous to the "E" sequence. In addition, the simulator operates

on a set of data structures prepared by the File Management Facilities which are directly analogous to the IIDII part. Thus in effect the

simulator in this structured form is a simulation of a general \Dn Neumann archi tecture type of computer. This computer type encompasses rrost l6-bi t microprocessors.

To run the assembler one must create a Source Program Development File under control of FMF. After editing this file the user then loads and registers it into the merrory (M) using the specialized FMF facility, XLINK. M is a very specialized file which takes the form of large character rratrix directly simulating the target microprocessor mermry ,

Invoked Under

!XL run

-10-

- SYAm:l

TABLE 1

I

-,..--,..---,-- 1

I "D" I

---- ----_j

r~,INTR

INrERRUPI' t--~PROCESSING

CPUCDNTIDL REG

I I

I 1'----

I 1 INSTRDCrION

>-_I;....,I~ EXECUI'rON & I I ASSEMBLY

II ~--.---t

1 I

I I

I I UPDATE \

~--t-'--{ STATUS

I I REGISTER

I "1,,1 I

I I L \_ _

L __ ~S ~ I ts

--- __ J Error

RESULTS & OOJECI' roDE M)DULES

DISPLAY STATUS

I

I Yes

-- - -- - ----I

I

OPERAND I

ADD OPERATIONS I

1

1 I I I

I I "E" I

--_j

Figure 2. Simulator/Assembler Structure

I 8rART

-11-

Figure 3. Basic CPU Flow Diagram

-12-

The asseni:lly code in mnennnic form is entered directly in the matrix along with all binary or hexadecimal data. The sinrulator has special access to this memory and systematically works on each successive word as the program is being executed. Once the program is loaded into memory Sf A can then be invoked either alone through the APL execution node or under a IXL run. Four comrands control the execution of Sf A:

START - starts simulator and assembler

ASSEMBLE - changes to assemble only node SIMULATE - changes to sinrula te only rrode

REENTER - returns to CPUCONTROL after breakpoint

CPUCO~"'TROL is the heart of the Sf A system. It serves as a rraster control program that guides the sinrulated target CPU through its instruction acquisition and execution cycles. During each cycle, the CPUOONTHOL program, if desired, surveys all pending interrupts through a secondary subroutine, and take appropriate action to service the interrupt and return to the main program. All interrupts (0-15, RESET, WAD) are sinrulated and are entered directly from the tenninal. In addition, ESC is a high priority system interrupt that terminates the simulation.

All breakpoints are surveyed, and if one is detected the CPUOONTHOL exits so that appropriate action can be taken. The breakpoints that the system provides are very complex and powerful and allow the designer

a great deal of flexibility in debugging programs.

E-break: break at specified instruction S-break: break on status register condition

-13-

T-break: break at special time allotment

I-break: break at specified interrupt

P-break: break at specified program control value.

To set a typical breakpoint one enters as follows under APL execution IIDde or :ocr.. run IIDde:

TBREAK '542'

'This means that the simulator will stop execution, display the CPU status snapshot and wait for further comrands once 542 microseconds of simulated target CPU cycle time has passed. 'This is a very unique feature and is extremely important in such time-sensitive applications such as operating system, time-sharing systems, and real time-systems.

In addition, there are various special trap conditions (88, ~S and ESC) are associated flags.

88 - trap at every single step

1E - trap at rrrultiple steps (specified) E8C - error or escape flag trap

- memory protection violation trap

- illegal meIIDry reference trap

'These various breakpoints and traps can be cleared by the user at any point and can be resent into the simulation.

'The instruction execution or "E" part of the 8jA system is very important for it is here that the actual instructions are being assembled

-14-

and executed. These two processes are selectively concurrent as rrentioned before. For instance, as the operand addresses are being computed the respective part of the object codes are being processed. At the end of the instruction execution cycle the binary object code is decoded and concatenated to the end of the OBJ object nodule vector. As the instructions are being executed and assembled all relevant CPU status indicators are being updated as well as keeping a record of execution during information.

3. Debugging Facilities

APLSlMUL provides a set of powerful debugging facilities that may be used under both APL system execution node and OCL run node. Any debugging facility may be interactive by typing in the command followed by "I". There are basically too types of debugging facilities available in APLSlMUL. The first are acc~~ facilities. The facilities resolve the problem of getting at and modifying the data items which are the contents of hardware units such as rremory locations, CPU registers,

I/0 words, etc. These data items are collectively referred to as the

CPU Configuration Fiel Assembly. The access debugging facilities directly operate on this special file assembly. Since the simulator simulates these data i terns the user can have direct access to them. All debugging facilities that access memory words automatically check the data through a separate function, DATASET. The second type of debugging facilities

are those involved with co nVwt. The purpose of control is to handle a dynamic process to direct, alter or interrupt a source program while

-15-

it is running. The APISIMUL debugging facilities provide a set of control

functions that are totally transparent to the program being simulated.

A summary of the debugging facilities is shown in Figure 4, and a sample

interactive run in Figure 5.

4. File Management Facilities

The File Management Facilities (FMF) provide a general set of APL

functions that operate on and edit the various files used in the APLSIMUL

system. Basically there are three categories of files used in APLSIMUL:

1) CPU Configuration File Assembly

This is a group of data structures that define the CPU and are operated on by the Simulator/Assembler. These include:

M

rrermry simulation

CRU CIO

I/O simulation

CRU bit configuration

SYM

symbol tables )

) Linked list symbol values )

NUM

PC,WP,ST

CPU registers

Breakpoint tables

Interrupt Flags Simulator Control Flags

2) Source Program Developrrent Files

This set of files contain source programs to be eventually

simulated or asseniJled. Thus the program can be edited with

ACCESS

-16-

MEMINSPECT- inspect and alter single memory locations

CRUINSPECT- inspect and alter single or rnul tiple CRU bits and their I/O or interrupt status

REGISTER- inspect and alter CPU program counter, workspace pointer and status register

WORKSPACE- inspect and alter the current workspace register assembly

ENTER- directly load programs or data blocks into the memory

LIST- produce symbolic listing of programs in the merrory

SEARCH- search t1etrory for a particular word

CDNTROL

SETINTERRUPT- sets all interrupt masks

EBREAK- sets breakpoints at specified instructions

SBREAK- sets breakpoints on specified status register conditions

TBREAK- sets breakpoints at specified time allotment

IBREAK- sets breakpoints at specified interrupt calls

PBREAK- sets breakpoints at specified program counter values

CLEARBREAK- clears specified breakpoints

SINGLESTEP- sets up single step mode

MULTISTEP- sets up specified multiple step mode

UTILITIES

DECODE- decodes packed binary data to decimal and hexadecimal data

ENCODE- encodes decimal or hexadecimal data to packed binary data

DISPLAY- displays status of the simulated CPU at all breakpoints & traps

Figure 4. Debugging Facilities

-17-

SEARCH 'END'

END

FOUND AT OA40

REGISTER

CPU REGISTER DISPLAY

PROGRAM COUNTER (PC) = OOFE WORKSPACE POINTER (WP) = OA3A

STATUS REGISTER (ST) = 0 1 1 0 1 0 0 0 0 0 0 1 0 1 0 1

>WOULD YOU LIKE TO CHANGE ANY? YES,NO YES

>ENTER REGISTER CODE (PC,WP ,ST):

WP

>ENTER NEW WORKSPACE POINTER:

OA41

CPU REGISTER DISPLAY

PROGRAM COUNTER (PC) = OOPE WORKSPACE POINTER (WP) = OA41

STATUS REGISTER (ST) = 0 1 1 0 1 0 0 0 0 0 0 1 0 1 0 1

>WOULD YOU LIKE TO CHANGE ANY? YES,NO NO

Figure 5. Typical use of Debugging Facilities

-18-

greater facility without the constraints of the mennry sinrulation. When the program is ready to be processed, it is linked into the rrarory.

3) OCL Program Files

These files contain the DCL programs to be interpretively conpiled and run.

The use of APL shared variable processor allows these files to be transferred from disk in to the current APL workspace and vice versa. In addition, a powerful set of general facilities process these files. Figure 6 is a summary of the File ~IDnagement Facilities in APLSIMUL.

5. Development Control Language

The Development Control Language is a powerful addition to the APLSIMUL system that greatly simplifies the software development process. Using DCL the systems programmer can follow a systematic debugging procedure quickly, algorithmically and efficiently in order to achieve debugging results. The language supports the entry and editing of structured code that defines a particular debugging process. In addition, using OCL uniform program testing procedures can be developed to test resul ts and be used repeatedly to verify the source programs.

The entire philosophy of the language is based on Algorithmic Debugging Blocks which function as user defined nodules. Each block or nodule performs a single debugging task as defined under the language

-19- OOUBCE PImRAM DEVELOPMENT FILES

FILE CDMMANre

FSAVE FLIST FLOAD FERASE FLINK

- save file on disk

- list file

- load file

- erase file

- prepare and relocate program to load into merrory

FILE EDITING UI'ILITIES

ENTER - enter data

TOP - bring pointer to top

BOT - bring pointer ro end of file

LOCATE - locate text

PRINT - print file lines

ADVANCE - advance pointer REPLACE - replace text DELETE - delete text

INSERT insert lines

ERASE - erase lines

oct PIOGRAM FILES

Same except for FLINK

EXECUTE - interpretively compiles and runs oct source program

CPU mNFlGURATION FILE ASSEMBLY

MEMINSPECT - REGISTER CRUINSPECT - INPUT

LIST WORKSPACE - SEARCH

DUMP

DETACH ATTACH

) ) )

» Same as in Debugging Facilities )

)

)

dumps merrory into source program developrrent file saves entire CPU configuration file assembly on disk loads entire CPU configuration file assembly from disk

Figure 6. Summary of File Management Facilities

-20-

constructs and the various debugging facilities. Essentially the language

is a coomand processor in that rrost corrmands previously described can be

used in all !XL statements. There are basically three parts to the language:

1) COMMAND (l)NSTRUCIS. Abst of the Debugging Facilities, Simulator/

Asserrbler corrmands, File Management Facilities from the basis

for all of the basic language corrmands. For example:

PBREAK 'OB61'

is perfectly valid as a language conmmd. When followed by a

command to start the simulation or to reenter the simulation the

program will then break when it reaches a program counter vanue

of 0061.

2) (l)Nffi)L CDNSTRUcrS. This is the heart of the algorithmic

structure of the language. Every control construct is identified

by a PERFORM statement. This is a feature which rrakes each

control statement easily identifiable and also makes the language

very consistent. Since the language is composed of rrodules the

PERFORM statements easily selectively control the execution of

differe~t nDdules. In addition, often tasks must be selectively

controlled wi thin rrodules. For this reason subrrDdules are

provided.

A rrodule is defined as follows:

cc NAME:

-21-

A subnDdule wi thin a rrodule is defined as follows:

c NAME:

For a subnDdule a nane need not be provided if and only if it is

referenced irrplicitly by a conplex PERFORM. There are two types of

PERFORM which involves a single rrodule or sttbnDdule reference. The

conplex PERFORM involves a double rrodule or sub-rrodule reference.

Figure 7 shows a sunmary of the PERFORM stataoonts.

3) EXPRESSIONS. Expressions are APt statements that operate on

either DCL defined variables or actual data structures used in

the sinrulation. Any executable APt expression can also be used

as a DCL expression. This unique feature makes APt a pseudo

subset of DCL. In fact DCL can be thought of as an APt

inplementation which includes structured ALGOL-like control

constructs as well as additional debugging comnands. This rrakes

DCL an extremely powerful language capable of many advanced

functions.

All expressions are determined by I-beamc:; as follows:

I I+O I

PERFORM cI M[(~WP)+I;I+I+1J+ '0' I~ 16 TIMES

DCL is run in two steps:

1) Enter and Edit DCL program files using relate utilities in FMF.

2) Invoke the DCL Interpretive Compiler System (ICS) through EXECUI'E.

PERFORM

PERFORM

PERFORM

PERFORM

-22-

1-

1) nodule reference

2) suOODdule reference

3) FOLLOWING

(implicit submodule)

4) inserted suOODdule

1), 2)

1), 2)

1).2L3).4)

WHILE WHEN UNTIL

condition

WITHOUT RETURN

I expression! TIMES

Figure 7. Simple PERFORM Constructs

-23-

PERFORM

CASE OF rexpresstonr

11 c,.. ............. ~,....-~ :::>

21 c ~ """_oJ"" ,....... :::::>

31 c ~,...- .-....rI -,.. :::>

41 c ,.. """W ~ ,.. :::>

ELSE I c ~,~- ...... ~ ::>

PERFORM

WHILE condition

c ~- -,.....,. "" _.

ELSE

c ......... _ ....... ,..-v wl"tt#l'V

PERFORM

WHEN condition

PERFORM

FOR I expr I TO I expr I STEP I expr I

ELSE

ELSE

c ~ .................. ~ oJ

PERFORM

UNTIL condition

ELSE

Figure 7 cont' d. Complex PERFORM Constructs

-24-

Using FMF a single OCL program file is created. At least one nodule must be written. Although several nodules can be included. In the file each llDdule is written after the other and must begin and end with the appropriate del:ineters. The OCL program file can be saved on disk using FSAVE or loaded from disk using FLOAD. The OCL program can then be listed using 1!L1ST.

After the DCL program file is complete the DCL Interpretive Conpiler System (Ies) is invoked through EXECUTE. Since multiple DCL programs can exist in the APL workspace the file name of the nodules to be executed rnust be specified. In addition, the first nodule to be executed rnust be specified. Usually this first nodule will call upon the other IlDdules in a predetermined sequence. After the Interpretive Compiler is called, Ies, then line by line translates (interprets)

the DCL code into APL code. Each actual nodule is converted into an APL function in canonical representation. During the conpiling process all errors are detected and if so the process aborts.

After each line has been interpreted the Symbol Reference Table

and the Symbol Definition Table are compared. If there are any errors, then the OCL program is not run and the user is warned. After all of the nodul.es are compiled the canonically represented functions are then transformed (fixed) into standard APL function format. Finally, the Execution Control Utility executes the first IlDdule which then runs on

its own. The 1es is relatively easy to implement because of the simplicity of the language design. A special APL function operates on all the

-25-

PERFORM statements. When one is recognized, the sequence of APL control statements is substituted in the translation.

The IXL Commnd Processor and the IXL expressions are just rmnifestations of the APlSIMUL and can be easily irnplenented. However, the statements are checked for errors.

A sample IXL program and its execution is shown in Figure 8.

-26-

ENTER 'PROGRAM' cc INIT:

r I+O r

PERFORM FIRST WITHOUT RETURN ::J::J cc FIRST:

PERFORM EXIT WHEN r I>MSIZE-1 r PERFORM

WHEN r M[(I-1).(I+I+1);116J= 2 16 prot r c r Q+-'DOUBLE ZERO AT: ',,,«I-1),I) r PERFORM FIRST WITHOUT RETURN ::J ELSE

c PERFORM FIRST WITHOUT RETURN ::J

cc EXIT~

EXECUTE 'PROGRAM'

>ENTER NAME OF FIRST MODULE TO BE EXECUTED:

INIT

COMPILATION OK EXECUTING

DOUBLE ZERO AT: 4 5 DOUBLE ZERO AT: 24 25 DOUBLE ZERO AT: 321 322 DOUBLE ZERO AT: 693 694 DOUBLE ZERO AT: 694 695 DOUBLE ZERO AT: 695 696 DOUBLE ZERO AT: 696 697 DOUBLE ZERO AT: 697 698 DOUBLE ZERO AT: 698 699 DOUBLE ZERO AT: 699 700

Figure 8. OCL program run

-27-

IV. DISCU3SION ON ASPECTS OF IMPLEMEm'ATION

The use of a high. degree of rrodul.arf, ty in the APlSIMUL system, particularly in the Simulator/Assembler is important both structurally and functionally. Structurally it serves as a nodet of an ideal implerrentat ion of state-of-the-art software engineering techniques. Throughout

the APLSlMUL design process it has been possible to independently verify the system correctedness of each program nodule. In addition, this concept of rrodularf ty has been extended to the design of the Development Control language (DCL).

Functionally the modular design is critically important in the universal extensibility of the APLSlMUL system to all 16-bit microprocessors. The design of Simulator/ Assembler has been based on conventional conputer architectures. An outline of the APLSIMUL Simulator/ Assembler essentially resembles both the structure and functioning of a typical coIIputer, see Figures 2 and 3. For instance, in the TMS9900

there is only one APL function for each opeartion code. Figure 9 shows

one of these functions. The basic flowchart that executes these instructions is shown in Figure 10. Using this flowchart and various standard

APL idiom, the instruction execution function can be inplemented for

any given instruction set in a particular CPU architecture. The Digital Equipment PDP 11 implementation for the NEG instruction is shown in

Figure 11. Once the basic design has been inplemented, then these modifications can be put into others to simulate other instructions of

PDP 11. This is a sinple process. In addition, each instruction can

-28-

be tested individually with a suitable test program. In fact, this approach was used to verify all of the instructions execution functions for the TMS9900.

The universal extensibility process can be defined exclusively by two factors:

1) The rrdcroprocessor architecture

2) The instruction set.

Therefore with further research, it should be possible to develope a set of programs that upon inputting the architecture and instruction set specifications a Simulator/Assembler would be generated.

-29-

Il NEG [1] SADD

[2] +«ADD[lJE:MP).ESC=1)/9.0

[3] +(ASM=2)/8.T+T+8+1tW,MRW+MRW+1

[4] T1+M[ADD[lJ;116J+DW/~BWT1+BW~~!DW\M[ADD[lJ;116J [5J ST[4J+T1='1' .15p'O'

[6J STW

[7J +8xASM

[8J +O.OBCAL.TOB[t10J+ 0 0 0 0 0 1 0 1 0 0

[9J AER+AER+ESC+1t1.p[fr' ;ERROR: MEMORY PROTECTION VIOLATION! [7J '

('f( !oPC )-EX). ' , ,IR

1: S~ Single address operand preparation function

2: Error trap, ADD is the address vector, ESC is the ESCAPE flag

3: Update program statistics, T &:MRW, If assembly flag ASM = 2 then assemble

4: Negate and store rnemry word, T1 is status update transfer vector

5: update status register

6: Update status register

7: If asm = 1 then assemble as well as simulate

8: Finish assembly of operation and process object code vector OBJ with OBCAL

9: Error message, adjust program counter

Figure 9. TMS9900 NEG Instruction Execution Function Implementation

ENS

STW * SIB

VAR

T1

-30-

FCNS

* FAnD SADD DADD BAnD DISP SHADD HAnD JADD

OPERAND PREPARATION

VARIABLES AID BYTE1 BYTE2

IMM

DI

ASSEMBLE ONLY

ERROR TRAP

UPDATE PRXiRAM STATISTICS

FCN

Yes

___ ~ ASSEMBLE

EXECUTE and/or ASSEMBLE

VARIABLFS

* OBCAL 'IDB EX

RETURN TO CPU CDNrRQ

Figure 10. Instruction Execution Flowchart

UPDATE STATUS REGISTER

[1J [2J [3J [4J [5J [6J [7J [8J [9J [10J

-31-

'V NEG

SADD

+«ADD[1JEMP),ESC=1)/10,0

+(ASM=2)/9,T+T+1

+(MODE=0)/6 +7,pT1+M[ADD[lJ;116J+DWZ~BWT1TBW~~~DW\M[ADD[lJ;116J Tl+R[REG[lJ;J+DW/~BWT1+BW~~~DW\R[REG[lJ;J

STW

+9xASM

+0,OBCAL,TOB[110J+ 0 0 0 0 1 0 1 1 0 0

AER+AER+ESC+1 +1 ,p[}-' ; ERROR : MEMORY PROTECTION VIOLATION! (~(!.PC)-EX),' , ,IR

[7J '

4,6: Different for the PDP-11 because registers are in the CPU; node is the addressing flag set by SADD, when this is 0 the registers are directly addressed.

Figure 11. PDP-11 NEG Instruction Execution Function Implementation

-32-

v. SUMMARY AND OJNa..U3ION

In the present paper a software development system design is described and its significant and unique features elucidated. Fur-themnre , based on implementation experiences 1 relevant aspects of the design features are discussed.

The APISHn system can be used to reduce the cost and time involved in 16-bi t microprocessor system development. Although it is obvious

that the current trends in advanced microprocessor technology require powerful and complex development tools, such syatems have not been implemented. APISIMUL has been designed to effectively fill that gap through the integrated use of many features including the Simulator/ Assembler, the Interactive Debugging Facilities, the File Management Facilities and the Development Control Language. A significant part of the APISIMUL system is its universal extensibility which lends the

system a great deal of flexibility and structure.

-33-

I would like to thank the IBM Corporation for providing the use of an IBM 5110 computer system. In particular t I would like to thank Mr. Frank T. Cary, Chairnan of the Board of IBM, Mr. J. W. Scruggs, Vice-President of General Systems Division, Mr. David Hanna, Manager of IBM Business Computer Center in New York and Mr. Tom Wolfe, Administrative Manager of IBM Cambridge Scientific Center.

-34-

References

Blaauw, Gerrit A., Digital System Irrplerrentation, Prentice Hall, (Englewood Cliffs, New Jersey), 1976

Falkoff, A.D., Iverson, K.E., Sussenguth, E.H., "A fonnal description of System/ 360", IBM Systems Journal, Vol. 3, No.3, 1964

Goos, G., and Ila.rtImnis, J., Software Engineering, Springer-Verlag, (Berlin), 1975

Katzan, Harry, The IBM 5100 Portable Cbmputer, Van Nostrand Reinhold Co. (New York), 1977

Kemerer, N.J., and Poerio, J.D., "An Integrated Development Discipline for Microprocessor Systems/Software", IBM Technical Directions, Vol.4, No.4, Decanber 1978

M:>tt, Donal.d. R., "A Software Development Methodology for Real-T:i.Ioo Applications", Proceedings CDMPSAC '80, IEEE Computer Press, 1980

Myers, Glenford,J., O?mposite/Structured Design, Van Nostrand Reinhold, (New York), 1978

Riddle, W.E., and Fairley,R.E., Software Developnent Tpols, SpringerVerlag, (Berlin ), 1980

Satterthwaite, Edwin,H., Source Langlli.l.ge Debugging Tools, Garland Publishing Inc. (New York), 1979

Wiecek, Cheryl A., and Steely, Sinon C., ''Perfonmnce Simulation as

a Tool in Central Processing Unit Design", Simuletter, Vol. 11, No .1,

9900 Family Systems Design and Data Book, LCC4400 Texas Instruments,1978 IBM 5110 APL Reference Manual,SA21-9303-0, IBM 1977

-- APL Progranming Guide, G320-6103-0, BIM 1978

-- APL Language, GC26-3847-4, IBM 1978

~- PDP 11 Processor Handbook, Digital Equipment Corporation 1979