T

CST305 System Software Module 5

MODULE 5

SYLLABUS
Macro Preprocessor:
Macro Instruction Definition and Expansion, One pass Macro processor Algorithm and data
structures, Machine Independent Macro Processor Features, Macro processor design options
Device drivers:
Anatomy of a device driver, Character and block device drivers, General design of devicedrivers
Text Editors:
Overview of Editing, User Interface, Editor Structure
Debuggers:
Debugging Functions and Capabilities, Relationship with other parts of the system,Debugging
Methods- By Induction, Deduction and Backtracking.

5.1 MACRO PREPROCESSOR

Macro
• A macro (or macro instruction)
– It is simply a notational convenience for the programmer.
– It allows the programmer to write shorthand version of a program
– It represents a commonly used group of statements in the source program.
• For example:
• Suppose a program needs to add two numbers frequently. This requires a sequence
of instructions. We can define and use a macro called SUM, to represent this
sequence of instructions.

SUM MACRO &X,&Y

LDA &X
MOV B
LDA &Y
ADD B
MEND
T
CST305 System Software Module 5

Macro Preprocessor
• The macro pre-processor(or macro processor) is a system software which replaces each
macro instruction with the corresponding group of source language statements. This
operation is called expanding the macro.
• It does not concern the meaning of the involved statements during macro expansion.
• The design of a macro processor generally is machine independent.

5.2 BASIC MACRO PROCESSOR FUNCTIONS

The fundamental functions common to all macro processors are: ( Code to remember - DIE )
o Macro Definition
o Macro Invocation
o Macro Expansion

Macro Definition
• Macro definitions are typically located at the start of a program.
• A macro definition is enclosed between a macro header statement(MACRO) and a
macro end statement(MEND)
• Format of macro definition
macroname MACRO parameters
:
body
:
MEND

• A macro definition consist of macro prototype statement and body of macro.

• A macro prototype statement declares the name of a macro and its parameters. It has
following format:
macroname MACRO parameters
T
CST305 System Software Module 5

where macroname indicates the name of macro, MACRO indicates the beginning of
macro definition and parameters indicates the list of formal parameters. parameters is
of the form &parameter1, &parameter2,…Each parameter begins with ‘&’. Whenever
we use the term macro prototype it simply means the macro name along with its
parameters.

• Body of macro consist of statements that will generated as the expansion of macro.
• Consider the following macro definition:
SUM MACRO &X,&Y
LDA &X
MOV B
LDA &Y
ADD B
MEND
Here, the macro named SUM is used to find the sum of two variables passed to it.

Macro Invocation(or Macro Call)

• A macro invocation statement (a macro call) gives the name of the macro instruction
being invoked and the arguments to be used in expanding the macro.
• The format of macro invocation
macroname p1, p2,...pn
• The above defined macro can be called as SUM P,Q

Macro Expansion
• Each macro invocation statement will be expanded into the statements that form the
body of the macro.
• Arguments from the macro invocation are substituted for the parameters in the macro
prototype.
• The arguments and parameters are associated with one another according to their
positions. The first argument in the macro invocation corresponds to the first parameter
in the macro prototype, etc.
• Comment lines within the macro body have been deleted, but comments on individual
statements have been retained. Macro invocation statement itself has been included as
a comment line.
• Consider the example for macro expansion on next page:
T
CST305 System Software Module 5

In this example, the macro named SUM is defined at the start of the program. This
macro is invoked with the macro call SUM P,Q and the macro is expanded as
LDA &P
MOV B
LDA &Q
ADD B
MEND
Again the same macro is invoked with the macro call SUM M,N and the macro is expanded
as

LDA &M
MOV B
LDA &N
ADD B
MEND
Figure: Example for macro expansion

Difference between Macro and Subroutine

Macros differ from subroutines in two fundamental aspects:
1. A macro call leads to its expansion, whereas subroutine call leads to its execution. So
there is difference in size and execution efficiency.
2. Statements of the macro body are expanded each time the macro is invoked. But the
T
CST305 System Software Module 5

statements of the subroutine appear only once, regardless of how many times the
subroutine is called.

5.3 MACRO PROCESSOR ALGORITHM AND DATA STRUCTURES

Two pass macro processor

• It is easy to design a two-pass macro processor in which all macro definitions are
processed during the first pass and all macro invocation statements are expanded during
second pass.
• Such a two pass macro processor cannot handle nested macro definitions. Nested
macros are macros in which definition of one macro contains definition of other
macros.
• Consider the macro definition example given below, which is used to swap two
numbers. The macro named SWAP defines another macro named STORE inside it.
These type of macro are called nested macros.

SWAP MACRO &X,&Y

LDA &X
LDX &Y
STORE MACRO &X,&Y
STA &Y outer macro
Inner macro
STX &X
MEND
MEND
T
CST305 System Software Module 5

One pass macro processor

• A one-pass macro processor uses only one pass for processing macro definitions and
macro expansions.
• It can handle nested macro definitions.
• To implement one pass macro processor, the definition of a macro must appear in the
source program before any statements that invoke that macro.
Data Structures involved in the design of one pass macro processor
• There are 3 main data structures involved in the design of one pass macro processor:
DEFTAB
NAMTAB
ARGTAB

Definition table (DEFTAB)

• All the macro definitions in the program are stored in DEFTAB, which includes
macro prototype and macro body statements.
• Comment lines from macro definition are not entered into DEFTAB because they will
not be a part of macro expansion.
• References to the macro instruction parameters are converted to a positional notation
for efficiency in substituting arguments.

Name table (NAMTAB)

• The macro names are entered into NAMTAB
• NAMTAB contains pointers to beginning and end of definition in DEFTAB.

Argument table (ARGTAB)

• The third data structure is an argument table (ARGTAB), which is used during
expansion of macro invocations.
• When macro invocation statements are recognized, the arguments are stored in
ARGTAB according to their position in argument list.
• As the macro is expanded, arguments from ARGTAB are substituted for the
corresponding parameters in the macro body.
• Example: Consider the following source code
SUM MACRO &X,&Y
LDA &X
T
CST305 System Software Module 5

MOV B
LDA &Y
ADD B
MEND
START
LDA 4500
ADD B
SUM P,Q
LDA 3000
………….
END

• When the macro definition for SUM is encountered, the macro name SUM along with
its parameters X and Y are entered into DEFTAB. Then the statements in the body of
macro is also entered into DEFTAB. The positional notation is used for the parameters.
The parameter &X has been converted to ?1, &Y has been converted to
?2.
• The macro name SUM is entered into NAMTAB and the beginning and end pointers
are also marked.
• On processing the input code, opcode in each statement is compared with the
NAMTAB, to check whether it is a macro call. When the macro call SUM P,Q is
recognized, the arguments P and Q will entered into ARGTAB. The macro is expanded
by taking the statements from DEFTAB using the beginning and end pointers of
NAMTAB.
• When the ?n notation is recognized in a line from DEFTAB, the corresponding
argument is taken from ARGTAB.

Figure shows the different data structures used

T
CST305 System Software Module 5

Algorithm for one pass macro processor

T
CST305 System Software Module 5
T
CST305 System Software Module 5

Explanation of algorithm
• The algorithm uses 5 procedures
o MACROPROCESSOR (main function)
o DEFINE
o EXPAND
o PROCESSLINE
o GETLINE

MACROPROCESSOR (MAIN function)

• This function initialize the variable named EXPANDING to false.
• It then calls GETLINE procedure to get next line from the source program and
PROCESSLINE procedure to process that line.
• This process will continue until the END of program.
T
CST305 System Software Module 5

PROCESSLINE
• This procedure checks
o If the opcode of current statement is present in NAMTAB. If so it is a macro
invocation statement and calls the procedure EXPAND
o Else if opcode =MACRO, then it indicates the beginning of a macro definition
and calls the procedure DEFINE
o Else it is identified as a normal statement(not a macro definition or macro
call) and write it to the output file.
DEFINE
• The control will reach in this procedure if and only if it is identified as a macro
definition statement.Then:
o Macro name is entered into NAMTAB
o Then the macro name along with its parameters are entered into DEFTAB.
o The statements in body of macro is also enterd into DEFTAB. References to
the macro instruction parameters are converted to a positional notation for
efficiency in substituting arguments.
o Comment lines from macro definition are not entered into DEFTAB because
they will not be a part of macro expansion.
o Store in NAMTAB the pointers to beginning and end of definition in DEFTAB.

• To deal with Nested macro definitions DEFINE procedure maintains a counter named
LEVEL.
o When the assembler directive MACRO is read, the value of LEVEL is
incremented by 1
o When MEND directive is read, the value of LEVEL is decremented by 1
o That is, whenever a new macro definition is encountered within the current
definition, the value of LEVEL will be incremented and the while loop which
is used to process the macro definition will terminate only after the value of
LEVEL =0. With this we can ensure the nested macro definitions are properly
handled.
EXPAND
• The control will reach in this procedure if and only if it is identified as a macro call.
T
CST305 System Software Module 5

• In this procedure, the variable EXPANDING is set to true. It actually indicates the
GETLINE procedure that it is going to expand the macro call. So that GETLINE
procedure will read the next line from DEFTAB instead of reading from input file.
• The arguments of macro call are entered into ARGTAB.
• The macro call is expanded with the lines from the DEFTAB. When the ?n notation is
recognized in a line from DEFTAB, the corresponding argument is taken from
ARGTAB.

GETLINE
• This procedure is used to get the next line.
• If EXPANDING = TRUE, the next line is fetched from DEFTAB. (It means we are
expanding the macro call)
• If EXPANDING = False, the next line is read from input file.

Flow Diagram of a one pass macroprocessor

T
CST305 System Software Module 5

5.4 MACHINE INDEPENDENT MACRO PROCESSOR FEATURES

• The features of macro which doesn’t depends on the architecture of machine is called
machine independent macro processor features.
• The features includes:
1. Concatenation of Macro Parameters
2. Generation of Unique Labels
3. Conditional Macro Expansion
4. Keyword Macro Parameters

1. Concatenation of Macro Parameters

• Most macro processor allows parameters to be concatenated with other character
strings.
• Suppose that a program contains a series of variables named by the symbols XA1, XA2,
XA3,..., and another series of variables named XB1, XB2, XB3,..., etc.
• If similar processing is to be performed on each series of labels, the programmer might
put this as a macro instruction.
• The parameter to such a macro instruction could specify the series of variables to be
operated on (A, B, etc.). The macro processor would use this parameter to construct the
symbols required in the macro expansion (XA1, XB1, etc.).

• For example, suppose that the parameter to such a macro instruction is named &ID.
The body of the macro definition contain a statement like LDA X&ID1, which means
&ID is concatenated after the string “X” and before the string “1”
TOTAL MACRO &ID
LDA X&ID1
ADD X&ID2
STA X&ID3
MEND

The macro call TOTAL A will be expanded as:

LDA XA1
ADD XA2
STA XA3
T
CST305 System Software Module 5

• Ambiguity Problem: In the statement LDA X&ID1, & is the starting character of
the macro parameter; but the end of the parameter is not marked.
• So X&ID1 may mean
X + &ID + 1 or X +&ID1

• Most of the macro processors deal with this problem by providing a special
concatenation operator to specify the end of parameter.
• Thus LDA X&ID1 can be rewritten as . So that end of the parameter
&ID is clearly defined.
• Example:

• The example given above shows a macro definition that uses the concatenationoperator
as previously described. The statement TOTAL A and TOTAL BETA shows the
invocation statements and the corresponding macro expansion.
• The macroprocessor deletes all occurrences of the concatenation operator immediately
after performing parameter substitution, so the symbol will not
appear in the macro expansion.

2. Generation of unique labels

• It is not possible to use labels for the instructions in the macro definition, since every
expansion of macro would include the label repeatedly.
• This results in duplicate labels problem if macro is invoked and expanded multiple
times.(which is not allowed by the assembler)
T
CST305 System Software Module 5

• To avoid this we can use the technique of generating unique labels for every macro
invocation and expansion.
• During macro expansion each $ will be replaced with $XX, where XX is a two
character alphanumeric counter of the number of macro instructions expansion.
• For the first macro expansion in a program, XX will have the value AA. For succeeding
macro expansions XX will be set to AB,AC etc. This allows 1296 macro expansions in
a single program
• Consider the following program:
SAMPLE START 0
COPY MACRO &A,&B
LDA &A
.........
$LOOP ADD &B
..........
JLE $LOOP
STA &B
MEND
.............
COPY X,Y
LDA M
COPY P,Q
...........
END

After the macro expansion above code becomes:

SAMPLE START 0
.............
LDA &X
.........
$AALOOP ADD &Y Expansion of COPY X,Y
..........
JLE $AALOOP
STA &Y
T
CST305 System Software Module 5

LDA M
LDA &P
.........
$ABLOOP ADD &P
.......... Expansion of COPY P,Q
JLE $ABLOOP
STA &Q
...........
END

In the example, for the first invocation of COPY X,Y the label generated is $AALOOP and for
the second invocation COPY P,Q the label generated is $ABLOOP. Thus for eachinvocation
of macro unique label is generated.

3. Conditional Macro Expansion

• Arguments in macro invocation can be used to:
o Substitute the parameters in the macro body without changing the sequence of
statements expanded.(sequential macro expansion)
o Modify the sequence of statements for conditional macro expansion. This
capability increases power and flexibility of a macro language.
• Macro-Time Variables:
o Macro-time variables (often called as SET Symbol) can be used to store
working values during the macro expansion.
o It can also be used to store the evaluation result of Boolean expression
o Any symbol that begins with & and not a macro instruction parameter is
considered as macro-time variable. All such variables are initialized to zero.
o The value of macro-time variables can be modified by using the macro
processor directive SET
o The macro processor must maintain a symbol table to store the value of all
macro-time variables used. The table is used to look up the current value of
the macro-time variable whenever it is required.

Implementation of Macro-Time Conditional Structure IF-ELSE-ENDIF

• Structure of IF-ELSE_ENDIF:
T
CST305 System Software Module 5

Macroname MACRO &COND

........
IF (&COND NE ’’)
.part I
ELSE
.part II
ENDIF
.........
MEND
• When an IF statement is encountered during the expansion of a macro, the specified
Boolean expression is evaluated.
• If the value of this expression TRUE,
o The macro processor continues to process lines from the DEFTAB until it
encounters the ELSE or ENDIF statement.
o If an ELSE is found, macro processor skips lines in DEFTAB until the next
ENDIF.
o Once it reaches ENDIF, it resumes expanding the macro in the usual way.
• If the value of the expression is FALSE,
o The macro processor skips ahead in DEFTAB until it encounters next ELSE
or ENDIF statement.
o The macro processor then resumes normal macro expansion.

• Example for conditional macro:

COPY START 0
EVAL MACRO &X,&Y,&Z
IF (&Y LE &X)
LDA &X
SUB &Z
ELSE
LDA &Y
ADD &Z
ENDIF
MEND
STA P
....................
T
CST305 System Software Module 5

EVAL 2 ,3 ,4
STA Q
...............
END
After expansion the above code becomes:
COPY START 0
STA P
...................
LDA 3
ADD 4
STA Q
.........................
END

Implementation of Macro-time looping(or Expansion time looping) structure: WHILE-ENDW

• WHILE statement specifies that the following lines until the next ENDW statement,
are to be generated repeatedly as long as a particular condition is true. The testing of
this condition, and the looping are done during the macro under expansion.
• When a WHILE statement is encountered during the expansion of a macro, the
specified Boolean expression is evaluated.
• If expression is TRUE, the macro processor continues to process lines from DEFTAB
until it encounters the next ENDW statement.When ENDW is encountered, the macro
processor returns to the preceding WHILE, re-evaluates the Boolean expression, and
takes action based on the new value.
• If the expression is FALSE, the macro processor skips ahead in DEFTAB until it
finds the next ENDW statement and then resumes normal macro expansion.
• The example given below shows the usage of Macro-Time Loopingstatement.
In this example, the variable &LIMIT is a macro time variable.
T
CST305 System Software Module 5

Above loop after expansion

4. Keyword Macro Parameters

• The parameters used in macro can be of two types
a)Positional Parameters
b)Keyword Parameters

a) Positional Parameters
• Parameters and arguments are associated according to their positions in the macro
prototype and invocation. The programmer must specify the arguments in proper
order.
• Syntax : In macro definition,
macroname MACRO &parameter1, &parameter2,……
In macro invocation,
macroname argument1, argument2,….
Example: In macro definition,
EVAL MACRO &X, &Y
In macro invocation,
EVAL P,Q
Here &X recieves the value of P and &Y recieves the value of Q
• If an argument is to be omitted, a null argument should be used to maintain the
proper order in macro invocation statement.
• For example: Suppose a macro named EVAL has 5 possible parameters, but in a
particular invocation of the macro only the 1st and 4th parameters are to be specified.
Then the macro call will be EVAL P,,,S,
T
CST305 System Software Module 5

• Positional parameter is not suitable if a macro has a large number of parameters,

and only a few of these are given values in a typical invocation.
b) Keyword Parameters
• Each argument value is written with a keyword that names the corresponding
parameter.
• Arguments may appear in any order. That is not any importance to the position of
arguments.
• Null arguments no longer need to be used.
• For macros using keyword parameters the macro prototype statement specification
is different. Here each parameter name is followed by equal sign, which identifies a
keyword parameter and a default value is specified for some of the parameters.
• Keyword parameters are easier to read and much less error-prone than the positional
parameters.
• It is of the form
&formal parameter name = <ordinary string>
• Consider the example:
INCR MACRO &X=, &Y=, &Z=
MOV &Z, &X
ADD &Z, &Y
MOV &Z, &X
MEND
The following calls are now equivalent
1) INCR X=A, Y=B, Z=C
2) INCR Y=B, X= A, Z= C

Default specification of parameters

• Default specification of parameters can also be possible in macros.
• This specification is useful in situations where a parameter has the same value in most
calls.
• When the desired value is different from the default value, the desired value can be
specified explicitly in a macro call.
T
CST305 System Software Module 5

• This specification overrides the default value of the parameter for the duration of that
macro call.
• Consider the example:
Here the default value R is
specified for the parameter Z
INCR MACRO &X=, &Y=, &Z=R
MOV &Z, &X
ADD &Z, &Y
MOV &Z, &X
MEND

• Then the macro call INCR X=A, Y=B will take the values A for parameter X, B for
parameter Y and R for the parameter Z.
• The macro call INCR X=A, Y=B, Z=C will take the values A for parameter X, B for
parameter Y and C for the parameter Z.

5.5 MACRO PROCESSOR DESIGN OPTIONS

5.5.1 Two Pass Macro Processor

• Same as on page 4
• It is easy to design a two-pass macro processor in which all macro definitions are
processed during the first pass and all macro invocation statements are expanded during
second pass.
• Such a two pass macro processor cannot handle nested macro definitions.
• Nested macros are macros in which definition of one macro contains definition of
other macros.
• Consider the macro definition example given below, which is used to swap two
numbers.
• The macro named SWAP defines another macro named STORE inside it. These type
of macro are called nested macros.
T
CST305 System Software Module 5

SWAP MACRO &X,&Y

LDA &X
LDX &Y
STORE MACRO &X,&Y
STA &Y outer macro
Inner macro
STX &X
MEND
MEND

5.5.2 One Pass Macro Processor

• Same as on page 4 (here only brief description is needed)
• A one-pass macro processor uses only one pass for processing macro definitions and
macro expansions.
• It can handle nested macro definitions.
• To implement one pass macro processor, the definition of a macro must appear in the
source program before any statements that invoke that macro.
• Data Structures involved in the design of one pass macro processor
DEFTAB
NAMTAB
ARGTAB
• Whenever a macro definition is encountered, the macro prototype and body of macro
is entered into DEFTAB. References to the macro instruction parameters are converted
to a positional notation for efficiency in substituting arguments.
• The macro name along with the begin and end pointers are entered into NAMTAB.
• Whenever a macro invocation is encountered, the arguments are entered into
ARGTAB.
• The macro call is expanded with the lines from the DEFTAB. When the ?n notation is
recognized in a line from DEFTAB, the corresponding argument is taken from
ARGTAB.

5.5.3 Recursive Macro Expansion

• Invocation of one macro by another macro is called recursive macro.
• Example for recursive macro:
T
CST305 System Software Module 5

SUM MACRO &X,&Y

STA &X
ADD &Y
MEND

INPUT MACRO &A,&B

SUM &A,&B .i n v o k i n g the macro SUM
MEND

Here the macro named INPUT is calling another macro named SUM. This is called as
recursive macro.
• The macro processor design algorithm discussed previously cannot handle recursive
macro invocation and expansion.
• Reasons are:
o The procedure EXPAND would be called recursively, thus the invocation arguments
in the ARGTAB will be overwritten.
o The Boolean variable EXPANDING would be set to FALSE when the “inner”
macro expansion is finished, that is, the macro process would forget that it had been
in the middle of expanding an “outer” macro.
o A similar problem would occur with PROCESSLINE since this procedure too would
be called recursively.
• Solutions:
o Write the macro processor in a programming language that allows recursive calls, thus
local variables will be retained.
o If we are writing in a language without recursion support, use a stack to take care of
pushing and popping local variables and return addresses. So the recursive calls can
be handled.

5.5.4 General-Purpose Macro Processors

• The macro processor we discussed so far is related to assembly language programming.
Macro processor for high level languages have also been developed. Macro processors
which are designed for a specific language are called special purpose macro processors.
Example for special purpose macro processor is MASM Macro processor
• These special purpose macro processors are similar in general function and approach but
the implementation details differ from language to language.
T
CST305 System Software Module 5

• The general purpose macro processor do not dependent on any particular programming
language, but can be used with a variety of different languages.
• Example for a general purpose macro processor is ELENA Macro processor

Advantages
• Programmers do not need to learn many macro languages, so much of the time and
expense involved in training are eliminated.
• Although its development costs are somewhat greater than those for a specific language
macro processor, this expense does not need to be repeated for each language, thus save
substantial overall cost.

Disadvantages
In spite of the advantages noted, there are still relatively few general purpose macro
processors. The reasons are:
• Large number of details must be dealt with in a real programming language.
• There are several situations in which normal macro parameter substitution or normal
macro expansion should not occur.
o For example, comments are usually ignored by the macro processor. But each
programming languages uses its own method for specifying comments. So a
general purpose macro processor should be designed with the capability for
identifying the comments in any programming languages.
• Another problem is with the facilities for grouping together terms, expressions, or
statements.
o Some languages use keywords such as begin and end for grouping statements
while some other languages uses special characters like { }. A general purpose
macro processor may need to take these groupings into account in scanning the
source statements.
• Another problem is with the identification of tokens of the programming languages. The
tokens means the identifiers, constants, operators and keywords in the programming
language. Different languages uses different rules for the formation of tokens. So the
design of a general purpose macro processor must take this into consideration.
• Another problem is with the syntax used for macro definitions and macro invocation
statements.
T
CST305 System Software Module 5

5.5.5 Macro Processing within Language Translators

• Macros can be processed
1. Outside the language translators
2. Within the Language translators

1. Macro processing outside the language translators

• The macro processors that we had discussed so far belongs to this group. They are
called macro preprocessors.
• They reads the source program statements, process the macro definitions and expand
macro invocations, producing an expanded version of the source program.
• This expanded program is then used as input to an assembler or compiler.
• So this can be considered as macro processing outside the language translators.

2. Macro processing within the language translators

• In this section we discuss the methods for combining the macro processing functions
with the language translator itself.
• Two common methods are
a) Line –by- Line Macro Processors
b) Integrated Macro Processors
a) Line-by-line macro processor
• The simplest method for combining the macro processing functions with the language
translator is a line-by-line approach.
• Using this approach, the macro processor reads the source program statement, process
the macro definitions and expand macro invocations. But it does not produce an
expanded version of source program.
• The processed lines are passed to the language translator(compiler or assembler) as
they are generated, instead of being written to an expanded source file.
• Thus macro processor operates as a sort of input routine for the assembler or compiler.
Benefits of line –by-line macro processor
• It avoids making an extra pass over the source program. So it can be more efficient
than using a macro preprocessor.
T
CST305 System Software Module 5

• Some of the data structures required by the macro processor and the language translator
can be combined (e.g., OPTAB and NAMTAB)
• Many utility subroutines can be used by both macro processor and the language
translator. This involves scanning input lines, searching tables , converting numeric
values to internal representation etc.
• It is easier to give diagnostic messages related to the source statements.

b) Integrated Macro Processors

• Although a line-by-line macro processor may use some of the same utility routines as
language translator, the functions of macro processing and program translation are still
relatively independent.
• It is possible to have even closer cooperation between the macro processor and the
language translator. Such a scheme is called as language translator with an integrated
macro processor.
• An integrated macro processor can potentially make use of any information about
the source program that is extracted by the language translator.
• The macro processor may use the results of the translator operations such as scanning
of symbols, constants, etc without involved in processing it.
• For example in FORTRAN language, consider the statement:
DO 100 I = 1,20
where DO is a keyword, 100 is statement number, I is a variable name etc.
DO 100 I = 1
since in FORTRAN blanks are not significant, this statement is an assignment
that gives the value 1 to the variable DO100I. Thus the proper interpretation
of characters cannot be decided until the rest of the statement is examined.

Disadvantages of line-by-line and integrated macro processors

• They must be specially designed and written to work with a particular implementation
of an assembler or compiler. The cost of macro processor development is added to the
costs of the language translator, which results in a more expensive software. The
assembler or compiler will be considerably larger and more complex than using a
macro preprocessor. Size may be a problem if the translator is to run on a computer
with limited memory.
T
CST305 System Software Module 5

5.6 TYPES OF MACRO

Different types of macro are 1. Parameterized Macro 2. Nested Macro 3. Recursive Macro
1. Parameterized Macro
• Macros which uses parameters are called parameterized macro.This type of macro has
the capability to insert the given parameters into its expansion.Macros we studied so
far belongs to this type.
• Example:
SUM MACRO &X,&Y
LDA &X
MOV B
LDA &Y
ADD B
MEND

2. Nested Macros
• Nested macros are macros in which definition of one macro contains definition of other
macros.Consider the macro definition example given below, which is used to swap two
numbers. The macro named SWAP defines another macro named STORE inside it.
These type of macro are called nested macros.

SWAP MACRO &X,&Y

LDA &X
LDX &Y
STORE MACRO &X,&Y
STA &Y outer macro
STX &X Inner macro
MEND
MEND

3. Recursive Macro
• Invocation of one macro by another macro is called recursive macro.Example for
recursive macro:
SUM MACRO &X,&Y
STA &X
ADD &Y
MEND
INPUT MACRO &A,&B
SUM &A,&B .i n v o k i n g the macro SUM MEND
Here the macro named INPUT is calling another macro named SUM. This is called as
recursive macro.
 CST305 System Software Module 5

5.2 DEVICE DRIVERS

5.2.1 ROLE OF DEVICE DRIVER
A device driver is a program that controls a particular type of device that is attached to your
computer. They act as translators converting requests received from the operating system into commands
that specific device can understand. Device drivers communicate directly with devices. A Device Driver
act as a glue between an OS and its I/O devices. There are device drivers for printers, hard disks,
displays, CD-ROM and so on.
Relationship between an application software, OS and device driver is shown in above figure.
The application software makes system calls to the OS requesting services. The OS analyses these
requests and when necessary issues requests to the appropriate device driver. Device drivers in turn
analyses the request from OS and when necessary issues command to the hardware interface to perform
the operations needed to service the request.
 CST305 System Software Module 5

When you buy an operating system, many device drivers are built into the product. However, if
you later buy a new type of device that the operating system didn't anticipate, you'll have to install the
new device driver.
Device drivers simplifies the design of OS. Without the device drivers the operating system
would be responsible for talking directly to the hardware. This would require the OS designer to include
support for all the devices that the users might want to connect to thecomputer. It would also
mean adding support to a new device would require modifying the OS.By separating device driver's
functions from OS, the designer can concentrate on the issues related to the operation of the system as
a whole. Thus device driver designer does not have to worry about the general issues related to I/O
management which is handled by the OS. The device driver writer can connect any I/O device to the
system without having to modify the OS.

5.2.2 DEVICE DRIVER DESIGN ISSUES

The device driver designers must take care of following 3 issues:
◼ OS / Driver Communication
◼ Driver/Hardware Communication
◼ Driver Operations

OS / Driver Communication
• Deals with the issues related to the exchange of information (commands and data)
between DD and OS.
• It also includes the support functions that the kernel provides for the benefit of DD
Driver / Hardware Communication
• Deals with exchange information ie command and data between device driver and the
device it controls.
• Deals with how the software talks to the hardware
• Deals with how the hardware talks to the software
Driver Operations
• It deals with the issues related to the actual internal operations of the driver itself.
• It includes:
o Interpretting commands recieved from OS
o Scheduling multiple requests for service.
o Managing transfer of data
36
 CST305 System Software Module 5

o Accepting and processing hardware interrupts

5.2.3 TYPES OF DEVICE DRIVERS

Based on the differences in the way they communicate with OS the device drivers areclassified
into
1. Block Drivers
2. Character Drivers
3. Stream Drivers
4. Terminal Drivers

1. Block Drivers
Block drivers are used for block devices. For example, hard disk is a block device and hard disk
drives are commonly implemented as block drivers. Block drivers communicate with OS through a
collection of fixed-sized buffers. For example, disk drives are commonly implemented as block devices.
The OS manages a cache of these buffers and attempts to satisfy user requests for data by accessing
buffers in the cache. The driver is invoked only when the requested data is not in the cache or when
buffers in the cache have been changed and must be written out.

Fig: Block Drivers

Advantage of using Buffer Cache:
The buffer cache is used by the kernel to store data that has come from a block device, or
going to a block device, or both (has been read and changed, and will soon be written back). The

36
 CST305 System Software Module 5

buffer cache has following advantage. It allows user processes to perform I/O without regard to the
fundamental block structure of the device and it significantly improves the performance of the system.
All of the management of the buffer cache is handled within the kernel. The device driver merely has to
fill or empty buffers as requested. The rest is handled automatically. Each buffer in the buffer cache is
represented by a buffer header.

2.Character Drivers
Character drivers can handle I/O requests of arbitary size and can be used to support almost any
type of device. Mostly used devices are Printers. Usually character drivers are used for devices that either
deal with data a byte at a time or work best with data in chunks smaller or larger than the fixed sized
buffers used by block drivers (eg tape drives).
Major difference between block and character device driver is that the user processes interact
with block drivers indirectly through the buffer cache but the user process interact with with character
drivers directly. From figure we can see that the I/O request is passed unchanged from the process to the
driver and the driver is responsible for transferring the data directly to and from the user process's
memory.

Fig: Character Drivers

(The only relevant difference between a character device and a regular file is that you can always
move back and forth in the regular file, whereas most char devices are just data channels, which you can
only access sequentially.)

3. Terminal Drivers
Same as character drivers but specialized to deal with communication terminals that connect
users to OS. Terminal drivers are not only responsible for transferring data to and from user terminals
but also for handling line editing, tab expansion and many other terminal functions
36
 CST305 System Software Module 5

that are part of the standard UNIX terminal interface. Because of this additional processing thatterminal
drivers must perform it is useful to consider terminal drivers as a separate type of driver.

Fig: Terminal Drivers

4. Stream Drivers
Stream Drivers are used for network devices.It can handle high speed communication devices
such as networking adapters that deal with unusual sized chunks of data and that need to handle protocol.
It is also known as Network Device Drivers.

Fig: Stream Drivers

Network devices support layered protocol. If character drivers where used for network devices,
it would require that each layer of the protocol be implemented within the single driver. This causes lack
of modularity and re-usability and thus reduces the efficiency of the system. As aresult stream device
drivers where developed which is an extension of character drivers. It send and receive packets. They do
not know about individual connections. They support protocols and streams related to packet
transmission .(Only block drivers and character drivers are mentioned in syllabus)

36
CST305 System Software Module 5

5.2.4 GENERAL DESIGN AND ANATOMY OF DEVICE DRIVERS

• A device driver has three sides:
– one side talks to the rest of the kernel
– one talks to the hardware
– one talks to the user

Kernel Interface of a Device Driver

– In order to talk to the kernel, the driver registers with subsystems to respond to
events.
– Such an event might be the opening of a file, a page fault, the plugging in of a new
USB device, etc.

User Interface of a Device driver

– Since Linux follows the UNIX model, and in UNIX everything is a file, users talk
with device drivers through device files.
– Device files are a mechanism, supplied by the kernel, precisely for this direct User-
Driver interface.
• Most drivers are written as a single source file. It consist of mainly 3 parts:
– Prologue
– Entry points ( functions referenced by OS)

36
 CST305 System Software Module 5

– Private Routines or Internal operation of driver(functions private to the driver)

• The initial part of the driver is sometimes called prologue. The prologue is everything
before first routine.Prologue contains:
– #include directives referencing header files which define various kernel data types
and structures
– #define directives that provide mnemonic names for various constants used in the
driver
– Declaration of variables and data structures
• Entry points
– This section includes functions which are referenced by operating system.
• Private Routines
– This section includes functions which are private to the driver, which are used for
the internal operation of the driver.
(NOTE:
If the question is to explain anatomy of device driver write upto here and then just mention
the device driver design issues(6.2) and explain block and character drivers with their figure)

General Design of a character device driver

• Explain about character device driver with its figure.
• Explain the design issues of device driver. (Read from 6.2)
• The design of character device driver includes three sections:
– Prologue
– Entry points ( functions referenced by OS)
– Private Routines or Internal operation of driver(functions private to the driver)

36
 CST305 System Software Module 5

• Prologue
The initial part of the driver is sometimes called prologue. The prologue is everything
before first routine. Prologue contains:
o #include directives referencing header files which define various kernel data types
and structures
o #define directives that provide mnemonic names for various constants used in the
driver
o Declaration of variables and data structures
#include directives
o Used as Reference to the header files which define various kernel data types and
structures.
o Some header files used by the character device driver are:
#include <sys/types.h> - this header file contains various data types

#include<sys/user.h> - this header file contains the definition of user structure

#include <sys/param.h> - this header file contains definition of various kernel

parameter and macros that are needed by sys/user.h

#include <sys/dir.h> - this header file contains definition of directory structure

#include <sys/signal.h> - this header file contains the definition related to signals

needed by sys/user.h

#include <sys/errno.h> - It contains the definition of various error codes.

All the above header files are found in the directory /usr/include/sys.

#define directives
o This provide mnemonic names for various constants used in the driver
Declaration of variables and data structures
o This section includes the declaration of different variables and data structures used
by the device driver.

• Entry points
How does the Os tell the driver what it wants to do? This is done in two steps:

36
CST305 System Software Module 5

o Firstly, the OS calls one of the entry points of the device driver. This helps to pass
the control to device driver
o Secondly, the device driver examines the parameters passed and the kernel data
structures for getting information on exactly what to do and performs the required
operation to satisfy users request.
A character driver uses following entry points:
init( ):
– The init( ) entry point is called by the kernel immediately after the system
is booted. It provides the driver with an oppurtunity to initialize the driver
and the hardware. It also display messages anouncing the precesence of
device and the hardware.
start( ):
– This is called by the kernel late in the bootstap sequence when more system
services are available.
open(dev, flag, id):
– This entry point is called by the kernel whenever a user process wants to
open a file that is related to the driver. It provides the driver an oppurtunity
to perform initialization that need to handle read write system calls.
close(dev, flag, id):
– This entry point is called by the kernel when some files need to be closed.
read(dev):
– This entry point is called by the kernel whenever the user process performs
a read system call on a special file related to this driver.
write(dev):
– This entry point is called by the kernel whenever the user process performs
a write system call on a special file related to this driver.
poll( ):
– This entry point is called by the kernel 25 to 100 times a second which
helps the driver to check the status of the device on a regular basis.
halt( ):
– This entry point is called by the kernel before the system is shutdown
intr(vector):
– This entry point is called by the kernel whenever an interrupt is recievd.

36
 CST305 System Software Module 5

ioctl():
– This entry point is called by the kernel for processing special requets.

• Private Routines
– This section includes functions which are private to the driver, which are used for the internal
operation of the driver.
• The overall process
Now let us trace the detailed flow of control and data when a user process first opens and then
reads data from device driver. When the operating system receives the open call, it starts by accessing
the file referenced in the open call and determines that it is a special device file. It also sets up a series
of data structures that connect the user's process with the driver.
A table called character driver table is maintained in kernel which contains the information
regarding different character drivers used in the system. The operating system uses the device number
to index into this table to obtain a pointer to the driver's open entry point which is called.
An inode is a data structure containing information about files. The information that was
obtained from the file's inode is placed in a free entry in the inode table. If the file was already open
and in use by another process, then the same inode table entry will be shared among all processes that
have opened the file.
Next, the system allocates a new entry in the kernel's file table that points to the inode table.
Finally, a free entry in the user process's file table is located and set to point to the new entry in the
kerne1's file table. The index to this entry in the process's file table is the value returned by the open
system call. The relationship between these different tables is shown in the following figure.
CST305 System Software Module 5

When the user process executes a read system call, the OS follows the same sequence
of pointers to obtain a pointer to drivers read entry point. The kernel then calls the drivers read
entry point by passing the parameters.

General Design of a block device driver

• Explain block device drivers with its figure.
• Explain the design issues of device driver. (Read from 6.2)
• The design of block device driver includes three sections:
– Prologue
– Entry points ( functions referenced by OS)
– Private Routines or Internal operation of driver(functions private to the driver)

• Prologue
o Same explanation as that of character drivers.
o Add only two more header file
#include <sys/buf.h> - this header file contains the definition of buffer header that
are used to coordinate the transfer of data to and from block drivers.
#include <sys/cmn-err.h> - this header file contains the definition used by the
error reporting routines.
• Entry points
o Block devices uses the following entry points:
init ( ) - same as that of character driver
open( ) - same as that of character driver
close( ) - same as that of character driver
strategy( ) –
This entry point is responsible for handling requests for data. Block device
drivers doesn’t use read and write entry points, instead of that strategy () entry point
is used.
print( ) -
This entry point is used by the kernel to report the problems related to the
driver. It calls the kernel routine cmn_err() to display the error message.
 CST305 System Software Module 5

5.2.5 DEVICE CHARACTERISTICS

Some device characteristics are:
Identifier
A universally unique identifier that is specific to the device.
Operational State
Indicates whether the device is mounted or unmounted.
Type
Type of device, for example, disk or CD-ROM.
Capacity
Total capacity of the storage device.
LUN
Logical Unit Number (LUN)
Drive Type
Information about whether the device is a solid-state drive (SSD) or a regular non-SSD hard
drive.

5.3 TEXT EDITORS

5.3.1 OVERVIEW OF EDITING

A text editor is a computer program that allows a user to create and revise a target document. The
term document includes objects such as computer programs, texts, equations, tables, diagrams,
photographs etc. The primary elements being editing in a text editor are character strings of the target
text.
An interactive text editor has become an important part of almost any computing environment.
Normally, the common editing features associated with text editors are moving the cursor, inserting,
deleting, replacing, pasting, searching, searching and replacing, saving andloading, quitting etc. The
example for text editors on Windows OS are Notepad, WordPad, Microsoft Word and text editors on
UNIX OS are gedit, vi, emacs , jed, pico.
The document editing process is an interactive user-computer dialogue designed to accomplish
four tasks:
1. Select the part of the target document to be viewed and manipulated
 CST305 System Software Module 5

2. Determine how to format this view on-line and how to display it.
3. Specify and execute operations that modify the target document.
4. Update the view appropriately.
The above operations can be explained using the technical terms travelling, filtering, formatting, editing
as follows:
• Traveling: It means the selection of the part of the document to be viewed and edited. It
involves first traveling through the document to locate the area of interest.
• Filtering: It means the selection of what is to be viewed and manipulated is controlled by
filtering. Filtering extracts the relevant subset of the target document at the point of interest
such as next screenful of text or next statement.
• Formatting: It determines how the result of filtering will be seen as a visible representation
(the view) on a display screen or other device.
• Editing: In the actual editing phase, the target document is created or altered with a set of
operations such as insert, delete, replace, move or copy

5.3.2 USER INTERFACE OF AN EDITOR

The user interface is concerned with the:
a) Input devices
b) Output devices
c) Interaction language of the system.
a) Input Devices
The input devices are used to enter elements of text being edited, to enter commands, andto
designate editable elements. Input devices are categorized as:
1. Text or string devices
2. Button devices
3. Locator devices
4. Voice Input devices
Text or string devices:
These are typically typewriter like keyboards on which user presses and release keys,
sending unique code for each key. Normally all computer key boards are of the QWERTY type.
Button or Choice devices:
These generate an interrupt or set a system flag, usually causing an invocation of anassociated
application program. Special function keys are also available on the key board.
 CST305 System Software Module 5

Alternatively, buttons can be simulated in software by displaying text strings or symbols on the screen.

Locator devices:
These are two-dimensional analog-to-digital converters that position a cursor symbol on the
screen by observing the user's movement of the device. The most common such device is mouse and
tablet.
(The data tablet is a flat, rectangular, electromagnetically sensitive panel. Either the
ballpoint pen like stylus or a puck, a small device similar to a mouse is moved over the
surface. The tablet returns to a system program the co-ordinates of the position on the data
tablet at which the stylus or puck is currently located. The program can then map these data-
tablet coordinates to screen coordinates and move the cursor to the corresponding screen
position. Text devices with arrow (Cursor) keys can be used to simulate locator devices.
Each of these keys shows an arrow that point up, down, left or right. Pressing an arrow key
typically generates an appropriate character sequence; the program interprets this sequence
and moves the cursor in the direction of the arrow on the key pressed.)

Voice-Input Devices:
These devices translate spoken words to their textual equivalents. Voice recognizers arecurrently
available for command input on some systems.
b) Output Devices
The output devices let the user view the elements being edited and the result of the editing
operations.
• The first output devices were teletypewriters and other character-printing terminals that
generated output on paper.
• Next are "glass teletypes" based on Cathode Ray Tube (CRT) technology which uses CRT
screen essentially to simulate the hard-copy teletypewriter.
• Today's advanced CRT terminals use hardware assistance for such features as moving the
cursor, inserting and deleting characters and lines, and scrolling lines and pages.
• The modern professional workstations are based on personal computers with high
resolution displays.
c) Interaction Language
The interaction language of the text editor can be of following types:
 CST305 System Software Module 5

• The typing oriented or text command-oriented method

• Function key interfaces
• Menu oriented interface
The typing oriented or text command-oriented method
It is the oldest of the major editing interfaces. The user communicates with the editor by typing
text strings both for command names and for operands. These strings are sent to the editor and are usually
echoed to the output device. Typed specification often requires the user toremember the exact form of
all commands, or at least their abbreviations.
If the command language is complex, the user must continually refer to a manual or an on-line
Help function. The typing required can be time consuming for in-experienced users.

Function key interfaces

Each command is associated with marked key on the key board. This eliminates much typing. E.g.:
Insert key, Shift key, Control key. The disadvantage with this approach is keyboard may contain too
many unique keys.
Menu oriented interface
A menu is a multiple choice set of text strings or icons which are graphical symbols that represent
objects or operations. The user can perform actions by selecting items for the menus. The editor prompts
the user with a menu.
One problem with menu oriented system can arise when there are many possible actions and
several choices are required to complete an action. And also the display area of the menu is limited.

5.3.3 EDITOR STRUCTURE

Most text editors have a structure similar to that shown in figure on next page.

The command Language Processor

It accepts input from the user's input devices, and analyzes the tokens and syntactic structure of
the commands. The command language processor invokes the semantic routines directly. The semantic
routines involve traveling, editing, viewing and display functions. In a texteditor, these semantic routines
perform functions such as editing and viewing.
Editing Component
Editing component is the collection of modules dealing with editing tasks. In editing a document,
the start of the area to be edited is determined by the current editing pointer
 CST305 System Software Module 5

maintained by the editing component, which is the collection of modules dealing with editing tasks. The
current editing pointer can be set or reset explicitly by the user using travelling commands, such as next
paragraph and next screen, or implicitly as a side effect of the previous editing operation such as delete
paragraph.

Fig: Editor Structure

Traveling Component
Travelling component is actually used to travel through the document and locate the area of
interest. The traveling component of the editor performs the setting of the current editing and viewing
pointers, and thus determines the point at which the viewing and /or editing filtering begins.

Viewing Component
The start of the area to be viewed is determined by the current viewing pointer. This pointer is
maintained by the viewing component of the editor, which is a collection of modules responsible for
determining the next view. The current viewing pointer can be set or resetexplicitly by the user or
implicitly by system as a result of previous editing operation. This view
 CST305 System Software Module 5

may be a very simple one consisting of a window's worth of text arranged so that lines are not broken in
the middle of the words.

Display Component
It takes the idealized view from the viewing component and maps it to a physical output device
in the most efficient manner. The display component produces a display by mapping the buffer to a
rectangular subset of the screen, usually a window

Editing Filter
Filtering consists of the selection of contiguous characters beginning at the current point. The
editing filter filters the document to generate a new editing buffer based on the current editingpointer as
well as on the editing filter parameters.
Editing Buffer
It contains the subset of the document filtered by the editing filter based on the editing pointer
and editing filter parameters.
Viewing Filter
When the display needs to be updated, the viewing component invokes the viewing filter. This
component filters the document to generate a new viewing buffer based on the current viewing pointer
as well as on the viewing filter parameters.
Viewing Buffer
It contains the subset of the document filtered by the viewing filter based on the viewing pointer
and viewing filter parameters. E.g. The user of a certain editor might travel to line 75,and after viewing
it, decide to change all occurrences of "sad" to "happy" in lines 1 through 50 of the file by using a change
command such as [ 1 , 5 0 ] c / sad /happy.
As a part of the editing command there is implicit travel to the first line of the file. Lines 1 through
50 are then filtered from the document to become the editing buffer. Successive substitutions take place
in this editing buffer without corresponding updates of the view.
This viewing buffer is then passed to the display component of the editor, which produces a
display by mapping the buffer to a rectangular subset of the screen, usually called a window.
Relation between Editing and Viewing Buffers
The editing and viewing buffers can be related in many ways.
o Identical
o Disjoint
o Overlapped
 CST305 System Software Module 5

In a simplest case, if the user edits the material directly on the screen, editing and viewing buffer
are said to be identical. On the other hand, if the user is editing the material which is not display on the
screen the editing and viewing buffers are said to be disjoint. If the user edits some portion of the
materials displayed on the screen and some portions not displayed on the screen then editing and viewing
buffers are said to be overlapped.

The mapping of the viewing buffer to a window is accomplished by two components of the system.
First, the viewing component formulates an ideal view often expressed in a device independent
inter-mediate representation. This view may be a very simple one consisting of a windows worth of text
arranged so that lines are not broken in the middle of words.
Second the display component takes these idealized views from the viewing component and maps
it to a physical output device in the most efficient manner possible.

Windows typically cover the entire screen or rectangular portion of it (part of screen)
The content of viewing buffer is passed to the display component of the editor, which produces
a display by mapping the buffer to a rectangular subset of the screen, usually called a window. This
window can be Entire screen which means window is of same size as screen or Part of the screen
which means window cover only part of the screen. Mapping viewing buffers to windows that cover
only part of the screen is especially useful for editors on modern graphics based workstations. Such
systems can support multiple windows, simultaneously showing
 CST305 System Software Module 5

different portions of the same file or portions of different file. This approach allows the user to perform
inter file editing operations much more effectively than with a system only a single window.

Editors function in three basic types of computing environment:

• Time-sharing environment
• Stand-alone environment
• Distributed environment
Each type of environment imposes some constraint on the design of an editor.
Time Sharing Environment
In time sharing environment, the editor must move quickly within the context of the load on the
computer's processor, central memory and I/O devices.
Stand alone Environment
The editor on a stand-alone system must have access to the functions that the time sharing editors
obtain from its host operating system. This may be provided in reducing size by a small local operating
system or they may be built into the editor itself if the stand alone system is dedicated to editing.
Distributed Environment
The editor operating in a distributed resource sharing local network must works like a standalone
editor which run independently on each user's machine and must works like a time sharing editor.

(The components of the editor deal with a user document on two levels:
• In main memory
• In the disk file system
Loading an entire document into main memory may be infeasible. However if only part of a document
is loaded and if many user specified operations require a disk read by the editor tolocate the affected
portions, editing might be unacceptably slow.
In some systems this problem is solved by the mapping the entire file into virtual memory and
letting the operating system perform efficient demand paging. An alternative is to provide is the editor
paging routines which read one or more logical portions of a document into memory as needed. Such
portions are often termed pages, although there is usually no relationship between
 CST305 System Software Module 5

these pages and the hard copy document pages or virtual memory pages. These pages remain
resident in main memory until a user operation requires that another portion of the document be
loaded.)

5.4 DEBUGGERS
INTERACTIVE DEBUGGING SYSTEMS
The errors in the program are called bugs and the process of finding and correcting them is called
debugging. An interactive debugging system provides programmers with facilities that helps in
testing and debugging of programs interactively.

5.4.1 DEBUGGING FUNCTIONS AND CAPABILITIES

A good debugger must have following functions and capabilities.
• Execution sequencing:
Execution sequencing means the observation of the control flow of program. For example, the
program may be halted after a fixed number of instructions are executed.
• Breakpoints :
The programmer may define break points which cause execution to be suspended, when a
specified point in the program is reached. After execution is suspended, the debugging command is used
to analyze the progress of the program and to diagnose errors detected. Execution of the program can
then be removed.
• Conditional Expressions:
Programmers can define some conditional expressions, that are continually evaluated during the
debugging session. Program execution is suspended, when conditions are satisfied. Then analysis is
made, later execution is resumed.
• Gaits:
Gait means running the program in various speeds if a good graphical representation of program
progress is given.
• Tracing and Traceback:
A debugging system should also provide functions such as tracing and traceback. Tracing can be
used to track the flow of execution logic and data modifications. The control flow can be traced at
different levels of detail – procedure, branch, individual instruction, and so on
 CST305 System Software Module 5

Traceback can show the path by which the current statement in the program was reached.
It can also show which statements have modified a given variable or parameter.
• Program display Capabilities :
It is also important for a debugging system to have good program display capabilities. Agood
debugger must display the entire program being debugged with statement number.

• Multilingual Capability:
A debugging system should consider the language in which the program being debugged is written.
Most user environments and many applications systems involve the use of different programming
languages. A single debugging tool should be capable to debug multiple languages.
• Context Effects
The context being used has many different effects on the debugging interaction. For example.
The statements are different depending on the language. For eg,
In COBOL, MOVE 6 TO X
In FORTRAN, X = 6
Both these statement assigns the value 6 to the variable X.
Likewise different programming languages use different syntax for conditional statements. Foreg,
In COBOL, IF A NOT EQUAL TO B
In FORTRAN, IF (A .NE. B)
Both these statements checks whether the value of A is not equal to B.
Similar differences exist with respect to the form of statement labels, keywords and so on.
• Display of source code:
The language translator may provide the source code tagged in some standard way so thatthe
debugger has a uniform method of navigating about it.
• Optimization:
It is also important that a debugging system be able to deal with optimized code. Many
optimizations involve the rearrangement of statements or segments of code in the program.
For eg, loop invariant code motion which means the invariant expressions can be move
outside from loop. Consider the for loop,
for( i=1; i<100; i++ )
{
 CST305 System Software Module 5

a=b+c;
x=y+i;
}
Here value of the statement a=b+c doesn’t changes on the different iteration of for loop. Hence itcan be
consider as loop invariant code and can be move outside from the loop as follows:
for( i=1; i<100; i++ )
{
x=y+i;
}
a=b+c;
Other optimization strategies are separate loops can be combined into a single loop,common
sub expression may be eliminated etc.

5.4.2 RELATIONSHIP WITH OTHER PARTS OF THE SYSTEM

An interactive debugger must be related to other parts of the system in many different
ways.
• Availability
One important requirement for an interactive debugger is that it always be available. This means
that it must appear to be appear as a part of the run-time environment and an integral partof the system.
When an error is discovered, immediate debugging must be possible because it may be difficult or
impossible to reproduce the same program error in some other environment or at some other times.
• Communicate and cooperate with other OS components
A good debugger must communicate and cooperate with other operating system components.
• Maintain security and integrity
Debugger must also exist in a way that it is consistent with the security and integrity components
of the system. It must not be possible for someone to use the debugger to access any data or code that
would not otherwise be accessible to that individual. Similarly, it must not be possible to use the
debuggers to interface with any aspect of system integrity.
• Coordination with existing and future systems
 CST305 System Software Module 5

The debugger must co-ordinate its activities with those of existing and future language compilers
and interpreters. It is assumed that debugging facilities in existing language willcontinue to exist and be
maintained.

5.4.3 USER INTERFACE CRITERIA

The interactive debugging system should be user friendly. The facilities of debugging system
should be organized into few basic categories of functions which should closely reflect common user
tasks.
Full screen displays and windowing systems
The user interaction should make use of full-screen display and windowing systems. Advantage
of such interface is that the information can be displayed and changed easily and quickly.

Menus
With menus and full screen editors, the user has far less information to enter and
remember. It should be possible to go directly to the menus without having to retrace an entire hierarchy.
Command language
The command language should have a clear, logical, simple syntax. Parameters names should be
consistent across set of commands. Parameters should automatically be checked for errors for type and
range values. Defaults should be provided for parameters. It should minimize punctuations such as
parenthesis, slashes, and special characters.
On Line HELP facility
Good interactive system should have an on-line HELP facility It should provide help forall
options of menu. Help should be available from any state of the debugging system.

5.4.4 DEBUGGING METHODS

Debugging is the process of finding and correcting the errors in the program. Different debugging
methods are:
5.4.4.1 Debugging by Induction
5.4.4.2 Debugging by Deduction
5.4.4.3 Debugging by Backtracking
5.4.4.4 Debugging by Testing
 CST305 System Software Module 5

1. Debugging by Induction
In debugging by induction one starts from the available data which are related to the symptoms
of error, identify the relationship between them and devise some hypothesis. If the hypothesis can be
proved, fix the error using it.

Fig: Debugging by induction

1. Locate the pertinent data (locate the available data)

A major mistake debuggers make is failing to take account of all available data orsymptoms
about the problem. The first step is the enumeration of all you know about what the program did correctly
and what it did incorrectly and the symptoms that led you to believe there was an error.
2. Organize the data
Induction implies that you're processing from the particulars to the general, so the second step is
to structure the available data to let you observe the patterns.
3. Devise a hypothesis
Study the relationship among the data(clues) and devise one or more hypotheses about the cause
of the error using the patterns that are visible in the structure of the data(clues). If you can't devise a
theory, more data are needed, perhaps from new test cases. If multiple theories seem possible, select the
more probable one first.
4. Prove the hypothesis.
A major mistake at this point is skipping this step and jumping to conclusions to fix the problem.
If you skip this step, you'll probably succeed in correcting only the problem symptom, not the problem
itself.
 CST305 System Software Module 5

Prove the hypothesis by comparing it to the original clues or data, making sure that this
hypothesis completely explains the existence of the clues. If it does not, either the hypothesis is invalid,
the hypothesis is incomplete, or multiple errors are present. If the hypothesis is not proved, repeat step
3 and 4.
5. Fix the error
If the hypothesis is proved then fix the error based on that hypothesis.
2. Debugging by Deduction
The process of debugging by deduction proceeds from some general theories or premises, using
the processes of elimination and refinement, to arrive at a conclusion.

Fig: Debugging by deduction

The steps involved are:

1. Enumerate the possible causes or hypotheses
The first step is to develop a list of all possible causes of the error. They dont have to be
complete explanations; they are merely theories to help you structure and analyze the availabledata.
2. Use the data to eliminate possible causes.
Carefully examine all of the data, particularly by looking for contradictions and try to eliminate
all but one of the possible causes. If all are eliminated, you need more data through additional test cases
to devise new theories. If more than one possible cause remains, select the most prime hypothesis first.
3. Refine the remaining hypothesis.
The possible cause at this point might be correct, but it is unlikely to be specific enough to
pinpoint the error. Hence, the next step is to use the available clues to refine the theory.
4. Prove the remaining hypothesis.
A major mistake at this point is skipping this step and jumping to conclusions to fix the
 CST305 System Software Module 5

problem. If you skip this step, you'll probably succeed in correcting only the problem symptom,
not the problem itself.
Prove the hypothesis by comparing it to the original clues or data, making sure that this
hypothesis completely explains the existence of the clues. If it does not, either the hypothesis is
invalid, the hypothesis is incomplete, or multiple errors are present. If the hypothesis is not
proved, and no more hypothesis exist collect more data and starts from step 1.
5. Fix the error
If the hypothesis is proved then fix the error based on that hypothesis.

3. Debugging by Backtracking
• This is an effective method for locating and correcting errors in a small program
• In this method:
– Start at the place in the program where an incorrect result was produced
– Go backward in the program one step at a time, mentally executing the
program inreverse order
– Derive the state (values of all variables) of the program at the previous step
– Continuing in this fashion, the error is localized between the point where the
state of the program was what was expected and the first point where the
state was not what expected.

4. Debugging by Testing
The use of additional test cases is another very powerful debugging method which is often
used in conjunction with the induction method to obtain information needed to generate a
hypothesis and/or to prove a hypothesis and with the deduction method to eliminate suspected
causes, refine the remaining hypothesis, and/or prove a hypothesis.