\chapter{A CAL Tool For {\rm oggin}} \section{Introduction} A concept that is fundamental to understanding how computers are organised is the {\bf process} concept. A {\bf process} is basically a program in execution. At any instant of time, a process is in a certain state. The state of a process tells how far the process is in its computation. It contains all the information needed to stop the process and then restart it later. The process state consists of (at least) the following information : \begin{enumerate} \item The program, \item An indication of which instruction is to be executed next, \item The values of all the program's variables and data, \item The status and position of all input/output devices being used. \end{enumerate} As a process progresses in time, its state changes. Different instructions, in turn, become `the next instruction' to be executed. The variables take on successive values. To understand the concept of {\bf process} is part of the purpose of 31V4 (Programming Systems). {\rm oggin} is used as an introduction to the concept of process for the course. \\ \\ \noindent As we have seen from the previous chapter the output from {\rm oggin} is only a one-line display of registers and the processor status word (psw) for examining after each instruction cycle. It takes time and effort for students to match each output line with each instruction in their source file. It would be more striking and effective to use a visual system which can also inform the user of the state of the processor after each instruction cycle. \section{Background of Project} When I did the subject of 31V4, the second assignment was to write a moderately large Pascal program which would act as if it were an {\rm oggin} computer, but the input data was octal codes which were supposed to have been generated by an assembler. It might have been because of the time limit, but I was not required to implement every function code and the overflow flag (V-bit). So strictly speaking, the program was a simulated {\rm oggin} interpreter which could implement most of the function codes of {\rm oggin}. \\ \\ \noindent I remember I finished the assignment in a panic and hurry. I knew it was not complete and might be wrong in somewhere. I promised myself that if I could proceed to MSc stage, I would like to find a topic which was relevant to the assignment, to make the assignment complete and more useful. \\ \\ \noindent Encouraged by Richard Bland and Anne Bailey, I decided to extend the second assignment to be an visual system used as a CAL tool for {\rm oggin}, which I developed as the `new{\rm oggin}' program. \section{Objectives} Since students of 31V4 take time and effort to match instructions with the outputs, and they cannot see the constant changes of memory, the tool must enhance {\rm oggin} with three objectives helpful for learning : \subsection{Informative} Besides the one-line of output that {\rm oggin} produces, the tool also shows the changing memory and its contents, the current instruction, including its binary code, octal code and assembly language form, and an explanation and comment for each instruction. \subsection{Effective and Impressive} When memory is accessed or whenever significant changes occur, locations concerned will be highlighted to catch the user's attention, which would make the teaching result more impressive and effective. \subsection{Simple and Efficient} The user only needs to start up the tool by one command and then press a key for each instruction cycle or `q' for exit the tool. The instruction together with the output are displayed on the same screen at the same time. Subsequently, the user does not need to waste time and effort to match instructions with the output lines. \\ \\ \noindent Furthermore, the teaching tool will be developed on both {\rm crown} and {\rm forth} machines running under UNIX, and will thus be available to a wide range of potential users. It will be mainly aimed, however, at those who wish to aid their learning at their own pace. For example, the tool could be used by those who select 31V4 (Programming Systems), learning {\rm oggin} as the basic concept and experience for the subject. But, that is not to say that the tool is to be used only in conjunction with a course or tutorials. Anyone with an interest in learning {\rm oggin} or is curious about the changes in main components of cpu and memory could use it. \section{The Translation Tool ptc} \subsection{The Need for ptc} The design of the CAL tool was that it should display its output continuously on the screen of a video display terminal. Each piece of information is in a different place on the screen. The {\bf C Curses} package (introduced in the next chapter) available on the Computing Science Department's AT\&T 3B15 computer ({\rm crown}) is a package that lets you easily handle display windows on a text-based terminal. The {\bf X Windows} package also allows you to handle screen windows, but it is designed to be more suitable for use with workstations with a graphics display capability. For this program it would be like using a sledgehammer to crack a nut. However, extending the Pascal program to use {\bf C Curses} is difficult and impractial. \\ \\ \noindent I followed Richard Bland's suggestion to learn C and asked Sam Nelson to build up a tool on UNIX for me to translate the Pascal program into C, which would save time. \subsection{How to Use ptc} The tool, called ptc, was copied from {\rm crown}. It can be used to translate a pascal program to C by the command : \\ \hspace*{20mm}{\it ptc $<$ filename.p $>$ filename.c} \\ filename.p is the name of Pascal program and the translated result will be saved on filename.c. \\ For example, if the filename.p is a program such as the following : \\ \begin{verbatim} program mini(input,output); const z = 32; var x : integer; y : integer; Begin x := z * 2; y := x + z End. \end{verbatim} After the translation command, the result program filename.c would be fig 3.1 \newpage \dspaceoff \begin{verbatim} extern void exit(); /* Definitions for i/o */ # include typedef struct { FILE *fp; unsigned short eoln:1, eof:1, out:1, init:1, :12; char buf; } text; text input = { stdin, 0, 0 }; text output = { stdout, 0, 0 }; # define Fread(x, f) fread((char *)&x, sizeof(x), 1, f) # define Get(f) Fread((f).buf, (f).fp) # define Getx(f) (f).init = 1, (f).eoln = (((f).buf = fgetc((f).fp)) == '\n') ? (((f).buf = ' '), 1) : 0 # define Getchr(f) (f).buf, Getx(f) # define Fwrite(x, f) fwrite((char *)&x, sizeof(x), 1, f) # define Put(f) Fwrite((f).buf, (f).fp) # define Putx(f) (f).eoln = ((f).buf == '\n'), (void)fputc((f).buf, (f).fp) # define Putchr(c, f) (f).buf = (c), Putx(f) # define Putl(f, v) (f).eoln = v /* ** Definitions for standard types */ typedef int integer; extern char *strncpy(); /* ** Start of program definitions */ # define z 32 integer x; integer y; /* Start of program code */ main() { x = z * 2; y = x + z; exit(0); } /* End of program code */ Fig.3.1 The result of the translated Pascal program \end{verbatim} \dspaceon \newpage \subsection{Limitation of ptc} During the translation, the ptc may stop translating at some point in the program because ptc may not understand some of the statements in Pascal program. Those statements will need to be translated by the user. \section{Revising the C program} The translated program did not work very well because of the over complication of the file handling. This made it very cumbersome. I hand-translated the parts relevant to file input myself and revised the program to make it look succinct and structured. For instance, there is almost one page of lines such as these used to handle the procedure to input a file : \\ \begin{it} \#define Fscan(f) (f).init ? ungetc((f).buf, (f).fp) : 0, Tmpfil = (f).fp\\ \#define Resetx(f,n) (f).init = (f).init ? (Finish(f)) : (((f).fp = Fopen(n,Rmode)), 1), (f).eof = (f).out = 0, Getx(f) \\ ......... \\ \end{it} Those lines were deleted after I had translated the procedure for input file myself. \\ \\ \noindent There are 29 {\it For} loops in the Pascal program; but every loop was in the same format which looked very cumbersome : \\ \begin{verbatim} integer B3 = 0, B4 = 15; if (B3 <= B4 ) for (i = B3; ; i++) { oggin->A[i] = 0; if (i == B4) break; } \end{verbatim} I simplified all the {\it For} loops to become more like C structure : \\ \\ \begin{verbatim} for (i = 0;i<= 15 ; i++) oggin->A[i] = 0; \end{verbatim} \subsection{Differences Between Revised and Original C Programs} The dissimilarity between the C programs lies in their scope, design and results. \subsection{Scope} Strictly speaking the original C program only implemented most of the function codes of {\rm oggin}. and the V-bit of the psw was ignored; The revised C program is a complete program which can perform every function code of {\rm oggin} and the extended {\rm oggin} instruction set; the V-bit being fully implemented. \subsection{Design} The original C program generated by ptc was an large one-module program which had trouble with too many global variables. The revised program was separated into five files as described in section 3.4.1. Thus some global variables could be removed and made local; the other global variables left in a single file. Additionally, the program had another file added-- the curses user interface. It was the interface file which changed {\rm oggin} to a demonstration program. Furthermore, the revised program is much more succinct and well structured than the original one. The file of newg3.c, for instance, originally had one function for executing one function code, now it has only four functions for eight function codes; but the results are not affected. Appendix A contains algorithms of the original and the revised C programs. \subsection{Results} The significant difference of the two programs is the format of the output. The original program, {\rm oggin}, outputs a single line showing the contents of all the registers (including psw) for each instruction executed. The result could be printed out on a printer for tracing line by line. The results of the revised program are displayed on screen and cannot be printed except using the screen printer because it is designed to be an interactive program. The result is not only one line of registers contents, but also other relevant and useful information about each instruction, described in a later chapter. \section{Common points} The {\rm oggin} uses a 16-bit word while the HP 9000/835 stores integers as 32 bits. So all of the arithmetic and logical operations associated with handling {\rm oggin} data are performed by the set of procedures that represent the {\rm oggin} 16-bit structure. So in the Pascal program, it required two extra procedures to convert integer to {\rm oggin} word and vice versa. \\ \\ \noindent In the Pascal program, the two procedures --- IntegerToOggin (convert integer to 16-bit {\rm oggin} word) and OgginToInteger (convert {\rm oggin} word back to integer) --- were called before any arithmetic or logical shift. \\ \\ \noindent In the C program, both procedures are translated to two functions, which are still needed for the same purpose. It seems to be quite awkward to use the two functions since C supports bitwise shift, AND, OR directly from an integer, but they cannot be removed in the revised program due to {\rm oggin} 16-bit word. Therefore despite the big difference between both the C programs, there is still something in common. \\ \\ \noindent However, C allows you to convert between types by preceding a value with the type that you want to convert it to, called casting. For instance, \\ \hspace*{20mm} {\it Fred = (int)jim} \\ would convert jim into an integer and store it in Fred. \\ \hspace*{20mm} {\it jim = (oggin)Fred} \\ would convert Fred into an {\rm oggin} word and store it in jim. But I didn't know about this. Someone could revise the program to use this method instead of the functions.