$A MARK=2
$A TAB=5, 10, 15
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$B10 $L1M
imp AS A tOOL FOR sMALL oPERATING sYSTEMS iMPLEMENTATION
$b2
$l1m
bRIAN a. c. gILMORE
$B10
$l1m
tHESIS pRESENTED FOR THE dEGREE OF mASTER OF pHILOSOPHY
$l1m
fACULTY OF sCIENCE, uNIVERSITY OF eDINBURGH
$l1m
oCTOBER 1976
$N
$L1CM
ABSTRACT
$P2 @THIS THESIS DISCUSSES THE DESIRABILITY
OF USING A HIGH LEVEL LANGUAGE FOR SMALL SYSTEMS
IMPLEMENTATION. @AN EXAMINATION IS MADE OF SOME OF THE FEATURES
REQUIRED IN SUCH A LANGUAGE. @A DETAILED COMPARISON
IS DRAWN BETWEEN A MULTI-PROGRAMMING SYSTEM FOR A .PDP 11 WRITTEN
IN ASSEMBLER AND A SIMILAR SYSTEM WRITTEN IN THE HIGH LEVEL
LANGUAGE .IMP. @THE FACTORS BEING COMPARED
INCLUDE THE COSTS OF WRITING AND MAINTAINING THE TWO SYSTEMS
AND THE DIFFERENCES IN THEIR PHYSICAL CHARACTERISTICS,
NAMELY  THE
STORE USED AND TIME TAKEN. @IT IS SHOWN THAT THE USE OF .IMP
IS ADVANTAGEOUS IN THE WRITING AND MAINTAINING OF THE
SYSTEM WRITTEN IN .IMP BUT THAT THIS 
ADVANTAGE
IS OFFSET TO A CERTAIN
EXTENT BY EXTRA STORE REQUIREMENTS AND A SLOWER RESPONSE TIME.
$N
$L1CM
CONTENTS
$B1 @CHAPTER 1 $C67 1
$I1 .INTRODUCTION
$I2 @STATEMENT OF THE @PROBLEM $C67 1
$I2 @MYTHOLOGY AND @BELIEFS $C67 1
$I2 @THE @EXPERIMENT $C67 6
$I2 @BRIEF @HISTORY $C67 7
$B1 @CHAPTER 2 $C67 9
$I1 .DESCRIPTION .OF .SYSTEM .ONE
$I2 @GOALS $C67 9
$I2 @CONSTRAINTS $C67 11
$I2 @STRUCTURAL @OVERVIEW $C67 11
$I2 @IMPLEMENTATION $C67 16
$I2 @OPERATION $C67 17
$B1 @CHAPTER 3 $C67 18
$I1 .DESCRIPTION .OF .SYSTEM .TWO
$I2 @GOALS $C67 18
$I2 @CONSTRAINTS $C67 19
$I2 @STRUCTURAL @OVERVIEW $C67 20
$I2 @IMPLEMENTATION $C67 24
$I2 @OPERATION $C67 25
$B1 $V5@CHAPTER 4 $C67 26
$I1 .A .QUALITATIVE .COMPARISON
$I2 @APPROPRIATENESS OF .IMP AS A @SYSTEMS @PROGRAMMING @LANGUAGE $C67 27
$I3 @STRUCTURE OF THE @LANGUAGE $C67 28
$I3 @DATA @STRUCTURE AND THE @OPERATORS ON THEM $C67 30
$I3 @ADEQUACY OF THE @IMPLEMENTATION OS .IMP $C67 32
$I2 @IMPLEMENTATION @CONSIDERATIONS $C67 33
$I3 @INITIAL @IMPLEMENTATION $C67 33
$I3 @FAULTS $C67 35
$I3 @ADDITIONS $C67 40
$I2 @PHYSICAL @CONSIDERATIONS $C67 41
$I3 @SYSTEM @SIZE $C67 41
$I3 @SYSTEM @SPEED $C67 43
$I2 @INTERFACING @COSTS $C67 45
$B1 @CHAPTER 5 $C67 46
$I1 @A .QUANTITATIVE .COMPARISON
$I2 @SYSTEM @SIZE $C67 46
$I2 @SYSTEM @SPEED $C67 58
$B1 @CHAPTER 6 $C67 65
$I1 .CONCLUSIONS
$I2 @APPROPRIATENESS OF .IMP $C67 67
$I2 @FUTURE @SYSTEMS $C67 68
$B1 @APPENDIX ONE $C67 71
$I1 .USER .MANUAL .FOR .THE .FIRST .SYSTEM
$B1 @APPENDIX TWO $C67 97
$I1 .USER .MANUAL .FOR .THE .SECOND .SYSTEM
$B1 @APPENDIX THREE $C67 112
$I1 .LISTING .OF .THE .KERNEL .OF .THE .SECOND .SYSTEM
$B1 @REFERENCES $C67 124
$B1 @ACKNOWLEDGEMENTS $C67 126
$N
$A PAGENO=1

$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 1

INTRODUCTION
$B1 $L1C
STATEMENT OF THE PROBLEM
$P0 @OVER THE PAST YEARS THE USE AND VARIETY OF HIGH LEVEL
LANGUAGES HAS GROWN CONSIDERABLY, ESPECIALLY FOR APPLICATIONS
PROGRAMS AND TO A MORE LIMITED EXTENT FOR COMPILERS. @HOWEVER,
AT THIS TIME, VERY FEW SYSTEMS HAVE BEEN WRITTEN IN A HIGH LEVEL LANGUAGE
AND MOST OF THESE HAVE BEEN DESIGNED TO RUN IN A LARGE SYSTEM ENVIRONMENT.
@THIS POSES A QUESTION AS TO WHETHER A 
HIGH LEVEL LANGUAGE IS SUITABLE FOR IMPLEMENTING A SYSTEM ON A SMALL
COMPUTER.
@THIS ALSO INVOLVES CONSIDERING
 WHAT FEATURES ARE DESIRABLE IN SUCH A LANGUAGE.
$B1 $L1C
MYTHOLOGY AND BELIEFS
$P0 @THE BENEFITS OF USING A HIGH LEVEL LANGUAGE ARE WIDELY CLAIMED (2,3,5).
@HOWEVER VERY 
FEW ACTUAL COMPARATIVE FIGURES HAVE BEEN GIVEN.
 @THE
CLAIMS USUALLY ADVANCED IN FAVOUR OF USING A HIGH LEVEL LANGUAGE
ARE:
$A INDENT=1
$B1 $I0 1) $T+1 @INITIAL DEVELOPMENT.
$B0 @THE COSTS OF WRITING AND COMMISSIONING
A PIECE OF SOFTWARE
IN A HIGH LEVEL LANGUAGE ARE LOWER THAN WRITING
IT IN ASSEMBLER.
@BROOKS (4) HAS EXAMINED TWO LARGE PROJECTS, ONE WRITTEN IN ASSEMBLER
AND THE SECOND IN A HIGH LEVEL LANGUAGE AND CAME TO THE CONCLUSION
THAT PROGRAMMER PRODUCTIVITY, IN TERMS OF THE NUMBER OF
SOURCE STATEMENTS WRITTEN IN A GIVEN PERIOD, IS CONSTANT
IRRESPECTIVE OF THE LANGUAGE USED.
@THE IMPLICATION IS THAT THE USE OF A HIGH LEVEL LANGUAGE
GIVES AN INCREASE OF FIVE TO SIX TIMES IN THE QUANTITY
OF MACHINE CODE PRODUCED IN A GIVEN TIME.
$A INDENT=1
$B1 $I0 2) $T+1 @MAINTAINABILITY.
$P0 @THE MAINTAINENCE OF A LARGE SYSTEM IS EXTREMELY EXPENSIVE
AND IT IS CLAIMED THAT USING A HIGH LEVEL LANGUAGE TO WRITE
THE SYSTEM REDUCES THESE COSTS (6). @ONE FACTOR INVOLVED IN THIS
IS THE TURNOVER IN STAFF
THAT CAN BE EXPECTED IN ANY LARGE PROJECT.
@A NEW PROGRAMMER HAS TO FAMILIARISE
HIMSELF WITH THE PROJECT. @CORBATO CLAIMS THAT THIS IS ACHIEVED
MORE QUICKLY WHEN A HIGH LEVEL LANGUAGE IS USED (5). @THE AUTHOR'S
EXPERIENCES  IN TAKING OVER PROGRAMS IN BOTH ASSEMBLER
AND IN A HIGH LEVEL LANGUAGE HAVE CONFIRMED THIS.
@ONE PROBLEM ASSOCIATED WITH A PROGRAM WRITTEN IN ASSEMBLER IS ITS
SHEER BULK.
@USUALLY
THE SIZE OF THE ASSEMBLER PROGRAM WILL BE
AT LEAST THREE TIMES
THE SIZE
OF THE EQUIVALENT HIGH LEVEL LANGUAGE PROGRAM,
AND
@CORBATO IN FACT  STATES A FACTOR OF TEN TIMES FOR .PL/1 (5).
$P1 @A SECOND PROBLEM IS THE LACK OF STRUCTURE INHERENT IN A
PROGRAM IN ASSEMBLER,
AS EACH PROGRAMMER
TENDS TO STRUCTURE THE PROGRAM IN HIS OWN WAY WHEREAS IN A HIGH
LEVEL LANGUAGE MUCH OF THE STRUCTURE IS DICTATED BY THE LANGUAGE.
@FOR EXAMPLE, IN ASSEMBLER THERE ARE INNUMERABLE WAYS
TO PASS PARAMETERS TO A ROUTINE - IN REGISTERS, ON A STACK,
IN A PARTICULAR AREA, IN LINE AFTER THE CALL,
OR COMBINATIONS OF THESE.
@A HIGH LEVEL LANGUAGE WILL, IN GENERAL, ONLY HAVE ONE METHOD
OF PASSING PARAMETERS, WITH THE PROBABLE 
ADDITIONAL ABILITY TO USE GLOBAL VARIABLES OR THE EQUIVALENT OF A
.FORTRAN .COMMON.
$P1 @WRITING IN A HIGH LEVEL LANGUAGE REMOVES PART OF THE
DRUDGERY ASSOCIATED WITH WRITING IN ASSEMBLER. @A SIMPLE EXAMPLE
IS THE .'FOR' LOOP. @ONE STATEMENT IN THE HIGH LEVEL LANGUAGE
WILL INITIALISE THE LOOP VARIABLE, ADJUST IT ON EACH ITERATION
AND CHECK FOR THE LOOP TERMINATION. @THE SAME LOOP IN ASSEMBLER
ON THE .PDP 11 WILL BE AT LEAST FIVE INSTRUCTIONS, DEPENDING
ON THE COMPLEXITY OF THE LOOP BOUNDS. @THE EXISTENCE OF 
SUCH EXTRA STATEMENTS INCREASE THE CHANCE OF ERRORS OCCURING.
$B1 $I0 3) $T+1 @PORTABILITY.
$B0 @AFTER SINKING A LARGE CAPITAL EXPENDITURE, IN THE FORM OF
PROGRAMMERS TIME, INTO AN ASSEMBLER PROGRAM, THE ADVENT OF A NEW MACHINE
WILL MAKE THE BULK OF THE CODE USELESS. @IN A HIGH LEVEL
LANGUAGE, ONCE A COMPILER EXISTS - A ONE OFF JOB - THE MOVING OVER
OF THE CODE SHOULD ONLY INVOLVE A RECONSIDERATION OF DIFFERENT
WORD LENGTHS. @EVEN THAT SHOULD BE VERY SMALL OR NON-EXISTANT
IN A CAREFULLY WRITTEN PROGRAM.
@THIS WAS CLEARLY SHOWN BY @R. @B @JOHN (18) IN THE IMPLEMENTATION
OF COMMUNICATIONS SOFTWARE ON SEVERAL DIFFERENT MACHINES.
$P1 @THE TRAINING OF A PROGRAMMER IS COSTLY AND IF THIS TRAINING
IS IN ASSEMBLER IT WILL BE
WASTED IF NEW HARDWARE IS INTRODUCED.
@MUCH OF THE SKILL IN WRITING EFFICIENT ASSEMBLER IS INTIMATELY
CONNECTED WITH THE TRICKS AND 'CLEVER INSTRUCTIONS'
IMPLEMENTED IN THAT HARDWARE,  FEATURES WHICH ARE LIKELY TO CHANGE
WITH DIFFERENT HARDWARE.
$A INDENT=0
$P1 @THESE CONSIDERATIONS HAVE MEANT IN PRACTICE THAT
HIGH LEVEL LANGUAGES ARE WIDELY USED INDEED IT IS CLAIMED BY
@BROOKS THAT ONLY 'INERTIA AND SLOTH' PREVENT THEIR
UNIVERSAL USE (4).
$P1 @DESPITE THIS 
THE ACCEPTANCE OF THE HIGH LEVEL LANGUAGE AS A SYSTEMS
PROGRAMMING TOOL FOR COMPILERS THEMSELVES IS BY NO MEANS COMPLETE.
@ON LARGE MACHINES MOST COMPILERS STILL SEEM TO BE WRITTEN
IN ASSEMBLER.
@THE @EDINBURGH @MULTI @ACCESS @SYSTEM .(EMAS) (12,13) IS ONE EXCEPTION, 
WITH ALL ITS
COMPILERS, .ALGOL, .FORTRAN AND .IMP (11, 22) BEING WRITTEN IN .IMP.
@SOME LANGUAGES ARE NOT VERY SUITABLE FOR SELF IMPLEMENTATION, .COBOL
BEING AN EXAMPLE, BUT THE ALTERNATIVE, THAT OF WRITING THE COMPILER
IN ANOTHER HIGH LEVEL LANGUAGE SEEMS TO BE OVERLOOKED OR REJECTED.
$P1 @ON SMALL MACHINES, THE SITUATION IS VERY SIMILAR. @ON THE WHOLE
ALL COMPILERS, ESPECIALLY THE MANUFACTURER'S OWN, ARE IN ASSEMBLER,
THE EXCEPTION BEING THE .CORAL66
COMPILERS, WHICH HAVE TENDED TO BE IMPLEMENTED IN .CORAL, FOR EXAMPLE
BY @FERRANTI AND @INTERDATA.
$P1 @WHEN IT COMES TO SYSTEMS THEMSELVES IT IS NOT, NORMALLY,
ACCEPTED THAT A HIGH LEVEL LANGUAGE SHOULD BE USED.
$P1 @THE FIRST LARGE SYSTEMS IN A HIGH LEVEL LANGUAGE WERE
THE @BURROUGHS .MCP (6) IN 1961, FOLLOWED BY
.MULTICS (1) IN 1964, AND .EMAS  IN 1966.
@MORE RECENTLY WE HAVE SEEN THE
.ICL .VME/B SYSTEM (20) ON THE 2900 SERIES 
WRITTEN IN .S3, A HIGH LEVEL LANGUAGE.
$P1 @ON MINI COMPUTERS, THE USE OF HIGH LEVEL LANGUAGES
HAS BEEN EVEN SLOWER, THE FIRST WELL KNOWN SYSTEM BEING
.UNIX (17) WRITTEN IN .'C', THOUGH THIS IS MORE FOR A 
LARGE SCALE .PDP 11. @THE @ARGUS 700 (8) SERIES SYSTEM IS ALSO
WRITTEN IN @CORAL (1973).
@RECENTLY, @PURSER (3) HAS PUBLISHED A PAPER DESCRIBING A REAL-TIME
SYSTEM FOR A .PDP11 ALSO WRITTEN IN .CORAL.
$P1 @AT THE LEVEL OF SYSTEMS IMPLEMENTATION
IT IS ARGUED THAT THE DISADVANTAGES OF USING A HIGH LEVEL
LANGUAGE OUTWEIGH THE ADVANTAGES. @THE MOST COMMONLY CITED
DISADVANTAGES (2) ARE
$A INDENT=1
$B1 $I0 1) $T+1 @EXTRA STORE. $P0
@A PROGRAM WRITTEN IN A HIGH LEVEL LANGUAGE WILL NORMALLY BE
LARGER THAN THE COUNTERPART IN ASSEMBLER.
@A COMPILER CAN USUALLY BE MADE TO OPTIMISE IN ONE OF TWO
DIRECTIONS, IT EITHER OPTIMISES FOR THE SHORTEST
CODE OR FOR THE FASTEST EXECUTION. @FOR SYSTEMS WORK THE CODE
OPTIMISER WILL PROBABLY BE TOO SLOW, AND A COMPROMISE IS LOOKED FOR.
@SUCH A COMPILER
IS UNLIKELY TO SPOT
GLOBAL OPTIMISATIONS THAT A PROGRAMMER CAN.
@HOWEVER, IN A LARGE PROJECT,
 THIS TREND IS
COUNTERACTED TO A CERTAIN EXTENT BY THE DECREASE IN COMPLEXITY.
$B1 $I0 2) $T+1 @SLOWER EXECUTION. $P0
@THE EFFECT OF EXTRA CODE WILL NORMALLY BE A SLOWER
EXECUTION TIME.
$A INDENT=0
$P1 @FOR SYSTEMS IMPLEMENTATION IN PARTICULAR, THERE IS A THIRD
SOLUTION, THAT OF A HIGH-LOW LEVEL LANGUAGE - FOR EXAMPLE
@BABBAGE (23) ON THE .GEC 4080,
THE .PL360 GROUP OF LANGUAGES (24)
 AND .HAL (25) DEVELOPED BY THE @COMPUTER
@SCIENCE DEPARTMENT OF @EDINBURGH @UNIVERSITY.
 @THIS TYPE OF LANGUAGE TENDS TO MAKE
ASSEMBLER PROGRAMMING EASIER, PROVIDING SOME OF THE
CONSTRUCTS USUALLY FOUND IN A HIGH LEVEL LANGUAGE, BUT
NOT ALL THE STRUCTURE THAT A HIGH LEVEL LANGUAGE PROVIDES. @IN
CERTAIN CIRCUMSTANCES SUCH LANGUAGES CAN BE BENIFICIAL
BUT NOT NECESSARILY ON ALL TYPES OF ARCHITECTURE.
$B1 $V6 $L1C
THE EXPERIMENT
$P0 @THE AUTHOR DECIDED TO WRITE A SYSTEM IN .IMP, A HIGH
LEVEL LANGUAGE, AND COMPARE THAT SYSTEM TO A SIMILAR SYSTEM
ALREADY WRITTEN IN ASSEMBLER.
$P1 @THE AUTHOR HAD IMPLEMENTED A MULTI-PROGRAMMING 
SYSTEM IN ASSEMBLER,
FOR A SMALL CONFIGURATION .DEC .PDP 11/20.
@AT THAT POINT IN TIME (1971), THE ONLY OTHER DISC-BASED
SYSTEM AVAILABLE FOR THE .PDP 11 WAS THE .DEC '@DISC @OPERATING
@SYSTEM' .(DOS), A SINGLE PROGRAM
SYSTEM.
@AFTER A PERIOD
OF TIME THE AUTHOR FELT THAT THE EFFORT OF MAKING
FURTHER ADDITIONS, FOR EXAMPLE NEW DEVICE HANDLERS, WAS DISPROPORTIONATE
TO THE COMPLEXITY OF THE DEVICE.
@NEW HARDWARE HAD BECOME AVAILABLE, IN THE FORM OF A .PDP
11/40 WITH MEMORY MANAGEMENT AND A SYSTEM WAS REQUIRED FOR IT. @HAVING WORKED
FOR A PERIOD OF TIME ON .EMAS, AND PARTICULARLY
ON THE @FRONT @END @PROCESSOR FOR ITS COMMUNICATIONS, ALL IN 
.IMP, THE AUTHOR CONSIDERED THAT IT SHOULD BE POSSIBLE TO
IMPLEMENT A SYSTEM FOR THE .PDP 11/40 IN .IMP.
$P1 @THE DESIGNS OF THE TWO SYSTEMS HAVE
 A COMMON ANCESTRY BUT DO USE
SOME DIFFERENT CONCEPTS. @THE DIFFERENCES, AND ESPECIALLY THOSE
DUE TO 
THE TARGET MACHINE, MEAN THAT IT IS NOT
POSSIBLE TO MAKE A LINE BY LINE COMPARISON OF THE TWO SYSTEMS.
@IT IS HOWEVER, POSSIBLE TO SEPARATE OUT SOME OF THE 
EFFECTS OF THE DIFFERENCES AND
MAKE USEFUL
COMPARISONS OF THE RESPECTIVE SIZES OF THE SYSTEMS.
@CONCLUSIONS MAY EASILY BE DRAWN ON THE IMPLEMENTATION ASPECTS
OF THE TWO SYSTEMS, IN PARTICULAR 
 ON THE INITIAL IMPLEMENTATION COSTS,
 THE DIFFERENCES IN THE EASE OF ADDING NEW COMPONENTS
AND THE GENERAL MAINTAINABILITY OF BOTH SYSTEMS.
@IT IS MORE DIFFICULT TO MAKE COMPARISONS OF THE SYSTEM OVERHEADS IN
RESPECT TO THE TIME SPENT IN THE SUPERVISOR. @BOTH THE DIFFERENCES
IN THE HARDWARE AND THE CONSEQUENTLY DIFFERING DESIGNS 
MEAN THAT IT IS VERY DIFFICULT TO DRAW OVERALL TIMING
COMPARISONS, BUT SIMILAR SUBSECTIONS
CAN USEFULLY BE COMPARED.
$B2 $V5 $L1C
BRIEF HISTORY
$P0 @WORK ON THE FIRST SYSTEM WAS STARTED IN @OCTOBER 1971 ON A PART
TIME BASIS. @THE MAJOR PART OF THE KERNEL AND SOME OTHER PARTS
OF THE SYSTEM WERE WRITTEN BY @OCTOBER 1972. @BY @JANUARY 1973, A BASIC
SYSTEM WAS ABLE TO RUN PROGRAMS WRITTEN
IN A RESTRICTED FORM OF .IMP. 
@AFTER THIS
PERIOD VERY LITTLE WAS DONE TO THE SYSTEM UNTIL @AUGUST 1973
WHEN WORK ON THE BENCHMARKING OF .EMAS WAS STARTED. @THIS
PROVIDED THE FIRST REAL TEST OF THE SYSTEM AND OVER THE
NEXT FEW MONTHS THE SYSTEM BECAME MORE ROBUST. @IN @MARCH
1974 THE  SYSTEM WAS PUT INTO  USE ON THE 
.PDP 11/20 IN THE @FACULTY OF @SOCIAL @SCIENCE OF
@EDINBURGH
@UNIVERSITY.
@THE MACHINE HAD 24K WORDS OF CORE,
THREE TERMINALS, ONE A GRAPHICS DEVICE,
A DISC, CARD READER, LINE PRINTER AND
 A GRAPH
PLOTTER.
@A LINK TO THE LOCAL .IBM 360,
TO EMULATE AN .IBM 2780 .RJE TERMINAL
WAS ESTABLISHED LATER THAT YEAR AND THE SYSTEM WAS THEN USED
ON A FULL TIME BASIS.
@IN THE FOLLOWING YEAR TWO OTHER SYSTEMS WERE INSTALLED ON .PDP 11/20S.
$P1 @A NEW IMPLEMENTATION OF .IMP (9) BECAME AVAILABLE IN @MARCH
1976, THE SECOND SYSTEM WAS STARTED IN THE MIDDLE OF THAT MONTH
AND THE FIRST VERSION OF THE KERNEL WAS BEING
TESTED AT THE END OF THE MONTH. @BY THE MIDDLE OF @APRIL THE
SYSTEM WAS RUNNING .IMP PROGRAMS, ALBEIT WITH RATHER RUDIMENTARY .I/O.
@A LOADER, TOGETHER WITH A PARTIALLY IMPLEMENTED
FILE SYSTEM WAS OPERATIONAL BY THE END OF @APRIL. @THE 
SYSTEM WAS FULLY SELF SUPPORTING BY THE 11TH @MAY. @SINCE
THEN, UNTIL THE END OF @JUNE AT WHICH STAGE DEVELOPMENT
PAUSED, SEVERAL DEVICE HANDLERS,
E. G., TO HANDLE MAGNETIC TAPE, A LINE PRINTER AND A
SYNCHRONOUS COMMUNICATION LINE,
HAD BEEN ADDED, THE SYSTEM
MADE MORE ROBUST,
VARIOUS EXTENSIONS MADE TO THE SYSTEM AND A NUMBER
OF FAULTS PUT RIGHT.
$N 
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 2

DESCRIPTION OF SYSTEM ONE
$B1 $L1C
GOALS
$P0 @THIS SYSTEM WAS DESIGNED TO RUN IN A 
SMALL .PDP11.
@A MINIMAL SYSTEM REQUIRES
 AT LEAST .8K WORDS OF CORE AND ONE INPUT/OUTPUT
TERMINAL; A CLOCK IS DESIRABLE.
$P1 @THE SYSTEM WAS DESIGNED WITH FOUR MAIN AIMS:
$A INDENT=1
$B1 %@RUNNING %USER %PROGRAMS
$P0 @THE SYSTEM IS DESIGNED TO RUN
GENERAL USER PROGRAMS.
@THE SYSTEM WILL SUPPORT A LARGE NUMBER OF PROGRAMS, WITH
EACH PROGRAM HAVING FULL ACCESS TO ALL AVAILABLE SYSTEM RESOURCES.
@EACH USER PROGRAM RUNS IN ITS OWN ENVIRONMENT, IT
MAY USE  ALL THE MACHINE STORE NOT USED BY THE SYSTEM,
THOUGH NORMALLY RESOURCES WILL BE SHARED WITH OTHER PROGRAMS.
 @A PROGRAM
DOES NOT HAVE TO BE IN ANY SPECIAL FORM, FOR EXAMPLE, AN .IMP
PROGRAM LOOKS LIKE AN .IMP PROGRAM AS RUN ON OTHER MACHINES. @A
SPECIAL HEADER IS REQUIRED TO INFORM THE SYSTEM OF THE PROGRAM
CHARACTERISTICS SUCH AS ITS STORE REQUIREMENTS, PRIORITY ETC. 
@THIS HEADER
IS SETUP AUTOMATICALLY FOR .IMP PROGRAMS 
BY THE COMPILER
BUT A TASK- BUILDING
PROGRAM NEEDS TO BE USED FOR ASSEMBLER PROGRAMS.
@A PAPER TAPE READER IS USED TO LOAD PROGRAMS ON A MINIMAL
SYSTEM, A DISC CAN BE USED ON LARGER SYSTEMS.

$B1 %@MULTIPLE %TERMINAL %SUPPORT
$P0 @THE SYSTEM SHOULD SUPPORT MORE THAN
ONE TERMINAL, WHERE 
EACH TERMINAL
HAS EQUAL ACCESS TO THE ALL THE SYSTEM RESOURCES THROUGH
A COMMAND
LANGUAGE INTERPRETER.
@ONE CONSOLE IS NOMINATED AS A MASTER CONSOLE FOR
OUTPUTTING SYSTEM ERROR MESSAGES.
$B1 %@PERIPHERAL %SUPPORT
$P0 @THE SYSTEM SHOULD SUPPORT
A WIDE RANGE OF PERIPHERALS,
EG, LINE PRINTER, CARD READER, PAPER TAPE READER AND PUNCH, SEVERAL
TYPES OF DISCS, DECTAPE AND 
COMMUNICTION LINES.
$B1 %@FAST %SYSTEM %RESPONSE
$P0 @THE SYSTEM SHOULD BE ABLE TO
RESPOND TO EVENTS WITH MINIMUM DELAY, ALL
UNINTERRUPTABLE PATHS WITHIN THE KERNEL
SHOULD BE SHORT,
WITH A GUARENTEED INITIAL INTERRUPT
RESPONSE OF 400 MICRO SECONDS.
@A PRIORITY STRUCTURE MAY BE USED TO ENSURE
THE NECESSARY RESPONSE TIME.
$A INDENT=0
$B2
$V6 $L1C
CONSTRAINTS
$P0 @THE MOST SERIOUS CONSTRAINT IN THE SYSTEM IS THAT OF
STORE.
@THIS CONSTRAINT WAS IMPOSED BY THE FIRST AIM OF THE
SYSTEM; IN ORDER TO ALLOW AS MUCH SPACE AS POSSIBLE FOR
USER PROGRAMS THE AIM WAS TO RESTRICT THE KERNEL TO
AROUND 4K WORDS OF STORE.
@THIS CONSTRAINT HAS AFFECTED THE USER INTERFACE, WHICH
IS VERY BASIC.
$B2
$V4$L1C
STRUCTURAL OVERVIEW
$P0 @THE PRIMATIVE STRUCTURE OF THE SYSTEM WAS DERIVED FROM A
PAPER BY .D$. @MILLS (15,16). 
$P1 @THE SYSTEM CONSISTS OF A MINIMAL KERNEL
(OF 800 WORDS OF CODE AND A 750
WORD DATA AREA),
WHICH SUPPORTS  VIRTUAL MACHINES. @EACH
VIRTUAL MACHINE RUNS A PROGRAM, THE PROGRAM AND ITS
ENVIRONMENT IS COLLECTIVELY KNOWN AS A .TASK.
@A NUMBER OF THESE TASKS, KNOWN AS SYSTEM TASKS, ARE
USED TO HANDLE THE
PERIPHERALS AND OTHER
SYSTEM FUNCTIONS, E. G., A LOADER AND A GARBAGE COLLECTOR.
@WHEN A PROGRAM IS RUN, THE SYSTEM CREATES A NEW TASK
WHICH IS DESTROYED WHEN THE PROGRAM TERMINATES.
$P1 @THE KERNEL IS ESSENTIALLY A COLLECTION
OF ROUTINES,
WHICH ARE INVOKED BY TASKS AND RUN ON
A PRIVATE KERNEL STACK. @THEIR FUNCTIONS ARE TO:
$A INDENT=1
$I2 1) @CONTROL  .CPU ALLOCATION.
$I2 2) @HANDLE INTERRUPTS.
$I2 3) @HANDLE TASK FAULTS.
$I2 4) @IMPLEMENT SEMAPHORES (CLAIM AND RELEASE OPERATIONS).
$I2 5) @DEAL WITH  CLOCK AND TIMER FUNCTIONS.
$I2 6) @ALLOCATE AND DEALLOCATE  SMALL .I/O BUFFERS.
$A INDENT=0
$P1@THE KERNEL WAS DESIGNED SO THAT ALL UNINTERRUPTABLE PATHS
THROUGH IT ARE SHORT, FOR EXAMPLE, ONE OF THE LONGEST,
THE CLAIM SEMAPHORE OPERATION (WHEN THE SEMAPHORE IS HELD)
TAKES AN ADDITIONAL 70 MICRO SECONDS ON TOP OF THE BASIC CONTEXT
SWITCH TIME (ABOUT 330 MICRO SECONDS). @A SYSTEM FUNCTION THAT TAKES
LONGER THAN THIS IS DEALT WITH IN ONE OF THREE WAYS DEPENDING
ON THE TIME IT TAKES AND ITS NATURE.
$A INDENT=1
$B1 $I0 1) $T+1 @WITHIN THE KERNEL BUT AT LEAST PARTIALLY
INTERRUPTABLE. @THE TIMER QUEUE MANIPULATION IS AN EXAMPLE OF
THIS, IT IS INTERRUPTABLE BY AN INTERRUPT AT THE HIGHEST
PRIORITY LEVEL. @THE PATH LENGTH IS ABOUT 100 MICRO SECONDS,
RISING BY 20 MICRO SECONDS FOR EACH ENTRY ON THE QUEUE. @BY
ALLOWING IT TO BE INTERRUPTED AT THE HIGHEST PRIORITY, IT
FOLLOWS THAT TASKS RUNNING AT THAT PRIORITY CANNOT PERFORM
TIMER OPERATIONS.
$B1 $I0 2) $T+1 @BY A SYSTEM TASK. @THE GARBAGE COLLECTOR
IS A SYSTEM TASK, IT NEEDS TO RUN UNINTERRUPTABLY
FOR SIX INSTRUCTIONS EACH TIME IT NEEDS ACCESS TO THE GARBAGE QUEUE
BUT APART FROM THAT RUNS AT A NORMAL LEVEL FOR THE REST OF THE TIME.
$B1 $I0 3) $T+1 @BY RUNNING IN THE USER 
TASK BUT PROTECTED
EITHER BY RUNNING AT A PARTICULAR PRIORITY LEVEL, OR
BY A SEMAPHORE. @THE FILE STORAGE HANDLER RUNS IN THIS MANNER,
THE ADVANTAGE IS A SAVING ON CONTEXT SWITCHING 
OVERHEADS, THE DISADVANTAGE IS THE EXTRA SPACE REQUIRED
BY EACH USER TASK TO ACCOMODATE IT
(ABOUT 24 BYTES). @A SECOND EXAMPLE IS THE INSERTION AND
DELETION OF CHARACTERS FROM SMALL .I/O BUFFERS, THESE
OPERATIONS NEED TO BE PROTECTED FROM ONE ANOTHER, THIS IS
ACHIEVED BY PROTECTING THEM WITH A HIGH PRIORITY LEVEL, THE
PATH LENGTH IS ON AVERAGE 30 MICRO SECONDS WITHIN THE ROUTINES.
$P1 @THE DISTINCTION BETWEEN A FUNCTION PERFORMED
INTERRUPTABLY WITHIN THE KERNEL AND PERFORMED WITHIN
A TASK ENVIRONMENT IS IMPORTANT. @WHEN THE KERNEL IS
INTERRUPTED, IT ALLOWS THE INTERRUPT TO BE PROCESSED,
BUT IT WILL COMPLETE ITS PROCESSING BEFORE ALLOWING ANOTHER
TASK TO RUN. @WHEN A FUNCTION BEING PERFORMED
IN A TASK ENVIRONMENT IS INTERRUPTED, IT WILL NOT
CONTINUE PROCESSING UNTIL ALL HIGHER PRIORITY TASKS
HAVE BEEN SATISFIED.
$A INDENT=0
$P1 @ALL THE TIMINGS GIVEN ARE BASED ON A .PDP  11/40.
@THE INSTRUCTION TIME FOR A BASIC REGISTER MOVE IS 0.90
MICRO SECONDS ON THE 11/40. @THE 11/10 FIGURE IS 3.1 MICRO
SECONDS. @THESE, AND OTHER FIGURES (14) 
INDICATE THAT THE TIMINGS FOR AN 11/10 ARE ABOUT DOUBLE THE
11/40 TIMINGS.
$P1 @A TASK CONSISTS OF TWO PARTS, A TASK ENVIRONMENT AND A PROGRAM.
 @THE TASK ENVIRONMENT MAINTAINS A VIRTUAL MACHINE FOR THE RUNNING 
OF THE PROGRAM.
@THE TASK CAN BE IN ONE OF FIVE BASIC STATES:
$A INDENT=1
$V7
$B1 .WAIT $T+2 - THE TASK IS AWAITING AN INTERRUPT.
$B0 .ACTIVE $T+1 - THE TASK IS RUNNING.
$B0 .BLOCKED $T+1 - THE TASK IS HELD ON A SEMAPHORE.
$B0 .PENDING $T+1 - THE TASK IS READY TO RUN AND IS ON A .CPU
$B0 $T+2 $C+2 QUEUE
$B0 .SUSPENDED $T+1 - THE TASK IS PREVENTED FROM CONTINUING 
$B0 $T+2 $C+2 (EG AFTER AN ERROR)
$A INDENT=0
$P1 @THE PROGRAM IS LIMITED IN THE STATE TRANSITIONS IT
CAN EXECUTE TO THOSE FROM THE .ACTIVE STATE TO ONE OF THE OTHERS,
FOR EXAMPLE, TO THE .BLOCKED STATE BY ATTEMPTING TO CLAIM A

BUSY SEMAPHORE, OR THE .WAIT STATE BY ISSUING A SUPERVISOR CALL.
@THE REMAINDER OF THE STATE CHANGES ARE CARRIED OUT BY THE
KERNEL DIRECTLY, EG, .PENDING TO .ACTIVE, OR .BLOCKED TO .PENDING
WHEN A SEMAPHORE BECOMES FREE, OR BY THE TASK ENVIRONMENT, FOR
EXAMPLE, THE NORMAL RESPONSE TO AN INTERRUPT WILL BE TO CHANGE
THE TASK STATE FROM .WAIT TO .PENDING.
@THE CODE THAT INTERFACES THE TASK TO
THE SYSTEM AT THIS LEVEL IS CALLED THE 'TASK MONITOR' AND IT RUNS,
INTERRUPTABLE FROM A HIGHER LEVEL, IN SUPERVISOR MODE ON THE PRIVATE
KERNEL STACK.
@THERE ARE THREE KINDS OF INTERRUPTS WHICH THE 'TASK MONITOR'
PROCESSES:
$I2 1) @HARDWARE GENERATED INTERRUPTS FROM DEVICES
LINKED TO THAT 
$I2 $C+3 TASK.
$I2 2) @KERNEL GENERATED SOFTWARE INTERRUPTS WHEN THE
TASK FAILS.
$I2 3) @SOFTWARE GENERATED INTERRUPTS FROM OTHER TASKS.
$P1 @THE 'TASK FAILURE' INTERRUPTS ARE HANDLED
AT THIS LEVEL TO ALLOW DIFFERENT ACTIONS, DEPENDING
ON THE TYPE OF TASK, TO BE TAKEN, FOR EXAMPLE, IF A
USER PROGRAM TASK FAILS, DIAGNOSTIC INFORMATION ON THE
FAILURE IS HELD ON THE STACK. @A SYSTEM TASK DOES
NOT HAVE THE STACK SPACE TO HOLD THIS INFORMATION.
$P1 @INTERRUPTS ARE VECTORED DIRECTLY TO THE TASK
CONTROLLING THE DEVICE. @TO PROCESS AN INTERRUPT INVOLVES A CONTEXT
SWITCH GIVING AN ABSOLUTE UPPER LIMIT OF 2,700
 INTERRUPTS A SECOND. @WHEN
AN INTERRUPT IS PARICULARLY TIME CRITICAL, OR INTERRUPTS OCCUR AT A RATE
APPROACHING OR EXCEEDING THE LIMIT - THUS USING NEARLY ALL THE AVAILABLE
.CPU - EXTRA CODE IS USED AT THE INTERRUPT LEVEL TO CONSTRUCT A NEW
INTERFACE BETWWEN THE TASK AND THE DEVICE. @A CARD READER IS HANDLED
IN THIS WAY, ON INTERRUPT, THE DATA IS STORED DIRECTLY INTO A BUFFER,
AND THE TASK IS ONLY INTERRUPTED ON A 'CARD DONE' INTERRUPT. @THE SYSTEM
DOES NOT QUEUE INTERRUPTS, FOR SPACE SAVING REASONS. @IT IS
NORMALLY THE PRACTICE FOR ONE TASK TO CONTROL A SINGLE 
DEVICE. @TO
HANDLE MULTIPLE DEVICES, THE TASK WOULD NEED TO QUEUE
THE INTERRUPTS INTERNALLY,
 WHICH WOULD SEEM RATHER WASTEFUL CONSIDERING THAT
THE SYSTEM IS BUILT TO MULTIPROGRAM A LARGE NUMBER OF TASKS, AND
THE MARGINAL COST OF A SECOND TASK, SHARING ITS CODE WITH THE FIRST, IS
SMALL, ABOUT 70 BYTES.
$P1 @THE TWO BASIC COMMUNICATION AND
SYNCHRONISTAION MECHANISMS ARE THE SEMAPHORE (21)
AND A 'SOFTWARE INTERRUPT'.
$P1 @EACH PERIPHERAL HAS A SYSTEM TASK TO CONTROL IT. .I/O
FROM A USER TASK IS PASSED TO THE DEVICE HANDLER THROUGH ONE
OF TWO INTERFACES
DEPENDING
ON WHETHER THE PERIPHERAL  INVOLVED IS A 
FILE ORIENTATED DEVICE OR A SINGLE CHARACTER DEVICE.
$P0
@THE FILE ORIENTATED DEVICE - DISC, DECTAPE - IS BUFFERED A BLOCK
(256 WORDS) AT A TIME AND EACH BLOCK IS HANDLED
INDIVIDUALLY, PROCESSING (OF THE TASK) STOPS UNTIL THE TRANSFER
IS COMPLETED. 
$P0 @A SINGLE CHARACTER DEVICE - TERMINAL, LINE PRINTER,
PAPER TAPE DEVICES ETC - IS HANDLED BY BUFFERING THE CHARACTERS
INTO A CHAIN OF SMALL BUFFERS .(NIBBLES) WHICH ARE LINKED TOGETHER.
@THERE IS A .BUFFER .CONTROL .BLOCK THAT CONTAINS THE NECESSARY
POINTERS INTO THE CHAIN. @THE KERNEL HOLDS A GLOBAL FREE LIST OF THESE
BUFFERS.
@THE USER TASK IS ABLE TO (AT LEAST) DOUBLE BUFFER ITS REQUESTS
BEFORE BEING SUSPENDED ON THE HANDLERS SEMAPHORE.
 @THE USE OF SMALL BUFFERS IS MORE EXPENSIVE IN CODE AND
CERTAINLY MORE EXSPENSIVE IN EXECUTION TIME BUT IN A MINIMAL
CONFIGURATION MACHINE REPRESENTS A CONSIDERABLE SAVING IN
BUFFER SPACE AS THERE IS NO NEED TO HOLD POOLS
OF MAXIMUM LENGTH BUFFERS.
$B2 $L1C
IMPLEMENTATION
$P0 @THE SYSTEM WAS WRITTEN IN .PDP11 ASSEMBLER. @AT THE TIME
THAT THE SYSTEM WAS STARTED THERE WAS NO SUITABLE
HIGH LEVEL LANGUAGE AVAILABLE AND THE AIM WAS TO WRITE A SYSTEM
TO RUN PROGRAMS RATHER THAN WRITE A COMPILER. 
@THE SYSTEM IS CROSS-ASSEMBLED AND IS NOT SELF SUPPORTING.
$P1 @MOST APPLICATIONS PROGRAMS ARE WRITTEN IN A HIGH
LEVEL LANGUAGE .(IMP). @AS THE MACHINES THAT THE SYSTEM RUNS
ON EITHER DO NOT HAVE ENOUGH CORE TO RUN A COMPILER
OR DO NOT HAVE ENOUGH DISC SPACE.
@THE SOURCES ARE HELD ON .EMAS AND COMPILED THERE.
@THE BINARY MAY BE TRANSFERRED TO THE TARGET MACHINE
IN A NUMBER OF WAYS, FOR EXAMPLE, PAPER TAPE, CARDS, OR 
VIA A COMMUNICATIONS LINE IF ONE IS AVAILABLE.
@RECENTLY, A SMALLER COMPILER HAS BECOME AVAILABLE AND THIS WILL
ALLOW SOME OF THE SYSTEMS TO COMPILE AND RUN ON SITE.
$B2 $V4 $L1C
OPERATION
$P0 @THE SYSTEM HAS NOW BEEN IN OPERATION AT THREE
SITES FOR BETWEEN ONE AND TWO YEARS.
@THE THREE CONFIGURATIONS ARE 16K, 24K AND 28K WORDS OF CORE
WITH A WIDE VARIETY OF PERIPHERALS.
@THE SYSTEM HAS ALSO  BEEN USED TO
INTERACTIVELY BENCHMARK THE .EMAS SYSTEM,
SIMULATING 32 TERMINALS,
RUNNING ON A .PDP 11/45 (10).
@OTHER SYSTEMS, ONE WITH ONLY 8K WORDS OF CORE, HAVE BEEN
RUN FROM TIME TO TIME.
$P1 @THE SYSTEM HAS RESPONDED WELL UNDER VARYING SITUATIONS
FROM A FAIRLY FIXED SYSTEM HANDLING ANALOGUE  DEVICES WITH
INTERRUPT RATES OF UP TO 5000 A SECOND TO A 
SYSTEM PROVIDING A CONVERSATIONAL
.RJE TERMINAL HANDLING  A GRAPHIC TERMINAL,
LINE PRINTER AND A GRAPH PLOTTER.
$N 
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 3

DESCRIPTION OF SYSTEM TWO
$B1 $L1C
GOALS
$P0 @THE SECOND SYSTEM WAS DESIGNED FOR OPERATION IN A MEDIUM
SIZED .PDP 11. @AT LEAST 16K WORDS OF CORE, A MEMORY MANAGEMENT UNIT,
A DISC OR SIMILAR FAST MASS STORAGE DEVICE, A TERMINAL AND A CLOCK ARE
REQUIRED.  @A FULLY SELF SUPPORTING SYSTEM REQUIRES 28K WORDS OF CORE
IN ORDER TO SUPPORT THE COMPILER.
$P1 @THE SYSTEM WAS DESIGNED WITH FIVE MAIN AIMS:
$A INDENT=1
$B1
%@RUNNING %USER %PROGRAMS
$P0 @THE SYSTEM IS DESIGNED TO RUN GENERAL USER
PROGRAMS. @NORMALLY,
 ABOUT TWENTY SIMULTANEOUS PROGRAMS SHOULD BE SUPPORTED,
BUT THIS FIGURE SHOULD BE A PARAMETER AT SYSTEM
GENERATION. @EACH PROGRAM
WILL RUN IN ITS OWN VIRTUAL MEMORY ENVIRONMENT .(VM), NOT
NECESSARILY LIMITED TO THE HARDWARE'S MAPPING LIMIT OF 32K WORDS. @THE
SYSTEM, AND OTHER USER PROGRAMS, SHOULD BE FULLY PROTECTED FROM
THE FAILURE OF A USER PROGRAM.
$B1
%@MULTIPLE %TERMINAL %SUPPORT
$P0 @THE SYSTEM SHOULD SUPPORT
MULTIPLE TERMINALS, EACH TERMINAL SHOULD, OPTIONALLY, BE LINKED TO A
COMMAND LANGUAGE INTERPRETER WHICH WILL ENABLE THE USER TO INITIATE AND
CONTROL PROGRAMS FROM THE TERMINAL.
$B1
%@PERIPHERAL %SUPPORT
$P0 @THE SYSTEM SHOULD SUPPORT A WIDE RANGE
OF PERIPHERALS, EG, LINE PRINTER, CARD READER, PAPER TAPE READER AND 
PUNCH, VARIOUS DISCS, MAGNETIC TAPE AND A SYNCHRONOUS COMMUNICATION LINE
RUNNING UNDER 
A NUMBER OF PROTOCOLS.
@IT SHOULD BE POSSIBLE TO ADD NEW PERIPHERALS WITH MINIMUM
DISTURBANCE TO THE SYSTEM.
$B1
%@SWAPPING
$P0 @THE NUMBER AND SIZE OF USER PROGRAMS SHOULD NOT BE LIMITED TO
THE PHYSICAL STORE SIZE OF THE MACHINE, A LIMITED SWAPPING
STRATEGY
SHOULD BE IMPLEMENTED TO SUPPORT A VIRTUAL STORE
SIZE OF TWO TO THREE TIMES THE PHYSICAL STORE SIZE.
$B1 %@MINIMAL %RESIDENT %SECTION
$P0 @THE SIZE OF THE RESIDENT SYSTEM SHOULD BE KEPT SMALL
TO ALLOW AS MUCH STORE AS POSSIBLE FOR USER PROGRAMS.
$A INDENT=0
$B3 $L1C
CONSTRAINTS
$P0 @THE CORE CONSTRAINTS,
WHICH DOMINATED THE FIRST SYSTEM DO NOT DOMINATE
THIS SYSTEM. @THERE ARE TWO MAIN REASONS FOR THIS:
$A INDENT=1
$B0 1) THE TARGET MACHINE IS LARGER THAN THAT FOR THE FIRST SYSTEM
$B0 2) THE SYSTEM IS NOT ENTIRELY CORE RESIDENT.
$A INDENT=0
 @THIS MEANS THAT
DEVICE HANDLERS THAT ARE INACTIVE WILL NOT BE USING VALUABLE CORE,
FOR EXAMPLE,
IT IS FEASABLE TO HAVE A MORE COMPLEX
TERMINAL HANDLER, BECAUSE THOSE THAT ARE INACTIVE WILL BE SWAPPED OUT. @THE
TIME REQUIRED TO SWAP A PROGRAM WILL BE IN THE ORDER OF 
1/5 OF A SECOND, AND 
TO MINIMISE THE AFFECTS ON RESPONSE THE SYSTEM
TASKS WILL
BE ABLE TO LOCK THEMSELVES DOWN
WHILE THEY ARE ACTIVE.
$P1 @IT IS STILL DESIRABLE TO KEEP THE RESIDENT PART OF THE SYSTEM
AS SMALL AS POSSIBLE TO ENABLE THE SYSTEM TO RUN IN SMALLER
CORE CONFIGURATIONS. @THIS CONSTRAINT EFFECTS THE OVERALL DESIGN,
DISTINGUISHING IT FROM  SYSTEMS WITH A LARGE SET OF
FACILITIES LIKE .UNIX AND .RSX11D
WHICH REQUIRE 48K WORDS OF CORE TO DO USEFUL WORK.
$B1 $V10 $L1C
STRUCTURAL OVERVIEW
$P0 @THE DESIGN OF THIS SYSTEM STEMS LARGELY
FROM THE PREVIOUS SYSTEM HOWEVER THE BASIC TASK SYNCHRONISATION
MECHANISM IS NOW A 'MESSAGE', RATHER THAN THE SEMAPHORE OF
THE FIRST STYSTEM.
@THE CONCEPT OF MESSAGES COMES FROM .EMAS, THE .GEC 4080
AND OTHERS.
$P1 @THE USER INTERFACE IS HEAVILY INFLUENCED BY A NUMBER OF MACHINES
RUNNING IN THE @COMPUTER @SCIENCE DEPARTMENT.
$P1 @THE SYSTEM HAS TWO MAIN SECTIONS, A RESIDENT
SECTION AND A POTENTIALLY SWAPPABLE SECTION.
$B1 @THE RESIDENT SECTION CONSISTS OF A KERNEL AND THE
MASS STORAGE DEVICE HANDLER WHICH RUNS AS AN OTHERWISE STANDARD
SYSTEM TASK.
$B1 $V7 @THE KERNEL PROVIDES THE FOLLOWING SERVICES:
$A INDENT=1
$B0 1) @CONTROLS THE .CPU ALLOCATION.
$B0 2) @PASSES INTERRUPTS TO THEIR DEVICE HANDLERS.
$B0 3) @PASSES MESSAGES BETWEEN TASKS, STORING THEM IF NECESSARY.
$B0 4) @SUPPORTS THE VIRTUAL MEMORIES, INCLUDING MAPPING BETWEEN THEM.
$B0 5) @PROVIDES CLOCK AND TIMER FUNCTIONS.
$B0 6) @CONTROLS CORE ALLOCATION CONTROL.
$A INDENT=0
$P1 @ALL PERIPHERALS AND OTHER SYSTEM FUNCTIONS, E. G.,
 THE FILE STORAGE HANDLER,
COMMAND LANGUAGE INTERPRETER AND LOADER - ARE HANDLED BY SYSTEM
TASKS. @THE SYSTEM TASKS ARE 'PRIVILEGED', THIS ENTITLES THEM TO
ACCESS PARTS OF THE REAL MACHINE AND OTHER TASKS.
@A SYSTEM TASK MAY ALSO REQUEST TO BE HELD
IN CORE, AS THE MAIN DISC TASK DOES PERMANENTLY.
$P1 @A NEW TASK IS CREATED WHEN A USER PROGRAM IS RUN AND
IS DELETED ON ITS TERMINATION.
@A TASK CONSISTS OF A VIRTUAL MEMORY ENVIRONMENT AND A 'TASK DESCRIPTOR
BLOCK', HELD WITHIN THE KERNEL. @A TASK 
ON THIS SYSTEM DOES NOT HAVE A 'TASK
MONITOR';
ALL INTERRUPTS AND MESSAGES ARE PROCESSED BY THE TASK IN ITS 'USER'
STATE.
$A INDENT=1
$P1 @THE VIRTUAL MEMORY ENVIRONMENT OF A TASK CONSISTS
OF A NUMBER OF SEGMENTS, THESE SEGMENTS ARE USED TO HOLD
THE PROGRAM CODE, DATA AREAS AND SHARED SYSTEM CODE.
@THE HARDWARE OF THE .PDP11 ALLOWS EIGHT SEGMENTS TO BE MAPPED 
ONTO REAL STORE AT ANY GIVEN TIME, GIVING A VIRTUAL MEMORY ADDRESS
SPACE OF 32K WORDS. @THE NUMBER OF SEGMENTS OWNED BY A TASK IS
NOT LIMITED TO EIGHT, AND A 'SEGMENT STACK' IS USED TO
HOLD THE NON-MAPPED SEGMENTS. @A SEGMENT MAY BE MAPPED IN A READ
ONLY OR A READ/WRITE MODE WHICH ALLOWS PROTECTION OF CODE AREAS.
$P1 @THE 'TASK DESCRIPTOR BLOCK' CONTAINS THE REGISTERS
(WHEN THE TASK IS NOT ACTUALLY EXECUTING) AND OTHER INFORMATION
SUCH AS THE STATE, PRIORITY LEVEL AND MESSAGE QUEUE THAT
CONSTITUTES THE CONTEXT OF THE TASK.
$A INDENT=0

$P1 
@THE LIST OF SEGMENTS USED BY A TASK IS
HELD IN A .GLOBAL .SEGMENT .TABLE WITHIN THE
KERNEL, WITH 
THE CORE OR DISC ADDRESS, ACCESS PERMISSION AND
THE NUMBER OF TASKS USING THE SEGMENT. @THIS TABLE
ENABLES THE KERNEL TO MAINTAIN CONTROL OVER THE
USAGE OF SEGMENTS AND CAN EASILY DETERMINE
WHAT PARTS OF TASKS MAY BE SWAPPED OUT. @THE CORE ADDRESS,
ACCESS PERMISSION AND A POINTER INTO THE GLOBAL
SEGMENT TABLE ARE ALSO MAINTAINED WITHI THE TASK DESCRIPTOR
TO SPEED UP THE CONTEXT SWITCH.
$P1 @IF A TASK FAILS WITH EITHER A HARDWARE FAULT, EG, AN
ADDRESS ERROR OR MEMORY PROTECTION VIOLATION, OR WITH
A FAULT DETECTED BY SOFTWARE, E. G., AN ILLEGAL SUPERVISOR CALL
OR MESSAGE, THE KERNEL GENERATES A MESSAGE TO A 'SYSTEM ERROR
TASK'; TO ALLOW LATER INVESTIGATION
THE FAILED TASK IS PREVENTED FROM CONTINUING.
@THE 'ERROR TASK' INFORMS THE USER
OF THE TASK FAILURE AND THE REASON FOR IT.
@THE 'ERROR TASK' IS ALSO USED BY SOME SYSTEM TASKS TO INFORM THE
OPERATOR ABOUT THE STATE OF DEVICES.
$P1 @ALL COMMUNICATION IN THE SYSTEM IS DONE BY SENDING MESSAGES.
@THESE MESSAGES ARE QUEUED BY THE KERNEL, IF NECESSARY, UNTIL THEY
ARE REQUESTED. @INTERRUPTS ARE HANDLED SIMILARLY, THE KERNEL
GENERATES AND QUEUES A MESSAGE FOR THE APPROPRIATE TASK. @A TABLE

IS USED TO DETERMINE WHICH TASK A MESSAGE (OR INTERRUPT)
IS FOR. @A SUPERVISOR CALL IS PROVIDED TO ENABLE TASKS
TO 'LINK' THENSELVES TO A PARTICULAR MESSAGE NUMBER. @THIS
IS SLIGHTLY LESS EFFICIENT THAN DIRECT OWNERSHIP BUT 
ENABLES DEVICE HANDLERS TO BE CONFIGURED INTO THE SYSTEM DYNAMICALLY.
$P1 @THE ADDRESS OF A DATA AREA MAY BE PASSED BY A MESSAGE.
@THE SEGMENT
CONTAINING THIS AREA MAY THEN BE MAPPED FROM THE CALLERS .VM
TO THE RECEIVERS .VM. @CURRENTLY THIS MECHANISM IS ONLY USED TO
SHARE SEGMENTS, WHICH ARE EVENTUALLY RETURNED TO THE CALLER. @THERE
IS NO RESTRICTION TO STOP SEGMENTS ACTUALLY BEING TRANSFERRED
BY THIS METHOD.
$P1 @INPUT/OUTPUT ON THIS SYSTEM USES A SEPARATE
SEGMENT IN EACH USER'S TASK TO HOLD ITS .I/O BUFFERS. @THIS 
ALLOWS THE KERNEL TO SWAP THE MAJOR PART OF A TASK
WHILEST SLOW .I/O IS IN PROGRESS. @THE SHARING OF SEGMENTS, AS 
DESCRIBED ABOVE, IS USED BY THE DEVICE HANDLERS TO PROCESS THE
BUFFERS, THE SEGMENT BEING RELEASED AND A REPLY SENT ON COMPLETION.
$B1
$V10 $L1C
IMPLEMENTATION
$P0 @THIS SYSTEM WAS WRITTEN IN .IMP. .IMP WAS CHOSEN FOR A
VARIETY OF REASONS:
$A INDENT=1
$I0 1) $T+1 @THE IMPLEMENTER HAS HAD A LONG EXPERIENCE WITH
.IMP, USING IT AS A SYSTEMS PROGRAMMING LANGUAGE ON .EMAS AND
OTHER SYSTEMS.
$I0 2) $T+1 @THERE WAS NO EASY ACCESS TO ANY OF THE OTHER POSSIBLE
LANGUAGES, WITH THE EXCEPTION OF .FORTRAN, WHICH WAS NOT CONSIDERED
TO BE AS GOOD AS .IMP AS A SYSTEMS PROGRAMMING LANGUAGE, EITHER
IN ITS STRUCTURE OR ITS IMPLEMENTATION.
$I0 3) $T+1 @A NEW IMPLEMENTATION OF .IMP WAS AVAILABLE, TO A STANDARD
THAT MADE THE PROJECT POSSIBLE.
$A INDENT=0
$P1 @TWO MODULES OF THE SYSTEM HAVE BEEN WRITTEN IN ASSEMBLER. @THE FIRST
MODULE IS AT THE LOWEST LEVEL OF THE SYSTEM, LOADING UP THE REGISTERS
ON CONTEXT SWITCHING. @SINCE THERE ARE NO EXPLICIT REGISTER
MANIPULATIONS IN .IMP, IT FORCED THIS MODULE TO BE IN ASSEMBLER.
@THE SECOND ASSEMBLER MODULE PROVIDES THE RUN TIME SUPPORT FOR .IMP
PROGRAMS. @THIS MODULE COULD PROBABLY BE CONVERTED TO .IMP LATER,
BUT WAS WRITTEN IN ASSEMBLER FOR BOOTSTRAPPING REASONS. @FORTUNATELY,
THESE TWO SECTIONS ARE CHANGED INFREQUENTLY AS THEY HAVE PROVED TO BE A
DISPROPORTIONATE SOURCE OF PROBLEMS IN RELATION TO THEIR SIZE.
$P1 @THE REST OF THE SYSTEM CONSISTS OF SIX .IMP MODULES, COMPRISING
THE KERNEL AND THE SYSTEM TASKS. @THESE MODULES ARE COMPILED SEPARATELY
AND THEN 'LINKED' BY A PURPOSE BUILT LINKER WHICH ALSO SETS UP
THE BOOTSTRAPPING AREA.
$P1 @APPLICATION PROGRAMS, WITH THE EXCEPTION OF THE EDITOR - WHICH
WAS BROUGHT FROM THE PREVIOUS SYSTEM - HAVE BEEN WRITTEN IN .IMP. @THE
SOURCES ARE HELD AND COMPILED ON THE SYSTEM.
$B2
$V10 $L1C
OPERATION
$P0 @THIS SYSTEM HAS BEEN IN OPERATIONAL USE ON TWO MACHINES
SINCE @MAY 1976, AND IS OCCASIONALLY USED ON A THIRD MACHINE
FOR A SPECIAL PROJECT,
THE INTERACTIVE BENCHMARKING OF AN .ICL 2970.
 @AT THIS STAGE SWOPPING
AND THE USE OF MORE THAN EIGHT SEGMENTS,
HAS STILL
TO BE IMPLEMENTED, THOUGH MOST OF THE NECESSARY KERNEL
FEATURES ARE ALREADY PRESENT. @THE MULTIPLE TERMINAL SUPPORT
HAS NOT BEEN TRIED, OWING TO A LACK OF HARDWARE.
$P1 @IT IS STILL TOO EARLY AT THIS STAGE TO
EVALUATE THIS SYSTEM PROPERLY,
 BUT IT IS CURRENTLY BEING USED BY
SEVEN OTHER PEOPLE, IN WIDELY DIFFERING WAYS AND IS PROVING
SATISFACTORY.
$N 
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 4

A QUALITATIVE COMPARISON
$P2 @A DIRECT COMPARISON BETWEEN THE TWO SYSTEMS
IS DIFFICULT FOR THREE REASONS.
$A INDENT=2
$I1 1) $T+1 @THE SECOND SYSTEM WAS DESIGNED TO RUN ON A MORE
COMPLEX MACHINE THAN THE FIRST SYSTEM.
$I1 2) $T+1 @THE IMPLEMENTER WAS MORE 
COMPETANT IN IMPLEMENTING THE SECOND SYSTEM,
ALTHOUGH, OF COURSE, NEW MISTAKES WERE MADE.
$I1 3) $T+1  @THE SECOND SYSTEM SUPPORTS A FAR MORE
COMPREHENSIVE USER INTERFACE.
$A INDENT=0
$P1 @IF ALLOWANCES ARE MADE FOR THE EXTRA COMPLEXITY OF THE
SECOND SYSTEM, COMPARISONS CAN BE MADE UNDER THE FOLLOWING 
HEADINGS:-
$A INDENT=1
$B1
1) @APPROPRIATENESS OF .IMP AS A SYSTEM PROGRAMMING LANGUAGE

$B0 $T+1 @A) @STRUCTURE OF .IMP, IN PARTICULAR THE ROUTINE STRUCTURE
$B0 $T+1 @B) @APPROPRIATENESS OF THE DATA STRUCTURES AND THE
$B0 $T+1 $C+4  OPERATORS ON THEM
$B0 $T+1 @C) @APPROPRIATENESS OF .IMP AS IMPLEMENTED
$B1 2) @IMPLEMENTATION CONSIDERATIONS
$B0 $T+1 @A) @INITIAL IMPLEMENTATION
$B0 $T+1 @B) @FAULTS
$B0 $T+1 @C) @EXTENSIONS
$B1 3) @PHYSICAL CONSIDERATIONS
$B0 $T+1 @A) @SYSTEM SIZE
$B0 $T+1 @B) @SYSTEM SPEED
$B1 4) @INTERFACING COSTS
$A INDENT=0
$B2
$L1C
1) APPROPRIATENESS OF IMP AS A SYSTEMS PROGRAMMING LANGUAGE.
$P1 .IMP HAS SHOWN ITSELF TO BE AN APPROPRIATE LANGUAGE
FOR SYSTEM IMPLEMENTATION
IN LARGE SYSTEM ENVIRONMENTS. @ALL OF THE SOFTWARE OF THE
.EMAS SYSTEM FOR THE .ICL 4/75 IS WRITTEN IN .IMP, AS ARE THE COMPILERS.
@HOWEVER IT DOES NOT FOLLOW THAT .IMP IS EQUALLY GOOD
FOR SYSTEM IMPLEMENTATION ON SMALL MACHINES, IN PARTICULAR
THE .DEC .PDP 11.
@TO JUDGE HOW USEFUL A LANGUAGE IS ON A PARTICULAR MACHINE 
IT IS NECESSARY TO LOOK AT THE SEMANTICS OF THE LANGUAGE
 AND THE ARCHITECTURE OF THE MACHINE.
@A LANGUAGE WHICH CLOSELY MATCHES THE ARCHITECTURE OF ONE MACHINE
MAY NOT FIT
WELL INTO A MACHINE WITH A DIFFERENT ARCHITECTURE. @AN
EXAMPLE OF THIS
IS A LANGUAGE DESIGNED FOR A MULTI REGISTER MACHINE,
UNLIKELY TO BE EFFICIENTLY IMPLEMENTABLE ON A SINGLE
REGISTER MACINE -
VIZ A LANGUAGE WHICH ALLOWED EXPLICIT
USE OF THE MACHINE REGISTERS.
.IMP IS A GENERAL PURPOSE 
LANGUAGE AND ALTHOUGH ITS FACILITIES 
ARE CONSTRAINED BY WHAT HAS
BEEN EFFICIENT TO IMPLEMENT ON THE 4/75,
DESPITE THIS CONSTRAINT IT DOES NOT CONTAIN
MANY FEATURES THAT ARE DEPENDANT ON THE 4/75. @THIS HAS BEEN SHOWN
BY ITS IMPLEMENTATION ON A RANGE OF MACHINES, .PDP 9,15,10,8,
@INTERDATA AND THE @NOVA.
$A INDENT=1
$B1 $L1C
     A) STRUCTURE OF THE LANGUAGE, IN PARTICULAR ITS ROUTINE STRUCTURE.
$P1 @A GREAT PART OF THE CLARITY WHICH CAN BE ACHIEVED WHEN WRITING IN
.IMP IS ATTRIBUTABLE TO ITS
OVERALL STRUCTURE.
@IT IS EASY FOR  THE PROGRAMMER TO STRUCTURE HIS PROGRAM, SPLITTING
IT INTO SECTIONS AND ROUTINES. @THESE ROUTINES 
HAVE A CLEARLY DEFINED ENTRY POINT.
@THE ENTRY TO AN .IMP ROUTINE SETS UP A NEW ENVIRONMENT IN WHICH
THERE ARE THREE TYPES OF VARIABLES:-
$I3 1) @PARAMETERS.
$I3 2) @LOCAL VARIABLES.
$I3 3) @GLOBAL VARIABLES.
$B0 @THE PARAMETERS TO THE ROUTINE ARE CLEARLY DEFINED, USUALLY
MAKING IT UNNECESSARY TO REFER BACK TO THE CALL OF THE ROUTINE
TO UNDERSTAND THE FUNCTION OF THE ROUTINE. @THE LOCAL VARIABLES,
PRESENT ON THE STACK ONLY DURING THE EXECUTION OF THE ROUTINE,
ISOLATES THE ROUTINE FROM OTHER SECTIONS OF CODE
AND SAVES STACK SPACE.
@FOR COMPLETE CLARITY IT WOULD BE PREFERABLE IF THE GLOBAL VARIABLES
WERE ALSO DEFINED IN THE BODY OF THE ROUTINE, .IMP
DOES NOT DO THIS, WHICH FORCES THE PROGRAMMER TO SEARCH AROUND
OTHER PARTS OF THE PROGRAM TO DETERMINE THE TYPE AND OTHER FEATURES
 OF A
GLOBAL VARIABLE, OR, OF COURSE, SUPPLY
ADEQUATE COMMENTS IN THE SOURCE.
$P1 @A RESULT MAY HAVE TO BE PASSED BACK FROM A ROUTINE
BUT FREQUENTLY A VECTOR OR RECORD RESULT IS REQUIRED,
FOR EXAMPLE, A VALUE AND AN ASSOCIATED FLAG
IS NEEDED. .IMP SATISFIES THE FIRST CASE, 
A .'$%FUNCTION' IS DEFINED, WHICH 
RETURNS A SINGLE RESULT. .IMP DOES NOT ALLOW MULTIPLE
RESULTS TO BE RETURNED, SO THE PROGRAMMER IS FORCED TO USE A GLOBAL
VARIABLE, OR PASS AN ADDITIONAL .'$%NAME' TYPE PARAMETER TO
THE ROUTINE, THIS BEING LESS EFFICIENT THAN THE EQUIVALENT CONSTRUCT
IN ASSEMBLER, WHICH WOULD RETURN THE RESULTS IN TWO REGISTERS.
$P1
@A OPERATING SYSTEM DOES NOT
USUALLY REQUIRE
ROUTINES OF GREAT COMPLEXITY, A 'SIMPLE' SINGLE LEVEL
NON-RECURSIVE ROUTINE STRUCTURE BEING QUITE SUFFICIENT.
@THE .IMP ROUTINE STRUCTURE IS VERY POWERFUL, AS IT ALLOWS RECURSION
AND MULTIPLE LEXICAL DEPTH. @THE CONSEQUENCE
OF THIS IS THAT 
ON SOME MACHINES
IT IS EXPENSIVE TO ENTER AND EXIT, AS FOR EXAMPLE ON THE .PDP11, WHERE
 THE STACK MUST BE CAREFULLY
INCREASED TO ALLOW FOR THE LOCAL NAME SPACE AND
PARAMETERS, AND DECREASED AGAIN ON EXIT, THIS
IS ESPECIALLY CRITICAL AS THE HARDWARE ALSO USES THE STACK AND
MAY AT ANY TIME TEMPORARILY PLANT WORDS ON THE TOP.
@THE EFFECT OF THIS CAN BE SEEN IN THE KERNEL WHERE THERE WAS A GREAT
RELUCTANCE TO PUT ANY ROUTINES INTO THE
THE TIME CRITICAL AREAS, THUS 
EVENTUALLY ONLY THREE ROUTINES WERE
USED. 
@THE ENTRY AND EXIT SEQUENCE HAS SINCE BEEN 
PARTIALLY OPTIMISED AND
THE ENTRY IS SEVEN WORDS AND THE EXIT IS
FOUR WORDS ALL OF WHICH ARE PLACED IN LINE. @SINCE THIS WAS INTRODUCED,
THE KERNEL HAS BEEN SLIGHTLY REWRITTEN AND ROUTINES USED A LITTLE MORE.
@IN OTHER MODULES A MUCH HEAVIER USE HAS BEEN MADE OF 
ROUTINES. @THE RESIDUAL OVERHEAD, HOWEVER, IS STILL APPRECIABLE AND
FURTHER REDUCTIONS WOULD BE WELCOME
BUT WOULD APPEAR TO REQUIRE THE ADDITION OF 
 AN EXTRA PASS TO THE COMPILER.
$P1 @IN THIS INSTANCE, .CORAL IS PREFERABLE TO .IMP,
FOR SYSTEMS PROGRAMMING AT LEAST, BECAUSE ROUTINES ARE ASSUMED
NON-RECURSIVE UNLESS THE COMPILER IS INFORMED OTHERWISE. @THIS,
COUPLED WITH THE STATIC STACK, SHOULD ALLOW FASTER ROUTINE ENTRY/EXIT.
$P1 @WHEN WRITING
IN ASSEMBLER, THE 'JUMP TO SUBROUTINE'
INSTRUCTION IS SIMPLE AND CHEAP. 
@THE PRESSURE TO OPTIMISE THE CODE  LEADS TO ASSEMBLER
ROUTINES 
IN WHICH THERE IS NO DEFINABLE
BEGINNING OR END, MERELY VARIOUS ENTRY AND EXIT POINTS.
@THESE SAME PRESSURES LEAD TO THE USE OF
 GLOBAL VARIABLES ONLY, 
USUALLY COUPLED WITH A  DANGEROUS USE OF REGISTERS.
@THIS LEADS TO A VERY HEAVY USE OF 'ROUTINES', MANY
WITH JUST ONE OR TWO LINES OF CODE, AND WHOLE SECTIONS OF
CODE ARE JUST A SERIES OF REGISTER MANIPULATIONS AND
SUBROUTINE JUMPS.
$B2
$L1C
     B) APPROPRIATENESS OF THE DATA STRUCTURES AND THE OPERATORS ON THEM
$P0 @THE SYSTEMS PROGRAMMER WANTS TO BE ABLE
TO CREATE DATA STRUCTURES THAT ARE SIMPLE TO USE, BUT 
WHICH REFLECT
ACCURATELY WHAT HE IS TRYING TO DO. @A HIERARCHICAL STRUCTURE IS
PROBABLY MOST SUITABLE AS IT WILL ALLOW DIFFERENT COMPONENTS OF
THE SYSTEM TO OPERATE ON SEPERATE PARTS OF THE STRUCTURE. @FOR
EXAMPLE, A MESSAGE WHICH IS GOING TO BE TRANSMITTED INTO A
COMMUNICATIONS NETWORK WILL NORMALLY HAVE A HIERARCHICAL
STRUCTURE, THE ACTUAL DATA AT THE CENTRE, EMBEDDED IN,
POSSIBLY SEVERAL, LAYERS OF PROTOCOL. @THERE WILL
BE SEVERAL SECTIONS OF CODE EACH PROCESSING ONLY
A PART OF THE STRUCTURE AND DOING ONLY MINIMAL
OPERATIONS ON OTHER PARTS. @FOR COMPLETE CLARITY
IT SEEMS BENIFICIAL TO HAVE ONE GLOBAL DEFINITION OF
THE STRUCTURE, EACH SECTION THEN HAVING AN EXPANDED
DEFINITION OF ITS OWN PART.
$P1 .IMP GOES PART WAY TOWARDS THIS GOAL AS IT IS POSSIBLE
TO GROUP COLLECTIONS OF DATA OBJECTS, EG, INTEGERS, BYTES,
STRINGS, ARRAYS AND POINTERS INTO A SET CALLED A .'$%RECORD'.
@IT ONLY PARTLY SATISFIES THE REQUIREMENT BECAUSE THE
POSSIBLE OPERATIONS ON 'RECORDS' ARE VERY LIMITED.
 @THE
DEFINITION OF .IMP ONLY ALLOWS 'RECORDS' TO BE 
ASSIGNED, EITHER TO ONE ANOTHER OR A CONSTANT.
 @THE
LACK OF FURTHER OPERATIONS, FOR EXAMPLE A PROPERLY
DEFINED  'COMPARE' AND OTHER BIT MANIPULATIONS,
LEAD TO INEFFICIENCES IN THE CODE. 
@THE NEED FOR THESE EXTENSIONS CAN BE SEEN
IN THE FILE STORAGE HANDLER WHERE THE NAME OF A FILE IS
CONTAINED IN A SIX ELEMENT BYTE ARRAY. @AT TIMES
THIS MUST BE PROCESSED BYTE BY BYTE BUT AT OTHER
TIMES IT IS MUCH BETTER TO CONSIDER IT AS ONE
ENTITY, EG, WHEN COMPARING IT TO ANOTHER NAME.
@WITHOUT THE ABILITY TO DEFINE A 'RECORD COMPARE' IN .IMP
IT MUST BE DONE IN A ROUNDABOUT WAY THE RESULT BEING
FAR LESS EFFICIENT CODE.
$P1 @THE .'TABLE' FEATURE OF .CORAL IS SOMEWHAT DIFFERENT
AND THE AUTHOR FEELS, HAVING HAD EXPERIENCE OF BOTH, THAT THE .IMP
.'RECORDS' ARE BOTH MORE POWERFUL AND EASIER
FOR ANOTHER PROGRAMMER ATTEMPTING TO UNDERSTAND. @THE LACK OF
SUCH FACILITIES IN BOTH .FORTRAN AND .ALGOL60 REDUCES THEIR
USEFULLNESS.
$P1 @THE .PDP11 HARDWARE CONTAINS OPERATORS THAT
THE COMPILER WRITER FINDS GREAT DIFFICULTY IN USING.
@THESE ARE THE AUTO INCREMENT AND AUTO DECREMENT OPERATORS
THAT ASSEMBLER PROGRAMMERS TEND TO MAKE HEAVY USE OF. @THE
DEFINITION OF OPERATIONS ON COMPLEX DATA STRUCTURES WOUULD
GIVE MUCH MORE SCOPE FOR THESE OPERATORS TO BE USED.
@AN ALTERNATIVE WAY WOULD BE TO INCLUDE THESE OPERATORS
DIRECTLY IN THE LANGUAGE. @THERE ARE TWO PROBLEMS
WITH THIS. @FIRSTLY, THEIR USE WOULD NOT
BE EFFICIENTLY TRANSFERRABLE TO MANY OTHER MACHINES, THUS
INCLUDING AN ESSENTIALLY MACHINE-DEPENDANT FEATURE INTO THE
LANGUAGE. @SECONDLY, IT WOULD INCREASE THE COMPLEXITY
OF THE CODING, MAKING THE UNDERSTANDING OF IT THAT MUCH MORE
DIFFICULT.
$P1 @IN ASSEMBLER THE BUILDING BLOCKS ARE SIMPLY INTEGERS 
AND BYTES, CONSEQUENTLY THE PROGRAMMER CAN CREATE ANY DATA STRUCTURE
THAT HE CHOOSES, AND CAN USE IT VERY EFFICIENTLY USING THE AUTO
INCREMENT AND DECREMENT INSTRUCTIONS MENTIONED ABOVE. @HOWEVER,
THE HEAVY USE OF THESE OPERATORS WILL  
PRODUCE CODE THAT IS ABSOLUTELY DEPENDANT ON THE INDIVIDUAL 
POSITIONS OF THE VARIABLES WITHIN THE DATA STRUCTURE.
$B2 $L1C
     C) ADEQUACY OF THE IMPLEMENTATION OF IMP
$P0
@THE QUESTION IS RAISED AS TO WHETHER
THIS IMPLEMENTATION OF .IMP IS OF A HIGH ENOUGH STANDARD,
OR ARE WE JUST COMPARING THE QUALITY OF THIS IMPLENTATION
TO WRITING A SYSTEM IN ASSEMBLER?
@IF THE OUTPUT FROM THE .IMP COMPILER
IS CAREFULLY EXAMINED, IN PARTICULAR IN A COMPARISON
WITH AN EQUIVALENT ASSEBLER SECTION - AS IS DONE IN THE
NEXT CHAPTER - THEN IT IS FOUND THAT THE COMPILER ITSELF IS
IS PRODUCING AS TIGHT CODE AS CAN BE EXPECTED
FROM ANY HIGH LEVEL LANGUAGE AND
ANY LARGE IMPROVEMENTS WOULD IMPLY LANGUAGE
CHANGES.
$B2 $L3C
2) IMPLEMENTATION CONSIDERATIONS

     A) INITIAL IMPLEMENTATION
$P0 @THE FIRST SYSTEM WAS DEVELOPED OVER A PERIOD OF THREE YEARS OF PART TIME
WORK. @THE SECOND SYSTEM WAS IMPLEMENTED IN
 FOUR MONTHS OF CONCENTRATED WORK. @ALTHOUGH
COMPARISONS ARE DIFFICULT THE INDICATIONS ARE A 
FACTOR OF THREE OR FOUR TO ONE
IN FAVOUR OF THE SECOND SYSTEM.
@THE SPEED WITH WHICH THE SECOND 
SYSTEM WAS WRITTEN  MANIFESTS ITSELF TO A CERTAIN EXTENT IN 
SOME ROUGH
EDGES.
@SOME FUTHER EFFORT WILL BE REQUIRED TO ACHIEVE
THE SAME STANDARD AS WAS ACHIEVED ON THE ASSEMBLER SYSTEM.
$P1 @EVEN WITH THESE QUALIFICATIONS
THE SYSTEM IN .IMP INVOLVED FAR
LESS EFFORT THAN THE SYSTEM IN ASSEMBLER.
@THE AUTHOR HAS BEEN ABLE TO IDENTIFY SEVERAL REASONS FOR THIS.
@FIRST, THE TOOLS USED. @THE ASSEMBLER SYSTEM WAS 
INITIALLY WRITTEN AND ASSEMBLED USING THE .DEC OPERATING 
SYSTEM .DOS FOR ABOUT A YEAR, IT WAS THEN TRANSFERRED TO .EMAS
WHERE IT HAS REMAINED. @THE NATURE OF ITS STRUCTURE AND
LANGUAGE MEANS THAT WHENEVER IT IS CHANGED, APART FROM TRULY
TRIVIAL CHANGES, A NEW LISTING HAS TO BE OBTAINED TO KEEP TRACK
OF ADDRESSES. @THIS INVOLVES A PRINTER LISTING OF SOME 4,800
LINES, WHICH USUALLY TAKES A LONG TIME.  @THE BINARY
IS THEN PUNCHED ON PAPER TAPE WHICH IS TAKEN TO THE TARGET
MACHINE AND TESTED. @IF THAT VERSION FAILS THEN A RETURN
TO .EMAS IS USUALLY NECESSARY.
@IT SHOULD BE POSSIBLE, BY WORKING ON THE ASSEMBLER (
ESPECIALLY IN THA AREA OF SYMBOL TABLE SIZE)
 TO ASSEMBLE ON THE SYSTEM ITSELF. 
@THE PROBLEM OF UP-TO-DATE LISTINGS WOULD BECOME EVEN MORE ACUTE.
$P1 @THE SYSTEM IN .IMP, IN COMPARISON, IS SELF SUPPORTING AND IS
CONTAINED IN SMALL PARTS, THE LARGEST BEING 600 .IMP
STATEMENTS. @TO COMPILE THIS SECTION TAKES TWO AND A HALF MINUTES.
@LISTINGS ARE NO PROBLEM BECAUSE
THEY ARE SMALL AND TAKE AT MOST TWENTY MINUTES ON A
30 CHARACTERS PER SECOND TERMINAL, AND ALSO BECAUSE IT IS NOT
ESSENTIAL IN A HIGH LEVEL LANGUAGE TO HAVE A COMPLETELY
UP TO DATE LISTING OF THE MODULE. @IT IS SOMETIMES NECESSARY HOWEVER
TO DECOMPILE THE COMPILER CODE TO CHECK IT FOR FAULTS, BUT THIS IS
USUALLY DONE TO A DISC FILE AND THEN EXAMINED IN PARTS
USING THE EDITOR.
$P1 @THE SECOND REASON WHY THE FIRST SYSTEM INVOLVED MORE
EFFORT CAN BE SEEN BY  THE EASE WITH WHICH CODE WAS WRITTEN.
@IT IS ALWAYS EASIER TO USE A LANGUAGE THAT MATCHES THE
LEVEL AT WHICH THE PROGRAMMER IS THINKING. @THE IMPLEMENTER
HAS FOUND THAT .IMP REFLECTS WHAT HE IS THINKING
MORE CLOSELY. @FOR EXAMPLE, TAKE THE ROUTINE OPERATION
OF TESTING A VARIABLE AND MAKING A DECISION. 
@IN ASSEMBLER THIS INVOLVES TWO SEPERATE STATEMENTS, THE
COMPARISON, FOLLOWED BY A 'BRANCH ON CONDITION'. @THE
.IMP SOLUTION IS ONE STATEMENT, IN THE FORM .'$%IF',
CLOSER TO THE WAY OF THINKING.
$B2 $L1C
     B) FAULTS
$P0 @A FAULT APPEARS IN ONE OF TWO WAYS, IT
IS EITHER VERY DRAMATIC IN THE FORM OF A SYSTEM CRASH, OR IT IS
INSIDIOUS, WITH NO HARD EVIDENCE TO PIN IT DOWN.
$P1 @BY FAR THE MORE DIFFICULT TYPE OF FAULT TO FIND
IS THE SECOND TYPE. @THIS TYPE HAS TENDED TO BE MORE FREQUENT IN THE FIRST SYSTEM,
ONE SUCH FAULT HAVING TAKEN
 A WEEK OF HARD WORK TO UNCOVER THE FAULT  WAS CAUSED
BY THE USE OF A VARIABLE IN A COMPLEX DATA STRUCTURE
THAT DIDN'T IN FACT EXIST IN ONE CASE, AND THIS RESULTED IN
THE OVERWRITING OF THE FOLLOWING VARIABLES.
@THE NEAREST EQUIVALENT OF THIS TYPE OF FAULT ON THE SECOND 
SYSTEM WAS A SITUATION WHERE THE SYSTEM RAN CORRECTLY
FOR A PERIOD OF TIME, THEN SUDDENLY APPEARED TO RUN OUT
OF CORE. @THE FAULT WAS FOUND FAIRLY RAPIDLY BY CAREFULL
MONITORING OF CORE USE.
@THREE IDENTIFIABLE REASONS WHY THIS TYPE OF FAULT OCCURS MORE
FREQUENTLY IN THE FIRST SYTEM ARE:
$A INDENT=2
$P0 @THERE IS FAR LESS OF THE SECOND
SYSTEM, SO THERE IS LESS LIKELYHOOD OF ERROR.
$P1 @THE 'RECORD' STRUCTURE IN .IMP PROTECTS THE PROGRAMMER
FROM SOME OF THE OVERWRITING FAULTS.
$P1 @THE HARDWARE PROTECTION GIVEN BY THE MEMORY
MANAGEMENT UNIT ENABLES THE PROGRAMMER TO SHIFT SOME
FAULTS FROM THE SECOND CATEGORY INTO AN IMMEDIATE SYSTEM
CRASH. @UNFORTUNANTLY THIS PROTECTION
IS STILL LIMITED, ESPECIALLY WHEN RUNNING IN KERNAL MODE.
$A INDENT=1
$P1
@THE 'SYSTEM CRASH' TYPE OF FAULT IS FAR MORE FREQUENT, IT IS
ALSO EASIER TO IDENTIFY. @THIS TYPE OF FAULT OCCURED FREQUENTLY
IN BOTH SYSTEMS. @THE NATURE OF AN ASSEMBLER PROGRAM, WITH ITS
SYMBOL TABLE,MAKES LOOKING THROUGH DUMPS EASIER THAN WITH A
DUMP FROM AN .IMP PROGRAM. @IN THE .IMP PROGRAM IT TAKES
EXPERIENCE TO CALCULATE WHERE THE COMPILER HAS ALLOCATED 
THE VARIABLES. @EITHER WAY IT IS STILL A TIME CONSUMING PROCESS
TO EXAMINE DUMPS AND IT HAS BEEN FOUND VERY WORTH WHILE, IN
BOTH SYSTEMS, TO WRITE A DUMP ANALYSIS PROGRAM THAT INTERPRETS AT
LEAST PART OF THE DUMP. @THESE PROGRAMS HAVE MEANT THAT
THERE IS LITTLE DIFFERENCE BETWEEN THE TWO SYSTEMS IN THIS
RESPECT.
$P1 @NORMALLY, THE PROGRAMMER WOULD EXPECT THAT A PROGRAM WRITTEN
IN .IMP WOULD GIVE A TRACE BACK AND THE VALUES OF THE VARIABLES
WHEN IT FAILS, BUT THIS IS NOT AVAILABLE YET ON THE .PDP 11.
@ALTHOUGH THIS FACILITY WOULD HELP ENORMOUSLY WITH APPLICATION PROGRAMS,
EXPERIENCE HAS SHOWN, ON .EMAS AT LEAST, THAT IT
IS OF LIMITED VALUE WHEN IT COMES TO SUPERVISORS.
$P1 @AFTER A CRASH THERE IS USUALLY MORE INFORMATION AVAILABLE
IN THE SYSTEM IN .IMP AS VARIABLES ARE HELD IN STORE, RATHER
THAN IN VOLATILE GENERAL REGISTERS. @FOR EXAMPLE, IN SITUATIONS
WHERE CORE IS DISAPPEARING, THE DETAILS OF THE LAST TRANSACTION
ARE ALWAYS AVAILABLE IN THE SYSTEM IN .IMP IN THE VARIABLES
THAT ARE USED IN CORE MANIPULATION. @THE ASSEMBLER SYSTEM,
HOWEVER, USES THE GENERAL REGISTERS AND ALL INFORMATION
IS LOST ON EXIT FROM THE KERNEL.
$P1 @IN GENERAL A SECTION OF CODE
WILL HAVE THREE MAIN CLASSES OF ERROR.
$A INDENT=2
1) @TYPING FAULTS.
$B0 2) @'SIMPLE' LOGICAL ERRORS.
$B0 3) @DESIGN FAULT.
$B1 %@TYPING %FAULT
$P0 @A TYPING FAULT IS NORMALLY SHOWN UP BEST BY THE
STRICT SYNTAX OF THE COMPILER, WHEREAS THE VERY FLEXIBLE FORMS
OF STATEMENT USED IN ASSEMBLER MEANS THAT VIRTUALLY ANYTHING
WILL PRODUCE SOME CODE.
$B1 %'SIMPLE' %LOGICAL %FAULT
$P0
 @A 'SIMPLE' LOGICAL FAULT, FOR EXAMPLE
THE SUBSTITUTION OF ONE VARIABLE FOR ANOTHER, PROBABLY HAPPENS
WITH EQUAL FREQUENCY IN BOTH THE HIGH AND LOW LEVEL
LANGUAGES, BUT AS THERE ARE MANY MORE ASSEMBLER
STATEMENTS THAN .IMP STATEMENTS, MORE WILL OCCUR IN A GIVEN PIECE
OF CODE. @A MORE SERIOUS EXAMPLE OF THIS TYPE OF
ERROR OCCURS IN CONDITIONS;
IN ASSEMBLER, EVEN THE SIMPLEST CONDITION REQUIRES
TWO SEPARATE STATEMENTS, ONE TO SET A CONDITION CODE
AND THE SECOND TO DETERMINE THE BRANCH FROM THE
CONDITION CODE, WHILST A COMPLEX CONDITION WHICH
STILL REQUIRES ONLY ONE .IMP STATEMENT COULD
REQUIRE THIRTY OR FOURTY ASSEMBLER STATEMENTS,
GIVING MORE SCOPE FOR FAULTS TO ARISE.
$B1 %@DESIGN %FAULT
$P0 @THE SYSTEM DESIGN TYPE OF FAULT IS EQUALLY LIKELY
IN BOTH TYPES OF SYSTEM, BUT IT CAN BE MUCH EASIER
TO RECTIFY IN THE SECOND SYSTEM. @TAKE, FOR
EXAMPLE, THE ADDITION (OR REMOVAL) OF NEW VARIABLES
FROM A COLLECTION OF VARIABLES.
@IN .IMP THIS COLLECTION OF VARIABLES WOULD BE GROUPED
TOGETHER INTO A COMPLEX DATA STRUCTURE. @ALL ACCESSES
TO THE VARIABLES ARE MADE IN RESPECT OF THAT DATA
STRUCTURE, SO THE ADDITION OF NEW ELEMENTS SIMPLY
REQUIRES A REDEFINITION OF THE STRUCTURE, A ONE LINE
CHANGE. @IN ASSEMBLER, EVEN WHERE CARE HAS BEEN TAKEN 
TO DEFINE A DATA STRUCTURE BY DEFINITIONS AT THE BEGINNING,
SO THAT A CHANGE SHOULD ONLY MEAN THE ALTERING OF A LIST
OF DISPLACEMENTS, THE ACTUAL EFFECTS USUALLY SPREAD
THROUGHOUT THE PROGRAM. @THIS IS BECAUSE USE HAS BEEN MADE
OF THE MORE EFFICIENT FORMS OF ACCESS TO VARIABLES
BY USING REGISTERS AS POINTERS, PERHAPS
INTO THE CENTRE OF THIS STRUCTURE.
@USE OF THESE FACILITIES MAKE THE INITIAL
DISPLACEMTS USELESS.
$A INDENT=1
$P3 @WHEN A FAULT IS ISOLATED IT MUST BE CURED. @WITH
THE ASSEMBLER LEVEL SUPERVISOR THERE IS A TEMPTATION
TO ATTEMPT BINARY PATCHES, 
 WHICH ALMOST INEVITABLY
LEADS TO INCONSISTENT SYSTEMS ON DIFFERENT MACHINES AND
WITHOUT A LOT OF CARE THE PATCH IS FORGOTTEN,
WITH THE RESULT THAT AFTER THE NEXT CHANGE IS MADE TO THE SYSTEM
ONE REPEATS THE STEPS TO FIND THE PREVIOUS FAULT.
@BINARY PATCHING IS SEVERAL TIMES MORE COMPLEX IN THE
SECOND SYSTEM  AND WOULD NORMALLY REQUIRE DECOMPILING
OF THE CODE, THUS PROBABLY TAKING AS
LONG AS A RECOMPILATION OF THE SOURCE.
$B2 $V4 $L1C
     ADDITIONS
$P0 @PRACTICE HAS SHOWN THAT IT IS MUCH
EASIER TO ADD NEW SYSTEM COMPONENTS TO THE SECOND
SYSTEM. @THIS HAS BEEN SHOWN IN BOTH 
SMALL AND MAJOR PARTS OF THE SYSTEM.
@A HANDLER FOR MULTIPLE TELETYPE MULTIPLEXORS .(DH11) WAS WRITTEN
AND TESTED IN A PERIOD OF TWO DAYS 
ON THE SYSTEM IN .IMP.
@THIS HANDLER WAS USED, NOT TO PROVIDE
ACCESS FROM TERMINALS TO THE MACHINE, BUT TO 
SIMULATE THE EFFECT OF TERMINALS ON 
A MAINFRAME.  @THE EQUIVALENT ON THE ASSEMBLER SYSTEM,
THOUGH USING A SYNCHRONOUS COMMUNICATIONS LINE
RUNNING UNDER A SIMPLE PROTOCOL TOOK THREE WEEKS TO
WRITE AND TEST. @PART OF THIS DIFFERENCE CAN
CERTAINLY BE EXPLAINED BY THE SIMPLER OVERALL
STRUCTURE OF THE SYSTEM IN .IMP, WHERE  MESSAGES
ARE USED, AS AGAINST THE MORE COMPLEX SEMAPHORE
STRUCTURE OF THE ASSEMBLER SYSTEM.
$P1
@A LINE PRINTER HANDLER PROVIDES AN EXAMPLE
OF A SMALL ADDITION TO THE SYSTEM.
@THE SYSTEM IN .IMP VERSION
TOOK
A PERIOD OF ONE HOUR, INCLUDING THE TIME TO
THINK, WRITE AND TYPE THE CODE. @ON THE
OTHER HAND, THE ADDITION OF A SIMILAR HANDLER ON THE ASSEMBLER 
SYSTEM USUALLY TOOK THREE OR FOUR RETRIES, REQUIRING
IN TOTAL THREE OR FOUR HOURS OF SYSTEM TIME,
EXCLUDING THE THINKING TIME REQUIRED AND THE EXTRA TYPING
TIME, PROBABLY  A FACTOR OF THREE OR FOUR TIMES.
@AN EXPLANATION OF THE DIFFERENCES LIES WITHIN THE
STRUCTURE, OF LACK OF IT, OF THE LANGUAGES. @THIS HAS
ALREADY BEEN DISCUSSED
BUT AN ADDITIONAL POINT ARISES. @SINCE, IN ASSEMBLER, A ROUTINE
IS VERY CHEAP TO CALL, 
A SECTION OF CODE IS OFTEN CALLED, IN
SLIGHTLY DIFFERENT WAYS, FROM A NUMBER OF PLACES.
@A SLIGHT CHANGE CAN BE MADE TO THE CODE, WITHOUT REALISING
THE EFFECTS ELSEWHERE.
$P1 @WHEN AN ADDITION IS MADE TO A SYSTEM, THERE
WILL USUALLY BE FAULTS IN IT, THE CONSIDERATIONS OF THE LAST
SECTION APPLY TO THIS, PARTLY EXPLAINING WHY 
IT IS EASIER TO ADD TO THE SECOND SYSTEM.
$B4 $V6 $L3C
PHYSICAL CONSIDERATIONS

     A) SYSTEM SIZE
$P0 @THE SECOND SYSTEM IS CURRENTLY 72$% LARGER THAN ITS ASSEMBLER
COUNTERPART; THIS DIFFERENCE IS REFLECTED 
IN 74$% EXTRA CODE AND 68$% EXTRA STACK REQUIREMENTS.
@ALTHOUGH THIS SEEMS A VERY LARGE DIFFERENCE, IN ACTUAL
SPACE IT IS LESS THAN 4K WORDS.
@THE FIRST SYSTEM OCCUPIES OVER 4K WORDS AND
THE SECOND SYSTEM ABOUT 8K WORDS.
 @THE DETAILED SIZES
ARE INVESTIGATED IN THE FOLLOWING CHAPTER.
$A INDENT=2
$B1 %@COMPETANCE %OF %THE %CODING
$P0 @IT IS EQUALLY EASY TO WRITE BAD CODE IN BOTH
A HIGH LEVEL LANGUAGE OR ASSEMBLER.
@PARTS OF THE SYSTEM
IN ASSEMBLER HAVE NOW BEEN REWRITTEN SEVERAL TIMES, THEIR SIZE NOW
REFLECTS THE  BETTER CODING.
@THE SECOND SYSTEM IS STILL VERY NEW, MOST MODULES HAVE NOT
BEEN SERIOUSLY EXAMINED SINCE THEIR INITIAL IMPLEMENTATION.
 @HOWEVER, AFTER
SEEING THE SIZES OF, IN PARTICULAR, THE DISC HANDLER AND THE DISC
DIRECTORY HANDLER, AN ATTEMPT WAS MADE TO REDUCE THEM.
$P1 @THE DISC HANDLER WAS REDUCED BY ALMOST 150 BYTES OR
OVER 20$%. @THE %TOTAL EFFORT INVOLVED WAS ONE HOUR, INCLUDING
TESTING TIME. @THE DISC DIRECTORY HANDLER WAS
REDUCED BY ALMOST 300 BYTES OR 15$%. @THIS WAS ACHIEVED BY
RECONSIDERING THE DATA STRUCTURE AND DEFINING IT IN A DIFFERENT 
WAY TO SIMPLIFY THE OPERATIONS ON IT. @IT TOOK HALF AN HOUR,
BUT THERE IS CERTAINLY MORE SCOPE FOR REDUCING THE OVERALL
SIZE OF THAT MODULE FURTHER.
$A INDENT=1
$P1 @THE SIZES OF THE SECOND SYSTEM ARE NOT AT ALL CONSTANT, NOT
BECAUSE THE CODE IS BEING CHANGED, BUT BECAUSE THE COMPILER
IS. @SINCE THE SYSTEM WAS STARTED SEVERAL VERSIONS OF THE
COMPILER HAVE BEEN USED AND QUITE CONSIDERABLE SAVINGS HAVE BEEN
ACHIEVED IN THE SIZE. @THIS UNDERLINES ANOTHER FACTOR IN FAVOUR
OF USING A HIGH LEVEL LANGUAGE, VIZ, IF THE CODE PRODUCED IS TOO BIG
OR FOR THAT MATTER TOO SLOW, THEN CHANGES CAN BE MADE TO THE COMPILER
WITHOUT DISRUPTING THE LOGIC OF THE SYSTEM.
@THE ROUTINE ENTRY/EXIT MECHANISM PROVIDES A GOOD EXAMPLE OF THIS.
@THE NEXT RELEASE OF THE COMPILER WILL HAVE A MUCH FASTER ROUTINE
ENTRY IMPLEMENTED FOR ROUTINES THAT IT CAN ESTABLISH ARE NON-RECURSIVE
AND OTHERWISE WELL BEHAVED. @THIS MODIFICATION WILL REDUCE THE
OVERHEAD DOWN FROMM 22.5 MICRO SECONDS TO 
THE ASSEMBLER FIGURE OF 12 MICRO SECONDS FOR A ROUTINE WITHOUT
PARAMETERS, EXTRA TIME WILL BE REQUIRED FOR PARAMETERS.
$B2 $V6 $L1C
     B) SYSTEM SPEED
$P0
@THE CONTEXT SWITCH TIME ON THE SECOND SYSTEM IS 70 MICRO
SECONDS SLOWER THAN THE FIRST SYSTEM. @THIS DIFFERENCE IS DUE TO
THE MEMORY MANAGEMENT REGISTERS WHICH TAKE THE SECOND SYSTEM 103
MICRO SECONDS TO LOAD UP. @THE OTHERWISE BASIC SIMILARITY IN TIMING
IS NOT SURPRISING AS BOTH CODE SECTIONS ARE IN ASSEMBLER AND CARRY
OUT SIMILAR FUNCTIONS.
$P1 @THE BASIC KERNEL FUNCTIONS IN THE SECOND SYSTEM ARE BETWEEN
70$% AND 80$% SLOWER THAN THE FIRST SYSTEM. @TAKE FOR
EXAMPLE THE ROUTINE WHICH INSERTS A TASK ONTO ONE OF THE
.CPU QUEUES. @THE STRUCTURE OF THE ROUTINE IS SIMILAR IN BOTH THE
SYSTEMS, IT CALLS A SECOND ROUTINE  WHICH IS A GENERALISED ROUTINE
FOR INSERTING ITEMS ON QUEUES, ALTHOUGH THE QUEUEING
STRATEGY IS DIFFERENT. @THE FIRST SYSTEM TAKES 64 MICRO
SECONDS ON THE LONGEST PATH, THE SECOND SYSTEM TAKES 110 MICRO
SECONDS.
@THIS IS A INCREASE OF 72$%, A FIGURE VERY COMPARABLE TO
THE DIFFERENCE IN THE CODE SIZES. @IT IS INTERESTING TO NOTE
THAT THE TOTAL
ROUTINE ENTRY/EXIT OVERHEADS IN THE FIRST SYSTEM
ARE 12 MICRO SECONDS AND 45 MICRO SECONDS FOR THE SECOND SYSTEM.
@OTHER DETAILED FIGURES ARE GIVEN IN CHAPTER FIVE.
$P1 @THERE ARE SOME BASIC DIFFERENCES BETWEEN THE
TWO SYSTEMS THAT EFFECT THE OVERALL SYSTEM OVERHEADS.
$A INDENT=2
$B1 $I1 1) $T+1 @ON ENTRY TO THE FIRST SYSTEM, CARE IS TAKEN
NOT TO USE MORE REGISTERS THAN ARE ABSOLUTELY NECESSARY
UNTIL IT IS CERTAIN THAT A CONTEXT SWITCH WILL BE NECESSARY.
@FOR EXAMPLE, ON CLAIMING A NON-BUSY SEMAPHORE, ONE REGISTER
IS NEEDED BY THE KERNEL TO SWITCH ON THE TYPE OF CALL, BUT ON
INSPECTION OF THE SEMAPHORE, THE RETURN TO THE USER CONSISTS
SIMPLY OF RESTORING THAT ONE REGISTER AND RETURNING.
$P1 @WHEN THE SECOND SYSTEM IS ENTERED, ALL THE REGISTERS NEED
TO BE SAVED BECAUSE THE PROGRAMMER NO LONGER HAS ABSOLUTE CONTROL
OVER THE USE OF  THE REGISTERS IN THE .IMP SECTION. @FOR
A 'SIMPLE' CALL ON THE KERNEL THIS IS A SIGNIFICANT OVERHEAD.
$B1 $I1 2) $T+1 @A FASTER INTERFACE 
FOR .I/O FROM .IMP PROGRAMS HAS BEEN USED IN THE SECOND SYSTEM. @THIS
HAS BEEN POSSIBLE FOR TWO REASONS. @FIRST, THE .IMP INTERFACE
IS NECESSARY FOR THE SYSTEM ITSELF, THEREFORE IT HAS BEEN DESIGNED
IN WITH THE SYSTEM INSTEAD OF BEING ADDED LATER. @SECONDLY,
THE MEMORY MANAGEMENT UNIT HAS ENABLED A MORE EFFICIENT INTERFACE.
@THE EFFECTS OF THIS IS THAT THE OUTPUT OF A SINGLE
CHARACTER TO A DISC BUFFER IS 27 MICRO SECONDS IN THE SECOND
SYSTEM IN COMPARISON TO 85 MICRO SECONDS IN THE
FIRST SYSTEM.
$A INDENT=1
$P1 @THE OVERALL EFFECT OF THESE FACTORS
IS THAT USER PROGRAMS, THAT ARE NOT .CPU BOUND, ACTUALLY RUN FASTER
ON THE SECOND SYSTEM.
$A INDENT=0
$B4 $L1C
4) INTERFACING COSTS
$P0 @THE SEVERE CORE RESTRAINTS APPLIED TO THE FIRST SYSTEM
HAS SHOWN IN THE USER INTERFACE, WHICH IS, IN GENERAL, 
CLUMSIER TO USE THAN THE INTERFACE IN THE SYSTEM IN .IMP. @THIS
DIFFERENCE HAS OF COURSE ALSO SHOWN ITSELF IN THE RELATIVE
SIZES OF THE TWO SYSTEMS. @TO A CERTAIN EXTENT HOWEVER, IT IS
A FUNCTION OF WRITING IN THE TWO DIFFERENT LANGUAGES. @IT
HAS PROVED EASIER AND LESS TROUBLE PRONE TO ADD IN 
.IMP THE FEATURES
WHICH MAKE THE SYSTEM EASIER TO USE.
@IN ASSEMBLER, THERE IS ALWAYS A TENDENCY TO LOOK AT THE
EVER GROWING SIZE AND REFUSE TO ADD A FEATURE THAT HAS ONLY
A MINOR EFFECT APPARENTLY, BUT IS VERY EXPENSIVE IN CODE.
$N 
$A TAB=5, 10,15,20
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 5

A QUANTITATIVE COMPARISON
$B1 $L1C
SYSTEM SIZE
$P0 @TABLE 5.1 BELOW GIVES THE COMPARATIVE SIZES, IN BYTES,
OF THE BASIC PARTS
OF THE TWO SYSTEMS.
$A INDENT=1
$N
$B1 $L1CM
TABLE 5.1   COMPARATIVE CORE REQUIREMENTS (BYTES)
$B0 $L1
----------------------------------------------------------------
$B0 .MODULE .NAME $C28 .FIRST .SYSTEM $C47 .SECOND .SYSTEM
$B0  $C26 .CODE $C36.DATA $C46 .CODE $C56 .DATA
$L1
----------------------------------------------------------------
$B0 @KERNEL $C26 1732 $C36 1559 $C46 2538 $C56 2678
$B0 @HARDWARE INTERFACE $C27 212 $C47 230
$B0 @DISC HANDLER $C27 248 $C38 64 $C47 488 $C57 126
$B0 @FILE HANDLER $C27 656 $C36 1070 $C46     1460 $C56 1174
$B0 @LOADER       $C27 672 $C37 120 $C46 2112 $C57 544
$B0 .C$.L$.I$.  $C27 898 $C38 92 $C46 1398 $C55 (1)
$B0 .TERMINAL $C15 @INPUT $C27 328 $C38 74
$B0           $C15 @OUTPUT $C27 248 $C38 68
$B0           $C15 .TOTAL $C27 576 $C37 142 $C46 1520 $C57 344
$B0 .IMP TASK SUPPORT $C27 280
$B0 @MOTHER TASK $C47 606 $C57 258
$B0 .I/O ROUTINES ETC $C26 1472 $C46 1538
$B0 $L1C
----------------------------------------------------------------
$B0 .TOTALS $C26 6848 $C36 3047 $C45 11890 $C55 5122
$B0 '$%' INCREASE $C46 +74$% $C55 +68$%
$B0 .OVERALL TOTAL $C30 9895 $C50 17012
$B0 '$%' INCREASE $C51 +72$%
$B0 $L1C
----------------------------------------------------------------
@NOTE 1. @THE DATA AREAS OF THE @LOADER AND .CLI ARE CURRENTLY
COMBINED.
$A INDENT=0
$N
$P1 @THE REASONS FOR THE SIZE DIFFERENCES ARE VERY VARIED,
SO EACH MODULE WILL BE EXAMIND INDEPENDANTLY, WITH
GENERAL NOTES ON THEIR SIZE.
$P1 @THE ACTUAL RUNNING SIZE OF THE SECOND SYSTEM IS LARGER
AS THE MEMORY MANAGEMENT FORCES ALIGNMENT OF ALL SECTIONS
ON A 32 WORD BOUNDARY.
$A INDENT=1
$B1 %@KERNEL
$A INDENT=2
$B0 %@CODE
$P0 @A DIRECT COMPARISON IS VERY DIFFICULT IN THE KERNEL
BECAUSE OF THEIR DIFFERENT FUNCTIONS.
@THE SIZE OF THE FIRST KERNEL REFLECTS SOME FUNCTIONS, LIKE
THE INSERTION AND REMOVAL OF CHARACTERS FROM SMALL .I/O
BUFFERS THAT ARE CARRIED OUT ELSEWHERE IN THE SECOND SYSTEM. @THE
.IMP KERNEL HAS A CONSIDERABLE AMOUNT OF CODE 
(ABOUT 12.5$%)
THAT
SUPPORTS THE VIRTUAL MEMORIES.
$B1
%@DATA
$P0 @THE DATA SIZES OF THE TWO KERNELS ARE EQUALLY DIFFICULT TO
COMPARE, VARIOUS DATA SECTIONS HAVE BEEN MOVED, OR
WERE NOT NECESSARY IN THE OTHER KERNEL, FOR EXAMPLE,
THE DATA SIZE OF THE FIRST KERNEL INCLUDES 800 BYTES FOR
THE POOL OF SMALL .I/O BUFFERS, WHEREAS THE SECOND KERNEL
INCLUDES 500 BYTES FOR SYSTEM TASK DESCRIPTORS, 250 BYTES FOR
MESSAGE BUFFERS AND 200 BYTES FOR THE .GLOBAL .SEGMENT .TABLE.
$B1 $I1 %@HARDWARE %INTERFACE
$P0 @THESE SIZES ARE COMPARABLE AS THEY ARE BOTH IN ASSEMBLER
AND PERFORM SIMILAR FUNCTIONS.
$B1 $V5 $I1 %@DISC %HANDLER
$B0 %CODE
$P0 @AS THIS MODULE CARRIES OUT A SIMILAR FUNCTION
IN BOTH SYSTEMS ONE WOULD EXPECT THE SIZE TO BE COMPARABLE. 
@HOWEVER ON CAREFUL ANALYSIS OF THE SECOND SYSTEM,
ONE FINDS TWO ELEMENTS OF THE SECOND HANDLER THAT
ARE NOT PRESENT IN THE OTHER ONE - VIRTUAL MEMORY MAPPING AND
EXTENSIONS TO USE A SECOND DISC DRIVE. @THE .VM MAPPING
TAKES 122 BYTES  AND THE EXTENSIONS 78 BYTES. @THIS LEAVES THE
TOTAL AT 288 BYTES, A FIGURE MUCH CLOSER TO THE FIRST SYSTEM. @ONE
CLEAR AREA WHERE WORDS ARE LOST IS IN THE LOADING OF THE
DISC HARDWARE REGISTERS, BECAUSE 
THE ASSEMBLER MODULE USES THE AUTO INCREMENT
INSTRUCTIONS, WHERE THE .IMP VERSION USES A MORE EXPENSIVE FORM.
$B1 %@DATA
$P0 @THE EXTRA DATA REQUIREMENTS CAN BE EXPLAINED BY THE FACTS THAT:-
$A INDENT=3
$I2 1) $T+1 EACH .IMP PROGRAM HAS A FIXED DATA OVERHEAD 
OF 60 BYTES/
FOR
LINKAGE AND CHECKING
$I2 2) $T+1 LOCAL VARIABLES ARE USED IN THE SECOND SYSTEM
THAT ARE HELD IN REGISTERS IN THE FIRST SYSTEM.
$A INDENT=2
$B1 $I1 %@FILE %HANDLER %(DIRECTORY %TASK)
$B0 %@CODE
$P0 @THIS
MODULE SHOWS THE EXTENT TO WHICH A SECTION OF CODE
VERY TIGHTLY CODED IN ASSEMBLER, WITH ALMOST NO LOCAL VARIABLES EXEPT 
THOSE HELD IN REGISTERS, COMPARES IN SIZE TO AN EQUIVALENT SECTION IN .IMP.
@THIS IS EXCELENTLY ILLUSTRATED BY A SCRUTINY OF THE NUMBER OF
WORDS USED PER ASSEMBLER INSTRUCTION (A REGISTER/REGISTER OPERATION
USES ONE WORD, A SINGLE BASE AND DISPLACEMENT TWO WORDS AND
A DOUBLE BASE AND DISPLACEMENT THREE WORDS).
@THE FOLLOWING TABLE SUMMARISES THE RESULTS.
$V6
$B1
$L1CM
TABLE 5.2  FILE HANDLER CODE SIZES
$L1
---------------------------------------------------------------------
$B0
$C32 .INSTRUCTIONS $C50  .WORDS $C59 .AVERAGE
$B0 .ASSEMBLER $C37 245 $C51 333 $C60 1.36
$B0 .IMP       $C37 417 $C51 730 $C60 1.75
$B0 $L1
---------------------------------------------------------------------
@AS CAN BE SEEN FROM THE TABLE, PROGRAMMING IN ASSEMBLER
CAN CREATE MUCH TIGHTER CODE. @HOWEVER THAT IS NOT
THE FULL STORY. @THE FILE HANDLER, LIKE THE
DISC HANDLER, HAS THE FOLLOWING ADDITIONS:
$A INDENT=3
$B1 $I2 1) $T+1 .VM SUPPORT. @IT IS NECESSARY
TO MAP THE PARAMETERS FROM THE CALLERS .VM TO THE
FILE SUPPORT .VM. @THIS COSTS 130 BYTES.
$I2 2) @EXTENSIONS. @THERE ARE THREE EXTENSIONS
TO THE CODE:
$A INDENT=3
$B0 A) $T+1 @SUPPORT FOR A SECOND DISC DRIVE: $C61 120 BYTES
$B0 B) $T+1 @AN EXTRA CALL TO RENAME TEMPORARY FILES: $C62 84 BYTES
$B0 C) $T+1 @ADDITIONAL FILE SECURITY: $C62 30 BYTES
$A INDENT=2
$P1 @THIS IS A TOTAL OF 364 BYTES, GIVING REVISED COMPARATIVE
FIGURES FOR ASSEMBLER, 656 BYTES; FOR .IMP, 1096 BYTES. @THESE FIGURES
ARE MUCH CLOSER AND ON INSTRUCTION COUNT TERMS YIELDS A FIGURE
FOR ASSEMBLER OF 245 INSTRUCTIONS AND FOR .IMP OF 313 INSTRUCTIONS.
$P1 @TO GIVE A CONCRETE EXAMPLE, A ROUTINE, WHICH IS FAIRLY TYPICAL
HAS BEEN DIRECTLY COMPARED IN ITS .IMP FORM TO THE
ASSEMBLER FORM. @THE ROUTINE IS .'EXAMINE' WHICH SEARCHES A FILE
DIRECTORY FOR A PARTICULAR FILE NAME.
$A INDENT=3
$B1 $V23 $L1CM
TABLE 5.3  USE OF INSTRUCTIONS IN THE ROUTINE 'EXAMINE'
$L1
---------------------------------------------------------------------
$B0 $C40 .IMP $C45 (EXTRAS) $C60 .ASSEMBLER
$B0 @ENTRY SEQUENCE $C42 7 $C62 1
$B0 @DISC UNIT CALCULATION $C48 15 (1)
$B0 @FILE SYSTEM NUMBER $C41 10 $C62 7
$B0 @FILE SYSTEM 0 CYCLE. $C42 5 $C62 8
$B0 @BLOCK LOADED CHECK $C48 20 $C62 2 (2)
$B0 @FILE CYCLE $C41 10 $C61 14
$B0 @NAME COMPARISON $C41 23 (3) $C62 9
$B0 @MISCELLANEOUS $C42 4 $C62 1
$B0 .$%RESULT $C42 6 $C62 5
$B0 @USER ENTRY SEQUENCE $C41 13 $C48 3 $C62 2
$B1 .TOTALS $C41 78 $C48 38 $C61 44
$B0 @INSTRUCTIONS $C41 47 $C61 35
$B0 $I2 .NOTES:
$I2 1. $T+1 @THIS REFERS TO ADDITIONS TO THE .IMP CODE THAT
CALCULATES THE DISC UNIT NUMBER.
$I2 2. $T+1 @IN THE ASSEMBLER MODULE, THIS SECTION OF THE
CODE IS DONE ELSEWHERE.
$I2 3. $T+1 @THE LATEST VERSION OF THE COMPILER HAS
REDUCED THIS FIGURE TO 9 BYTES.
$B0 $L1
---------------------------------------------------------------------
$A INDENT=2
$B1 @THE ACTUAL CODING OF THE TWO ROUTINES IS GIVEN BELOW.
$A NLS=1
$V20
$L2CM
TABLE 5.4  ROUTINE 'EXAMINE' AS CODED IN ASSEMBLER

$L1
--------------------------------------------------------------------
$A UND=0
$L0C

NUMBER OF WORDS         INSTRUCTION         COMMENT

---------------------------------------------------------------------
     ; SVC EXAMINE(HEADER)
 2   EXAM1:  JSR     R4,USAVES        ; SAVE USER REGISTERS
     ;       ALSO CLAIMS THE SEMAPHORE TO ENSURE NON-REENTRANT
     ;       AND SETS PRIORITY TO 3 (HIGHEST USER PRIORITY)
     
     EXAMINE:                            ; (R0=HEADER, NEXT=R0)
     ;ON EXIT 
     ;       R4=POS
     ;       R0=0 IF NO FILE
     ;       R2 --> CODE
     ;
 1           MOV     R0,-(SP)            ;  SAVE POINTER TO HEADER ON STACK
 2           MOVB    1(R0),R0            ; GET FSYS NUMBER
 1           BGE     EXCY                ; USE DEFAULT FILESYS NO.
 2           MOVB    FILSYS(PSP),R0      ; GET IT FROM PSECT
 2   EXCY:   ADD     #DIRBLK,R0          ; AS AN INCREMENT ON DIRBLK 
     
 2           CLR     CODE                ; WILL HOLD THE FILE PROTECT CODE
     ;
     ;       LOAD(NEXT)
     EXCY0:                              ; LOOP FOR MULTIPLE DIR. BLOCKS
 2           JSR     PC,LOAD             ; LOAD THE BLOCK IN R0
 2           MOV     #4,R4
 2           ADD     WRM,R4              ; R4 -> START OF ACTUAL BLOCK
 2           MOV     #63,R3              ; NUMBER OF FILES IN BLOCK
     EXCY1:                              ; CHECK EACH FILE NAME
     
     ;  COMPARE THE NAME IN THE DIRECTORY BLOCK
     ;   POINTED AT BY R4 TO THE NEW NAME POINTED AT 
     ;    BY THE TOP OF THE STACK
 1           MOV     (SP),R1             ; RESCUE NEW FILE NAME
 1           TST     (R1)+
 1           MOV     R4,R2
 1           CMP     (R1)+,(R2)+
 1           BNE     EX2
 1           CMP     (R1)+,(R2)+
 1           BNE     EX2
 1           CMP     (R1)+,(R2)+
 1           BNE     EX2
     
     ; MATCHED FILE NAME, SO EXIT
     
 1           MOV     (R2)+,R0           ; GET FIRST BLOCK
 1   EXRT:   TST     (SP)+              ; POP PARAMETER
 1           RTS     PC                 ; AND RETURN
     EX2:            
 2          INC     CODE                ; FILE COUNT
 2          ADD     #12,R4              ; STEP TO NEXT DESCRIPTOR
 1          DEC     R3                  ; BOTTOM OF DISC BLOCK?
 1          BGT     EXCY1               ; NO, SO TEST NEXT
 2          MOV     WRM,R0              ; CURRENT DIRECTORY BUFFER
 2          MOV     2(R0),R0            ; CURRENT BLOCK NUMBER
 1          INC     R0                  ; LOOK AT NEXT
 2          CMP     #DIREND,R0          ; END OF DIRECTORY?
 1          BGE     EXCY0               ; NO
    ;
 1  EXRT1:  CLR     R0                  ;(NOTE CREATE USES THIS LABEL)
 1          CLR     R4                  ; CREATE USES THIS TO DETERMINE 
                                       ; THAT DIR ISNT FULL
 1          BR      EXRT                ; AND RETURN TO USER
    ;  END OF SVC EXAMINE

$N
$L2CM
TABLE 5.5  ROUTINE 'EXAMINE' AS CODED IN IMP

$L0C
---------------------------------------------------------------------

NUMBER OF WORDS           STATEMENT             COMPILER OUTPUT

--------------------------------------------------------------------

            - FIRST THE RECORD DEFINITIONS
     53        %RECORDFORMAT N1F(%BYTEINTEGERARRAY NAME(0:5))
     54        %RECORDFORMAT N2F(%INTEGER A,B,C)
     56       %RECORDFORMAT FILEF(%RECORD (N1F) N, %INTEGER FIRST, PR)
     61       %RECORDFORMAT INFF(%BYTEINTEGER UNIT, FSYS, %RECORD (N1F) N)
     62       %RECORDFORMAT INF2F(%BYTEINTEGER UNIT, FSYS, %RECORD (N2F) N)


    101  
            - THE RECORD 'INF' CONTAINS THE FILE DESCRIPTOR
            - PASSED IN BY THE CALLING PROGRAM
    102       %RECORD (FILEF) %MAP EXAM(%RECORD (INFF) %NAME INF)
 1                                                   MOV   R0, -(LNB)
 1                                                   MOV   LNB, -(SP)
 1                                                   MOV   SP, LNB
 2                                                   MOV   LNB, 2(LNB)
 2                                                   ADD   #-20, SP
    103          %INTEGER N,J,K,HIT, NORD
    104          %RECORD (FILE2F) %NAME F
    105          %RECORD (INF2F) %NAME INF2
            - FOR EFFICIENCY, THE USER RECORD HAS TWO FORMATS
            - 1) A BYTE INTEGER ARRAY OF 6 ELEMENTS
            - 2) THREE INTEGER ELEMENTS A, B AND C
    106          INF2 == INF;    ! MAP 'INF' INTO FORMAT OF 3 INTEGERS
 2                                                   MOV   4(LNB), -20(LNB)
            - THE ELEMENT 'INF_UNIT' CONTAINS THE DRIVE NUMBER
            - AS 'INF' AND 'INF2' ARE MAPPED TO THE SAME SPACE, EITHER 
            - CAN BE USED
    107          %IF INF2_UNIT#0 %THEN DRIVE=UNIT1
 2                                                   MOV   -20(LNB), R0
 1                                                   TSTB  (R0)
 1                                                   BEQ   340
 1                                                   MOV   (GLA), R1
 3                                                   MOV   #20000, -66(R1)
            - 'DIRBLK' IS A CONSTANT, IT IS THE START OF THE DIRECTORY AREA
    108          N=DIRBLK+INF_FSYS
 2                                                   MOV   4(LNB), R1
 2                                                   MOVB  1(R1), R2
 2                                                   BIC   #-400, R2
 2                                                   ADD   #150, R2
 2                                                   MOV   R2, -4(LNB)
    109          %UNTIL N>=DIRBLK+3 %CYCLE;    ! USE 3 BLOCKS AT BOTTOM
 1                                                   BR    376
 2                                                   CMP   #153, -4(LNB)
 1                                                   BLE   614
    110          NORD = N!DRIVE
 2                                                   MOV   -4(LNB), R0
 1                                                   MOV   (GLA), R1
 2                                                   BIS   -66(R1), R0
 2                                                   MOV   R0, -14(LNB)
            - THIS SECTION IS DONE IN 'LOAD' IN THE ASSEMBLER VERSION
            - IT CHECKS TO SEE IF THE DESIRED BLOCK IS IN CORE
            - IF NOT, IT FREES A BLOCK AND READS IT IN
    111          %IF D SAVE#NORD %START
 2                                                   CMP   60(GLA), R0
 1                                                   BEQ   464
    112             %IF DWRM#0 %THEN WRITE D
 2                                                   MOV   64(GLA), R2
 1                                                   BEQ   434
 2                                                   JSR   R0, -272
    113             D SAVE=NORD
 3                                                   MOV   -14(LNB), 60(GLA)
    114             DA(N, X_X, DREAD)
 2                                                   MOV   -4(LNB), -(SP)
 1                                                   MOV   (GLA), R0
 2                                                   MOV   -36(R0), R1
 1                                                   MOV   R1, -(SP)
 1                                                   CLR   -(SP)
 2                                                   JSR   R0, -442
    115          %FINISH
            - THERE ARE 51 FILE ENTRIES IN EACH DIRECTORY BLOCK
    116          %CYCLE J=0, 1, 50
 3                                                   MOV   #-1, -6(LNB)
 3                                                   CMP   -6(LNB), #62
 1                                                   BEQ   606
 2                                                   INC   -6(LNB)
            - SAME AS 'CODE' ABOVE, IT IS THE FILE POSITION (GLOBAL)
    117             FNO = J
 1                                                   MOV   (GLA), R0
 3                                                   MOV   -6(LNB), -72(R0)
            - 'F' POINTS TO AN ENTRY IN THE DIRECTORY ARRAY
    118             F == FA(J)
 2                                                   MOV   -6(LNB), R1
 2                                                   MUL   R1, #12
 1                                                   ADD   GLA, R1
 2                                                   ADD   #100, R1
 2                                                   MOV   R1, -16(LNB)
            - COMPARES THE NAMES, AN INTEGER AT A TIME
    119             %IF F_N_A=INF2_N_A %AND F_N_B=INF2_N_B %ANDC
 2                                                   MOV   -20(LNB), R2
 2                                                   CMP   2(R2), (R1)
 1                                                   BNE   604
 3                                                   CMP   4(R2), 2(R1)
 1                                                   BNE   604
 3                                                   CMP   6(R2), 4(R1)
 1                                                   BNE   604
 1                                                   MOV   LNB, SP
 1                                                   MOV   (SP)+, LNB
 2                                                   ADD   #4, SP
 1                                                   MOV   (LNB)+, PC
    120               F_N_C=INF2_N_C %THEN %RESULT == F
    121          %REPEAT
 1                                                   BR    472
    122          N=N+1
 2                                                   INC   -4(LNB)
    123          %REPEAT
 1                                                   BR    366
            - A FAILURE RETURN
    124          %RESULT == NULL
 1                                                   CLR   R1
 1                                                   BR    572
    125       %END
    126  
    168  
            - WHEN A REQUEST IS RECEIVED FROM ANOTHER PROGRAM
            - THE DESIRED SERVICE IS DETERMINED, 
            - AND THE RELEVENT SECTION IS ENTERED BY THE SWITCH 'REQUEST'

    169  REQUEST(EXAMINE):         ! P_A2 CONTAINS ADDRESS OF DESC
    170          F==EXAM(INF)
 2                                                   MOV   -40(LNB), -(SP)
 2                                                   JSR   R0, -1044
 2                                                   MOV   R1, -32(LNB)
    171          %IF F==NULL %THEN NO=0 %ELSE NO=F_FIRST!DRIVE
 1                                                   BNE   1354
 2                                                   CLR   -52(LNB)
 1                                                   BR    1370
 2                                                   MOV   6(R1), R0
 2                                                   BIS   -66(LNB), R0
 2                                                   MOV   R0, -52(LNB)

            - THIS IS COMMON TO ALL THE CALLS, THE FINAL 'RETURN'
            - IN THE ASSEMBLER VERSION ENTERS A SIMILAR SECTION OF CODE.
    172  REPLY:  WRITE D %IF DWRM#0
 2                                                   MOV   64(GLA), R0
 1                                                   BEQ   1402
 2                                                   JSR   R0, -1240
    173          WRITE B %IF BWRM#0;   ! UNTIL CLOCK IS GOING OK
 2                                                   MOV   66(GLA), R0
 1                                                   BEQ   1414
 2                                                   JSR   R0, -1174
    174          MAP VIRT(0, -1, MYSEG)
 1                                                   CLR   -(SP)
 2                                                   MOV   #-1, -(SP)
 2                                                   MOV   #4, -(SP)
 2                                                   MOV   46(GLA), R1
 1                                                   JSR   GLA, @(R1)+
    175          PX_A1=NO
 3                                                   MOV   -52(LNB), -26(LNB)
    176          PON(PX)
 2                                                   MOV   #-30, -(SP)
 1                                                   ADD   LNB, (SP)
 2                                                   MOV   40(GLA), R1
 1                                                   JSR   GLA, @(R1)+
    177          %CONTINUE
 1                                                   BR    1132

---------------------------------------------------------------------
$B1
$V10
$A NLS=2
$B1 @THE TOTALS INDICATE THAT .IMP IS 77$% LARGER. @HOWEVER THE
INSTRUCTION COUNTS ARE MUCH CLOSER, ESPECIALLY WHEN THE 9
INSTRUCTIONS FOR ROUTINE ENTRY AND EXIT ARE TAKEN INTO
CONSIDERATION.
$B1 %@DATA
$P0 @THE BULK OF THE DATA IN BOTH CASES 
IS MADE UP OF THE TWO DISC BUFFERS USED BY THE CODE.
@THE SLIGHTLY LARGER SIZE OF THE .IMP VERSION AGAIN REFLECTS THE
FIXED .IMP OVERHEAD.
$B1 $I1 %@LOADER
$P0 @THE LOADER ON THE FIRST SYSTEM IS VERY BASIC, AS IT
LOADS THE CODE DIRECTLY INTO CORE AND THEN INITIATES THE
TASK. @THE SECOND SYSTEM HAS TO LOAD INTO A VIRTUAL MEMORY,
CHECKING THAT EACH SEGMENT IS WITHIN ITS BOUNDARIES.
$B1 $I1 %@COMMAND %@LANGUAGE %@INTERPRETER
$P0 @THE SIZE OF THE .IMP VERSION DOES NOT APPEAR TO BE
MUCH LARGER, THIS BEING PARTLY DUE TO FEATURES IN
THE FIRST SYSTEM THAT ARE IN THE LOADER IN THE SECOND SYSTEM.
@THE SECOND SYSTEM VERSION IS LARGER IN COMPARISON BECAUSE OF THE 
TIDIER USER INTERFACE.
$B1 $V3 $I1 %@TERMINAL
$P0 @THE DIFFERING BUFFERING STRATEGIES MAKE A COMPARISON
USELESS.
$B1 $I1 .%I/O %ROUTINES
$P0 @IT IS NOT SURPRISING THAT THESE TWO MODULES
ARE COMPARABLE IN SIZE AS THEY WERE BOTH
WRITTEN IN ASSEMBLER.
$A INDENT=0
$B2 $L1C
SYSTEM SPEED
$P0 @IT IS MORE DIFFICULT TO QUOTE ACCURATE 
TIMINGS FOR THE SECOND SYSTEM
THAN IT IS TO QUOTE THE FIGURES FOR THE FIRST SYSTEM. @THE MAIN
DIFFICULTY IS THAT CHANGES TO THE COMPILER CAN MAKE CONSIDERABLE
DIFFERENCES TO DETAILED TIMING FIGURES.
$B1 $A INDENT=1
%@KERNEL
$P0 @THE BASIC CONTEXT SWITCHING TIME IS GIVEN IN @TABLE 5.6.
$B2 $V7 $L1CM
TABLE 5.6  BASIC CONTEXT SWITCHING TIME
$L1
---------------------------------------------------------------------
$I2 @FIRST SYSTEM $C40 280 MICRO SECONDS
$I2 @SECOND SYSTEM $C40 390 MICRO SECONDS
$L1
---------------------------------------------------------------------
$B2 @AS PREVIOUSLY SHOWN, THE DIFFERENCE IS  EXPLAINED
BY THE ADDITIONAL LOADING OF THE MEMORY MANAGEMENT REGISTERS
NECESSARY ON THE SECOND SYSTEM.
$P1 @THE DIFFERING FUNCTIONS PERFORMED BY THE TWO KERNELS MAKE OTHER
COMPARISON FIGURES VERY DIFFICULT. @THERE IS, HOWEVER, ONE GENERALISATION
THAT CAN BE DRAWN. @A 'SIMPLE' ENTRY TO THE KERNEL
IN THE FIRST SYSTEM, VIZ, ONE THAT DOES NOT INVOLVE ANOTHER TASK, HAS A
BASIC OVERHEAD OF ONLY 60 MICRO SECONDS BECAUSE
A FULL REGISTER SAVE/RESTORE IS AVOIDED. @THE SECOND SYSTEM REQUIRES
THE FULL CONTEXT SWITCH TIME 
AS THERE IS NO CONTROL OVER THE USE OF THE REGISTERS. @THIS PROBLEM
WOULD BE AVOIDED ON THE .PDP 11/45 SINCE THE SECOND SET OF REGISTERS
COULD BE USED. @ONE FAIRLY SIMPLE OPTIMISATION CONCERNING THE
RELOADING OF THE MEMORY MANAGEMENT REGISTERS WHICH WOULD SAVE
THE 100 MICRO SECONDS HAS NOT YET BEEN IMPLEMENTED.
$P1 @A FURTHER COMPARISON CAN BE DRAWN FROM THE MINIMUM TIME TAKEN TO
RESPOND TO AN INTERRUPT (ONE THAT IS PASSED BACK TO TASK LEVEL), @TABLE
5.7 GIVES THE FIGURES.
$B2
$V6 $L1CM
TABLE 5.7  INTERRUPT RESPONSE TIMINGS
$L1
---------------------------------------------------------------------
$I2 @FIRST SYSTEM $C40 303 MICRO SECONDS
$I2 @SECOND SYSTEM $C40 693 MICRO SECONDS
$L1
---------------------------------------------------------------------
$B2
$P0 @THESE FIGURES SHOW A GREATER VARIATION THAN EXPECTED, THE SECOND
SYSTEM BEING 111$% SLOWER THAN THE FIRST. @FOR A CLEARER UNDERSTANDING
OF THE FIGURES THEY CAN BE SPLIT INTO THE FOLLOWING SECTIONS:
$I2 @A) ENTRY AND REGISTER SAVE
$I2 @B) RE-SCHEDULE OF INTERRUPTED PROCESS
$I2 @C) CHECKS AND OTHER PROCESSING
$I2 @D) SCHEDULE OF INTERRUPT-OWNING PROCESS
$I2 @E) .CPU DISPATCH
$I2 @F) REGISTER RESTORE
$P1 @TABLE 5.8 SHOWS THE TIMINGS FOR EACH STAGE
$B2
$V10 $L1CM
TABLE 5.8  BREAKDOWN OF INTERRUPT RESPONSE TIMINGS
$L3
---------------------------------------------------------------------
SECTION                       FIRST SYSTEM         SECOND SYSTEM
---------------------------------------------------------------------
$B0 @A) @ENTRY $C35 35 $C55 57
$B0 @B) @RE-SCHEDULE $C35 64 $C54 112
$B0 @C) @CHECKS ETC $C35 17 $C54 128
$B0 @D) @SCHEDULE $C35 61 $C54 112
$B0 @E) .CPU DISPATCH $C34 83 $C54 124
$B0 @F) @REGISTER RESTORE $C35 43 $C54 160
$L1
---------------------------------------------------------------------
$P2 @THE TABLE INDICATES AN INCREASE OF ABOUT 70$%-80$%
IN MODULES WHICH ARE BASICALLY VERY SIMILAR, EG PARTS @B, @D AND @E.
@OF THE THREE REMAINING PARTS, PARTS @A AND @C ARE VERY MUCH GREATER BECAUSE 
OF THE MORE GENERALISED INTERRUPT HANDLING OF THE SECOND SYSTEM.
@PART @F CONTAINS THE 103 MICRO SECONDS TO LOAD THE MEMORY MANAGEMENT
REGISTERS.
$P1 @IN @CHAPTER FOUR,
WHERE THE ROUTINE 'SCHEDULE' WAS EXAMINED, IT WAS FOUND A 
LARGE PART OF THE DIFFERENCE BETWEEN THE ROUTINES WAS DUE TO THE
.IMP ROUTINE ENTRY/EXIT OVERHEAD. @THIS IS ALSO TRUE OF THE
OTHER CRITICAL ROUTINES IN THE KERNEL, FOR EXAMPLE, THE ROUTINE
TO EXTRACT AN ITEM FROM A QUEUE IS 56$% ENTRY/EXIT OVERHEAD.
$B2
%@USER %@PROGRAMS
$P0 @THE .I/O INTERFACE TO AN .IMP PROGRAM IS MUCH MORE
EFFICIENT IN THE SECOND SYSTEM; THE FIGURES HAVE ALREADY BEEN
GIVEN IN @CHAPTER FOUR. @THE COMPILER IS A GOOD EXAMPLE,
MAKING HEAVY USE
OF THE .I/O FACILITIES,
EVEN THOUGH IT IS FAIRLY .CPU DEPENDENT.
 @TABLE 5.9 QUOTES THE FIGURES FOR
A FIRST PASS COMPILATION OF A 580 STATEMENT PROGRAM
(22000 CHARACTERS).
$B2
$V8 $L1CM
TABLE 5.9  FIRST PASS COMPILATION TIMES (IN SECONDS)
$L1
---------------------------------------------------------------------
$B0 $C35 .ENTRY $C50 .EXECUTION
$L1
---------------------------------------------------------------------
$I1 @FIRST SYSTEM $C37 7 $C54 75
$I1 @SECOND SYSTEM $C37 6 $C54 62
$L1
---------------------------------------------------------------------
$B2 $V5 $P0
@A SECOND EXAMPLE IS PROVIDED BY THE .EDITOR. @ON THE FIRST
SYSTEM IT USES A MORE EFFICIENT .I/O INTERFACE THAN A STANDARD .IMP
PROGRAM BUT ON THE SECOND SYSTEM IT USES THE STANDARD INTERFACE.
@TABLE 5.10 GIVES THE FIGURES FOR ENTERING THE EDITOR AND THEN
AN IMMEDIATE EXIT (THIS COPIES THE FILE).
$B2 $V10 $L1CM
TABLE 5.10  EDITING A 43 BLOCK FILE (22000 CHARACTERS)
$L1
---------------------------------------------------------------------
$C35 .ENTRY $C45 .EXIT (ALL IN SECONDS)
$L1
---------------------------------------------------------------------
$I1 @FIRST SYSTEM $C37 2 $C47 15
$I1 @SECOND SYSTEM $C37 1 $C47 16
$L1
---------------------------------------------------------------------
$P2 @THE SIGNIFICANCE OF THESE FIGURES IS THAT THEY INDICATE
THAT IN THESE TYPES OF PROGRAM THE EXTRA TIMING OVERHEAD IN THE
KERNEL OF THE SECOND SYSTEM IS NEGLIGABLE AND IS SWAMPED BY
OTHER OVERHEADS, EG, USER INTERFACE OVERHEADS, DISC HEAD MOVEMENT
AND .CPU TIME SPENT IN THE USER PROGRAM.
$N 
$A TAB=5, 10
$A JUST=1; LINE=69; PAGE=54; TOP=5; BOTTOM=7
$A NLS=2
$L3CM
CHAPTER 6

CONCLUSIONS
$P2 @IT HAS BEEN SHOWN THAT THE USE OF .IMP FOR
WRITING A SYSTEM FOR A FAIRLY SMALL CONFIGURATION
PROVIDES CERTAIN ADVANTAGES AND DISADVANTAGES.
$P1 @THE ADVANTAGES WERE IN:-
$I2 INITIAL IMPLEMENTATION
$I2 FAULT FINDING
$I2 MAKING EXTENSIONS
$A INDENT=1
$B1 %@INITIAL %@IMPLEMENTATION
$P0 @THE FIRST SYSTEM, WRITTEN IN ASSEMBLER, TOOK THREE TO FOUR
TIMES MORE EFFORT TO WRITE AND COMMISSION.
$B1 %@FAULT %@FINDING
$P0 @THERE WAS FEWER 'TRIVIAL' FAULTS IN THE SECOND SYSTEM AND
ALTHOUGH THE NUMBER OF MORE SERIOUS FAULTS WERE SIMILAR IN BOTH
SYSTEMS, THEY WERE EASIER TO CURE IN THE SECOND SYSTEM.
$B1 %@EXTENSIONS
$P0 @IN BOTH MINOR AND MAJOR ADDITIONS TO THE SYSTEMS, THE SECOND 
SYSTEM PROVED ITSELF MORE EASILY ADAPTABLE THAN THE FIRST SYSTEM, AGAIN
BY AT LEAST A FACTOR OF THREE TO ONE.
$A INDENT=0
$P1 @THE DISADVANTAGES OF USING .IMP WERE FOUND TO BE:
$I2 EXTRA CORE REQUIREMENTS
$I2 SLOWER EXECUTION
$A INDENT=1
$B1 %@EXTRA %@CORE %@REQUIREMENTS
$P0 @THE SECOND SYSTEM REQUIRED AN ADDITIONAL 4K WORDS OF STORE, 70$%
MORE THAN THE FIRST SYSTEM. @THIS IS THE MORE IMPORTANT DISADVANTAGE 
ALTHOUGH THE FIGURE IS OVERSTATED BECAUSE OF THE DIFFERENCES BETWEEN
THE TWO SYSTEMS.
$B1 %@SLOWER %@EXECUTION
$P0 @THE TIME SPENT IN THE SUPERVISOR OF THE SECOND SYSTEM IS
GREATER THAN THAT OF THE FIRST SYSTEM. @THIS IS, HOWEVER, IN MOST
APPLICATIONS A FAIRLY MINOR PROPORTION OF THE TOTAL .CPU TIME AND
IT WAS SHOWN IN @CHAPTER FIVE THAT THE TIME SPENT AT THE USER
INTERFACE LEVEL IS AS CRITICAL AS THE TIME SPENT IN THE
KERNEL. @THE SLOWER KERNEL EXECUTION TIME WILL BE FELT MOST
IN TWO PARTICULAR INSTANCES. @FIRSTLY, 
 IN AN
APPLICATION OF THE SYSTEM THAT WOULD NORMALLY EXPECT TO SPEND A HIGH
PROPORTION OF THE .CPU WITHIN THE SYSTEM ITSELF, FOR EXAMPLE,
A MESSAGE PASSING APPLICATION WHERE LITTLE PROCESSING OF THE
MESSAGE IS DONE.
@SECONDLY, A TIME CRITICAL DEVICE COULD WELL CAUSE PROBLEMS ON
THE SECOND SYSTEM. @WITH THE CURRENT VERSION OF THE COMPILER
IT MIGHT BE NECESSARY TO RECODE THE CENTRAL PART OF THE
KERNEL INTO ASSEMBLER TO HANDLE SUCH A DEVICE. @HOWEVER,
THIS MEASURE IS A LAST RESORT.
$A INDENT=0
$B1 $L1C
APPROPRIATENESS OF IMP
$P0 @IT HAS BEEN SHOWN THAT .IMP IS A SUITABLE
LANGUAGE FOR SMALL SYSTEMS IMPLEMENTATION BUT THAT IT
DOES HAVE SOME DEFICIENCES FROM THE SYSTEMS IMPLEMENTER'S
POINT OF VIEW.
$A INDENT=1
$B1 %@ROUTINE %@ENTRY %@AND %@EXIT
$P0 @THE CURRENT (@SEPTEMBER 1976) OVERHEAD
INCURRED IN ROUTINE ENTRY AND EXIT IS TOO EXPENSIVE. @EITHER
THE SYNTAX SHOULD BE CHANGED TO ALLOW THE SPECIFICATION
OF A 'SIMPLE' ROUTINE OR THE COMPILER SHOULD DETERMINE THIS
FOR ITSELF.
$B1 %@VECTOR %@OR %@RECORD %@RESULTS %@FROM %@ROUTINES
$P0 @IT WOULD BE DESIRABLE TO BE ABLE TO RETURN A VECTOR
(OR A .'$%RECORD') AS A RESULT OF A ROUTINE, THE ABSENSE OF
SUCH A FACILITY LEADS TO INEFFICIENCES IN THE CODE.
$B1 %@EXTENSION %@TO %@RECORD %@OPERATORS
$P0 @THE ABILITY TO 'COMPARE' .RECORDS, COUPLED WITH OTHER
BIT BY BIT MANIPULATIONS ON .RECORDS WOULD BOTH BE MORE
EFFICIENT AND LEAD TO BETTER CLARITY IN PROGRAMMES.
$A INDENT=0
$P1 @THE SCALE OF THE DISADVANTAGES OF USING .IMP AS LISTED
ABOVE ARE HEAVILY DEPENDENT ON THE ACTUAL IMPLEMENTATION
OF .IMP ON THE .PDP 11. @SINCE
THE FIRST VERSION OF THE COMPILER THERE HAS ALREADY BEEN A CONSIDERABLE INCREASE IN ITS 
EFFICIENCY AND THE QUOTED FIGURES 
FOR THE SPACE AND TIME USED BY THE SYSTEM
ARE ONLY TRUE OF THE VERSION COMPILED BEFORE 1:10:76.
@THE IMPORTANT POINT TO NOTE IS THAT THESE FIGURES CAN BE GREATLY
ALTERED 
BY A RE-COMPILATION ALONE
WITHOUT A SINGLE CHANGE BEING MADE TO THE SYSTEM.
$B1 $L1C
FUTURE SYSTEMS
$P0 @IT IS NOT POSSIBLE FROM THESE RESULTS TO CLAIM THAT EVERY FUTURE
MINI-COMPUTER
SYSTEM SHOULD BE WRITTEN IN .IMP, OR ANOTHER HIGH LEVEL LANGUAGE,
BUT IT IS POSSIBLE TO DRAW GUIDELINES AS TO WHERE THE USE OF .IMP
WOULD BE BENEFICIAL.
$A INDENT=1
$B1 %@VERY %@SMALL %@SYSTEMS
$P0 @WHERE, BECAUSE OF COST CONSIDERATIONS OR BECAUSE THERE
ARE MULTIPLE SYSTEMS, CORE LIMITATION IS A DOMINANT FEATURE
THE EXTRA CORE OVERHEADS OF USING .IMP WOULD EFFECTIVELY
RULE ITS USE OUT. @EXAMPLES OF THIS TYPE OF SYSTEM COULD BE
A SMALL TERMINAL CONTROLLER OR A MICROPROCESSOR DEDICATED
TO A PIECE OF EQUIPMENT. @A POSSIBLE TREATMENT OF THIS CASE,
HOWEVER, WOULD BE TO WRITE THE SYSTEM INITIALLY IN .IMP,
TEST IT OUT IN A LIMITED FORM, OR ON A LARGER MACHINE,
THEN HAND CODE THE .IMP INTO ASSEMBLER KEEPING THE BASIC STRUCTURE
INTACT.
@THIS SOLUTION WOULD OVERCOME THE CORE COST OF USING .IMP
WHILE RETAINING MOST OF THE INITIAL IMPLEMENTATION ADVANTAGES.
@SOME COST MUST BE ATTACHED TO THE
NEW SET OF FAULTS THAT WOULD BE INTRODUCED AT
THE HAND CODING STAGE. @MODIFICATIONS TO THE SYSTEM COULD BE HANDLED
BY A REFERRAL BACK TO THE .IMP VERSION.
$B1 %@LARGER %@SYSTEMS
$P0 @ON LARGER SYSTEMS, VIZ OVER 8K, IT IS ILLUMINATING
TO COMPARE THE TRENDS OF CORE COSTS AGAINST PROGRAMMER COSTS.
@TABLE 6.1 BELOW SHOWS THE CHANGE IN CORE COSTS OVER A 
NUMBER OF YEARS. @TABLE 6.2 GIVES SOME INDICATIVE COSTS OF
PROGRAMMER TIME.
$B2 $V10
$L1CM
TABLE 6.1  CHANGE IN CORE COSTS
$L1
---------------------------------------------------------------------
$I1 @APR 1972 $C30 #7040 FOR 16K WORDS .(DEC)
$I1 @MID 1973 $C30 #4930 FOR 16K WORDS .(DEC)
$I1 @MID 1976 $C30 #3000 FOR 16K WORDS .(DEC)
$I1 @MID 1976 $C30 #3000 FOR 32K WORDS .(OEM)
$L1C
---------------------------------------------------------------------
$B2 $V10 $L1CM
TABLE  6.2  CHANGE IN PROGRAMMER COSTS (ERCC EXTERNAL RATES)
$L1
---------------------------------------------------------------------
$I1 1972 $C30 #28 A DAY
$I1 1974 $C30 #34 A DAY
$I1 1976 $C30 #68 A DAY
$L1
---------------------------------------------------------------------
$B3 $P0
@THE TABLES SHOW VERY CLEARLY THAT WHEREAS THE COST OF CORE IS DROPPING
VERY RAPIDLY, PROGRAMMER COSTS ARE INCREASING.
@THE EFFECT OF THESE TRENDS ARE THAT MEASURES WHICH REDUCE PROGRAMMING
COSTS, EVEN THOUGH THEY ARE AT THE EXPENSE OF EXTRA CORE COSTS, WILL
BECOME EVEN MORE SIGNIFICANT.
@THE EXTRA 
PROGRAMMER TIME 
TO BALANCE OUT THE COST
OF THE ADDITIONAL 4K WORDS REQUIRED BY THE
SECOND SYSTEM IS ONLY 11 DAYS. @THIS HOLDS WHEN A SINGLE SYSTEM IS
BEING CONSIDERED, OR EVEN A SMALL GROUP OF SYSTEMS, BUT THE
ARGUMENT CHANGES WHEN A MANUFACTURERS OWN SYSTEM IS UNDER CONSIDERATION,
WHERE THE NUMBER OF MACHINES WILL BE IN THE HUNDREDS OR THOUSANDS. @HOWEVER
IN THIS SITUATION THERE ARE STILL ADVANTAGES IN USING A HIGH LEVEL
LANGUAGE. @A MANUFACTURER ON THE SCALE OF .DEC HAS TO SUPPORT A
CONTINUALLY CHANGING RANGE OF PERIPHERALS.
@THEREFORE THE SAVINGS WHICH CAN BE ACHIEVED IN THE ONGOING
SUPPORT OF SYSTEMS BY THE USE OF A HIGH LEVEL LANGUAGE
SHOULD NOT BE IGNORED.
$E