Journal of M icrocomputer Applications (1982) S, .

209-223

S A S -a n e x p e r im e n t a l to o l f o r d y n a m ic p ro g ra m
s tru c tu re a c q u is it io n a n d a n a ly s is

V. Callaghan and K. Buk ••.

Department of Electronic and Electrical Engineering,
The University,
M appin Street,
Sheffield S/ 3JD, UK

Ths paper dcsctibes an •• perimenlal microprocessor-based tool, SAS (Software

Analysis System), which has been developed to enable dynamic program structure
acquisilion and analysis to be made on digital computing machines.
The system uses a universal hardware ""traction technique to obtain branch veclors
which are used 1 0 analyse and display the struclure of the software being monitored. A
display. especially designed for small instrument screens, is used to present this slruc.
ture. Emphasis has been directed towards development of methods with high degrees
of machine independence and it is envisaged th a t s u c h techniques could either be
integrated into the new generation of logjc analysers or fonn part of a universal tool
for computer programmers. Initial research has been guided towards the application of
these tcchiJiques to compiled, assembled, or machine coded systems and in trus context
a number of techniques are described.
The mOlivation for this research has been provided by the present escalating soft-
ware costs, in particular those in post development which account for apprmdmately
75 % of the lotal software •• pendilure.

1. Introduction
Software is presently dominating the cost of computing systems. The price of computer
hardware is falling at a rate of appro,imate!y 28 % p.a. whilst programmer productivity
is rising at only 4-7 % p.a. This indicates an escalating dominance of software costs on
computer systems (Allison, 1980) (see Figure I). The software demand growth rate is

100
~dII •• I c ; : ; . "
90
80
TO

>0
ZO
'0
o
-
&60

flIure J. Life<ycle costs of computer S)'ltems.

209
014:l-3792/82/030209+ 15 $03.0010 It! 1982Academic Press Ioc. (London) Limiled
210 'f . Callaghan and K. Barker

estimaled to be in the order of 21-23 % p.a. whilst the software labour force and ilS
productivity per individual are producing a combined growth rate of only 11.5-17 % p.a.
(Boehm, 1976). Recent American government figures indicate tbat, if this trend con-
tinues, by 1990 there will be a shortage of between 1-2 million programmers (Schindler,
1981). One solution to tbis problem would be to substantially raise the level of pro-
grammers' productivity. It is this environment which is motivating the research for new
tools and techniques to lISsist the programmer in his efforts throughout the software
life cycle.

l.l Software life eye/e

The life cycle of a program may be envisaged as comprising two stages; namely, develop-
ment and maintenance. Software development accounts for approximately 25 % of the
total cost, the remainder being attributed to maintenance (Mills, 1980). An estimate of
the order of expenditure involved is provided by Boehm who reckoned that the annual
cost of software in the United States during 1976 was some 20 billion dollars (Boehm,
1976).

1.2 Software maintenance

The term 'maintenancc' (Munson, 1981) is misleading because when used in this context,
it refers to the following post delivery activities defined by Swanson (Munson, 1981;
Swanson, 1976) as:
(i) Corrective-fixing a pre-existing error (in either specification or code).
(ii) Adaptive-modifying the software to accommodate environment change.
(iii) Perfective-improving or augmenting the performing capabilities.
Boehm (1976) has defined maintenance as 'the process of modifying existing operalional
software whilst leaving its primary functions intact'. These post-delivery activities usually
continue for considerably longer periods than their corresponding development time
thus accounling for the high maintenance overheads. Reducing any of the activities
defined by Swanson can thus potentially have a profound influence on software ex-
penditure. Unfortunately, as Boehm (Boehm, 1976) has stated 'Despite its size, software
maintenance is a highly neglected activity'. SAS has been constructed to address the
problem of maintenance by providing a tool which can counter the programmers'
intrinsic intellectual limitations (Gries, 1980) by, in the firsl instance, restricting software
complexity and enforcing adherence to structural constructs during software develop-
ment and qualily assurance checks and, in the second instance, supporting maintenance
by providing an aid for deciphering poorly documented or complex code.

1.3 Presen/teehnology

The main impetus for innovation and development of program execution monitoring
tools has been provided by companies with a commercial interest (Marshall, 1978).
Results of such research usually manifest themselves in marketed products. Reported
research is sparse, a fact supported by a recent survey (Plattner & Nievergelt, 1981)
which reports, 'program execution monitoring has been a neglected research topic' and
 SAS--a software &IIll1ys1s
system 211

concludes by stating 'program execution monitoring has not received attention com-
mensurate to its practical importance'.

1.3.1 Commercial systems. Commercially available tools which provide facilities for
program execution monitoring are; (i) performance monitors, (ii) logic analysers and
(iii) development-emulation systems.
Performance monitors (Nutt, 1975) are normally used on computer systems which
manage such facilities as multi-user, virtual storage and multiprogramming. They gather
and analyse information concerning the monitored system hy either timing or counting
the occurrence nf specific events or conditions. Activities monitored by these systems
include CPU activity, channel activity and I/O activity. Analysis of this data is then used to
(i) investigate resource utilization, (ii) determine the characteristics of the jnb load, (iii)
remove bottlenecks and (iv) tune software and gather data for system monitoring. Due
to the large quantity of data produced by these systems, the information is normally
gathered and presented statistically. These tools are usually used on large systems and
cost in the region of £40,000 to £150,000,
logic analysers (Marshall, 1978) are tools which log absolute time sequential data
present on a number of parallel channels. Data acquisition may usually be started on the
occurrence of a pre-specified combinational trigger and continues until the analyser
memory is full. Data is normally displayed either as a timing diagram, state map or as a
table. A current trend by manufacturers is the adaptation of logic analysers to directly
support program development by including facilities such as disassemblers. Typically,
a logic analyser may contain 24 channels, a memory depth of 256 words, an operating
speed of 100 MHz and cost between £4000-£8000.
Development systems and hardware emulators (Krummel, 1977) include facilities such
as dynamic tracing and breakpoint execution to aid program development and de-
bugging. Although many systems implement these features in software, some systems,
particularly emulators, provide hardware for this purpose. Professional development and
emulation systems cost in the region of £5000 to £25,000.

1.3.2 Research acrivities. Research activities concerned with prngram execution monitor-
ing are reported in an early paper by Stockham (Stockham, 1965)and a recent paper by
Plattner & Nievergelt (1981). Fryer (1973) has described a dumb system, 'The Memory
Bus Monitor' which utilizes the stream of addresses and data travelling the memory bus
in conjunction with hardware comparitors, timers and counters. These provide such
measures as branch ratio, routine timing and variable behaviour. An eight-word shift
register provides a limited trace facility. lemon (1979) describes an improved version of
the monitor, 'SOVAC', which uses a PDP-l 1/34 to support a graphic terminal, simplify
the user interface and provide an analysis capability. IBM's recent reports have de-
scribed a 'Programable Map aod Trace Instrument-PMATl' (lloyd et aI., 1980) and a
'Program Counter Sampling Tool' (Armbruster et 01., 1978). PMATI maps and traces
program execution by interfacing to the system address hus. The trace function records
the sequential stream of address whilst the mapping facility is implemented by associating
a bit with each possible address occurrence. The program counter sampling tool
periodically samples the instruction counter and increments a counter associated with a
window which the value of the program counter lies between. The window widths and
address space coverage are variable whilst the number of counters and windows is
 212 V. Callaghan and Ie. Barker
fixed at 4096. In applications where the loss of time sequential data is not of significance
an advantage of increased sampling periods may be achieved by use of this technique. A
debugging tool 'The Program Tracer' (Antoine et al., 1979) interfaces to the system
address, data and control buses. Upon triggering it llClectivelyacquires data from the
monitored buses according to a set of initialization conditions. The selective acquisition
capability both differentiates it from, and provides a sizeable data reduction over the
conventional logic analysis techniques. Results arc presented as text on either a printer
or YOU. Versions for tracing the ITT 3202, Intel 8085 and the RCA 1802 processors
have been reported.

1.3.2 Summary. The majority of these tools and techniques usc the monitored systems
buses to extract direct program execution data in the form of real time traces. As such,
they arc primarily debugging tools. Performance monitors extract indirect data concern-
ing the effects of the program execution from various system testpoints and perform
analysis to produce certain measures on characteristics of the software. SAS differs from
these tools by directly extracting a fundamental structural program property, performing
analysis and presenting the programmer with data concerning the program's complexity
and structure.

2. T h e S A S s y s te m

2.1 Physical description

SAS consists of a cabinet which houses two single sided, double density 8 in. disc drives,
a power supply, cooling unit and a 12-slot rack containing:
(i) a CPU board;
(ii) a disc controller board;
(iii) two structure table RAM boards;
(iv) an EPROM system software board;
(v) a structure monitor board;
(vi) a control board.
System peripherals include a VDU, a printer, a colour monitor and a data acquisition
probe set.

2.2 Principle of operation

Figuse 2 shows a block diagram of the SAS system. The personality adaptor interfaces
the program counter or memory address lines of the system under test to the structure
monitor which extracts branch vectors. These vectors are stored in one of two memory
blocks, structure tables I and 2, which in tum may be operated upon, displayed, or
stored on the system discs.

2.2.1 Structure a<:quisitionprinciple. The technique to be described is based upon the

principle that branches in compiled and assembled code correspond directly to deviations
from the normal sequential incrementation process of the program counter. Dynamically
executed branches can therefore be logged during program execution by storing two
 SAS-a software aaalysis system 213

F"JllUI"ll. Scbematic diasram of SAS.

S tru c tu re r n o o lt o r

CloCk
q u a llf Ita to r y
circuits

FI& un 3. Structure acquisition schem e.

words which correspond to the value of the program counter i=ediate1y prior and
following a non-incrementally sequential update. It is then possible to reconstruct the
structural properties of the executing program in the form of a directed graph from the
table.
Figure 3 shows a block diagram of the structure acquisition scheme. A probe unit is
connected to either the program counter chip set, computer backplane or a micro-
2I4 V. CaUaghaa aod K. Barker

processor. These probes fetch the program couoter outputs including clock qualificatory
signals through line driving and receiving circuits to the structure monitor. In the struc-
ture monitor the successive addresses are clocked into a two bit shift register which
enable the time adjacent values of the instruction address register to be analysed for a
branch by the succeeding circuitry. Analysis of branch conditions is performed by com-
paring the shift register word corresponding to the instruction address register's latest
value to its former value plus one. An inequality in this comparison indicates that a
branch has taken place and a sequence is initiated which causes the two non-sequential
values of the program counter to be stored in a memory-based structure table.

2.2.2 Structure di.rplay principle. The technique utilized to display the program's
dynamic structure is based upon a directed graph and has been particularly devised for
use in conjunction with small instrument display screens. Essentially it is a circle. the
circumference of which is calibrated to correspond to the portion of memory being
monitored. Branches in the program's normal sequential flow are depicted as chords on
the circle. A clockwise rotation corresponds to the normal positive sequential incrementa-
tion process of the program counter. On a colour display the chords are colour coded to
indicate the direction of the branch, the execution frequency being impressed as the

"""""Y
steff/finish

rlKUre 4. Structure map.

intensity of the chord. Figure 4 illustrates a measurement being made on a Texas Instru-
ments TM990jIOI which has a simple program containing three loops, two of which arc
nested and a subroutine call.

2.2.3 Structure analysis principles. SAS provides a set of software-implemented algor-

ithms which augment the hardware-based acquisition and display system by providing a
means of testing, modifying and presenting the acquired branch vectors in a man ncr
which may be readily interpreted. A complete list of SAS commands and algorithms is
provided in Figure 5. These commands may be divided into three classes, namely, tcst,
control and operator commands. Test commands are concerned with verifying various
functional elements in SAS itself such as the structure tables and display (e.g. TM, SB).
Control commands supervise the acquisition, movement, storage and display of data
within SAS (e.g. DP, DV). Operator commands arc responsible for analysis of the data
usually operating on data stored in the structure tables.
The structure tables are the nucleus of the analysis system (see Figure 6). All data
which is communicated to the user is obtained directly fro~ the structure tables. Data
 S~a software analysis system 215

6081>"" ~omplnity 35 FO- frequency Qpcrala<

AC

:2 .400 and Qpcralor J6 OP liet froaram

~cquisition o n ~o 37 01 Qet 15t St.rue:lure
3 AZ
4 AO ~cquisition on Q nc Table
~olour 1!&r G e n e r a t o r 38 02 get !nd Structure
5 CB
6 CD ~onlinual1y Q isplay Table
YectO rl 39 LV .List Yecton
7 CM Qeor ~emory 40 MA M aanitudc ~ c q u U it i? n

8 CP S;ontinu3.lIy fnol 41 MO M_itude Qpcratvr

Tc~as 990 Y e c t O I '\ 42 PC froanm ~ru Bits

9 CS Q ear ¥fccn 43 PEl !rint Etpansion

l;onfilUrc ~ex •• 990 P a ra m e te rs
10 CT
Personality Card 44 RE !.esct ~paNion
II DC Qraw ~irde 45 R1 Retrieve: ImaEc
12 DO Qisc Qiro.:lor1 46 RM .Return to M onitor

13 01 Q isplay lmaer 47 58 ~tar .l!ur"

101 OM ~isplay ~ark 48 SC ~ ~olour Table
15 DO ~al3. Qpcrator 49 SV ~ n yecton

16 OP Q um l"!rolnm 50 TM rest Memory

17 OV Q ispgy Y~tor.\ 51 TO Ie_us .Qpcrator
18 01 12ump 1st Structun: Table 52 TW lransfer ytord BIo<:I.:
19 01 .Qump lnd Structure Table 53 WA !!indow Acquisitio;t
20 ED txpand !2isplay 54 WL ytanderins1.inc
21 EO ~or Qpcralor '5 WO ~indow Q perator
22-23 E 'x ' ~.'caJte froJram :It F - , ' 0 0 56 WZ ~and Zero Acquisition
J4 FD formal );!is; 37 WO ~ a n d Qnc AcqUlsition

f'IIurt 5. SAS com m and iodu.

L. _ _• • . _ .. _

" T _ '"
_.-
"'.-.
•••. 0" data
r - - - - ,/
)
..... Slrvc!.',
labl.

Fisrure6. The structure tables :ire the D U c :le u s of [be software.

intended 10 be Ignored by SAS or Ih. user is nulled in Ihese tables_ This principle is
utilized by the anal)~ic:ll roulines which null the veclors in locations which have been
either eliminated or made redundant.

,--
216 V. CaJlagIwlaad K . Bark ••.

Five main analysis techniques are employed in SAS which are described in the follow-
ing paragraphs.
(i) YUlor mDgnilude, frequency and window jiltering. Filtering in the SAS context,
refers to the elimination of branch vectors which do not conform to prescribed
conditions. Two types of filtering process are employed in SAS; pre-storage and
post-storage. Pre-storage filters examine and eliminate, if necessary, the branch
vectors as they are acquired before storage. They can be implemented in either
bard ware or software. Post-storage filters process the branch vectors stored in the
structure tables, eliminated vectors being set to zero. Data null vectors are ig-
nored by the output processors of SAS.
M agnitude jiltering. These algorithms such as MA (pre-storage), and MO
(Post-storage) determine the magnitude of each vector and compare this to a
magnitude window supplied by the user. Vectors with a magnitude not between the
limits set by the window arc nulled.
Frequency jiltering. Frequency filtering refers to the elimination of vectors from
a specified table whose frequency of occurrence lies outside the boundaries of a
window supplied by the user. Intrinsically, frequency filtering can be only of a
post storage nature, as pre-storage implementation would imply prior knowledge
of vectors yet ungenerated. An example of this filter is the FO algorithm.
W indoM ' jillering. The elimination of vectors whose source or destination lies
outside a user specified window is referred to as window filtering. WA is a pre-
storage implementation of this algorithm whilst WO is a post-storage version.
(ii) Complexity and struell/re anal)'sis. Computer programs may be assembled using
arbitrary control structures. SAS extracts the branch vectors dynamically from
the program whilst it is running and uses them to fabricate a diagram which
mirrors the program structure. The freedom allowed in being able to use arbitrary
control constructs can lead to the production of highly complex programs which
are difficult to understand, maintain, adapt and test. To combat this type of
complexity, a methodology which allows the programmer to build programs ftom
only a limited set of structures is often adopted. This type of methodology is
already in frequent use amongst high level language programmers who commonly
use the three constructs; linear sequence, selection and iteration (Jensen &
Williams, 1981). Unlike high level languages whose algorithmic implementations
are based on the virtual machine rdIected by the language, low level assembly
languages' algorithmic implementations depend on the actual machine. As such
the use of GOTOs or absolute branches is unavoidable in all but trivial assembly
or machine code programs. Further, it is felt to gain many of the intrinsic ad-
vantages of particular machines a more lIexihle structuring criterion is required.
The approach on SAS is to allow the user the ultimate choice of which structure
criteria is appropriate to apply by placing the structure analysis routines in RAM
which is supported by the system discs and called by the EF command. A measure
of the conformity of a program to specified constructs is presented as the number
of instances in which these programming constructs are violated.
Predicate hranching in the control flow of computer programs can potentially
create control structures which are beyond the management intcllect of program
dcvelopment. maintenance and ada pI ion engineers (Gries, 1980, Mills. 1980).
 SA5-a software analysis system 217

Forward predicate branching causes the number of distinct control paths to

increase in proportion to 2" where n is the number of predicates, whilst back-
wards branching, can cause an infinite number of potential paths. Thus, even
small programs may contain a number of control paths which is beyond the
normal intellectual capacity of an individual (Gries, 1980). A measure for this
type of complexity has been devised by Thomas McCabe (1976, 1978) and is
known as cyclomatic complexity. This approach uses the cyclomatic number
derived from graph theory as a measure. The cyclomatic number is the number of
independent paths existing within a program module which, when taken in
combination, generate all paths and is expressed as:

V(G)=e-n+2p
where
V(G)x cyclomatic number (complexity measure);
e =number of edges (branch vectors);
n =number of vertices (branch vector nodes);
p =number of connected components (modules).

McCabe suggests a limit of 10 as representing an optimum level of complexity.

This algorithm is called on SAS by the command AC.

(iii) Instruction, data separation. A need to separate program data from instruction
addresses occurs in two main instances; program counter tracking which contains
data words embedded in the program memory field and composite instruction-
data tracking which gather data fields from both inside and outside the program
memory area. The latter situation would arise if measurements were made on a
microprocessor without instruction fetch cycle qualifying signals, whilst the
former occurs on systems with such signals. Program counter tracking systems
effectively branch around data blocks producing pseudo branch vectors which are
not part of the program logic flow. Some processors treat the additional words in
multiple word instructions as data words, thus inducing pseudo branch vectors.
These false branch instructions are eliminated by using the 'not instruction fetch'
qualifying signal to produce a data track and negating branch vectors, which
correspond to these data domains. Composite instruction-data tracking results in
the generation of mixed data fields and instruction branch vectors. Intrinsically,
this system eliminates the multiple instruction word pseudo branch problem en-
countered in the former case. The most successful solution to separating the
instruction and data activity is to window filter the program memory area, the
disadvantage being that this requires some prior knowledge of the program being
run. This data operation is called by the SAS command DO.

(iv) Event correlation. A requirement to correlate sections of code with certain events
is evident when programs are being maintained or adapted, in particular when
accompanying documentation is either not available or inadequate. In such
circumstances, the correlation wand of SAS may be used. Essentially, the wand is
an electrical probe which may be placed in contact with the conductor trans-
mitting a signal, related to a section of software. The occurrence of this signal is
then used to cause the structure spy to store the address it is currently monitoring.
218 Y. Callagban and Ie. Barltu
Such values may then be either printed out or. marked on the structure map.
Event correlation on SAS is executed by using the WO and WZ commands.
(v) Structure comparison. SAS has two structure tables the contents of which may be
compared, the results providing a list of branch vectors and events which arc
either equal or not equal.
AND operator. The AND operator, AO, compares the contents of a reference
structure table to an operation structure table. Vectors which arc in the operation
table and not the reference table are set to zero.
EXOR operator. This algorithm, EO, compares the contents of two structure
tables, a reference and operation table. Vectors which appear in both tables arc
nulled in the operation table.

3. SAS application

3.1 M easurement considerations

The application of SAS is affected by the type of hardware and software technology in-
corporated into the computer system it is intended to measure. The main application
considerations quantitizcd from the SAS perspective are therefore discussed.

3.1.1 Hardware. The program counter on modem digital computing machines consists
of either a set of discrete logic integrated circuits or is integrated into a VLSI device
(Osbourne & Kane, 1978; ERA, 1979a, b; Healey, 1979). Discrete program counter
chip sets are now mainly found in mini and mainframe computers where speed is a
primary concern, whilst VLSI circuits dominate the microcomputer, embedded computer
and instrumentation areas. Probes may be readily attached to discrete program counter
integrated circuits, whilst YLSI devices present problems due to inaccessibility of their
program counters. VLS1 circuits may be considered as belonging to one of two groups.
The first and largest group, microprocessors, are CPUs which usually do not contain any
integral memory elements with the exception of registers. The second group-micro-
computers and controllers-are CPUs with integral memory and sometimes I/O chan-
nels such as A/D conversion devices. As microprocessors require external memory
clements, their memory address lines are always available for probing. In contrast,
microprocessor circuits contain integral memory and rarely have their associated memory
address lines externally available and are therefore unsuitable for monitoring by SAS.
The majority of microprocessors provide qualificatory signals to indicate instruction
cycle fetches (see Table I) and where these are provided they are used to gate the memory
bus data to provide an effective program counter. As described earlier, where no in-
struction cycle qualificatory signals are provided window operations may be used to
isolate the relevant data.

3.1.2 Software. Program. may be written in a number of different languages the

characteristics of which occupy a spectrum from those low level languages which reflect
the computing machine's architecture to high level languages whose affinity is to the
problem (McIotine, 1978; Calingaert, 1979). The program environment may vary from a
simple single program situation common to many microprocessor and embedded systems
 SAS-a software ualys1s system 219

Table 1

M icroprocessor M anufacturer No. of No. of Instruction cycle

bilS pins qualifying pins
No. Name

8080A Intel 8 40 18,19,20,21 STO-ST3

808SA Inlel 8 40 From data bus during 1'2
Z80A Zilog 8 40 29,33 SO, SI
MC6800 M otorola 8 40
MCS6502 MOS Tech. 8 40 7 SYNC
2650A Signetics 8 40
CDPI8020 RCA 8 40 6, S seo, SCI
SCjMP Nat. Semi 8 40 From data bus at beginning of
input cycle
TMS9980 Texas lnst. 8 40 3 AQ
IM6100 Intersil 12 40 36 IFETCH
INS8900 Nat. Semi. 16 40
CPI600 Oen.lnst. 16 40
TMS9900 Texas InsL 16 64 7 lAQ
TMS999S Texas Inst. 16 40 16,20 lAQ,MEMEN
8086 Intel 16 40 26,27, 28 SQ-S2
ZS002 Zilog 16 40 21,20, 19, 18 STQ.ST3
ZOOOI Zilog 16 48 23, 22, 21, 20 STO-STJ
9440 Fairchild 16 40 6,8 00,01
FI()()'L Ferranti 16 40 4 IR2

to complex multi programmed, timeshared and paged systems found in large data pro-
cessing systems (Anderson, 1981). The present configuration of SAS is designed to
monitor the execution of single program systems machine coded from either a compiler,
assembler or by hand, common to instrumentation, embedded and engineering ap-
plications.

3.1.3 Speed. A feature of the structure extraction technique is that tbe sequence of
nodal branch data acquisition is irrelevant as structural data is independent of execution
sequence. Thus, if the monitored program forms a closed loop, as is the case with most
embedded or realtime control systems, the instruction address register can be statistically
sampled rather than traced in real time without incurring loss of structural data. This
means that the monitoring system can be of slower speed thau the monitored system.

3.2 An example application: Location of the hexadecimal word output routine XOP 10
associated with the Texas Instruments TM 990{IOI.I and TM 990140I-3 microcomputer and
m o n ito r
Using SAS there are two principal methods which may be used to determine the memory
position of XOP 10. For clarity any interaction with XOP 12 is ignored.
(i) The first method entails writing two trivial programs, one which includes XOP 10,
the second which is identical except that it does not contain XOP 10. These pro-
grams are shown in Figure 8(a, b). Note that NOP, no operation, is used to replace
XOP 10.
The procedure then is:
 SAS-a software analysis system 221

FEOO 0300 UMI >0000 Inten;upt

FE02 0000
FE04 01£0 LWPI >FESO Workspace
FE06 FE80
FEC8 020C U RI2,>OO8O CRU. main serial port
FEOA 0080
FEOC 0201 U RI,>oooo Output data
FEOE 0000
FEIO 1000 NOP Dummy instruction
FEI2 IFU TB 21 Hal key been pressed ?
FEI4 16FD SNE >FEIO No. continue
FEI6 0460 B @>0080 Yes, GOTO monitor
FEl8 0080

FIpre 7(b). Test program without XOP.

Source Destination S o u rc e Destination

FEl4 FElO FEI4 FEIO
036A FEl2 FEl4 FEIO
FEI4 FEIO FEt4 FEIO
0358 035E FEI4 FEtO
FEIO 0348 FEl4 FEIO
0368 034E FEl4 FEIO
0358 035E FEt4 FEIO
0368 034E FEt4 FEtO
036A FEI2 FEl4 FEIO
0368 034E FEI4 FEIO

f1aw'e 7(e). Structure table 1 after acquisition Ffcure '(d). Structure table 2 after acquisition
o f v e c to n fro m p ro g ra m (a ), of vectors from program (b).

Source Destination Source Destination Frequency

0000 0000 0358 035E 0002
036A FEI2 0368 034E 0003
0000 0000 036A FEl2 0002
0358 035E FEIO 0348 0001
FEtO 0348
0368 034E FIpre 7(0, SortinS the vectors makes it easier
0358 035E to identify the lowest and hishest XOP routine
0368 034E values 0348, 036A which represent the entry and
036A FEl2 exit points.
0368 034E

FIgure 7(e). Vceton p r e s e n t in both structure

tables arc elim inated from structures table 1
1eavina only vecto~ associated with the XOP.
222 V. Can_Shan _00 K. Barker

Source Destination Source Destination

0368 034E 0000 0000

0368 034E 0000 0000
FEIO 0348 FEIO 0348
0358 035E 0000 0000
FEl4 FElO 0000 0000
036A FEl2 OJ6A FE12
0368 034E 0000 0000
0358 035E 0000 0000
FE!4 FEIO 0000 0000
036A FEl2 036A FEI2

fIIIn 7c.>. Slt\IClURtable 1 after acquisition Flaan 7(h). SltUc:lUn:table I aCterapplication

oCMO-JO.
oCvector>Cromprogam (a).

36A

Sowal Dertiaauon Frequency

035A FEI2 0002
FE10 0348 0001

FIpre 7(1). The contents or sltUc:lUn:table I FIpre 7(J) The dynamic SttuelUR map or pro-
soned and listed usin8 commands SV and LV. Jt210 (a) as p•.•••nted nn the system display.

4. C o n c lu s io n
Program maintenance dominates the cost associated with the software life cycle. Re-
search in this area and that of program execution monitoring is sparce. Escalating soft-
ware costs make the research for new tools to increase software productivity increasingly
urgent. The majority of existing hardware tools place an emphasis on program de-
bugging and often either are very specialized or require the programmer to possess
detailed knowledge of the machine to apply or interpret the results. In contrast, SAS is
concerned with monitoring, analysing and presenting fundamental program properties
which address program design and maintenance rather than debugging. It achieves this
criterion by using a universal hardware technique to extract the dynamic structure of the
software. A method based on directed graphs is used to provide a display particularly
suitable for small instrument screens. It is proposed that such techniques could either be
integrated into a new generation of logic analysers or as part of a universal test tool for
computer programmers.

R e fe re n c e s
Allison, A. 1980. Follow three simple rules to improve software productivity. EDN, March,
167-171.
Anderson, D. A. 1981. Operating systems. IEEE Comput." June, 69-82.
Antoine, J. M., Decaestel«, P. & Wailstein, R. 1979. Effective software debugging using a
program tracer. Eitctrical Communication, 54(2), 111-114.
Armbruster, C. E., Duke, A. H. & Dunbar, R. G. 1978. Hardware Sampler Cor system measure-
ment. IBM Technical Disclosure Bul/etin, 21(4), September, 1427-1429.
 SAS-a software analysis system 223

Boehm, B. W. 1976. Software engineering. IEEE Transactions on Computers, December, 1227-

1241.
Calingaert, P. 1979. Ass~mblt'.r, C o m p iltr s and P rogram T r a n s la tio n . London: Pitm an.
Electrical Research Association 19790. M ic r o p r o c e s s o r s : 11ft;r D e v e lo p m e n t and A p p lic a tio n .

ERA Technology.
Electrical Research Associalion (b) 1979b. The Engineering of M icroproc..,sor Systems. OxCord:
Pergamon Press.
Fryer. R. E. 1973. The m em ory bus m onitor. A F JPS C o n fe re n c e P r o c e e d in g s . N a tio n a l C o m p u te r
COII[trtnu. 42, 75-79
G ries. D. 1980. Current ideas in program m ing m ethodology. In R e s e a r c h D i r e c t i o n s in S o / r w a u
Technology, (P. Wegner, ed.), pp. 255-275. Amsterdam: North Holland.
H ealey. M. 1979. M i n i c o m p u t e r s a n d M i c r o c o m p u t e r s . London: H odder and Stoughton.
Jensen, R. W. 1981. Slructured programminll. IEEE Computtr, March, 31-48.
Krummel, L. 1977. Advances in microcompuler development systems. IEEE Computer, Feb-
ruary, 13-19.
Lemon, L. M. 1979. Hardware system for developinll and validatinll soClware. Proceedings of
13th Asilomer Conftrence on Circuits, Systems and Computers, Pacific Grove CaliCornia USA,
5-7 November, pp. 455-459.
Lloyd, R., Ovies, H., Rosado, 1. L. '" Wilson, D. 1. 1980. Proarammable map and trace in-
strument. IBM Technlazl Dise/osure Bulletin, Z3(5), 2075-2078.
Marshall, 1. S. 1978. Logic analy •••.• provide an essential real-time view of digital system ac-
tivity. Proceedings of M IDCON TechnlazI Conference, Dallas, USA, 12-14 December, pp.
31-34.
McCabe, T. 1. 1976. A complexily measure. IEEE Transactionr on Software engineering,
5£..1(4),30S-320.
McCabe, T.1. 1978. Software complexity measurement. Proceedings of 2nd Software Life Cye/e
M anagement W orlishop, Allanta, USA, 21-22 Aul\Us!, pp. 186-190.
Mc1ntine, T. C. 1978. Software Interpreters for M icrocomputers. New York: lohn Wiley.
Mills, H. D. 1980. Sonware developmenl. In Res-arch Dlroctlonr In Software TechnolollY (ed.
P. Wegner), pp. 87-105. Amsterdam: Nonh Holland.
M unson, J. B. 1981. Software m aintenability. practical concern (or life cycle costs. I E E E
C o m p u t e r , Novem ber, 103-109.
Nutt. G . J. 1975. Tutorial, com puter system m oniton. I E E E C o m p u te r , Novem ber, 51-61.
Osbourne, A. & : Kane, 1. 1978. An Introduction to M icrocomputers Vol. 2, Some Real M icro-
prou ssors. California: O sbourne and Associates Inc.
Plattner, B. & : Nitvergelt, 1. 1981. Moniloring program execution-a survey. IEEE Computer,
November, 76-93.
Schindler, M. 1981. Software, ttchnology forecost. Electronic Design, January, 1ro-l99.
Stockham, T. G. 1965. Some methods of graphical debugging. Proceedings of IBM Scientific
C o m p u t i n g S y m p o s i u m o n M a n M a c h i n e C o m m u n i c a t i o n . p p . 57-71.
Thornton, C. 1980. H ow to get the best perform ance from your system . D a ta P r o c e s s in g ,

January, 29-32.
Williams, G. 1981. Structured programming and structured flowcharts. BYTE, March, 20-34 .
. ---_._-