$A TAB=1,6,11,16,21,31,36,41,46,51
$A INDENT = 2
$A JUST=1
$B20
$LUM
@A @HIGH @LEVEL @ASSEMBLER @FOR THE @I@C@L 2900
$B6
$LUM
@PHILIP @A. @F. @HARTLEY
$B6
$LUM
@COMPUTER @SCIENCE 4 @PROJECT
$LUM
@MAY 1976
$N
$A LINE = 65
$LCUM
CHAPTER 1.
$L2CUM

INTRODUCTION.
$P
@THE GOAL OF THE PROJECT WAS TO WRITE A HIGH LEVEL ASSEMBLER FOR
THE .ICL 2900 SERIES OF COMPUTERS. @THIS PROBLEM IMMEDIATELY
SEPERATED INTO TWO DISTINCT SUBPROBLEMS:
$B
$I4 1.  @GAINING AN UNDERSTANDING OF THE MACHINE.
$I4 2.  @CHOOSING THE FORM OF THE LANGUAGE.
$P
@THE 2970 HAD BEEN USED FOR DEVELOPMENT WORK OVER THE LAST YEAR
BY .ERCC. @SO THERE WAS A LOT OF FIRST HAND EXPERIENCE OF THE
MACHINE AROUND.
@THE FIRST PROBLEM, THEREFORE, COULD BE OVERCOME
BY READING THE MACHINE MANUALS AND THEN TALKING TO PEOPLE WHO HAD
EXPERIENCE OF THE MACHINE IN ORDER TO CLEAR UP THE POINTS WHICH
NEEDED CLARIFICATION.
$P
@THE CHOICE OF .HAL AS THE STRUCTURE OF THE LANGUAGE WAS
ARRIVED AT QUICKLY. @ONCE .HAL HAD BEEN SELECTED,
THE PROBLEM OF WHERE TO START AROSE. @WHETHER TO START FROM SCRATCH
OR TO TAKE AN ALREADY EXISTING .HAL, DETERMINE THE MACHINE
DEPENDENT PARTS AND ALTER OR REPLACE THESE TO PRODUCE 2900 CODE.
.EMAS WAS CHOSEN AS THE DEVELOPMENT MACHINE ON WHICH TO IMPLEMENT
.HAL-2900 USING THE LATTER OF THE ABOVE TECHNIQUES.
$P
@IT IS IMPORTANT TO SEE THIS PROJECT IN A GREATER CONTEXT THAN
JUST A FOURTH YEAR PROGRAMMING EXERCISE. @THIS WAS
THE FIRST PROJECT UNDERTAKEN IN THE DEPARTMENT WHICH INVOLVED DIRECT
CONTACT WITH THE MACHINE STRUCTURE. @IT WAS THEREFORE FELT THAT
THE PROJECT COULD PLAY A LARGE PART IN HELPING LATER PROJECTS
COME TO GRIPS WITH THE MACHINE AT AN EARLIER STAGE THAN WAS
POSSIBLE IN THIS PROJECT, DUE TO LACK OF ADEQUATE DOCUMENTATION.
$N
$L3CUM
CHAPTER 2.

@APPROACH TO THE 2900.
$P
$P
@IN ORDER TO WRITE A GOOD COMPILER OR HIGH LEVEL ASSEMBLER FOR A
MACHINE THE IMPLEMENTOR MUST HAVE AN EXTEMELY GOOD KNOWLEDGE OF THE
MACHINE BOTH IN TERMS OF ITS ORDER CODE AND OF THE OVERALL STRUCTURE
OF THE SYSTEM. @A CONSIDERABLE PART OF THE PROJECT WAS SPENT
TRYING TO UNDERSTAND THE MACHINE BY GOING THROUGH THE
MANUFACTURER'S DOCUMENTATION.
$P
@IT WAS QUITE EVIDENT THAT NONE OF THE DOCUMENTATION GAVE
AN ADEQUATE 'MIDDLE OF THE ROAD' VIEW OF THE SYSTEM - IT WAS
EITHER TOO GLOSSY OR EXTREMELY DETAILED AND VIRTUALLY UNREADABLE.
$P
@THE EXPERIENCE OF THE .EMAS PROJECT TEAM WAS THAT THE
MANUFACTURER'S DOCUMENTATION WAS NOT QUITE GOOD ENOUGH; SOME
DETAILS WERE EITHER CONFUSED, AMBIGUOUS OR EVEN OMITTED.
$P
@IT WAS FOR THESE REASONS,
BOTH FOR THE PROJECT'S OWN SAKE AND TO AID THE DISSEMINATION OF
INFORMATION ABOUT THE MACHINE,
THAT @APPENDIX @A WAS
WRITTEN, A DETAILED, BUT NOT EXHAUSTIVE, DESCRIPTION AND
DISCUSSION OF THE 2970 SYSTEM. @IT WAS INTENDED
TO GIVE THE REASONABLY EXPERIENCED COMPUTER SCIENTIST AN INTRODUCTION
TO THE MAIN CONCEPTS OF THE SYSTEM, WITHOUT GETTING BOGGED DOWN
IN TOO MUCH DETAIL. @BUT IT WAS ALSO DESIGNED AS A START TO THE
DOCUMENTATION WHICH WOULD COMPLEMENT THAT OF THE MANUFACTURER
INASMUCH AS IT WOULD CONTAIN CLARIFICATION OF DETAILS OF THE SYSTEM
WHICH WERE NOT ADEQUATELY COVERED ELSEWHERE.
$N
$L3CUM
CHAPTER 3.

THE APPROACH TO THE HIGH LEVEL ASSEMBLER FOR THE 2900
$B
$LIUC
GENERAL
$P
@A HIGH LEVEL ASSEMBLER IS A PROGRAMMING LANGUAGE IN WHICH THERE
ARE PROGRAM STRUCTURING - AND OFTEN DATA STRUCTURING - FACILITIES
WHICH ONE EXPECTS TO FIND IN A HIGH LEVEL LANGUAGE BUT WHICH
ALLOWS DIRECT ACCESS TO ALL MACHINE FACILITIES,
INCLUDING ALL MACHINE INSTRUCTIONS, REGISTERS AND MEMORY.
$P
@THE FIRST HIGH LEVEL ASSEMBLER WAS @N.$ @WIRTH'S .PL360
[1] FOR THE .IBM 360/370. @IT WAS ORIGINALLY WRITTEN AS A TOOL
TO AID THE IMPLEMENTATION OF AN .ALGOL 60 COMPILER BUT IT SOON
BECAME EVIDENT THAT THIS TYPE OF LANGUAGE BRIDGED THE RATHER WIDE
GAP BETWEEN ASSEMBLERS AND HIGH LEVEL LANGUAGES.
$P
@THE ADVANTAGE OF HIGH LEVEL ASSEMBLERS OVER NORMAL ASSEMBLERS IS,
AS @BELL AND @WICHMANN SAY IN [3], "THAT THEY ARE AN EASY METHOD
OF EXPLOITING THE HARDWARE WITHOUT BECOMING ENTANGLED IN MACHINE CODE".
@THE NUMBER OF MISTAKES ELIMINATED BY BEING ABLE TO WRITE ARBITRARY
EXPRESSIONS INSTEAD OF HAVING TO GENERATE THE INSTRUCTIONS BY HAND
SHOWS HOW GREAT THESE ADVANTAGES ARE.
$P
@THE ADVANTAGE OVER HIGH LEVEL LANGUAGES IS PRECISELY THAT
ONE CAN GET DIRECT ACCESS TO MACHINE FACILITIES. @TECHNIQUES
USED TO ACCESS DATA OR PROGRAM CAN BE TAILORED TO THE PARTICULAR
APPLICATION RATHER THAN BEING VERY GENERAL AS IS NECESSARY
IN A COMPILER.
@CERTAINLY, ON A MACHINE
LIKE THE @INTERDATA 70/74, BY EQUIVALENCING A VARIABLE NAME
WITH A REGISTER, 2 BYTES PER ACCESS TO THAT VARIABLE CAN BE SAVED
OVER A PROGRAM IN WHICH THE VARIABLE WAS EQUIVALENCED TO
A MEMORY LOCATION
(THAT IS, THE DIFFERENCE BETWEEN A REGISTER-REGISTER FORM
AND A REGISTER-INDEXED FORM OF INSTRUCTION).
@THEREFORE, UNLESS THE COMPILER CAN DO GLOBAL OPTIMISATION, A
DIFFICULT AND EXPENSIVE PROCEDURE, AS MUCH AS 2 BYTES PER ACCESS CAN BE
GAINED IN THE HIGH LEVEL ASSEMBLER OVER THE HIGH LEVEL LANGUAGE.
@IF A VARIABLE IS ACCESSED 100 TIMES, THEN UP TO 200 BYTES CAN
BE SAVED ON THE SIZE OF THE CODE - A VERY IMPORTANT FACTOR WHEN
PROGRAMMING ON MACHINES WITH A SMALL MEMORY.
$B
$LIUC
A HIGH LEVEL ASSEMBLER FOR THE 2900?
$P
@BUT WHY A HIGH LEVEL ASSEMBLER FOR THE 2900? @THE 2900 IS NOT
A MULTI-REGISTER MACHINE SO THE ADVANTAGE OF ASSIGNING A VARIABLE
NAME TO A REGISTER QUOTED ABOVE DOES NOT APPLY.
$P
@HOWEVER, THERE ARE SOME SHORT FORMS (E.G.$ THE @L@N@B+N
ADDRESSING MODE) BUT THE MAIN ADVANTAGES ARE IN THE AREAS WHERE
THE AVAILABLE HIGH LEVEL LANGUAGES ARE DEFICIENT. @FOR EXAMPLE, IN
.IMP [4] THERE IS NO DIRECT
METHODS OF MANIPULATING 64 BIT INTEGER QUANTITIES;
THE ESCAPE DESCRIPTOR FOR DYNAMIC DATA STRUCTURING CANNOT BE USED
TO FULL ADVANTAGE.
$P
@AT THE MOMENT, THE ALTERNATIVE TO PROGRAMMING IN A HIGH LEVEL LANGUAGE ON THE
2900 IS ASSEMBLER.
@THERE
IS ONE TREMENDOUS DISADVANTAGE OF WORKING AT THIS LEVEL ON THE
2900: THE PRIMITIVE LEVEL INTERFACE IS NOT
GUARANTEED TO REMAIN THE SAME. @THIS MAKES IMPRACTICABLE THE
USE OF SUCH TECHNIQUES FOR ALL BUT THE SMALLEST APPLICATIONS, EVEN
ALTHOUGH SYSTEM .VME/K WAS WRITTEN IN .MAPLE/STAPLE.
$B
$LIUC
CHOICE OF THE LANGUAGE.
$P
@THERE WERE THREE CONSTRAINTS WHICH THE LANGUAGE HAD TO SATISFY,
IN ORDER TO MAXIMISE THE ADVANTAGES STATED ABOVE.
$B
$A INDENT = 3
 1.$ @THE LANGUAGE SHOULD NOT ENFORCE ANY METHOD OF ACCESSING
DATA OR PROGRAM.
$B0
 2.$ @THE LANGUAGE SHOULD ALLOW EASY ACCESS TO ALL MACHINE TYPES
AND FUNCTIONS.
$B0
3.$ @IT SHOULD BE POSSIBLE TO PRODUCE CODE AS EFFICIENT AS THAT
PRODUCED BY HAND.
$A INDENT = 2
$P
.HAL LANGUAGES,
DESIGNED BY @H.$ @DEWAR OF THE @DEPARTMENT OF @COMPUTER @SCIENCE,
 ARE A FAMILY OF ASSEMBLERS WHOSE HIGH LEVEL FEATURES
ARE BASICALLY THE SAME ON ALL MACHINES BUT WHOSE LOW LEVEL FEATURES
ARE TAILORED TO THE PARTICULAR MACHINE FOR WHICH THE .HAL IS
DESIGNED.
@THE HIGH LEVEL FEATURES INCLUDE BLOCK STRUCTURE (ONLY TO RESTRICT
THE SCOPE OF MACROS AND VARIABLE NAMES), ASSIGNMENT STATEMENTS,
CONDITIONAL STATEMENTS, CONTROLLED LOOPS, A MACRO SCHEME
AND A STATEMENT FOR EQUIVALENCING VARIABLE NAMES TO REGISTERS,
MEMORY LOCATIONS OR CONSTANTS. @THE LANGUAGE ALLOWS
FOR THE EXPLICIT POSITIONING OF CODE AND DATA.
$P
@ONE OF THE MAIN FEATURES OF THE LANGUAGE IS TO SEPERATE THE
PROGRAM INTO TWO MAIN SECTIONS; A DECLARATIVE SECTION AND A CONTROL
SECTION.
@MOST OF THE CONTROL SECTION CAN BE MACHINE INDEPENDENT, OPERATING
ON NAMES WHICH ARE BOUND TO MACHINE RESOURCES IN THE DECLARATIVE
SECTION.
$P
@THIS MEANS THAT THE BINDING OF A VARIABLE NAME
IN THE DECLARATIVE SECTION CAN BE CHANGED FROM
A STORE LOCATION TO A REGISTER, OR FROM A LONG FORM TO A SHORT FORM,
FOR EXAMPLE, WITHOUT ALTERING THE CONTROL SECTION.
$P
@THE LANGUAGE HAD TO BE EXTENDED TO CATER FOR THE MACHINE TYPES,
NAMELY DESCRIPTORS, WHICH DO NOT EXIST ON ANY OTHER MACHINE
FOR WHICH .HAL IS IMPLEMENTED.
$P
.HAL WAS CHOSEN BECAUSE IT SATISFIED THE ABOVE CONSTRAINTS
AND BECAUSE OF
THE GREAT DEAL OF PROGRAMMING
EXPERIENCE .I ALREADY HAD WITH .HAL70 AND THE SMALL AMOUNT
WITH .HAL7502. @IT IS VERY IMPORTANT, .I FEEL, TO BE FAMILIAR WITH
THE LANGUAGE WHICH IS BEING IMPLEMENTED.
$B
$LIUC
METHOD OF IMPLEMENTATION.
$P
@ONCE .HAL WAS CHOSEN, A DECISION HAD TO BE MADE:
TO START FROM SCRATCH OR TO CONVERT AN ALREADY EXISTING .HAL
IMPLEMENTATION
 TO
.HAL2900.
$P
@THIS WAS AN EXTREMELY DIFFICULT DECISION TO MAKE. @THE FIRST
METHOD WOULD HAVE INVOLVED A GREAT DEAL OF 'RE-INVENTING THE WHEEL'
TYPE OF WORK. @THEREFORE THE SECOND TECHNIQUE WAS CHOSEN, THUS TAKING
THE CHANCE THAT THE PROGRAM MIGHT HAVE TO HAVE BEEN REJECTED
AND SO WASTING A GREAT DEAL OF TIME.
$P
.HAL70 WAS EXAMINED SINCE IT WAS BY FAR THE MOST ESTABLISHED
.HAL LANGUAGE IN USE. @IT IS QUITE A LARGE AND COMPLICATED PROGRAM
AND TOOK A LONG TIME TO UNDERSTAND. @IT WAS WRITTEN FOR AN .8K .PDP15
AND IS THEREFORE NECESSARILY VERY TIGHTLY WRITTEN, WHICH MADE IT EVEN
MORE DIFFICULT TO UNDERSTAND.
$B
$LIUC
A BRIEF DESCRIPTION OF THE MACHINE INDEPENDENT HAL
$P
@THE MAIN FUNCTION OF THE MACHINE INDEPENDENT PART OF THE .HAL
PROGRAM IS TO CONVERT SOURCE STATEMENTS INTO A MORE CONVENIENT
SEMI-REVERSE POLISH FORM (NOT TRUE REVERSE POLISH, AS WILL BE SEEN LATER).
@THIS INCLUDES THE TASKS OF REDUCING OF NAMES TO AN INTERNAL FORM
AND DICTIONARY HANDLING. @THIS SECTIONS HANDLES CONDITIONAL
STATEMENTS, CONVERTING THEM TO A SET OF ASSEMBLER LABELS AND JUMP
DIRECTIVES, THE MACRO SCHEME, CONDITIONAL ASSEMBLY, DEFINITION
AND REDEFINITION OF VARIABLE NAMES, BLOCK STUCTURE, SETTING OF THE
ASSEMBLER LOCATION COUNTER, THE PRODUCTION OF THE LISTING FILE AND
ERROR REPORTS.
$P
@THE MACHINE DEPENDENT SECTION GENERATES THE OBJECT FILE,
EVALUATES EXPRESSIONS AND CONDITIONS, PLANTING CODE WHERE NECESSARY,
GENERATING JUMPS AND PLANTING DATA.
$P
@THE TWO SECTIONS ARE NOT TOTALLY DEPENDENT ESPECIALLY IN THE
AREA OF ASSEMBLER JUMPS WHERE THEY BECOME SLIGHTLY ENTANGLED
IN ORDER TO OPTIMISE THE SHORT FORM OF THE JUMP INSTRUCTION.
@SOME MACHINE DEPENDENT FEATURES TO DO WITH DESCRIPTORS
APPEAR IN THE MAIN REVERSE POLISH CONVERSION ROUTINE BUT THESE WILL BE
DISCUSSED LATER.
$B
$LIUC
CHOICE OF MACHINE.
$P
@ON WHICH MACHINE WAS THE LANGUAGE TO BE IMPLEMENTED? .EMAS WAS
CHOSEN FOR SEVERAL REASONS. @FIRSTLY, THE 2900 IS A 32 BIT MACHINE
AND THE ASSEMBLER WOULD HAVE TO MANIPULATE VALUES OF UP TO 32
BITS IN LENGTH. .EMAS WAS THE ONLY
READILY AVAILABLE
 MACHINE ON WHICH THIS COULD
BE DONE EASILY.
$P
@MORE IMPORTANTLY, THERE WERE EXTENSIVE FACILITIES FOR THE
GENERATION AND MANIPULATION OF 2900 OBJECT FILES
AVAILABLE ON .EMAS.
$P
@OTHER REASONS FOR CHOOSING .EMAS WERE THAT .IMP ON THE
@INTERDATAS WAS NOT FULLY DEBUGGED, THE OPERATING SYSTEM WAS NOT DESIGNED
FOR GENERAL PURPOSE USE ANYHOW, AND THE MACHINES WERE NOT RELIABLE
ENOUGH AT THE START OF THE PROJECT. @THE .PDP15 WAS NOT BIG
ENOUGH WITH ONLY .8K WORDS OF STORE - ALTHOUGH .HAL70
AND .HAL7502 BOTH FIT INTO THIS.
$N
$L3CUM
CHAPTER 4.

IMPLEMENTATION DETAILS.
$P
@FOR REFERENCE, MOST OF THE MACHINE DEPENDENT SECTION OF THE
ASSEMBLER IS CONTAINED IN ROUTINE .ASSEMBLE STARTING AT LINE
244 IN APPENDIX  .D.
$P
@THE INTERNAL REPRESENTATION OF A TAG IS BY 3*16 AND 1*32 BIT
VALUES.
$L8C

          +--------+--------+   +--------+----------------+
          |        |        |   |        |                |
          |  tag1  |  tag2  |   |  type  |      val       |
          |        |        |   |        |                |
          +--------+--------+   +--------+----------------+
              16       16           16           32

.TAG1 REPRESENTS THE FIRST 3 CHARACTERS OF A TAG
(IN BASE 36 FORMAT) AND .TAG2 HOLDS CHARACTERS 4$ -$ 6. @A TAG
IS A SEQUENCE OF LETTERS FOLLOWED BY A SEQUENCE OF DIGITS OF
WHICH ONLY THE FIRST 6 ARE SIGNIFICANT.
$P
@THE TYPE PART IS INTERPRETED AS FOLLOWS:

$B
$T4 BIT 0 $T6 UNUSED
$B0
$T4 BIT 1 $T6 MACHINE INSTRUCTION
$B0
$T4 BIT 2 $T6 MACRO
$B0
$T4 BIT 3 $T6 FORWARD REFERENCE
$B0
$T4 BIT 4 $T6 UNDEFINED TAG
$B0
$T4 BIT 5 $T6 RELOCATABLE
$B0
$T4 BIT 6 $T6 PSEUDO REGISTER
$B0
$T4 BIT 7 $T6 REGISTER
$B0
$T4 BIT 8 $T6 MEMORY REFERENCE
$B0
$T4 BIT 9 $T6 TYPE OF REFERENCE
$B0
$T6 =0 => .W(REG+VAL)
$B0
$T6 =1 => .L(REG+VAL)
$B0
$T6 =2 => .B(REG+VAL)
$B0
$T6 =3 => .IS(VAL) OR .IS(B) IF .REG = .B
$B0
$T6 =4 => .$@(REG+VAL)
$B0
$T6 =5 => .$@DR(REG+VAL)
$B0
$T6 =6 => .$@(REG+VAL)(B)
$B0
$T4 BITS 12 - 15 $T6 INDEX REGISTER (@R@E@G, ABOVE)
$B
@THE REGISTERS ARE REPRESENTED BY :
$L4I

.LNB = 1, .XNB = 2, .PC  = 3, .SSN = 4, .TOS = 5
.DR  = 6, .B   = 8, .SF  = 9, .ACC = 10

@ZERO IN THE INDEX REGISTER FIELD IMPLIES THAT NO INDEX REGISTER
IS BEING USED.

$B
$LUI
EXAMPLES
$B
@IN THE FOLLOWING EXAMPLES, AND THROUGHOUT THE REST OF THE REPORT,
($ ,$ ) REPRESENTS A .(TYPE,$ VAL) PAIR, .LMASK$ =$ X'10'
(I.E. 1 SET IN 'TYPE OF REFERENCE'), .PSREG$ =$ X'200' (I.E.
'PSEUDO REGISTER' SET TO 1)
AND .REGISTER$ =$ X'100' (I.E. 'REGISTER' SET TO 1).
@THE EXPRESSION ON THE LEFT HAND SIDE IS WHAT ACTUALLY APPEARS
IN THE SOURCE; THE EXPRESSION ON THE RIGHT HAND SIDE
IS THE INTERNAL REPRESENTATION OF THE LEFT HAND SIDE.
$L12IC

LNB = (REGISTER, LNB)
W(LNB+4) = (LNB, 1)         / LNB IS OFFSET BY A NUMBER OF WORDS
                            / SO A CONVERSION IS DONE FROM THE
                            / OFFSET STATED IN THE SOURCE (WHICH
                            / IS ALWAYS BYTES) TO WORDS.
L(PC+16) = (LMASK+PC, 8)    / AGAIN THE CONVERSION BUT TO HALF
                            / WORDS THIS TIME.
W(R0+16) = (PSREG+0, 16)    / NO CONVERSION FOR PSEUDO REGISTERS
                            / UNTIL THE ACTUAL EVALUATION OF THE
                            / PSEODO REG IS REQUIRED.

$P
@THEREFORE AN ASSEMBLY TIME EXPRESSION, TO WHICH A VARIABLE
NAME CAN BE EQUIVALENCED, FOR EXAMPLE, IS ONE WHOSE RESULT CAN
BE REPRESENTED BY A .(TYPE,$ VAL) PAIR,  WITHOUT
GENERATING ANY CODE.
$P
@AN OPERAND IN THE REVERSE POLISH FORM IS THEREFORE REPRESENTED
BY A .(TYPE,$ VAL) PAIR .(TAG1 AND .TAG2 CAN BE DISCARDED
SINCE THEY ARE ONLY REQUIRED FOR DICTIONARY LOOK-UP AND THESE
OPERATIONS HAVE BEEN COMPLETED
BY THE TIME THE REVERSE POLISH IS GENERATED). @AN OPERATOR IS REPRESENTED BY
A NEGATIVE NUMBER. (@THE SWITCH .ASS IN .ASSEMBLE IS INDEXED BY
THE OPERATOR VALUE).  @FOR EXAMPLE, GIVEN THE FOLLOWING
DEFINITIONS:
$L4IC

    $$DEF A = W(LNB+4), B = W(LNB+8)
    $$DEF C = L(SSN+32)

(I.E. DEFINE .A, .B AND .C TO HAVE THE VALUES OF THE ASSEMBLY
TIME EXPRESSIONS ON THE RIGHT HAND SIDES OF THE APPROPRIATE EQUALS
SIGNS)
$B0
THEN THE REVERSE POLISH FORM GENERATED FOR THE SOURCE STATEMENT:
$L3IC

    C = A+B+3

(I.E. ASSIGN TO THE MEMORY LOCATION OR REGISTER SYNONYMED BY .C
THE VALUE OF THE EXPRESSION GIVEN BY ADDING THE CONTENTS OF
THE MEMORY LOCATION, REGISTER OR CONSTANT SYNONYMED BY .A, ADDING IT
TO THE MEMORY REFERENCE, REGISTER OR CONSTANT SYNONYMED
BY .B, AND THEN ADDING 3).
$B0
WOULD BE:
$L4I
    .LMASK+SSN, 8, STORE,
           .LNB, 1, .LNB, 2, ADD, 0, 3, ADD, STORE
           !

WHERE 'STORE', 'LOAD' AND 'ADD'
ARE THE OPERATORS IN THE REVERSE POLISH.
$P
@ROUTINE .ASSEMBLE IS THEN CALLED AND THE EXPRESSION STARTING AT
THE POSITION INDICATED IS EVALUATED. @WHEN THE 'LOAD' OPERATION
IS MET THE POINTER IS RETURNED TO THE START OF THE EXPRESSION
AND WHEN THE 'STORE' OPERATION IS REACHED, THE EVALUATION IS
TERMINATED.
$P
@WHEN AN OPERATION IS MET IN 
THE REVERSE POLISH
THE APPROPRIATE PROCEDURE IS INVOKED BY JUMPING THROUGH THE SWITCH .ASS
(IN ROUTINE .ASSEMBLE)
INDEXED BY THE OPERATION VALUE.
@FOR BINARY OPERATIONS
THE LEFT OPERAND IS DELIVERED IN .(TYPE1,$ VAL1) AND THE RIGHT
OPERAND IN .(TYPE,$ VAL)
AND THE RESULT IS EXPECTED TO BE RETURNED IN .(TYPE,$ VAL).
@A UNARY OPERATION IS INVOKED
WITH ITS OPERAND IN .(TYPE,$ VAL) AND THE RESULT RETURNED IN THE
SAME.
$B 
$LIUC
DESCRIPTORS
$P
@THE DESCRIPTOR PROVIDES
A METHOD OF ACCESSING A REGULAR, USUALLY STATIC,
SET OF DATA ITEMS. @THE DESCRIPTOR ITSELF IS A 64 BIT QUANTITY
OF WHICH THE FIRST (MOST SIGNIFICANT) 32 BITS DEFINE THE TYPE OF
THE DATA BEING ACCESSED (1, 8, 32, 64 BIT LENGTH, FOR EXAMPLE),
WHETHER ANY MODIFIER APPLIED IS TO BE SCALED AND AN UPPER BOUND
ON THE SIZE OF THE MODIFIER. @THE SECOND (LEAST SIGNIFICANT)
32 BITS CONTAIN THE ADDRESS OF THE FIRST ITEM OF THE SET.
$P
@THE NOTATION CHOSEN FOR DESCRIPTORS WAS .$@DESC FOR NON-MODIFIED
DESCRIPTORS AND .$@DESC(MOD) FOR MODIFIED DESCRIPTORS. @THIS
WAS CHOSEN AS BEING THE MOST CONSISTENT WITH THE SYNTAX OF
OTHER INDIRECT FORMS IN .HAL; E.G .W(ADDR), .B(ADDR), ETC.
$P
@THE SYMBOL '$@' COULD THEN BE TREATED AS AN OPERATION - UNARY
FOR NON-MODIFIED DESCRIPTORS AND BINARY FOR DESCRIPTORS TO WHICH MODIFICATION
IS APPLIED. @THE PARTICULAR OPERATION TO BE INVOKED IS WORKED OUT
FROM CONTEXT.
@IT IS QUITE STRAIGHTFORWARD BUT NOT TRIVIAL SINCE, IN THE MODIFIED
CASE, THE '$@' IS BEING TREATED AS A PREFIXED BINARY OPERATOR,
WHEREAS ALL OTHER BINARY OPERATORS ARE INFIX. @OF COURSE, THE
TREATMENT OF UNARY '$@' IS QUITE CONSISTENT WITH UNARY MINUS (-)
AND NOT (\).
$P
@THE TECHNIQUE  OF 'EVALUATION' OF DESCRIPTORS IS TO TRY TO
FIT THE DESCRIPTOR REFERENCE TO ONE OF THE AVAILABLE ADDRESSING MODES
AND IF THIS IS NOT POSSIBLE, TO LOAD THE .DR (A REGISTER WHICH
HOLDS A DESCRIPTOR) WITH THE DESCRIPTOR. @THE MODIFIER, IF ANY,
IS LOADED INTO THE .B REGISTER UNLESS IT FITS ONE OF THE MODIFIER
ADDRESSING MODES WHICH IS CONSISTENT WITH THE DESCIPTOR REFERENCE.
@FOR EXAMPLE,
$LI
             .$@(L(LNB+4))(W(LNB+12))
WOULD BE COERCED TO
$LI
             .$@DR(W(LNB+12))
WHERE .DR GETS .L(LNB+4), AND
 $LI
             .$@(L(XNB+40))(L+M)
WOULD BE COERCED TO
$LI
             .$@(L(XNB+40))(B)
WHERE .B GETS .L+M, GIVEN THAT .L+M WILL NOT FIT ONE OF THE
MODIFIER ADDRESSING MODES.
$B
$LIUC
REGISTERS
$P
@EACH REGISTER ON THE 2900 IS MEANT TO SERVE A PARTICULAR PURPOSE.
@FOR INSTANCE, THE .XNB IS MEANT FOR USE AS AN INDEX REGISTER AND
NO COMPUTATION CAN BE PERFORMED ON IT. @THE ACCUMULATOR IS MEANT
TO HOLD INTERMEDIATE RESULTS OF EXPRESSIONS AND FOR PERFORMING
COMPUTATION AND IT CANNOT BE USED AS AN INDEX REGISTER. @THE .B
REGISTER IS SEMI-FLEXIBLE IN THAT A LIMITED AMOUNT OF COMPUTATIONAL
FUNCTIONS CAN BE PERFORMED WITH IT (ON 32 BIT QUANTITIES) AND IT
HAS GOT A ROUTE INTO THE STACK, ALTHOUGH ITS PRIMARY FUNCTION IS
TO HOLD MODIFIERS.
$P
@BECAUSE REGISTERS HAVE SUCH SET FUNCTIONS AND  A
PARTICULAR REGISTER %HAS TO BE USED WHEN ITS FUNCTION IS REQUIRED,
IT WAS DIFFICULT TO SEE HOW THE CONCEPT OF THE TEMPORARY
REGISTER SPECIFICATION (THE .'$$TEMP' DIRECTIVE)  WOULD FIT INTO
THE .HAL2900 SCHEME. @AFTER ALL, THE STACK AND THE ACCUMULATOR
CAN BE USED TO HOLD  PARTIAL RESULTS OF EXPRESSIONS SO THAT
EXPLICIT SPECIFICATION OF TEMPORARY REGISTERS IS UNNECESARY.
@THE ONLY REGISTER IT APPEARED TO BE NECESSARY TO LET THE THE USER
CLAIM OR RELEASE WAS THE @B REGISTER SINCE THERE ARE A NUMBER OF
INSTRUCTIONS TO ALLOW IT TO BE USED AS A CYCLE CONTROL VARIABLE.
$P
@THIS, HOWEVER, TURNS OUT TO BE A RATHER SHORT SIGHTED VIEW.
@THERE ARE SITUATIONS, ESPECIALLY WITH .XNB, WHERE THE USER MAY
WANT TO LOAD A REGISTER WITH A PARTICULAR VALUE AND BE SURE THAT
THE REGISTER WILL NOT BE USED LATER BY THE ASSEMBLER FOR ITS OWN
PURPOSES. @IF THE ASSEMBLER DOES NEED TO USE THE REGISTER, THEN
IT SHOULD FLAG THE OCCASION BY GENERATING AN ERROR MESSAGE.
$P
@A PROBLEM WITH INDEX REGISTERS IS THAT OFFSETS ARE OF DIFFERENT
LENGTHS DEPENDING ON THE REGISTER IN USE.
@FOR EXAMPLE, OFFSETS FROM THE .LNB ARE TAKEN BY THE HARDWARE TO
MEAN A NUMBER OF WORDS; OFFSETS FROM THE .PC ARE TAKEN TO BE
A NUMBER OF HALF-WORDS (I.E. 2 BYTES). @BUT WHEN A REGISTER IS
STORED, IF IT CAN BE, THEN THE VALUE IS A BYTE ADDRESS. @THE
ASSEMBLER, THEREFORE, ASSUMES THAT ALL OFFSETS IT FINDS ARE A NUMBER
OF BYTES AND DOES THE APPROPRIATE CONVERSIONS. @THE ONLY CASES
IN WHICH THIS IS NOT TRUE IS WHEN IT DETECTS
.SF$ =$ SF+($.$.$.$.) OR .LNB$ =$ SF-($.$.$.$.) IN WHICH CASE
IT USES THE INSTRUCTIONS .ASF AND .RALN (@ADJUST @STACK @FRONT
AND @RAISE @LOCAL @NAME @BASE) WHICH ASSUME AN OPERAND WHICH IS
A NUMBER OF WORDS.
$B
$LIUC
THE EVALUATION OF EXPRESSIONS
$P
@AT FIRST SIGHT THE 2900 IS  IDEAL FOR THE EVALUATION OF EXPRESSIONS;
IT HAS A STACK, THE TOP ITEM OF WHICH (TOP OF STACK - .TOS) CAN
BE ACCESSED BY A PRIMARY ADDRESSING MODE
AND AN ACCUMULATOR
(THE REAL TOP OF STACK) WHICH CAN BE LOADED, STACK AND LOADED OR
STORED USING ANY OF THE PRIMARY ADDRESSING MODES.
$P
@ON TOP OF THIS THE .B REGISTER CAN BE USED TO A LIMITED EXTENT
AS AN ACCUMULATOR TO PERFORM ADDITION, SUBTRACTION (BUT NOT
REVERSE SUBTRACTION) AND MULTIPLICATION ON 32 BIT QUANTITIES.
@IT IS BETTER TO USE THE @B REGISTER WHEN POSSIBLE SINCE
ITS ARITHMETIC IS FASTER THAN THAT OF THE MAIN ACCUMULATOR.
$P
@THE DRAWBACKS COME IN THE WAY THE MULTIPLE LENGTH ACCUMULATOR
IS HANDLED. @OPERATIONS CANNOT BE PERFORMED DIRECTLY BETWEEN A 64
BIT ACCUMULATOR AND 32 BIT TWOS COMPLEMENT DIRECTLY OR INDIRECTLY
(I.E. VIA A DESCRIPTOR) ADDRESSED VALUES.
@IN ORDER TO CONVERT A 32 BIT VALUE TO A 64 BIT VALUE WITH
SIGN EXTENSION, THE VALUE MUST FIRST
EITHER BE LOADED INTO A 32 BIT ACCUMULATOR AND THEN, BY A DIRECT
MODIFICATION OF THE PROGRAM STATUS REGISTER, CHANGE THE SIZE TO 64 BITS,
OR IT COULD BE LOADED DIRECTLY INTO A 64 BIT ACCUMULATOR VIA A
DESCRIPTOR. @IN EITHER CASE THE RESULT IS A 32 BIT VALUE EXTENDED
ON THE LEFT TO 64 BITS WITH ZEROES. @THE SIGN EXTENSION MUST
BE DONE BY PROGRAM; A LEFT SHIFT LOGICAL 32 BITS AND A RIGHT SHIFT
ARITHMETIC 32 BITS. @THERE ARE OTHER CASES WHEN THE ACCUMULATOR
CAUSES PROBLEMS, MOSTLY TO DO WITH CONVERSION, BUT THEY DO NOT CONCERN
THIS PROJECT.
$P
@THE ASSEMBLER, THEREFORE, HAD TO HANDLE EXPRESSIONS CONSISTING
OF OPERANDS POTENTIALLY OF DIFFERENT LENGTHS AND HAD TO DECIDE
WHAT CONVERSIONS SHOULD BE DONE.
$P
@THERE IS NO 
WAY AT COMPILE TIME,
 HOWEVER, OF TELLING THE LENGTH OF
INDIRECTLY ADDRESSED DATA ITEMS. @THERE ARE 2 CHOICES HERE:
EITHER A NEW NOTATION IS INTRODUCED TO SPECIFY THE LENGTH OF
THE ITEM IMPLICITLY OR SOME EXPLICIT WAY OF DESCRIBING THE LENGTHS
OF ALL INDIRECTLY ADDRESSED ITEMS IS EMPLOYED.
$P
@THE LATTER METHOD WAS CHOSEN. @THE FORMER METHOD WOULD CERTAINLY BE
THE MOST FLEXIBLE BUT A NOTATION TO DESCRIBE ALL TYPES OF
DESCRIPTORS WOULD HAVE BEEN CUMBERSOME, PERHAPS. @THE LATTER
METHOD SEEMED TO COVER THE MAJORITY OF CASES.
$P
@SO THE .'$$ACC' DIRECTIVE WAS INTRODUCED.
@IF THE DIRECTIVE .'$$ACC$ 32' IS GIVEN THEN ALL INDIRECTLY
ADDRESSED ITEMS UP TO THE NEXT .'$$ACC' DIRECTIVE ARE ASSUMED TO BE
32 BIT TWOS COMPLEMENT VALUES. @SIMILARLY FOR .'$$ACC$ 64'.
$P
@THE PROBLEMS WHICH NOW EXISTED WERE WHEN TO USE THE .B REGISTER
AS AN ACCUMULATOR AND WHEN TO COERCE DATA TO ANOTHER LENGTH.
$P
@THE CHOICE OF ACCUMULATOR WAS MADE AT THE START OF AN EXPRESSION.
@THE .B REGISTER WAS CHOSEN WHEN .'$$ACC$ 32' WAS IN FORCE
AND ALL OPERATIONS INVOLVED IN THE EXPRESSION COULD BE PERFORMED
ON IT. @THIS ONLY SEEMED TO HAVE ONE DISADVANTAGE; THAT THERE
WAS NO REVERSE SUBTRACTION ON THE .B REGISTER AND THE OCCURENCE OF
THIS OPERATION COULD NOT BE DETECTED BY A SIMPLE SCANNING OF
THE SOURCE TEXT (AS COULD BE DONE TO DETECT OTHER NON-@B REGISTER
OPERATIONS). @SO WHEN THIS OPERATION WAS REQUIRED IN THE EVALUATION
OF AN EXPRESSION IT IS CONVERTED TO A NEGATE AND ADD OPERATION.
$P
@THE LENGTH TO WHICH ALL OPERANDS SHOULD BE CONVERTED WAS TAKEN
TO BE INDICATED BY THE CURRENT .'$$ACC' DIRECTIVE.
@THIS SEEMED LIKE THE MOST DESIRABLE LENGTH AT THE TIME BUT
PERHAPS THE LENGTH OF THE .LHS (IF IT EXISTED) WOULD HAVE BEEN
A BETTER CHOICE.
$P
@CONVERSION AT PRESENT IS ALWAYS DONE WHEN A VARIABLE IS
REQUIRED AS AN OPERAND. @THERE IS, HOWEVER, QUITE A CONSIDERABLE
AMOUNT OF CODE REQUIRED TO DO CONVERSION SO PERHAPS IT WOULD HAVE
BEEN A BETTER IDEA TO DO THE CONVERSION ONLY WHEN  NECESSARY,
DEFERRING THE CONVERSION WHEN 2 OPERANDS OF THE SAME
LENGTH ARE COMBINED IN A BINARY OPERATION, AND CONVERTING IF THE
OPERANDS ARE OF DISSIMILAR LENGTH, FOR EXAMPLE.
@THIS GIVES THE ADVANTAGE OF DOING .CONVERT(J+K+L) RATHER
THAN .CONVERT(J)+CONVERT(K)+CONVERT(L).
$P
@AFTER HAVING WRITTEN SOME TEST PROGRAMS AND HAVING EXAMINED THE CODE
PRODUCED THERE IS, PERHAPS, A BETTER SCHEME FOR EVALUATING
EXPRESSIONS WHICH COMES TO MIND. @TAKE, FOR EXAMPLE, THE EXPRESSION:
$L3IC

    DEST = $@DESC(MOD)+W(ADDR)

@THE DESTINATION OF THE EXPRESSION INVOLVED IN .DESC IS THE .DR,
THEREFORE THE OPERANDS SHOULD BE COERCED TO 64 BITS WITHOUT SIGN EXTENSION.
.MOD WILL, UNLESS SOME OTHER 'LESS$ STRONG' ADDRESSING MODE
WILL SUFFICE, BE DESTINED FOR THE @B REGISTER. @THEREFORE OPERANDS
SHOULD BE TREATED AS SIGNED 32 BIT TWOS COMPLEMENT QUANTITIES AND
COERCED TO THIS LENGTH, IF NECESSARY. @SIMILARLY FOR .ADDR EXCEPT
THAT THE POSSIBLE FINAL DESTINATION WILL BE .XNB. @THE WHOLE EXPRESSION
SHOULD THEN BE COERCED TO THE LENGTH OF .DEST.
$P
@THIS IS DIFFICULT WITH THE PRESENT STRUCTURE SINCE A BINARY OPERATION
SEES ONLY 2 OPERANDS; IT KNOWS NOTHING ABOUT THE ENVIRONMENT OF THE
EXPRESSION. @THIS COULD BE DONE BY INSERTING MORE INFORMATION
INTO THE REVERSE POLISH TO INDICATE WHAT KIND OF EXPRESSION IS
COMING UP SO  THE APPROPRIATE ACCUMULATOR AND
COERCION LENGTH CHOICES CAN BE MADE.
@THERE ARE STILL PROBLEMS WITH EXPRESSIONS WHICH HAVE NO DESTINATION,
CONDITIONS, FOR EXAMPLE,
AND THUS NO SENSIBLE GUESS CAN BE MADE ABOUT COERCION LENGTH.
@PERHAPS THE .'$$ACC' DIRECTIVE MAY BE THE CHOICE.
$B
$LIUC
ASSIGNMENTS
$P
@ASSIGNMENTS ON THE 2900 ARE NOT AS STRAIGHTFORWARD AS ON
MULTI-REGISTER MACHINES. @THE DIFFICULTY COMES BECAUSE DIFFERENT
REGISTERS AND MEMORY LOCATIONS ARE ACCESSED BY DIFFERENT INSTRUCTIONS
 WHEREAS ON MULTI-REGISTER MACHINES THEY ARE ACCESSED MORE
UNIFORMLY.
@THERE ARE SPECIAL CASES WITH .ACC$ =$ DR WHICH HAS TO BE
DETECTED IN ORDER TO USE .CYD (COPY THE DESCRIPTOR REGISTER INTO
THE ACCUMULATOR) AND WITH .B AND .TOS SINCE THEY ARE TREATED AS
REGISTERS BUT, UNLIKE THE OTHER REGISTERS, CAN BE ACCESSED
DIRECTLY BY A PRIMARY ADDRESSING MODE.
$B
$LICU
PSEUDO REGISTERS
$P
@IN MULTI-REGISTER MACHINES LIKE THE .IBM 360/370 AND THE
@INTERDATA 70/74 IT IS POSSIBLE TO ACCESS A NUMBER OF SEPERATELY
ADDRESSABLE AREAS BY ASSIGNING A REGISTER TO POINT TO THE
BASE OF EACH AREA. @ELEMENTS OF EACH AREA CAN THEN BE ACCESSED
BY SPECIFYING AN OFFSET FROM THE APPROPRIATE BASE REGISTER.
$P
@THE 2900 DOES NOT HAVE MULTIPLE INDEX REGISTERS. @THERE IS
ONLY ONE SUCH REGISTER, THE .XNB.
$P
@A FACILITY IN THE ASSEMBLER IS THEREFORE PROVIDED TO ALLOW A
NUMBER OF MEMORY LOCATIONS TO ACT LIKE INDEX REGISTERS, THE .XNB
BEING LOADED WITH THE APPROPRIATE VALUE WHEN REQUIRED.
$P
@FOR THIS PURPOSE, SIXTEEN PSEUDO REGISTERS ARE PROVIDED,
.R0$ -$ R15. @A PSEUDO REGISTER CAN BE EQUIVALENCED IN THE
.'$$DEF' STATEMENT  TO ANY EXPRESSION CAPABLE OF ASSEMBLY TIME
EVALUATION. @THE PSEUDO REGISTER CAN THEN BE USED IN PLACE OF
A REAL INDEX REGISTER IN BOTH ASSEMBLY TIME AND RUN TIME
EXPRESSIONS.
$P
@THIS EFFECTIVELY ALLOWS THE USER TO EQUIVALENCE A VARIABLE NAME
WITH AN EXPRESSION WHICH HAS AN EXTRA LEVEL OF INDIRECTION
(_N_O_T MEANING VIA A DESCRIPTOR THIS TIME), FOR EXAMPLE,
AN EXPRESSION LIKE .W(W(LNB+4)+16) IN THE FOLLOWING MANNER:
$L4CI

          $$DEF R0 = W(LNB+4)
          $$DEF K = W(R0+16)

@WHEN THE VARIABLE NAME .K IS REFERENCED, THE .XNB WOULD BE
AUTOMATICALLY LOADED WITH .W(LNB+4) AND THE .(TYPE,$ VAL) PAIR
ALTERED TO REPRESENT .W(XNB+16).
$P
@THERE IS A RATHER OBVIOUS GENERALISATION TO THIS BUT
IT WOULD PROBABLY CREATE MORE PROBLEMS THAN IT WOULD SOLVE.
@FOR INSTANCE, WHEN DOES ONE ACTUALLY 'EVALUATE' THE OBJECT AND
LOAD THE APPROPRIATE REGISTERS?
@THE METHOD WHICH IS IMPLEMENTED IS RATHER CLUMSY BUT IT COVERS
THE MAJORITY OF CASES IN WHICH INDIRECTION IS
REQUIRED.
$B
$LIUC
SEGMENTATION
$P
@THE 2900 IS A SEGMENTED MACHINE. @THAT IS, LOGICAL PROGRAM AND
DATA SECTIONS CAN BE SEPERATED BY PLACING THEM IN DIFFERENT SEGMENTS.
$P
@IT IS WORTHWHILE DISCUSSING HERE HOW MUCH THE LOADER, OR RATHER
THE PROGRAM WHICH GENERATES A FILE FOR THE LOADER, CAN EFFECT
THE WAY THE ASSEMBLER OPERATES.
$P
@THE SYSTEM ROUTINE .LPUT IS THE PROGRAM WHICH GENERATES .ERCC 2900
OBJECT FILES ON .EMAS. @A PROGRAM PASSES FRAGMENTS
OF INFORMATION TO .LPUT AND IT ASSEMBLES THEM INTO A FORMAT
SUITABLE FOR OTHER PROGRAMS TO USE AS INPUT IN ORDER TO
PRODUCE PROPER LOADER FILES. @IT IS, HOWEVER, PRIMARILY
DESIGNED FOR USE BY COMPILERS. @THE RESTRICTIONS WHICH THIS
BRINGS ARE FAR REACHING. @FOR INSTANCE, IN THE PROCESS OF THE
COMPILATION OF AN .IMP PROGRAM, INFORMATION FOR A LIMITED NUMBER
OF SEGMENTS IS GENERATED. @THESE SEGMENTS ARE THE CODE SEGMENT,
THE .GLA SEGMENT FOR STATIC DATA, THE PROCEDURE LINKAGE TABLE
FOR EXTERNAL PROCEDURE LINKING AND ANOTHER SEGMENT FOR STORING
DIAGNOSTIC INFORMATION.
.LPUT IS TAILORED TO THIS SORT OF USE; IT IS NOT INTENDED TO
PRODUCE GENERAL OBJECT FILES, CONTAINING INFORMATION
FOR AN ARBITRARY NUMBER OF SEGMENTS.
$P
@IF .LPUT IS USED, THEREFORE, THERE A RESTRICTED NUMBER OF SEGMENTS
FOR USE, OF WHICH ONLY TWO ARE REALLY USEFUL, THE CODE AND
THE .GLA SEGMENTS. @IT WOULD OBVIOUSLY BE BETTER TO USE
A MORE GENERALISED SYSTEM. @THIS COULD BE DONE BY GENERATING
LOADER INFORMATION DIRECTLY BUT THERE SEEMS TO BE SUCH A PLETHORA
OF .ICL LOADER FORMATS THAT THIS
MIGHT LEAD TO UNACCEPTABLE INFLEXIBILITY.
@THE CHOSEN LOADER FORMAT MAY BECOME AVAILABLE ON ONLY
ONE SYSTEM, FOR INSTANCE, OR THE SPECIFICATION OF THE FORMAT, LIKE
THE PRIMITIVE LEVEL INTERFACE, MAY CHANGE.
$P
@IT WAS FELT, THEREFORE, THAT THE ONLY WAY OF PRODUCING A WORKING SYSTEM,
NO MATTER HOW LIMITED THAT SYSTEM IS, WAS TO USE THE FACILITIES
ALREADY AVAILABLE.
$P
@SO, AT THE MOMENT, CODE CAN ONLY BE DUMPED IN TWO SEGMENTS, THE
CODE AND .GLA SEGMENTS, ALTHOUGH THIS DOES NOT PRECLUDE THE LINKING
IN OF OTHER SEGMENTS AT RUN TIME. @THE MECHANISM FOR DEPOSITING
VALUES IN EITHER SEGMENT IS AS FOLLOWS: WHEN THE ASSEMBLER IS
ENTERED IT IS SET UP AS CURRENTLY DUMPING IN THE CODE SEGMENT.
@TO CHANGE TO THE .GLA SEGMENT, THE CURRENT LOCATION COUNTER IS
CAPTURED (BY THE .$$DEF$ VAR$ =$ * FACILITY) AND THEN CHANGED
(BY THE .'$$LOC' DIRECTIVE) TO A VALUE CONTAINING A PSEUDO
REGISTER COMPONENT. @THE ASSEMBLER ASSUMES THAT WHEN THE LOCATION
COUNTER HAS A COMPONENT OF A PSEUDO REGISTER, THEN IT
IS REQUIRED TO DUMP CODE IN THE .GLA SEGMENT.
$P
@THIS CAN BE GENERALISED BY SPECIFYING TWO EXPRESSIONS IN
THE .'$$LOC' DIRECTIVE; THE SEGMENT REQUIRED AND THE LOCATION COUNTER
WITHIN THAT SEGMENT. @SOME SEGMENTS WOULD HAVE PREDEFINED VALUES:
0 FOR THE CODE SEGMENT AND 1 FOR THE .GLA SEGMENT, SAY.
$B
$LIUC
OPTIMISATION
$P
@THE IMPLEMENTORS OF SOME LANGUAGES (OF .PL11 [2], FOR EXAMPLE)
FEEL THAT THE CODE PRODUCED BY THE ASSEMBLER SHOULD BE
AS 'CLEAR' AS POSSIBLE. @THAT IS, IT SHOULD NOT TRY TO HIDE ANYTHING
FROM THE PROGRAMMER, AND THAT A SIMPLE INSPECTION OF THE
SOURCE PROGRAM SHOULD BE ENOUGH TO 'GUESS' WHAT CODE SHOULD BE
PRODUCED. @THEY THEREFORE FEEL THAT OPTIMISATION SHOULD ONLY
BE DONE IN VERY RARE, BUT WELL DEFINED CASES, SINCE IT LEADS
TO OBSCURE CODE BEING PRODUCED.
$P
@CERTAINLY, THE ASSEMBLER SHOULD NOT USE ANY MEMORY LOCATIONS
UNLESS THEY ARE SPECIFICALLY SET ASIDE BY THE PROGRAMMER BUT
OPTIMISATION IN TERMS OF REMEMBERING THE CONTENTS OF REGISTERS
THROUGH BASIC BLOCKS (I.E. SECTION OF CODE WITH ONE ENTRY POINT
AND ONE EXIT AND CONTAINING NO MACHINE INSTRUCTIONS) PLAYS A
LARGE PART IN SATISFYING THE FOURTH
CONSTRAINT OF THE LANGUAGE MENTIONED IN CHAPTER THREE, THAT
THE CODE PRODUCED BY THE ASSEMBLER SHOULD BE EFFICIENT.
$P
@THE MAIN OPTIMISATION DONE, IN FACT, IS TO REMEMBER THE CONTENTS OF
REGISTERS.
@THIS CAN BE DONE BY HAVING A .(TYPE,$ VAL) PAIR
ASSOCIATED WITH EACH REGISTER WHOSE CONTENTS ARE TO BE RECORDED.
@WHEN THE REGISTER IS LOADED, THE DUPLET DESCRIBING THE ITEM BEING
LOADED IS DEPOSITED IN THE RELEVANT .(TYPE,$ VAL) PAIR OF
THE REGISTER.
$P
@THE PROBLEM HERE IS THAT THERE ARE SOME .(TYPE,$ VAL) FORMS WHICH
CANNOT BE ACCESSED DIRECTLY, FOR EXAMPLE, THE VALUE OF THE
CONTENTS OF AN INDEX REGISTER PLUS AN OFFSET (AN %IMMEDIATE FORM
IN @INTERDATA TERMS), OR AN ACCESS TO A BYTE WHICH HAS TO BE LOADED
VIA A DESCRIPTOR. @BUT BY THE TIME THE CODE HAS BEEN GENERATED TO
PRODUCE A FORM WHICH CAN BE DIRECTLY REFERENCED, THE ORIGINAL
.(TYPE,$ VAL) PAIR HAS BEEN LOST. @THIS IS A DIFFICULT PROBLEM
TO GET ROUND AND IT HAS NOT REALLY BEEN SOLVED, BUT THE ASSEMBLER
STILL CATCHES A LOT OF IMPORTANT CASES.
$P
@THE CONDITION CODE, AND WHAT SET IT, IS ALSO REMEMBERED BUT THIS
IS RELATIVELY MINOR SINCE, UNLIKE THE @INTERDATA, THE LOADING
OF A VARIABLE INTO A REGISTER DOES NOT AFFECT THE CONDITION CODE.
@SO THE ONLY TIME THIS OPTIMISATION WILL PRODUCE A RESULT IS WHEN
THE SAME COMPARISON IS DONE TWICE WITHIN A SHORT ENOUGH SPACE
SO THAT THE REGISTER INVOLVED DOES NOT GET CORRUPTED.
$P
@REGISTER CONTENTS ARE FORGOTTEN WHENEVER A VALUE IS WRITTEN TO STORE
UNLESS IT IS THE CONTENTS OF THE REGISTER ITSELF WHICH ARE BEING WRITTEN
OR THE REGISTER CONTAINS A CONSTANT. @A BETTER WAY WOULD BE TO FORGET
ALL MEMORY REFERENCES IN REGISTERS IF THE STORE WAS TO BE DONE
VIA A DESCRIPTOR, BUT IF THE STORE WAS DIRECT THEN ONLY TO FORGET
REFERENCES TO THAT SAME LOCATION IN OTHER REGISTERS. @THIS IS NOT
DONE AT THE MOMENT BECAUSE IT WOULD BE TOO CLUMSY WITH THE PRESENT
SET UP - ANOTHER AREA FOR IMPROVEMENT.
$B
$LIUC
OTHER FEATURES
$P
@ALL OTHER .HALS, SO FAR, HAVE GENERATED 'STAND$ ALONE'
PROGRAMS. @THAT IS, THERE WERE NO FACILITIES FOR GENERATING
EXTERNAL REFERENCES OR ENTRY POINTS. @FOR THE 2900 IMPLEMENTATION
THIS IS IMPRACTICABLE SINCE .HAL2900 PROGRAMS WILL ALMOST ALWAYS
WANT TO INTERFACE WITH OTHER ENTITIES IN THE SYSTEM, FOR EXAMPLE,
TO DO .I/O.
$P
@TWO DIRECTIVES HAVE BEEN INTRODUCED FOR THIS PURPOSE, .'$$EXT'
AND .'$$ENT'. @BOTH ARE FOLLOWED BY A NAME, .'$$EXT' INSTRUCTING
THE LOADER TO DEPOSIT IN THE SUCEEDING TWO LOCATIONS A DESCRIPTOR
VIA WHICH THE OBJECT REFERRED TO BY THE GIVEN NAME CAN BE ACCESSED,
AND .'$$ENT' INFORMING THE LOADER THAT THE SUCCEEDING TWO LOCATIONS
WILL CONTAIN A DESCRIPTOR DEFINING AN ENTRY POINT WHICH WILL BE
EXTERNALLY REFERRED TO BY THE GIVEN NAME.
$B
$LUIC
CURRENT STATE OF THE PROGRAM
$P
@THE ASSEMBLER IS NOW AVAILABLE ON .EMAS FOR GENERAL USE.
@PROGRAMS HAVE BEEN RUN ON THE @NEW @RANGE @SIMULATOR ON .EMAS, BUT
NOT, AS YET, ON THE REAL MACHINE, ALTHOUGH THIS NOT CAUSE ANY
PROBLEMS.
$N
$L3CUM
CHAPTER 5.

CONCLUSIONS.
$P
@CHAPTER 3 DISCUSSES IN DETAIL WHAT THE ADVANTAGES MIGHT BE
OF PROGRAMMING IN HIGH LEVEL ASSEMBLERS BUT AFTER PROGRAMMING
A LITTLE IN .HAL2900 IT BECOMES CLEAR THAT VERY LITTLE CAN BE
GAINED OVER HIGH LEVEL LANGUAGES ON THIS MACHINE.
@THIS IS CONNECTED WITH FACT THAT THE ARCHITECTURE OF THE
MACHINE ENFORCES QUITE STRICT TECHNIQUES ON THE PROGRAMMER,
FOR EXAMPLE, OF ROUTINE CALLING.
 @VERY LITTLE
IS SAVED IN TERMS OF CODE PRODUCED AND IS IT REALLY WORTH IT TO
SACRIFICE EXCELLENT DIAGNOSTICS FOR WHAT IS BASICALLY JUST A
REDUCTION IN THE AWKWARDNESS OF HANDLING CERTAIN ITEMS?
@I THINK NOT.
$P
@BUT THE PRIME OBJECT OF THE PROJECT WAS NOT TO PRODUCE A
PRODUCTION SYSTEM, ALTHOUGH .I WANTED TO GET SOMETHING WORKING,
BUT MORE TO LEARN HOW TO WRITE SUCH A SYSTEM, PERHAPS PRODUCING
A PLATFORM TO A USEABLE SYSTEM ON THE WAY. @I CERTAINLY FEEL .I
HAVE PROVIDED THE LATTER.
$P
@I HAVE LEARNED A LOT ABOUT THE PROCESS OF COMPILATION, THE
PROBLEMS OF EVALUATING EXPRESSIONS AT THIS LEVEL, THE PROBLEMS
OF OPTIMISATION, AND HOW TO MANAGE A LARGE PROGRAM. @THE
PROJECT WOULD HAVE BEEN WORTHWHILE JUST TO GAIN THIS EXPERIENCE.
$N
$L3CUM
CHAPTER 6.

REFERENCES AND ACKNOWLEDGEMENTS
$B
$L17I
[1]   .PL360 - @A @PROGRAMMING @LANGUAGE FOR THE .IBM360.
      @WIRTH, .N.
      .JACM, .VOL 15 (1968), P37

[2]   .PL11 - @A @PROGRAMMING @LANGUAGE FOR THE .PDP11
      @RUSSELL, .R.
      .CERN REPORT #74-24

[3]   .PL516 - @ @PROGRAMMING @LANGUAGE FOR THE @HONEYWELL .DDP516
      @BELL AND @WICHMANN
      @SOFTWARE, .VOL 1 (1971), P61

[4]   .IMP @PROGRAMMING @LANGUAGE AND @COMPILER
      @STEVENS, @P. @D.
      @COMPUTER @JOURNAL, @VAL 17 (1965), #3


@MANY THANKS GO TO MY SUPERVISOR, @NICK @SHELNESS, WITHOUT WHOSE
HELP, ADVICE, GOOD IDEAS, AND GENERAL BRINGING DOWN TO EARTH,
@I WOULDN'T HAVE FINISHED THE PROJECT.
$B
@ALSO TO @H.$ @DEWAR WHO SUGGESTED THE PROJECT IN THE FIRST PLACE
(IN A SLIGHTLY ALTERED FORM) AND WITHOUT WHOSE AMAZING
PROGRAM .I COULDN'T POSSIBLY HAVE GOT AS FAR.
$B
@THANKS TO @JEFF @TANSLEY FOR MANUALS AND ADVICE.
$B
@THANKS TO @P.$ @STEVENS, @G.$ @MILLARD, @R.$ @WICKHAM AND OTHERS
IN .ERCC AND THE .RCO WHO GAVE ME ADVICE.
$E
