Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Design and implementation of a simple systems language for microcomputers Lee, Peter C. 1979

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1979_A7 L45.pdf [ 4.33MB ]
Metadata
JSON: 831-1.0065612.json
JSON-LD: 831-1.0065612-ld.json
RDF/XML (Pretty): 831-1.0065612-rdf.xml
RDF/JSON: 831-1.0065612-rdf.json
Turtle: 831-1.0065612-turtle.txt
N-Triples: 831-1.0065612-rdf-ntriples.txt
Original Record: 831-1.0065612-source.json
Full Text
831-1.0065612-fulltext.txt
Citation
831-1.0065612.ris

Full Text

DESIGN AND IMPLEMENTATION OF A SIMPLE SYSTEMS LANGUAGE FOR MICROCOMPUTERS by PETER C. LEE B.Math., University of Waterloo, 1977 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES (DEPARTMENT OF ELECTRICAL ENGINEERING) v We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA February 1979 (c) Peter.C. Lee, 1979 In presenting th i s thesis in par t i a l fu l f i lment of the requirements for an advanced degree at the Univers ity of B r i t i s h Columbia, I agree that the Library shal l make i t f ree ly avai lable for reference and study. I further agree that permission for extensive copying of th i s thesis for scholar ly purposes may be granted by the Head of my Department or by his representatives. It i s understood that copying or publ icat ion of th i s thesis fo r f inanc ia l gain shal l not be allowed without my written permission. j, E l e c t r i c a l Engineering Department of fL The Univers ity of B r i t i s h Columbia 2075 Wesbrook Place Vancouver, Canada V6T 1W5 n a t P F e b 2 3 ' ] 9 7 9 DE-6 B P 75-51 1 E ABSTRACT The problems of software development f o r microcomputers are st u d i e d through the de s i g n and implementation of a simple systems language, c a l l e d E. E i s a descendant of the BCPL f a m i l y of systems programming languages. D i f f e r e n c e s between E and i t s predecessors a r i s e from the de s i g n of E as a minimal language, and from the o b j e c t i v e of e n a b l i n g i n t e r a c t i v e t r a c i n g of E programs. A development system f o r E has been c o n s t r u c t e d which may operate i n a microcomputer with 16K bytes of memory. As w e l l , E programs may be developed using a c r o s s compiler which runs on a l a r g e computer system. i i i TABLE OF CONTENTS PAGE ABSTRACT i i TABLE OF CONTENTS i i i LIST OF FIGURES iv ACKNOWLEDGEMENT v 1) INTRODUCTION 1 1.1 MICROCOMPUTERS AND SOFTWARE 1 1 .2 AVAILABLE MICROCOMPUTER SOFTWARE DEVELOPMENT TOOLS 2 1.2.1 ASSEMBLER LANGUAGE PROGRAMMING 3 1.2.2 BASIC SYSTEMS 4 1.2.3 ALGOL LIKE LANGUAGES . 6 1.3 MOTIVATION AND OBJECTIVES OF THE E PROJECT 7 2) CONCEPTS OF AN E DEVELOPMENT SYSTEM 11 2.1 THE E MACHINE 11 2.2 IMPLEMENTATION OF THE E MACHINE 15 2.3 PORTABILITY 1? 2.4 TRANSLATION OF E PROGRAMS 18 2.5 TRACING E PROGRAMS ..20 3) FEATURES OF THE LANGUAGE E 24 3.1 MODULARITY 24 3.2 CONTROL STRUCTURES 24 3.3 EXPRESSIONS ' 25 3.4 DATA STRUCTURES 26 3.5 INTERRUPT AND MULTITASKING PROGRAMMING 28 4) A BRIEF DESCRIPTION OF THE LANGUAGE E 31 4.1 TOKENS 31 4.2 EXPRESSIONS 33 4.3 ACTION STATEMENTS ' 35 4.4 DECLARATIONS 3^ 4.5 DEFINITIONS . 37 5) DESIGN AND IMPLEMENTATION OF E " 39 5.1 THE SPECIFICATION 39 5.2 THE BOOTSTRAP SYSTEM • 40 5.3 AN EMULATOR OF THE E MACHINE 41 5.4 THE PORTABLE SYSTEM 42 6) CONCLUSIONS ^5 7) RECOMMENDATIONS FOR FUTURE WORK 48 REFERENCES ^9 i v APPENDIX A — ISP DESCRIPTION OF THE. E MACHINE 55 APPENDIX B — ASCII CODE OF THE E CHARACTER SETS ?0 APPENDIX C — SUMMARY OF E ASSEMBLER INSTRUCTIONS ?1 APPENDIX D — SAMPLE E PROGRAM 75 APPENDIX E — SUMMARY OF THE LANGUAGE E 84 APPENDIX F — SAMPLE USE OF A PORTABLE E DEVELOPMENT SYSTEM 90 LIST OF FIGURES FIGURE 1 — A FRAME OF THE E MACHINE 12 FIGURE 2 — ACTION OF AN E MACHINE INTERRUPT SEQUENCE 14 FIGURE 3 — AN E TRANSLATION SYSTEM 19 V ACKNOWLEDGEMENT I l i k e to thank my advisors, Dr. G.F. Schrack and Dr. P.D. Lawrence, f o r t h e i r many suggestions and comments throughout the course of the p r o j e c t . I l i k e to thank Dr. Schrack, i n p a r t i c u l a r , f o r h i s valuable extra help during the w r i t i n g of t h i s t h e s i s . 1 1). INTRODUCTION 1.1 MICROCOMPUTERS AND SOFTWARE "as long as there were no machines, programming was no problem at a l l ; when we had a few weak computers, programming became a mild problem; and now we have gigantic computers, programming has become an equally gigantic problem." (Dijkstra 72, p. 861) The relevance of this statement applies to microcomputers as much as to the gigantic computers mentioned. Within five years, a revolution in hardware technology has created the microcomputer, and along with i t , a proportionately expanding software problem (Nicholls 76, Doerr 78, Yasaki 77, Noyce 77). The problem resulted not as much from the overwhelming complexity of microcomputer software projects, as from the need to put the many new computers (Osborne 76) with different characteristics and cost trade-offs to work. The following are some of the considerations relevant to microcomputer software: A) Software is an important part of systems cost, particularly since hardware cost is low. B) Memory efficiency is important since memories form as much as 50% of the hardware cost (Kornstein 77)• C) Minimal systems software support is to be expected because of memory overhead, and the novelty of microcomputers. D) Software should be adaptable to different peripheral configurations to minimize redesign for different hardware 2 software configurations. E) Operating system concepts are required since many a p p l i c a t i o n s use the microprocessor as the co-ordination center f o r several devices. F) L i m i t s i n speed and memory w i l l cause microcomputers to be used f o r dedicated a p p l i c a t i o n s , thus causing microcomputer software to remain modest i n s i z e . Microcomputer software has to e x i s t close to the hardware l e v e l because of minimal systems support, requirement of knowledge of perip h e r a l s , and operating system c h a r a c t e r i s t i c s . The l e v e l of programming which meets these requirements i s systems programming (Wulf 71, Nichols 75 p. 32-3*0 i and software t o o l s f o r microcomputers should provide systems programming c a p a b i l i t i e s . 1.2 AVAILABLE MICROCOMPUTER SOFTWARE DEVELOPMENT TOOLS The importance of software f o r microcomputers i s well recognized, and a c t i v e work i s being done i n the area by e l e c t r o n i c s manufacturers, software companies, and research i n s t i t u t i o n s . See Gibbons 75i Bass & Brown 76, Watson 77, Bleasdale 77, Gallacher 77. Hawkins & d'Arapeyeff 77, Yasaki 77, Kahn 78, Knottek 78, and Phoenix 78 f o r general information on the t o p i c . Most a v a i l a b l e software development t o o l s f a l l i n t o one of 3 the f o l l o w i n g three categories: A) assembler language programming; B) BASIC systems; C) ALGOL l i k e languages. The f o l l o w i n g sections discuss each of these groups. Some experimental work does not f a l l i n t o any one of the above categories, i n c l u d i n g a c a l c u l a t o r system c a l l e d GAMMA (Cleaveland & Satten 76), the language C which i s another descendant of BCPL (Lucklama 77» Madden 77)» and a s i m p l i f i e d version of Pascal (Chung & Yuen 78). E a l s o does not f i t i n t o any one of the above categories. 1 .2.1 ASSEMBLER LANGUAGE PROGRAMMING Assembler languages provide a mnemonic c a p a b i l i t y to s p e c i f y the machine code of a computer. Assembler language programming i s o f f e r e d as standard support by most manufacturers of microcomputers (Motorola 751 I n t e l 76, Texas 76). Generalized assemblers are a l s o being developed (Mueller & Johnson G.R. 76). Development support c o n s i s t s of p r o v i s i o n of an assembler program, which t r a n s l a t e s the assembler language to machine code. An assembler requires l i t t l e memory, and i s thiis o f f e r e d u s u a l l y as a stand-alone program f o r the microcomputer. A text e d i t o r and some p e r i p h e r a l support i s required to complete the development system. Assembler programming has several advantages: 4 A) It i s the only tool that allows direct access of a l l the resources of the computer. Because of this a b i l i t y , assembler i s suitable for systems programming. B) Assembler language programming optimizes the speed of the software. Thus in any application which i s time c r i t i c a l , assembler i s the only choice. C) The a v a i l a b i l i t y of standalone development without much support required i s an asset since then the support cost for development i s low. D) Interactive tracing of machine code i s possible, using standard manufacturer provided monitors, since assembler language i s close to machine code. The main disadvantage of assembler language i s that i t entails inefficient use of programmer time: A) Programmer time i s the predominant cost for software development and maintenance. B) Since microcomputer architectures are f a i r l y primitive, each assembler instruction does very l i t t l e . Programs are long and are error prone. C) An assembler program i s very limited in portability. A given assembler program w i l l work only on a machine with the same instruction set. 1.2.2 BASIC SYSTEMS BASIC (Be ginners All-purpose Symbolic Instruction Code) 5 systems form a prominent part of the a v a i l a b l e software t o o l s f o r microcomputers (Maples & Fisher 77, Phoenix 78, L i e n t z 76). Most vendor o u t l e t s f o r microcomputers o f f e r sale of BASIC. Many versions are a v a i l a b l e i n varying degrees of s o p h i s t i c a t i o n . Minimum memory requirements vary from JK to 12K bytes (Phoenix 78 p. 7 ) . Standalone development f o r BASIC i s standard, and minimum support i s required. A BASIC system includes a b u i l t - i n e d i t o r , and a program i s executed as i s by the system. There are s e v e r a l reasons why BASIC i s popular: A) The main a t t r a c t i o n of BASIC i s that i t i s a complete system. Once loaded, or i n t e r f a c e d using ROM, program development can take place without other support. T h i s contrasts with the continuous t r a n s l a t i o n requirements of assemblers and compilers. B) BASIC i s easy to l e a r n . C) BASIC i s portable since i t i s simple and widely used. D) BASIC provides enough computing c a p a b i l i t y f o r c a l c u l a t o r l i k e a p p l i c a t i o n s . BASIC has s e v e r a l weaknesses (Bass & Brown 76, Ogdin 71): A) Source programs are stored i n memory and i n t e r p r e t e d . The s i z e of a program i s r e s t r i c t e d since the storage of source data i s i n e f f i c i e n t . Also, the proper use of symbolic names i s impeded, since names are r e s t r i c t e d to 2 or 3 characters i n an e f f o r t to save memory. 6 B) Features to permit modular programming and which allow programs to grow g r a c e f u l l y are missing. C) The l a c k of a b i l i t y to define complex data structures and the l a c k of access to hardware makes BASIC unsuitable f o r systems programming. BASIC i s an a p p l i c a t i o n s product t a i l o r e d f o r use i n a c a l c u l a t o r l i k e fashion. 1.2.2. ALGOL LIKE LANGUAGES Derivatives of ALGOL or P L / l which has been implemented f o r microcomputers include the languages PL/M, MPL, PL/Z, and PASCAL (Motorola 76, I n t e l 75, Brown 78, Bass 78, F y l s t r a 76, Furgerson & Gibbons 77. USCD 78).. T h i s approach a p p l i e s the concepts of high l e v e l language development ( D i j k s t r a 66, Randell & R u s s e l l 66, Wirth 70, P o l l a c k & S t e r l i n g 76, Sammet 69) to microcomputers, and i s being a c t i v e l y developed'by many groups. Support f o r these languages u s u a l l y i s i n the form of a cross-compiler. Development using a large host computer system i s encouraged, though some stand-alone systems are a v a i l a b l e . I f standalone development i s used, then a large amount of memory as well as an e d i t o r i s r e q u i r e d . Fast p e r i p h e r a l , such as disks, are u s e f u l since the power of these languages w i l l encourage correspondingly large programs. The d i r e c t i o n of t h i s approach represents the best e f f o r t thus f a r to provide software support f o r microcomputers: A) Well recognized techniques to enable easy construction of 7 complex programs are provided. B) These languages may "be used f o r systems programming since they were designed with that c a p a b i l i t y i n mind. The main weakness of t h i s approach i s that support requirements are l a r g e : A) T r a d i t i o n a l programming i s done on l a r g e computers where unlimited memory and f a s t p e r i p h e r a l s are taken f o r granted. Thus the t r a n s l a t i o n systems f o r these languages are large and complex. B) The compilers f o r these languages perform changes to the code and thus i n t e r a c t i v e t r a c i n g i s made more d i f f i c u l t . C) S u b s t a n t i a l support i s required f o r the implementation of these languages on target systems. An 8K assembler program (USCD 78 p. 9) i s required as minimal run-time support. T h i s cost may be unacceptable to users with l e s s s o p h i s t i c a t e d a p p l i c a t i o n s . D) A user may not e a s i l y adapt the language to d i f f e r e n t hardware configurations since support i s complex. 1.2 MOTIVATION AND OBJECTIVES OF THE E PROJECT The conception of E d i d not follow any of the above approaches, although i t i s c l o s e s t to the ALGOL l i k e languages. Instead, E was motivated by the BCPL family of systems programming languages which include BCPL, B, and Eh (Richards 69, Braga et a l . 76, Richards et a l . 74, Johnson S.C. 731 Braga 8 76). The approach of t h i s family contains an elegance and s i m p l i c i t y which seemed i d e a l f o r a p p l i c a t i o n s to microcomputers. As w e l l , developers of microcomputer software t o o l s have l a r g e l y overlooked these examples. This family of languages, i n c l u d i n g E, have the f o l l o w i n g common features: A) a simple and concise syntax, B) a r i c h set of operators designed f o r systems programming purposes, C) easy means to define external modules, D) an untyped p r i m i t i v e data structure, E) a c l e a r and concise Input/Output system, and F) the aim of p o r t a b i l i t y as a design goal. The language C was a l s o derived from BCPL. However, C i s not considered here to he a part of t h i s family since G r e v i v e d the idea of data types, and was adapted to one computer, the PDP-11. Differences "between E and i t s predecessors arose mainly from the objective of c r e a t i n g a minimal system. The b a s i s of t h i s goal came from D i j k s t r a : "Another lesson we should have learned from the recent past i s that the development of 'ri c h e r ' or 'more powerful' .languages was a mistake i n the sense that these baroque monstrosities, these conglomerations of i d i o s y n c r a s i e s , are r e a l l y unmanageable, both mechanically and mentally. I see a great future f o r very systematic and very modest languages. When I say 'modest', I mean that, f o r instance, not only ALGOL 60's 'FOE clause', but even FORTRAN's 'DO loop' may f i n d themselves thrown out as being too baroque." ( D i j k s t r a 72 p. 685, repeated i n Plum 77 p. 218) A minimal system means that only the features d i r e c t l y r e l e v a n t to the s o l u t i o n of a l i m i t e d problem are provided. Extra features which are not obviously u s e f u l are not included. The • simple trouble of having to implement them, and of having to think about them, i s s u f f i c i e n t j u s t i f i c a t i o n f o r t h e i r e x c lusion. Minimality also means that e x i s t i n g t o o l s are used whenever po s s i b l e , because t h e i r use decreases the amount of the system which has to be b u i l t and which has to be learned. The BCPL family formed the b a s i s of the design of E because i t addressed a problem relevant to microcomputer software, and alone seemed to be taking the. path of systematicity and modesty. BCPL i s already quite simple when compared to ALGOL or P L / l , and each of i t s subsequent developments, B, Eh, and E, i s simpler than i t s predecessor. The other major cause of the uniqueness of E derived from the goal of enabling i n t e r a c t i v e t r a c i n g f o r E. Tracing makes po s s i b l e a p o s i t i v e approach, as software may then be v e r i f i e d by monitoring d i r e c t execution, r a t h e r than the batch method of p a s s i v e l y waiting f o r errors to occur, i n the form of a "bug". The most important consequence of t h i s was the choice of p o s t f i x , or reverse P o l i s h , notation to represent expressions. More generally, the E p r o j e c t attempts to provide a way to develop software which o f f e r s the advantages of a higher l e v e l language: A) c o n t r o l structures, B) easy means of modularizing programs, C) compact representation of expressions, and D) high p o r t a b i l i t y , while s t i l l r e t a i n i n g the advantages of assembler programming: A) minimum cost i n implementation B) high memory e f f i c i e n c y C) a b i l i t y to access hardware and p e r i p h e r a l s , i n c l u d i n g i n t e r r u p t s , and D) a b i l i t y to i n t e r a c t i v e l y trace the software during program development. 11 2) CONCEPTS OF THE E DEVELOPMENT SYSTEM 2.1 THE E MACHINE An abstract computer, c a l l e d the E Machine, serves as the semantic bas i s f o r the language E. The E Machine i s more concrete when compared to s i m i l a r devices i n BCPL (OCODE, see Peck 75) and Eh (the Eh Machine, see Braga 76 p. 2 ) . The E Machine has a d e f i n i t e memory structure with a 1 6-bit address bus and an 8-bit byte at each address. A 1 6-bit word i s stored as two consecutive bytes with the high order byte having the lower address. In comparison, OCODE has a vague address bus, and does not define the word s i z e of each memory l o c a t i o n . The E Machine has a w e l l defined i n s t r u c t i o n set with a s p e c i f i c operation f o r each i n s t r u c t i o n . In comparison, the Eh Machine does not f i x the format of the data f o r i t s i n s t r u c t i o n s . Appendix A contains an I n s t r u c t i o n Set Processor (ISP, see D i g i t a l 71 Appendix C) d e s c r i p t i o n of the complete E Machine. The E Machine has four r e g i s t e r s , a program counter (PC), a stack p o i n t e r (SP) , a frame p o i n t e r (FP), and a status f l a g (FLAG). The FLAG i s used to implement an i n t e r r u p t system. The PC and the SP pl a y the obvious r o l e s . The FP i s present to enable the management of a fu n c t i o n frame. Figure 1 i l l u s t r a t e s a function frame i n the E Machine. 12 other parameters parameter of current function parameter of current f u n c t i o n return PC FT of l a s t frame Automatic Data automatic data count parameter data count 0 - unlimited other parameters 0 - 8 parameters 0 - 250 r bytes (A) GO 0 - unlimited f* parameters A Frame of 'the E Machine The E Machine i s a pure stack machine (Bulman 77)• There are no data manipulation r e g i s t e r s nor condition code b i t s . Instead, the top elements of the stack f i l l these r o l e s . An element of the stack i n the E Machine i s a 16-bit word. Thus the E Machine possesses the c h a r a c t e r i s t i c s of a 16-bit microprocessor. The o v e r a l l design of the i n s t r u c t i o n set i s quite simple. An i n s t r u c t i o n code i s always a byte. Zero to two bytes of immediate data may f o l l o w each i n s t r u c t i o n code. The 79 i n s t r u c t i o n s of the E Machine may be divided i n t o 3 groups: the housekeeping i n s t r u c t i o n s , the p r i m i t i v e functions, and other i n s t r u c t i o n s . The 20 housekeeping i n s t r u c t i o n s allow management of the stack, basic execution c o n t r o l , and function i n t e r f a c i n g . The 39 p r i m i t i v e functions are zero address operations and act as the basic computation operators of the language E. The other 20 i n s t r u c t i o n s include i n t e r r u p t , multitasking, I/O, and user i n s t r u c t i o n s . Appendices G .3, C .4, and C.5 summarize the E Machine i n s t r u c t i o n s while Appendix A describes t h e i r a c t i o n s completely. An i n t e r r u p t system i s defined as a part of the E Machine. A s i n g l e i n t e r r u p t l i n e t r i g g e r s an i n t e r r u p t sequence. An i n t e r r u p t address i s presumed to be provided along with the i n t e r r u p t , g i v i n g the E Machine a vectored i n t e r r u p t c a p a b i l i t y . An i n t e r r u p t sequence pushes the four r e g i s t e r s onto the stack, and then pushes the PC and FP again, as i l l u s t r a t e d i n Figure 2. 14 After an interrupt, the stack i s the same as after execution of a c a l l instruction to a function with 4 parameters. Thus interrupt routines may he written as functions of the language E. SP "before interrupt sequence - p CD H O o - p o fe o c o SP after interrupt sequence CM CM <M CM CM CM saved SP return PC FP of last frame saved FLAG return PC FP of last frame > 4 parameters Figure 2 - Action of an E Machine Interrupt Sequence 15 The i n s t r u c t i o n set of the E Machine i s designed to i n t e r f a c e c l o s e l y to the requirements of the language E. A token i n an E program w i l l t r a n s l a t e to at most one i n s t r u c t i o n of the E Machine. The p r i m i t i v e functions, together with some of the other i n s t r u c t i o n s , correspond exactly to the operators of the E language. Within the housekeeping i n s t r u c t i o n s , two jump i n s t r u c t i o n s together with comparison functions allow the implementation of the usual control s t r u c t u r e s , and four f u n c t i o n entry and e x i t i n s t r u c t i o n s allow a n a t u r a l l y re-entrant function c a l l i n g mechanism. 2.2 IMPLEMENTATION OF THE E MACHINE The structure of the E Machine i s quite s i m i l a r to other r e c e n t l y published abstract machines (Tenenbaum 78, Chung & Yuen 78), e s p e c i a l l y i n the function c a l l i n g and framing mechanisms. T h i s shows a convergence of ideas on the basic requirements of a machine a r c h i t e c t u r e which w i l l a i d software development, i n contrast to most a v a i l a b l e computers, which ignore the requirements of software ( D i j k s t r a 72 p. 861, Bulman 77 p. 19). The general a r c h i t e c t u r e and structure of the E Machine i s as simple as many current microprocesssors. An i n d i c a t i o n of the s i m p l i c i t y of the E Machine i s the f a c t that i t s ISP d e s c r i p t i o n i s shorter than an ISP d e s c r i p t i o n ' f o r the PDP-11 (see D i g i t a l 71, Appendix C) . Thus there seems to be no d i f f i c u l t y i n an LSI 16 realization of a microprocessor with the basic architecture of the E Machine. Such a microprocessor w i l l have a distinct software advantage over other microprocessors. Programming at the assembler level i s easier since the instructions are more powerful, and the speed and memory disadvantages of high level language implementation are eliminated. An assembler program to emulate the actions of an E Machine i s expected to be the method by which a target microprocessor i s interfaced to the semantics of the E language. Conceptually, an E Machine may also be realized by hardware, by microprogramming, or by programming in a high level language. From experience, i t was found that a 2K byte assembler program i s sufficient to realize a l l instructions of the E Machine, except interrupt and f i l e access instructions. This emulator or interpreter method of implementation has the advantage of easy interfacing requirements and high memory efficiency, and i s similar to the approach used by USCD PASCAL (USCD 78). Execution speed has been sacrificed. An assembler program w i l l be at least 10 times faster than an E Program implemented in this way. A macro or inline code generation scheme (see Richards 71) has been rejected, although i t can generate code which may execute up to five times faster than an interpretive method. The cost-of inline code-generation includes the requirement of at least three times more memory, plus a more complex implementation problem which is more sensitive to the architecture of the target machine. An example of a conflict which will tax a macro implementation is the fact that the ordering of bytes to form a 16-bit word for the Motorola 6800 and the Intel 8080 are opposite to each other. 2.2 PORTABILITY Traditionally, portability of compilers has received the major share of attention (Richards 7 1 , Braga et al . 7 6 ) . With microcomputers, this consideration is not as crucial. Instead, the main problem is the development and maintenance of software for the many target microprocessors with their many different applications. A compiler and its supporting software development system is just a special kind of application. The E Machine and its implementation is the key to the portability of E. The language E has the property that the only part of an E system which is unique to each target system is the 2K assembler program which emulates the E Machine. A given E program always translates to the same E Machine Code no matter what the target system i s . With a running emulator, the only requirement to execute E programs is the generation and loading of E Machine Code. 18 This method may be compared to that of BCPL, which uses macro translation, thus entailing a modification to the compiler for transportation of programs, or to PASCAL, which requires an 8K assembler program to interpret the language. This minimization of implementation requirements was made possible by the conception of the E Machine as a concrete hardware system with the expected restrictions in complexity and features, instead of as a loose structure which attempts either to optimize speed, l i k e BCPL, or to provide a sophisticated underlying structure, l i k e PASCAL. 2.4 TRANSLATION OF E PROGRAMS A software development system requires f a c i l i t i e s to create and edit programs, plus f a c i l i t i e s to translate high level languages to an executable code. In accordance with the aim.of using existing tools whenever possible, an editor i s presumed to be provided by the existing system. Only translation programs, ^ which translates E programs to E Machine Code, the instruction code of the E Machine, are constructed to realize an E development system. An E translation system requires two programs, A) a one-pass E Compiler to translate E programs to an intermediate language, the E Assembler Language, and B) a -two-pass E-Assembler/Linker-to translate E Assembler 19 Language modules to E Machine Code i n an absolute load module format. Since the E Machine Code produced by the t r a n s l a t i o n programs i s independent of the implementation system, cross-compiler development i s e a s i l y done. The only requirement f o r implementation on d i f f e r e n t target systems i s a modification of the Assembler/Linker to produce a s u i t a b l e load module f o r the target system. Figure 3 i l l u s t r a t e s an E t r a n s l a t i o n system. E program E Assembly Language' E Machine Code Figure 3 -- An E T r a n s l a t i o n System 20 Because of the minimization of the E language, the E Compiler, which is the more complex of the two programs, is s t i l l quite manageable. In a high level language suitable for compiler writing, a compiler may be realized in less than 4000 lines of code. A portable version of the E Compiler, written in E, may run in 16K bytes of memory. 2.j5 TRACING E PROGRAMS Tracing in any form is rarely available for high level languages. The scarcity of such tools seem to stem from a combination of neglect, plus the difficulty of developing, maintaining and using such tools. "The computer cycle consists basically of six phases:. specification, functional decomposition, coding, testing, debugging, and evaluation. In recent years software engineers have concentrated on the second and third of these phases ... Their emphasis has detracted from the progress in other phases." (Johnson M.S. 78 p. ! ) • A principal aim of the development of E is the provision of tools to allow interactive tracing. The development of extensive and complex debugging or testing software systems seems to be the only approach used thus far to provide software testing tools (see Johnson 78 p. 6-12). Such an approach is feasible on large computing systems where memory is unlimited. Even so, the complexity of these testing systems make them experimental instead of practical tools. E avoids the design and development of complex software to enable i n t e r a c t i v e t r a c i n g . Instead, e x i s t i n g assembler language l e v e l t r a c i n g systems are used. I n t e r a c t i v e t r a c i n g systems f o r assembler programming are well developed, and are offered as standard products f o r most minicomputers and microcomputers ( D i g i t a l 71 P- 16-6, Motorola 75 Section 7-2, Texas 75 Section 5.4, Tektronix 77a Chapter 10). The E Machine forms the ba s i s of the t r a c i n g method. An E program i s traced by f o l l o w i n g the execution of the E Machine. Thi s e n t a i l s a knowledge of the E Machine before t r a c i n g may be used. However, such a complexity i s unavoidable with any t r a c i n g system, and the E Machine i s a simpler construct than the semantic d e s c r i p t i o n s of most high l e v e l languages. An i n t e r f a c e i s provided i n the E development system to r e l a t e the source of an E program to i t s generated E Machine Code. The syntax of E, i n p a r t i c u l a r the use of p o s t f i x notation, i s designed so that the sequence of generated E Machine i n s t r u c t i o n s i s the same as the sequence of tokens i n the source program. Each token i s tr a n s l a t e d i n t o at most one E Machine i n s t r u c t i o n . By using the device that a n u l l E Machine i n s t r u c t i o n i s p o s s i b l e (the assembler d i r e c t i v e .NULL), each token may be though of as being t r a n s l a t e d i n t o exactly one machine i n s t r u c t i o n . Thus the E Machine Code may be thought of as an exact semantic representation of an E Program with each E Machine i n s t r u c t i o n corresponding to each token of the E program. Of course, only tokens in the action section of an E function, the statements enclosed hy the "brackets ($ and )$, result in executing E Machine Code. A correspondence of the source to the E Machine Code i s provided "by l i s t i n g s from the translator programs. The f i r s t column of numbers of the compiler l i s t i n g , l i s t e d in Appendix D.l, gives a line number to each lin e of the E program source. The second column of numbers provide a count of the relevant tokens. This count relates directly to the addresses of generated E Machine instructions as l i s t e d i n the Assembler/Linker load map of Appendix D. 2. For example, the token H.TEMP in line 34 in Appendix D.l has a count of 20 (decimal), and.is translated to an instruction with the address of 201D hexadecimal as l i s t e d in Appendix D.2. With this interface, a standard monitor may be used to trace the execution of E programs. With the normal implementation of the E Machine as an assembler program, a hardware breakpoint f a c i l i t y i s ideal. Then, a breakpoint may be planted in the generated code in a transparent fashion, and tracing may be performed exactly as with assembler programming. I f only software tracers or debuggers are available, then breakpoints may be implemented by the use of an i l l e g a l opcode, though this breakpoint i s no longer transparent. The advantage of this scheme l i e s in the fact that minimal 23 software development i s required to realize a tracing capability. The d i f f i c u l t i e s of high level language tracing are avoided. The disadvantage i s that one has to interact at a low level, using addresses and machine instructions, instead of symbolic names and high level control structures. A special monitor, written in E, to provide a standard tracing interface for E programs with special adaptation to the E Machine, i s quite feasible. The main d i f f i c u l t y of such a system i s to define an effective interfacing mechanism between the tracer and the interrupt structure of target systems. Of course, such requirements are much more complex for more extensive concepts of interactive tracing (see Johnson 78 M.S. p. 99). 3_. FEATURES OF THE LANGUAGE E ^.1 MODULARITY An E program i s a series of single level modules (see Parnas 72, Yohe 7^ P- 278) with each module being a function definition statement. There are no internal blocks or procedures. Even though the E Compiler treats each module as a separate entity, implicit linkage exists between modules. The E Assembler/Linker performs the necessary actions to link E function names and external data names. A programmer i s encouraged to write an E program as a series of small functions. Only functions exist in the E language. Subroutines are not provided since a subroutine i s simply a function with i t s result discarded. 3.2 CONTROL STRUCTURES The basic sequential, loop, and decision structures of structured programming (see Dahl et a l . 72 p. 17) are available as constructs in E. The sequential structure i s implicit in the constructs of the language which allow a l i s t of statements whenever one i s allowed. A loop structure i s provided by a while statement. A decision structure i s provided by an i f - e l s e statement. 25 A fourth structure i s the function interfacing mechanism. Function entry i s an implicit part of the semantics of the language. The appearance of a function name in an expression i s sufficient to cause entry to a function. Exit from a function i s made using a return statement, which also returns a result to the ca l l i n g routine. Limited jumps are available within a loop in E. The break statement exits from the nearest loop. A next statement immediately restarts execution of the nearest loop. An indirect function c a l l i s provided in the form of an operator, :GALLS . This f a c i l i t y allows easy writing of jump table algorithms. Neither the goto statement, nor labels within the body of a function, are defined in the language. 2-2 EXPRESSIONS In E, actual computation may only be specified in the form of an expression. An expression i s a postfix formula, with the operator following the operands. Each operator has a fixed number of operands, from zero to eight. An operand may be a constant, a byte or word of data in memory, an address of memory, or the evaluation of an operator. Operators may be one of the 59 predefined operators (see Appendix C) , or a function name. 26 Evaluation of an expression i s from l e f t to right. The postfix notation guarantees that no ambiguity i s possible. Thus neither brackets nor a hierarchy of operators exists. The use of postfix notation also means that the calling format for a function of E i s exactly the same as the use of a predefined operator. In postfix notation, an operator does not separate operands as in i n f i x notation. Operators in E require more visual distinction. Thus operator names are defined tokens which start with a : character, and are followed by any sequence of characters. For example, the predefined operator for addition i s :ADD . 3_.4 DATA STRUCTURES Like BCPL, E has a typeless data structure. The only data which may be specified in E i s a contiguous byte array. The advantages of such a data structure are described in Richards 69 p. 56I. It should be emphasized that this method of describing primitive data i s more suitable to systems programming than the provision of data types. Systems programming usually involves memory management, and requires the definition and manipulation of complex data structures: "One of the most outstanding characteristics of systems programs i s their concern with a wide variety of data structures and schemes for representing these structures. Observations of what systems programmers do reveals that a 27 large f r a c t i o n of t h e i r design e f f o r t i s spent i n constructing representations f o r e f f i c i e n t l y encoding the information to be processed" (Wulf 71). With a typeless language, such data structures may be constructed using the most powerful feature a v a i l a b l e i n a computer language, that i s , functions. A data structure i s an area of memory plus functions to manage i t . Thus, functions e f f i c i e n t l y define types. For example, the a d d i t i o n operator of E defines i t s operands as 16-bit absolute magnitude numbers. With a typed language, the construction of data structures i s impeded by the exclusive a v a i l a b i l i t y of higher l e v e l structures such as characters, numbers or records. Such structures are useful i f the intended data structure i s constructable using i t s l i m i t e d template l i k e a b i l i t i e s . When a structure does not f i t ! i n t o t h i s category, however, the d e f i n i t i o n of required data structures becomes more complex. An example of t h i s was encountered i n t h i s p r o j e c t . The problem was the construction of a symbol table f o r an E Compiler. Two compilers were written, one i n P L / l , and one i n E. In the design of the symbol t a b l e , i t was found that the normal PL/l methods f o r constructing data structures were not s u i t a b l e f o r the task. The symbol table has to be able to accommodate f a i r l y long s t r i n g s without too much waste. Thus the s t r i n g v a r i a b l e of P L / l , which always uses the maximum amount of declared memory, was not s u i t a b l e . The ordinary record structure of PL/i was also unsuitable since the information f i e l d s of symbol table entries have several formats. A based variable was not used because the rules which govern access entries in based variables were complex, vaguely described, and l i k e l y to be implementation dependent.. In the end, a symbol table entry in PL/i was designed as a series of characters in a character array and conversion was required for every access of the symbol table. In contrast, a similar entry in the E symbol table required no conversions at a l l . Thus, for this example, even PL/l, a language known for i t s range of data types, was clumsier in i t s a b i l i t y to implement a moderately complex data structure, than the typeless language E. 2.$ INTERRUPT AND MULTITASKING PROGRAMMING E avoids the incorporation of operating systems concepts, such as semaphores, communications channels, or task control structures (Habermann 76) in i t s definition. Instead, E provides the basic tools required for the writing of interrupt routines and multitasking systems. These tools, in turn, allow the implementation of higher level operating systems concepts as E functions. The semantics of interrupt programming for E i s expressed by the interrupt system of the E Machine, implemented using bits in the status flag, FLAG. Interrupt on, interrupt off, and wait 29 statements of the E language provide d i r e c t c o n t r o l of the system. The operator :INSTF provides a'software i n t e r r u p t c a p a b i l i t y . Two operators provide the c a p a b i l i t y of w r i t i n g an E program as a s e r i e s of tasks or processes. One i s a context switch operator, :CONS¥I , which loads the E Machine r e g i s t e r s from a context vector i n memory. The r e g i s t e r s , together with a reserved area of memory f o r the stack, i s s u f f i c i e n t to define completely the state of a task. A context switch enables returns from i n t e r r u p t s , the c r e a t i o n of a task, or the r e s t a r t of a deallocated task. The other i s the function return context save operator, :CONRSV . T h i s operator saves the return context of the fu n c t i o n with the topmost frame on the stack (see Appendix A), and enables a task scheduler to e x i s t as an E functi o n . The scheduler i s c a l l e d as an E function by a de a l l o c a t i n g task. On execution, the scheduler saves the r e s t a r t context of the task by the rCONRSV operator, and a l a t e r context switch to t h i s vector w i l l resume the task. The d e f i n i t i o n of the E Machine as a stack machine i m p l i c i t l y d e f ines a simple method f o r the implementation of concurrent tasks. A separate stack i s a l l o c a t e d f o r the l o c a l data area of each task. Control of a task i s done by a scheduler using the context switch and return context save i n s t r u c t i o n s . Within a task, any p r i m i t i v e function, or any user defined f u n c t i o n which i s re-entrant, may be f r e e l y used. Since the only requirement of re-entrancy i s that no external data i s modified, a task may be e a s i l y w r i t t e n as a s e r i e s of sharable E functions. 31 k) A B R I E F D E S C R I P T I O N O F T H E L A N G U A G E E E i s a p r o g r a m m i n g l a n g u a g e d e s i g n e d f o r s y s t e m s p r o g r a m m i n g a p p l i c a t i o n s f o r m i c r o c o m p u t e r s . E e v o l v e d f r o m t h e l a n g u a g e E h , d e v e l o p e d a t t h e U n i v e r s i t y o f W a t e r l o o ( B r a g a 76). T h e f o l l o w i n g s e c t i o n s o f f e r a b r i e f d e s c r i p t i o n o f E . T h e l a n g u a g e r e q u i r e s s u c h a n i n t r o d u c t i o n s i n c e i t d i f f e r s i n d e t a i l f r o m m o s t o t h e r c o m p u t e r l a n g u a g e s , i n c l u d i n g E h . A p p e n d i x E g i v e s a s u m m a r y o f t h e l a n g u a g e u s i n g B N F n o t a t i o n ( s e e S a m m e t 69 p . 5*0 . k.l T O K E N S A s e t o f 59 A S C I I ( A m e r i c a n S t a n d a r d C o d e f o r I n f o r m a t i o n I n t e r c h a n g e ) c h a r a c t e r s m a y b e u s e d t o f o r m E p r o g r a m s ( s e e A p p e n d i x B ) . E x c e p t f o r t h e e n d - o f - f i l e , c a r r i a g e r e t u r n , l i n e f e e d , a n d s p a c e c h a r a c t e r s , e a c h c h a r a c t e r l i s t e d i n A p p e n d i x B m a y b e u s e d t o f o r m a n E t o k e n . O n l y o n e r u l e n e e d s t o b e r e m e m b e r e d w h e n w r i t i n g E t o k e n s . W i t h o u t e x c e p t i o n , e v e r y t o k e n i s s e p a r a t e d f r o m t h e n e x t t o k e n b y o n e o r m o r e o f t h e s e p a r a t o r c h a r a c t e r s : c a r r i a g e r e t u r n , l i n e f e e d o r s p a c e . C o m m e n t s m a y b e w r i t t e n b y e n c l o s i n g t h e m w i t h t h e / * a n d 32 */ tokens. Comments may e x i s t between any two tokens i n an E program and are ignored d u r i n g c o m p i l a t i o n . E Assembler Language codes may be i n t e r s p e r s e d w i t h i n an E program by e n c l o s i n g them w i t h the /" and "/ tokens. The assembler escapes are emitted as i s t o the ob j e c t f i l e , ' and are otherwise ignored d u r i n g c o m p i l a t i o n . The b a s i c vocabulary of E c o n s i s t s of constants, data names, f u n c t i o n names, keywords, and p r e d e f i n e d operators. D i f f e r e n t kinds of tokens are u s u a l l y i d e n t i f i a b l e by the f i r s t c h a r a c t e r of the token. One may w r i t e decimal, hexadecimal, c h a r a c t e r , or s t r i n g constants: A) A decimal constant s t a r t s w i t h a + or a - ch a r a c t e r , e.g. +3070 +03 -0001 B) A hexadecimal constant s t a r t s w i t h a $ c h a r a c t e r , e.g. $80 $0000 $2DFE C) A character constant s t a r t s w i t h a * ch a r a c t e r , e.g. •A '$ D) A s t r i n g constant s t a r t s w i th'a " c h a r a c t e r , e.g. "00 "THISISASTRING :• A three c h a r a c t e r hexadecimal constant may be embedded i n a s t r i n g t o denote a byte of any v a l u e , e.g. "$00 "THIS$20IS$20A$20STRING In a d d i t i o n the keywords TRUE and FALSE each represent s p e c i a l constants which are produced by comparison f u n c t i o n s . 33 D a t a names a r e u s e d t o a c c e s s an a r e a o f memory. A d a t a name s t a r t s w i t h an a l p h a b e t c h a r a c t e r , e . g. H.STR H.TEMP AK SYM.SPT F u n c t i o n names e n a b l e a c c e s s o f u s e r d e f i n e d f u n c t i o n s . A f u n c t i o n name s t a r t s w i t h a c o l o n , e.g. :FERROR.G :SYM.HASH :SYM.CLR One may a l s o s p e c i f y a n a d d r e s s name, a n d a n a s s i g n m e n t name. The a d d r e s s name f i l l s t h e r o l e o f t h e a d d r e s s o p e r a t o r i n Eh ( s e e B r a g a 76 p . 1 4 ) . An a d d r e s s name i s a d a t a name o r a f u n c t i o n name w i t h an added ampersand c h a r a c t e r , e . g. &SYM.SPT &AK &:SYM.HASH An a s s i g n m e n t name i s u s e d t o a s s i g n d a t a t o memory. An a s s i g n m e n t name i s a d a t a name w i t h an added e q u a l s i g n , e.g. =H.STR =AK =SYM.SFS Keywords a r e r e s e r v e d , and a r e l i s t e d i n A p p e n d i x E . l . The p r e d e f i n e d o p e r a t o r s p r o v i d e b a s i c c o m p u t a t i o n c a p a b i l i t y t o E pr o g r a m s , a n d a r e a l s o r e s e r v e d . They a r e l i s t e d i n A p p e n d i x E.2. The o p e r a t o r s i n t e r f a c e d i r e c t l y t o t h e s t a c k i n s t r u c t i o n s o f t h e E M a c h i n e . Thus, A p p e n d i x C and A p p e n d i x A may be c o n s u l t e d f o r d e t a i l s on t h e o p e r a t i o n s o f t h e p r e d e f i n e d o p e r a t o r s . 4.2 EXPRESSIONS 34 E, l i k e BLISS (Wulf 71), i s an expression oriented language. An expression i n E i s a p o s t f i x formula, with an operator f o l l o w i n g a l i s t of operands. The number of operands i s a property of the operator. An operator i n E may be a predefined operator, or a f u n c t i o n name. For the predefined operators, the number of operands i s predetermined. For function names, the number of operands i s a declared value of each function name. An operand may be a constant, a data name, an address name, or the evaluation of an operator. Evaluation of an expression occurs from l e f t to r i g h t . No ambiguity i n the order of evaluation i s p o s s i b l e because of the p o s t f i x notation. Thus there are no brackets, nor i s there a hierarchy of operators. E has no assignment statements. Instead, an assignment name i n an expression assigns the l a s t operand evaluated to the designated data name. For example, the expression H.TEMP +03 :RMUL H.STR :B@ :ADD =H.TEMP i s interpreted as follows: A) M u l t i p l y ( :RMUL ) H.TEMP and +03 . B) Get the byte ( :B@ ) with address i n H.STR . C) Add ( :ADD ) the r e s u l t s of (A) and (B) . D) Assign (=H.TEMP ) the r e s u l t of (C) to H.TEMP . 4.2 ACTION STATEMENTS A c t i o n statements are w r i t t e n t o evaluate expressions and to p r o vide program c o n t r o l s t r u c t u r e s . The e v a l u a t i o n statement simply e v a l u a t e s an expression w i t h no other e f f e c t s , e.g. EVAL H.STR :DEC =H.STR The w h i l e statement a l l o w s the w r i t i n g o f a loop s t r u c t u r e . The w h i l e statement begins wit h the keyword WHILE , f o l l o w e d by an e x p r e s s i o n , f o l l o w e d by a l i s t of a c t i o n statements enclosed i n (* and *) brac k e t s , and f o l l o w e d by a j token. The a c t i o n of a w h i l e statement c o n s i s t s of the repeated e v a l u a t i o n of the ex p r e s s i o n , f o l l o w e d by execution of the l i s t of a c t i o n statements, as lon g as the expression e v a l u a t e s t o TRUE. When the expression does not evaluate t o TRUE, the loop ends. L i n e s 33 t o 3? i n Appendix D.l provide an example of a wh i l e statement. The i f - e l s e statement a l l o w s the w r i t i n g of a d e c i s i o n s t r u c t u r e . An i f - e l s e statement c o n s i s t s o f an i f c l a u s e , f o l l o w e d by any number of e l s e c l a u s e s . The i f clause s t a r t s w i t h the keyword I F , and an e l s e c l a u s e s t a r t s w i t h the keyword ELSE. An epxression f o l l o w s the keyword, which i s f o l l o w e d by a l i s t of a c t i o n statements enclosed i n (? and )? b r a c k e t s . The expressions of the cl a u s e s are evaluated one a f t e r the other. 36 When one evaluates to TRUE, the l i s t of action statements of the clause i s executed, followed by a skip of a l l the other else clauses in the statement. Lines 63 to 73 in Appendix D.l provide an example of an if - e l s e statement. The expression may be absent for a while statement, or an else clause. In both cases, the absence of an expression i s equivalent to the presence of a TRUE constant as expression. The return statement exits from a function, and returns the evaluation of i t s expression to the calling routine, e.g. RETRN "4-0 G. INDEX :SYM.SPT ; The four statements above are sufficient to write most E programs. Six other statements exist. Each consists only of a keyword followed by a ; token. They are present to halt a program, to control interrupts, and to exit from loops. 4.4 DECLARATIONS A l l data names and function names in action statements must be previously declared. A declaration statement starts with the keyword DECL . The second token specifies the kind of name. The keywords PARAM, AUTO, EXTRN, and FNCTN specify parameter data, 37 automatic data, external data, and function names respectively. Parameter data i s i n i t i a l i z e d on entry to a function, and corresponds to the operands of a function c a l l in an expression. Automatic data i s local data which i s allocated on entry to a function. External data corresponds to static data in memory. Functions are the defined functions of an E program. The third token of a declaration statement contains the name being declared. The fourth token indicates the type attribute of the name. Type i s a non-negative decimal number. The keyword BYTE corresponds to type of +1, and the keyword WORD corresponds to type of +2. For data names, type indicates the number of contiguous bytes of the data area accessed through the name. A parameter always has type WORD . Since a parameter may hold at most one 16-bit word, only data of the type BYTE or WORD may appear as an operand in an expression. For function names, type i s the number of parameters of the function. Lines 86 to 100 in Appendix D.l contain declarations of a l l the different kinds of names of E. DEFINITIONS A series of function definitions form the bulk of E 38 programs. The structures of the previous sections a l l contribute to the formation of a function definition. A function definition consists of the keywords DEF FNGTN , followed by the function name, followed by a l i s t of declarations enclosed in (# and )# brackets, followed by a l i s t action statements enclosed in ($ and )$ brackets, and followed by a ; token. Lines 155 to 177 in Appendix D.l provide an example of a function definition. A definition of a function must exist in an E program before the function may be declared and used.. External data also have to be defined before i t may be declared and used. External data are defined by the external definition statement. This consists of the words DEF EXTRN , followed by the data name, followed by the type, followed by an optional initialization l i s t of constants or address names. Lines 261 to 264 of Appendix D contain examples of external data definition statements. Synonyms may be specified for constants using the manifest constant definition statement. For example, DEF MCON EOS$ $80 ; specifies the data name E0S$ to be the synonymn of the hexadecimal constant $80. 39 5_i DESIGN AND IMPLEMENTATION OF E J5..1 THE SPECIFICATION The design of an E development system required five months of work, and resulted in the document "E Language Specification" (Lee 7 8 ) . The syntax of E was developed using the structure of simple precedence grammar (see Aho & Ullman 77 p. 194-196) . The direct application of simple precedence grammar was possible only because of the spartan nature of E language constructs. Other languages usually require more complex theoretical frameworks, such as an LALR grammar (see Aho & Ullman 77 Chapter 6) . The semantics of E was defined as a combination of the action of the E Machine, plus the translation of E programs to E Machine Code. An intermediate language, the E Assembler Language, was defined as the interface between the E Compiler and the E Assembler/Linker. The method i s somewhat ad hoc. However, i t s key elements, an abstract machine, an intermediate language, and the use of syntax directed translation (see Aho & Ullman 77 Chapter 7)» represent relatively well formed techniques within the underdeveloped f i e l d of semantics specification. j>.2 THE BOOTSTRAP SYSTEM The implementation g o a l of the p r o j e c t was the r e a l i z a t i o n o f a microcomputer-based E development system. I t was decided t o use E t o support t h i s microcomputer software development. T h i s choice provided e f f i c i e n t use of memory, p o r t a b i l i t y of the product, as w e l l as a means to e x e r c i s e and t e s t the E method of d e v e l o p i n g software. However, an E development system must be a v a i l a b l e before E programs may be w r i t t e n and executed. T h i s i n i t i a l system i s c a l l e d the bootstrap system, and c o n s i s t s of an E Compiler and an E Assembler/Linker developed u s i n g the Michigan Terminal System (MTS) of the Computer Center of U n i v e r s i t y of B r i t i s h Columbia (Leigh 76, H a l l 77, Amos 77). The s e l e c t i o n of an implementation language was a choice between P L / l , and BCPL. P L / l was chosen mainly because of i t s wider a v a i l a b i l i t y . In r e t r o s p e c t , i t seems t h a t BCPL might have been more s u i t a b l e , as i t s use would have e n t a i l e d a lower c o s t i n programming and computing time. P L / l was chosen a l s o because i t provided a b a s i s of comparison between E and P L / l , s i n c e the same t r a n s l a t i o n programs w i l l be w r i t t e n u s i n g E immediately afterwards (see S e c t i o n 3•4). Such a comparison i s not u s e f u l w i t h BCPL, s i n c e E and BCPL are r e l a t i v e l y a l i k e . The E Bootstrap Compiler c o n s i s t of 3500 l i n e s of P L / l source codes and t a b l e s , w h i l e the E B o o t s t r a p Assembler/Linker c o n s i s t s of 2500 l i n e s . T h e i r completion r e q u i r e d three months 4 1 of work, and resulted in a cross-compilation development system using PL/i and MTS. The compiler has a basic error recovery capability, so that a syntax error w i l l not terminate compilation. Instead, the remaining tokens of a module are discarded, with compilation continuing at the beginning of the next definition statement. 5_._3_ AN EMULATOR OF THE E MACHINE A program was written to emulate the actions of the E Machine using the Motorola 6800 f a c i l i t i e s of the Tektronix 8002 uProcessor Development System (Tektronix 77a, Tektronix 77b) at the Department of E l e c t r i c a l Engineering of the University of Brit i s h Columbia. This development required only half a month of work. The main portion of the emulator, which implements the system independent portions of the E Machine, consists of a 2K byte assembler program. An additional 0.5K bytes was allocated for the E Machine stack. An E program implements the f i l e access features of the emulator, and occupies IK bytes of memory. This use of E minimized programming in assembly language and also gave an i n i t i a l test of E as a systems language. An interrupt system was not implemented because of lack of access to interrupt f a c i l i t i e s on the development system. 42 j$.4 THE PORTABLE SYSTEM The E bootstrap translators and the E emulator allowed the development and execution of E programs which may access f i l e s . This development system was used to construct the translation programs to provide a portable E development system. The system i s portable because only two steps are required for a transfer of the translation programs to other small machines: A) the implementation of an emulator of the E Machine on the target system which executes a l l the combinatorial instructions, plus the f i l e interfacing instructions, and B) the interfacing required to load the E Machine Code produced by translator programs into the memory of the target system. An Assembler/Linker was constructed f i r s t using a pure cross compilation method. Load modules of E Machine Code were downloaded from MTS to the Tektronix system using an ordinary 300 baud RS232C asynchronous terminal li n k . The result was a 1800 line E program which translated to approximately 4K bytes of E Machine Code. Together with the E emulator of 3-5K "bytes, and a symbol table of % bytes, the portable Assembler/Linker may thus run in I3K bytes of user memory. The portable E Assembler/Linker requires 1 second of processor time to process 30 characters of input. This speed i s quite slow, but i s comparable to the printing speed of the hardcopy terminal attached to the microprocessor development 43 system. The speed may be' improved by an assembler implementation of some of the modules of the program. The user f u n c t i o n s of the E language were i n c o r p o r a t e d t o i n t e r f a c e such assembler r o u t i n e s . The assembly speed may a l s o be improved by d e c r e a s i n g the number of c h a r a c t e r s i n the mnemonics of the i n t e r m e d i a t e language, thus decreasing the computing requirement of the Assembler/Linker. Once the p o r t a b l e Assembler/Linker was completed, i t was used t o assemble the E Assembler Language modules of the de v e l o p i n g p o r t a b l e E Compiler. Thus o b j e c t modules, i n s t e a d of a l o a d module, was downloaded from MTS. The d e s i g n of a l l f i l e s i n the E development system as ASCII f i l e s w i t h a l i m i t e d c h a r a c t e r set f a c i l i t a t e d the communications requirements. The a b i l i t y of the Assembler/Linker t o assemble the p o r t a b l e E Compiler a l s o means that the E development system on the T e k t r o n i x system may be s e l f - m a i n t a i n e d . An E Compiler may d e a l w i t h a r b i t r a r i l y l a r g e E programs, s i n c e the symbol t a b l e i s erased a t the end of each module. Thus, as l o n g as each module i s kept s m a l l , the compiler should have no symbol t a b l e o v e r f l o w . Such a s i t u a t i o n does not h o l d f o r the Assembler/Linker, which has t o remember a l l the e x t e r n a l data names and f u n c t i o n names of a complete program. The p o r t a b l e E compiler c o n s i s t s of a 3^00 l i n e program which t r a n s l a t e s t o 8K bytes of E Machine Code. Together w i t h 3.5K bytes of the emulator, and 4K bytes of symbol t a b l e , t h i s / 44 r e s u l t s i n a co m p i l e r which may run i n 16K bytes o f user memory. The speed of the Compiler i s comparable t o t h a t of the Assembler/Linker. The p o r t a b l e t r a n s l a t i o n programs were completed i n one and a h a l f months. The f a s t completion time was p o s s i b l e p a r t l y t o the f a c t t h a t the same programs had a l r e a d y been w r i t t e n u s i n g P L / l . However, t h i s has t o be balanced a g a i n s t the f a c t t h a t the development system a v a i l a b l e f o r the p o r t a b l e system was more p r i m i t i v e than MTS, and executed e v e r y t h i n g a t a slower speed. The p i v o t a l f a c t o r was the use of i n t e r a c t i v e t r a c i n g t o t e s t the E programs. T h i s experience w i t h t r a c i n g confirmed i t s usefulness i n q u i c k l y o b t a i n i n g enough knowledge on the execution behaviour o f a program t o v e r i f y i t s c o r r e c t n e s s , and a l s o i n p i n p o i n t i n g any e r r o r s t h a t i n t e r f e r e w i t h e x e c u t i o n . Appendix F c o n t a i n s a sample program which i l l u s t r a t e s the development sequence o f an E program u s i n g the p o r t a b l e system as implemented on the T e k t r o n i x system. The sample program sums an a r r a y of 6000 1 6-bit numbers, and a l s o g i v e s a b a s e l i n e f o r the performance of E programs. The compiled code f o r the sample program occupied 48 bytes of memory, and r e q u i r e d 8 seconds t o execute. T h i s may be compared with a Motorola 6800 assembler program t o perform the same computation, which occupied % "bytes of memory and r e q u i r e d 0.4 seconds t o execute. ^5 61 CONCLUSIONS A development system, which enables the development of systems l e v e l software f o r microcomputers u s i n g the language E, has been co n s t r u c t e d . The t r a n s l a t i o n programs which form the development system has been e x t e n s i v e l y t e s t e d . I n p a r t i c u l a r , a p o r t a b l e E Compiler, and a p o r t a b l e E Assembler/Linker has been v e r i f i e d by t h e i r use i n c o m p i l i n g and l i n k i n g themselves. Thus, a p o r t a b l e development system e x i s t s f o r E which has been demonstrated t o be s e l f m a i n t a i n i n g . The performance of the system has been evaluated by the generation and execution of a sample program. Comparison of the E program w i t h an e q u i v a l e n t assembler program showed t h a t the code generated from an E program i s a t l e a s t as memory e f f i c i e n t as assembler programming, and t h a t an E program executes 20 times slower than an assembler program. Developing software u s i n g E has the f o l l o w i n g implementation advantages: A) The . implementation of E on a t a r g e t system r e q u i r e s only a 2K byte assembler program as b a s i c support. B) A p o r t a b l e t r a n s l a t i o n system f o r E i s a v a i l a b l e which can run on a microcomputer w i t h 16K bytes of memory. A l t e r n a t i v e l y , a t r a n s l a t i o n system f o r E i s a l s o a v a i l a b l e on l a r g e computers which support P L / i . C) An E program uses memory a t l e a s t as e f f i c i e n t l y as 46 assembler programming. D) By the correspondence of the source E program t o the generated E Machine Code, i t i s p o s s i b l e t o use i n t e r a c t i v e t r a c i n g t o t e s t E programs. The m e r i t s of E as a programming language i n c l u d e the f o l l o w i n g : A) E i s s i m p l e r than most other languages i n t h a t i t embodied fewer concepts i n i t s c o n s t r u c t i o n . Thus, the e f f o r t r e q u i r e d t o l e a r n and master the use of E as a t o o l i s s m a l l e r than f o r other languages, and the chances of E c o n f u s i n g i t s users (Plum 77) i s diminished. B) The development of software as a s e r i e s of s m a l l modules i s encouraged by the ease with which e x t e r n a l f u n c t i o n s may be w r i t t e n . C) Higher l e v e l s e q u e n t i a l , d e c i s i o n , and loop s t r u c t u r e s are used t o c o n t r o l execution. D) Features are i n c l u d e d to enable the use of E as the means t o r e a l i z e o p e r a t i n g systems. E) Complex data s t r u c t u r e s may be e a s i l y c o n s t r u c t e d by the use of f u n c t i o n s because E does not pre d e f i n e d a t a types. To balance these advantages, the implementation method f o r E d e s c r i b e d here s u f f e r s from l o n g execution t i m e s . As w e l l , E i s u n f a m i l i a r t o programmers because many of the t r a d i t i o n a l f e a t u r e s p r e s e n t i n high l e v e l languages are not i n c l u d e d . 47 The experience of the p r o j e c t showed t h a t computer language development i s a complex a c t i v i t y . Some of the p a r t s of the problem, such as semantics, syntax, implementation, o p e r a t i n g systems, programming p r a c t i c e s , and software t e s t i n g , form e n t i r e f i e l d s by themselves. The challenge was the i n t e g r a t i o n of the e x i s t i n g knowledge i n these f i e l d s t o produce a u s e f u l t o o l w i t h i n the l i m i t a t i o n s of microcomputer technology. Seen i n t h i s l i g h t , the r a p i d completion of development systems f o r the language E showed the value of the approach of m i n i m i z i n g a problem whenever p o s s i b l e , and of making use of a v a i l a b l e t o o l s whenever p o s s i b l e . "We s h a l l do a much b e t t e r programming job, p r o v i d e d t h a t we approach the t a s k w i t h a f u l l a p p r e c i a t i o n o f i t s tremendous d i f f i c u l t y , p r o v i d e d t h a t we s t i c k t o modest and elegant programming languages, provided t h a t we respect the i n t r i n s i c l i m i t a t i o n s of the human mind, and approach the task as Very Humble Programmers." ( D i j k s t r a 72 p. 866) 48 72 RECOMMENDATIONS FOR FUTURE WORK The s u c c e s s f u l c o n s t r u c t i o n of a p o r t a b l e E t r a n s l a t i o n system has demonstrated the usefulness of E as a compiler w r i t i n g t o o l . However, many of the other p r o p e r t i e s mentioned have not yet been v e r i f i e d , i n c l u d i n g : A) p o r t a b i l i t y , which may be t e s t e d by the implementation of E Machines and E development systems on d i f f e r e n t microprocessors and minicomputers, B) o p e r a t i n g systems f e a t u r e s , which may be t e s t e d by usin g E t o w r i t e an ope r a t i n g system, and C) relevance to the microcomputer software development, which may be t e s t e d by u s i n g E to w r i t e the software of complete microcomputer a p p l i c a t i o n s . The r e a l i z a t i o n of an E Machine u s i n g microprogramming on a minicomputer, or usin g b i t s l i c e hardware such as the AM2900 • (Advanced 76), may a l s o be an i n t e r e s t i n g development. Such a r e a l i z a t i o n of an E Machine w i l l demonstrate the usefulness of the stack machine concept by the removal o f the execution time disadvantages of E programs. 49 REFERENCES Advanced M i c r o Devices I n c . , (1976), "The AM2900 Family Data Book", Advanced Micro Devices I n c . , C a l i f o r n i a , U.S.A., 1976 (172 pages). • Aho A.V., Ullman J.D., (1977), " P r i n c i p l e s of Compiler Design", Addison-Wesley P u b l i s h i n g Co., On t a r i o , 1977 (604 pages). Amos D., (1977), "Using P L / i a t UBC", Computing Center, U n i v e r s i t y of B r i t i s h Columbia, Vancouver, Nov. 1977 (81 pages). Bass C , (1978), "PL/Z: A Family of Systems Programming Languages f o r Microcomputers", IEEE Computer v o l . 11 no. 3 i p. 34-39, March 1978. Bass C , Brown D., (1976), "A P e r s p e c t i v e on Microcomputer Software", P r o c . of the IEEE vol.64 no.6, p. 905-909, June 1976. B l e a s d a l e E., (1977), "Development of High-Level Languages", Microp r o c e s s o r v o l . 1 no. 4, p. 241-244, A p r i l 1977-Braga R., (1976), "Eh Reference Manual", Dept, o f Comp. S c i . , U n i v e r s i t y of Waterloo, Waterloo, O n t a r i o , 1976 (32 pages). Braga R., Malcolm M.A., Sager G.R., (1976), "A P o r t a b l e L i n k i n g Loader", Symposium on Trends and A p p l i c a t i o n s 1976, p. 124-128, IEEE Computer S o c i e t y , 1976. Brown W.L., (1978), "Modular Programming i n PL/M", IEEE Computer v o l . 11 no. 3, p.40-46, March 1978. Bulman D.M., (1977), "Stack Computers: An I n t r o d u c t i o n " , IEEE Computer v o l . 11 no. 5, p. 18-28, May 1977. Cleaveland J.C., Satten CD., (1976), "The Design and Implementation of a Simple Programming Language f o r Microcomputers", AFIPS Conf. Proc. V o l . 64, p. 629-635. AFIPS P r e s s , 1976. 50 Chung K.M., Yuen H., (1978), "A Ti n y P a s c a l Compiler", Byte v o l . 3 no. 9, p. 58-65, Sept. 1978. Dahl O.J., D i j k s t r a E.W., Hoare C.A., (1972), " S t r u c t u r e d Programming", Academic P r e s s , New York, 1972 (150 pages). D i g i t a l Equipment Corp., (1971), "PDP-ll/ 2 0 , 1 5 , r 2 0 Processor Handbook", D i g i t a l Equipment Corp., U.S.A., 1971 (app. 150 pages). D i j k s t r a E.W., (1966), "A Primer of ALGOL 60 Programming", Academic P r e s s , New York, I966 (114 pages). D i j k s t r a E.W., (1972), "The Humble Programmer", CACM v o l . 15 no. 10, p.859-866, Oct. 1972. Doerr J . , (1978), "Low-Cost Microcomputing: The Pe r s o n a l Computer and Single-Board Computer R e v o l u t i o n s " , Proc. of the IEEE v o l . 66 no. 2, p. 117-130, Feb. 1978. Furgerson D.F., Gibbons A.J., (1977), "A High-Level M i c r o -processor Programming Language", Proc. of Compcon '77, IEEE Computer S o c i e t y , p. 185-188, 1977-F y l s t r a D.H., (I976), "PL/M6800: A Compatible High-Level Language f o r the Motorola Microprocessor", Proc. of the 1976 Symposium on Trends and A p p l i c a t i o n s , IEEE Computer S o c i e t y , p. 103-106, 1976. G a l l a c h e r J . , (1977), "Software f o r Hardware Engineers", Microprocessor v o l . 1 no. 3 , p. 169-180, Feb. 1977. Gibbons A.J., (1975), "When t o Use Higher L e v e l Languages i n Microcomputer Based Systems", E l e c t r o n i c s v o l . 48 no. 6, p. 107-111, Aug. 7 1975. Habermann A.N., (I976), " I n t r o d u c t i o n t o Operating System Design", Science Research A s s o c i a t e s I n c . , Toronto, 197& (372 pages). H a l l R.H., (ed.), (1977), "The MTS Commands Manual", Computing Center, U n i v e r s i t y of B r i t i s h Columbia, Vancouver, Feb. 1977 (123 pages). 51 Hawkins C , d'Arapeyeff A., (1977), "Developing Software f o r M i c r o s " , Datamation v o l . 23 no. 7, p. 76-80, J u l y 1977. I n t e l Corp., (1975), "8008 and 8080 PL/M Programming Manual (Rev. A ) " , I n t e l Corp., U.S.A., 1975 (app. 100 pages). I n t e l Corp., (1976), "8080 Assembler Language Programming Manual (Rev. C)", I n t e l Corp., U.S.A., 1976 (62 pages). Johnson S.C, (1973), "User's Reference t o B on TSS", B e l l L a b o r a t o r i e s , Murray H i l l , New Jersey, U.S.A., 1973 (32 pages). Johnson M.S., (1978), "The Design and Implementation of a Run-Time A n a l y s i s a n d - I n t e r a c t i v e Debugging Environment", Ph.D. T h e s i s , Dept. of Comp. S c i . , U n i v e r s i t y of B r i t i s h Columbia, Vancouver, 1978 (194 pages) . Kahn K . C , (1978), "A Small-Scale Operating System (Foundation f o r M i c r o p r o c e s s o r A p p l i c a t i o n s " , P r o c. of the IEEE v o l . 66 no. 2, p. 209-216, Feb. 1978. Knottek N. f (I978), "Mini and Microcomputer Survey", Datamation v o l . 24 no. 8, p. 113-131, Aug. 1978. K o r n s t e i n H., (1977), "Memories and Microcomputers", M i c r o p r o c e s s o r v o l . 1 no. 4, p. 253-257, A p r i l 1977. Lee P.C., (1978), " S p e c i f i c a t i o n of the Language E", Memorandum to Dr. C F . Schrack, Dept. of E l e c . Eng., U n i v e r s i t y of B r i t i s h Columbia, Vancouver, Nov. 1978 (90 pages, 160 pages appendices). L e i g h J.L., (1976), " I n t r o d u c t i o n t o the Computing Center and MTS", Computing Center, U n i v e r s i t y of B r i t i s h Columbia, Vancouver, Sept. 1976 (62 pages). L i e n t z B.P., (I976), "Comparative E v a l u a t i o n of Ve r s i o n s of BASIC", CACM v o l . 19 no. 4, p. 175-181, A p r i l 1976. Lucklama H., (1977), "UNIX on a Mic r o p r o c e s s o r " , Proc. of the AFIPS 1977 N a t i o n a l Computer Conference, p. 237-242, AFIPS P r e s s , 1977. 52 Madden J.G., (1977), "C: A Language for Microprocessors", Byte vol. 2 no. 10, Oct. 1977. Maples M.D., Fisher E.R., (l977). "Real-Time Microcomputer Applications Using LLL BASIC", IEEE Computer vol. 10 no. 9. . p. 14-21, Sept. 1977. Motorola Inc., (1975), "M6800 Microprocessor Applications Manual", Motorola Inc., U.S.A., 1975 (app. 400 pages). Motorola Inc., (1976), "MPL Language for the M6800 Microprocessor (Preliminary)", Motorola Inc., U.S.A., March 1976 (60 pages). Mueller R.A., Johnson G.R., (1976), "ASM/GEN: A Cross-Assembler Generating System for Microcomputers", Colorado State University, Colorado, U.S.A., 1976. Nicholls J.E., (1975), "The Structure and Design of Programming Languages", Addison-Wesley Publishing Co., Ontario, 1975 (571 pages). Nicholls J.E., (1976), "An Overview of Microprocessor Applications", Proc. of the IEEE vol. 64 no. 6,-p. 951-953, June 1976. Noyce R.N., (1977), "Microelectronics", Scientific American Vol. 237 no. 3 , p. 62-69, Sep. 1977. Ogdin J.L., (1971), "The Case Against BASIC", Datamation vol. 15 no. 9, P- 3 4 - 4 1 , Sep. 1 1971. Osborne A., (I976), "An Introduction to Microcomputers: Vol. II Some Real Products", Adam Osborne and Associates Inc., U.S.A., 1976 (app. 400 pages). Parnas D.L., (1972), "On the Criteria to be Used in Decomposing Systems into Modules", CACM vol. 15 no. 12, p.° 1053-1058, Dec. 1972. Phoenix Group Inc., (1978), "Byte Shopper: The Microcomputer Guide (Issue No. 3)", Microage Wholesale, U.S.A., Spring 1978 (72 pages). 53 Peck J.E., (1975), "The Essence of Computer Science", Dept. of Comp. S c i . , U n i v e r s i t y of B r i t i s h Columbia, Vancouver, 1975 (47 pages) . Plum T., (1977), " F o o l i n g the User of a Programming Language", Software: P r a c t i c e and Experience v o l . 7» P- 215-221, 1977. P o l l a c k S.V., S t e r l i n g T.D., (1976), "A Guide t o P L / l " , H o l t , R i n e h a r t , and Winston, Toronto, 1976 (63O pages). R a n d e l l B., R u s s e l l L . J . , (1966), "ALGOL 60 Implementation", Academic P r e s s , New York, I966 (418 pages). Richards M., ( l 9 6 9 ) 1 "BCPL: A Tool f o r Compiler W r i t i n g and Systems Programming", Proc. of AFIPS I969 S p r i n g J o i n t Conference, p. 557-566, AFIPS P r e s s , I969. Richards M., (1971), "The P o r t a b i l i t y of the BCPL Compiler", Software: P r a c t i c e and Experience v o l . 1, p. 135-146, 1971. Richards M., e t a l . , (1974), "The BCPL Programming Manual", Dept. of Comp. S c i . , U n i v e r s i t y of B r i t i s h Columbia, Vancouver, 1976 (86 pages). Sammet J.E. (I969), "Programming Languages: H i s t o r y and Fundamentals", P r e n t i c e H a l l Inc., U.S.A., I969 (785 pages). T e k t r o n i x I n c . , (1977a), "8002 uProcessor Lab System User's Manual", T e k t r o n i x I n c . , Oregon, U.S.A., 1977 (app. 400 pages). T e k t r o n i x I n c . , (1977b), "8002 uProcessors Lab 6800 Assembler & Emulator 1User's Manual", T e k t r o n i x Inc., Oregon, U.S.A., 1977 (app- ^00 pages). Tenenbaum A.S., (1978), " I m p l i c a t i o n s of S t r u c t u r e d Programming f o r Machine A r c h i t e c t u r e " , CACM v o l . 21 no. 3, p. 237-246, March 1978. Texas Instruments I n c . , (1976), "990 Computer Family Systems Handbook", Texas Instruments Inc., U.S.A., I976 (app. 200 pages). USCD, (1978) "USCD P a s c a l " , ACM SIGPC Notes v o l . 1 no. 1, p. 6-15, A p r i l 1978. Watson I.W., (1976), "Comparison of Commercially A v a i l a b l e Software Tools f o r M i c r o p r o c e s s o r Programming", Proc. of the IEEE v o l . 64 no. 6, p. 910-920, June 1976. Wirth N., (1970), "The Programming Language PASCAL", A c t a I n f o r m a t i c a v o l . 1, p. 36-63, 1970. Wulf W.A., (1971), "BLISS: A Language f o r Systems Programming", CACM v o l . 14 no. 12, p. 780-790, Dec. 1971. Y a s a k i E.K., (1977), "Microcomputers: For Fun and P r o f i t ? " , Datamation v o l . 23 no. 7, P- 66-77, J u l y 1977-Yohe J.M., (1974), "An Overview of Programming P r a c t i c e s " , Computing Surveys v o l . 6 no. 4, p. 221-245, Dec. 1974. 55 APPENDIX A — ISP DESCRIPTION OF THE E MACHINE THE INSTRUCTION SET PROCESSOR (ISP) NOTATION IS USED TO DESCRIBE THE E MACHINE. DIGITAL 71, APPENDIX C, DESCRIBES THE ISP NOTATION. THE NOTATION USED HERE CONTAIN SOME SYNTAX CHANGES: 1) SINCE DIFFERENT FONTS ARE NOT AVAILABLE, A COMMENT IS ANY NUMBER .OF CHARACTERS BETWEEN A SLASH, /, AND THE END OF A LINE. A SLASH IS NO LONGER USED FOR DEFINING SYNONYMS. 2) ROUND BRACKETS, ( ), REPLACE SQUARE BRACKETS. THE CONTEXT SHOULD RESOLVE POSSIBLE AMBIGUITIES. 3) & REPRESENTS THE LOGICAL AND OPERATOR. I REPRESENTS THE LOGICAL OR OPERATOR. II REPRESENTS THE CONCATENATE OPERATOR. Xl REPRESENTS THE LOGICAL EXCLUSIVE OR OPERATOR. MOD REPRESENTS THE REMAINDER OPERATOR. 4) ALL ARITHMETIC OPERATIONS USED HERE DEAL WITH DATA AS ABSOLUTE BINARY NUMBERS, OR AS PURE BIT PATTERNS. CONSTANTS IN ARITHMETIC OPERATIONS ARE ASSUMED TO BE • RIGHT JUSTFIED, WITH 0 FOR ALL UNSPECIFIED BITS. .5) THE SIDE EFFECTS NAMING CONVENTION IS NOT USED. 6) CONSTANTS DEFAULT TO HEXADECIMAL NUMBERS. THUS . A DIGIT SPECIFIES k BITS... .A BINARY. NUMBER IS SPECIFIED . BY A B CHARACTER AT THE END OF THE CONSTANT. 5 6 PRIMARY MEMORY MP(0000:FFFF)< 0:7> / 1 6 BIT ADDRESS SPACE GIVING 64K /8 BIT BYTES OF ADDRESSABLE MEMORY REGISTERS AND PROCESSOR STATE PC < 0 : F > SP < 0 : F > F P < 0 : F > FLAG < 0:F > INT EN := FLAG < 0 ^  RUN := F L A G < 1 > WAIT := FLAG < 2 > ON := IB OFF := OB /16 BIT PROGRAM COUNTER / 1 6 BIT STACK POINTER / 1 6 BIT FRAME POINTER FOR FUNCTION /FRAME CONTROL /16 BIT STATUS FLAG / "INTERRUPT ENABLE / RUN / WAIT FOR INTERRUPT / DEFINES ACTIVE STATES FOR LINES INPUT/OUTPUT IO(00:FF) <0:7> /256 ADDRESS SPACE OF 8 BIT 10 PORTS INTERRUPT LINES RESET RESET-ADD < 0 : 1 5 > INTREQ INT-ADD < 0 : 1 5 > /RESET TO INITIALIZE PROCESSOR /RESET JUMP ADDRESS /INTERRUPT REQUEST /INTERRUPT JUMP ADDRESS 57 ADDRESSING OPERATIONS ASGNW (MEMADD<0:15>, DATAl6<0:15» /WORD ASSIGNMENT ( MP(MEMADD ) <- DATAl6<0:7> ; MP(MEMADD + 1) <- DATA1'6<8:15> ) ASGNB (MEMADD, DATA8<0:7>) := ; MP(MEMADD ) <- DATA8 ) /BYTE ASSIGNMENT PUSHW (DATA16) := ; SP <- SP - 2 ; NEXT ASGNW (SP, DATA16) ) /PUSH WORD TO STACK PUSH (DATA8) := [ SP <- SP - 2 ; NEXT ASGNW (SP, 00 | | DATA8 ; ) /PUSH BYTE TO STACK IMW ; MP(PC +1) || MP(PC + 2) ) /IMMEDIATE WORD 1MB ^ MP(PC + 1) ) /IMMEDIATE BYTE TOSW (DATA8) := [ MP(SP + DATA8 + DATA8) | | MP(SP + DATA8 + DATA8 + l ) ) ./NTH ELEMENT FROM TOP OF /STACK TOSB (DATA8) := [ MP(SP + DATA8 + DATA8 + l ) ) /NTH ELEMENT BYTE FROM /TOP OF STACK FRAD ( FP + (00 | | 1MB) ) /FRAME ADDRESS MW (DATA16) := ( MP(DATA16) || MP(DATA16 + l ) ) /WORD OF MEMORY RETRNP (DATA16, PARAMN<0:7>) := /RETRN FOR PRIMITIVE /FUNCTION ( PARD <- DATA16 ; SP <- SP + PARAMN +PARAMN ; .NEXT . PUSHW (PARD) ; PC <- PC + 1 ) PARA<0:15> /INTERNAL REGISTERS PARB<0:15> PARC<0:15> PARD<0:15> INSTRUCTION FORMAT INST<0:7> : = MP(PC) /INSTRUCTION IS BYTE IN MEMORY /POINTED BY PC INSTRUCTION INTERPRETATION PROCESS RESET = > (RESET-SEQUENCE) /RESET ON INITIALIZES PROCESS REGARDLESS /OF PROCESSOR STATE INT-REQ & INTEN & RUE & ""RESET => (INTERRUPT-SEQUENCE) /INTERRUPT ACTIVATED ONLY WHEN INTEN ON ((~INTREQ &~WAIT &RUN) (INTREQ & ""INTEN & RUN)) & PRESET => (EXECUTION-SEQUENCE) /NORMAL EXECUTION I F RUN ON AND NO WAIT /OR INTERRUPT WAIT => () RUN => () /NO EXECUTION AT WAIT OR RUN RESET-SEQUENCE ( RUN <- ON OFF OFF WAIT. <-INTEN <-PC <- RESET-ADD INTERRUPT-SEQUENCE ( WAIT <- OFF PUSHW (SP PUSHW (PC PUSHW (FP NEXT NEXT NEXT NEXT NEXT PUSHW (FLAG PUSHW (PC PUSHW (FP INTEN <-PC <-OFF INT-ADD EXECUTION-SEQUENCE := ( EXECUTE-INSTRUCTION 59 INSTRUCTION EXECUTION EXECUTE-INSTRUCTION := /INSTRUCTION CODE CHECK ( INST<7> = IB ) => (RUN <- OFF ) /OPCODE ERROR ( INST =00 ) => (RUN <- OFF ) ////////////////////////// /PUSH AND POP INSTRUCTIONS /PUSHBA /PUSH BYTE ABSOLUTE ( INST =02 ) => ( PUSHB (MP(lMW)) ; NEXT PC <- PC + 3 ) ,/PUSHBI /PUSH BYTE IMMEDIATE ( INST =04 ) => ( PUSHB (1MB) ; NEXT PC <- PC + 2 ) /PUSHBX /PUSH BYTE INDEXED ( INST =06 ) => ( PUSHB (MP(FRAD)) ; NEXT PC <- PC + 2 ) /PUSHWA /PUSH WORD ABSOLUTE ( INST =08 ) => ( PUSHW (MW (IMW)) ; NEXT. PC <- PC + 3 ) /PUSHWI /PUSH WORD IMMEDIATE ( INST = OA ) => (PUSHW (IMW) ; NEXT PC <- PC + 3 ) /PUSHWX /PUSH WORD INDEXED ( INST = OC ) => ( PUSHW (MW(FRAD)) ; NEXT PC <- PC + 2 ) /PUSHWF /PUSH FRAME ADDRESS ( INST = OE ) => ( PUSHW (FRAD) J NEXT PC <- PC + 2 ) /POP /POP STACK ( INST = 10 ) => ( SP <- SP + 2 ; PC <- PC + 1 ) 60 ASSIGNMENT INSTRUCTIONS /ASGNBA /ASSIGN BYTE ABSOLUTE ( INST = 12 ) => ( ASGNB (TOSB (OO), IMW) ; NEXT PC <- PC + 3 ) /ASGNWA /ASSIGN WORD ABSOLUTE ( INST = 14 ) => (ASGNW (TOSW (00), IMW} ; NEXT PC <- PC + 3 ) /ASGNBX /ASSIGN BYTE INDEXED ( INST = 16 ) => ( ASGNB (TOSB (00) , FRAD) ; NEXT /ASGNWX /ASSIGN WORD INDEXED ( INST = 18 ) => ( ASGNW (TOSW (00) , FRAD) ; NEXT PC <- PC + 2 PC <- PC + 2 /OPCODE ( INST = ( INST = ( INST = ERROR 1A IC IE = > = > = > ( RUN <- OFF ) ( RUN <- OFF ) ( RUN <- OFF ) 6l //////////////////////////////// / EXECUTION CONTROL INSTRUCTIONS /JMP /JUMP UNCONDITIONAL ( INST = 20 ) => ( PC <- IMW ) /JNT /JUMP NOT TRUE ( INST = 22 ) => ( (TOSB (00) ~= FF) = ( SP <- SP + 2 ; PC <- IMW ; ELSE SP <- SP + 2 ; PC <- PC + 3 ) /HALT /HALT PROCESSOR ( INST = 24 ) => ( RUN <- OFF ) /NOP /NO OPERATION ( INST = 26 ) => ( PC <- PC + 1 ) /CALL /CALL FUNCTION ( INST = 28 ) => ( PUSHW (PC + 3) ; NEXT PUSHW (FP) ; PC <- IMW ) /ALST /ALLOCATE STACK ( INST = 2A ) => ( SP <- SP - 1MB ; PC <- PC + 2 ) . /SETFP /SET FRAME POINTER ( INST = 2C ) => ( PUSHW (IMW) ; NEXT FP <- SP PC <- PC + 3 ) /RETRN /RETURN FROM FUNCTION CALL ( INST = 2E ) => ( FP<- MW (PP + MP(FP + 1) + 2) PC<- MW (FP + MP(FP + 1) +4) SP <- FP + MP(FP + 1) + MP(FP) + 4 ASGNW (TOSW, FP + MP(FP + l ) + MP(FP) + 4 ) ) / MULTITASKING AND EXTRA CONTROL INSTRUCTIONS /INTON /INTERUPT ENABLE ( INST =30 ) = > ( INTEN <- ON ; PC <- PC + 1 /INTOFF /INTERRUPT DISABLE ( INST = 32 ) => ( INTEN <- OFF ; PC <- PC + 1 /WAIT /WAIT FOR INTERRUPT ( INST =34 ) => ( WAIT <- ON ; PC <- PC + 1 /OPCODE ERROR ( INST = 36 ) => ( RUN <- OFF ) /:INSTF /SOFTWARE'INTERRUPT ( INST = 38 ) = > ( PUSHW PUSHW PUSHW PUSHW PUSHW PUSHW INTEN PC (SP ) j NEXT (PC ) ; NEXT (FP ) ; NEXT (FLAG) ; NEXT (PC ) ; NEXT (FP ) ; <- OFF <- TOSW (06) /:CALLS ( INST = /INDIRECT FUNCTION CALL 3A ) ( PARD <- TOSW (00) SP <- SP + 2 PUSHW (PC + 2 ) PUSHW (FP ) PC <- PARD /:CONSWI ( INST = /CONTEXT SWITCH 3C ) ( SP PC FP <-<-<-MW (TOSW(OO) MW (TOSW (00" FLAG <- MW (TOSW(00 /:CONSRV ( INST = /SAVE CONTEXT OF FUNCTION RETURN NEXT MW (TOSW(OO) + 6 ) + 4 ) + 2 ) ) 3E ) => ( MW (TOSW(00) + 6) <-FP + MP (FP + 1) + MP (FP) + MW (TOSW(OO) + 4) <-M W ( F P + M P ( F P + l ) + 4 ) MW (TOSW(00) + 2) <-M W ( F P + M P ( F P + l ) + 2 ) MW (TOSW(00) + 0) <- FLAG ) /OPCODE ERROR ( INST = 40 ) => ( INST = 42 ) => ( INST =44 ) = > ( INST = 46 ) => ( RUN <- OFF ) ( RUN<- OFF ) ( RUN <- OFF ) ( RUN <- OFF ) 63 ////////////////////////////// /INDIRECT ASSIGNMENT FUNCTIONS /:=B@ ( INST /:=¥@ ( INST /:=B# ( INST /:=W# ( INST /:=STR ( INST /:=ARR ( INST /ASSIGN BYTE INDIRECT 48 ) => ( ASGNB (TOSW(OO) ,TOSB(Ol)) RETRNP(TOSW(00) >02 ) /ASSIGN WORD INDIRECT 4A ) => (ASGNW (TOSW(OO) ,TOSW(Ol)) RETRNP(TOSW(00),02 ) ) /ASSIGN BYTE INDEXED 4C ) => ( ASGNB (TOSW(Ol) + TOSW(00) ,TOSW(02) ) ; RETRNP(TOSW(01) ,03 ) ) /ASSIGN WORD INDEXED 4E ) => ( ASGNW (TOSW(Ol) + TOSW(OO) + TOSW(OO), TOSW(02)) ; RETRNP(T0SW(01) ,03 ) ) /ASSIGN TO STRING 50 ) => ( PARA <- TOSW (00) ; PARB <- TOSW (01) ; NEXT MP (PARB) ~= 80 => ( ASGNB (PARA, MP(PARB)) PARA <- PARA + 1 PARB <- PARB + 1 : NEXT ) NEXT ASGNB (PARA,80 ) ; RETRNP(TOSW(00),02 /ASSIGN TO ARRAY 52 ) => ( PARA <- TOSW (00) PARB <- TOSW (01) PARC <- TOSW (02) j NEXT PARA ~= 0000 => ( ASGNB (PARB, MP(PRAC)) PARA <- PARA - 1 PARB <- PARB + 1 PARC <- PARC + 1 : NEXT ) NEXT RETRNP(TOSW(01),03) 64 //////////////// / PUSH FUNCTIONS /:B® /PUSH ( INST = 54 /:W@ /PUSH ( INST = 56 /:B# /PUSH ( INST = 58 /:W# /PUSH ( INST = 5A ) => ( RETRNP(00 || MP (TOSW (OO)) ,01) ) WORD INDIRECT ) => ( HETRNP(MW(TOSW(0.0)) ,01) ) ) => ( RETRNP(00 | | MP(TOSW(.0l) + TOSW(OO)) ,02) ) ) => ( RETRNP(MW(T0SW(01) + TOSW(OO) + TOSW(00) ,02) ) /OPCODE ERROR ( INST = 5C ) => ( INST = 5E ) => ( RUN <- OFF ) ( RUN <- OFF ) ////////////////////// / ARITHMETIC FUNCTIONS /:INC INST :DEC INST :NEG INST /:ADD INST /:SUB INST :RMUL INST /:LMUL INST /:DIV INST /:REM INST /:AND INST /:OR INST /:XOR INST /:NOT INST /:LS INST /:RS INST /:LS4 INST /:RS4 INST /INCREMENT 60 ) => /DECREMENT 62 ) => /NEGATE 64 ) => /ADD 66 ) => /SUBTRACT 68 ) => 65 ( RETRNP( TOSW(OO) +1 , 01) ) ( RETRNP( TOSW(OO) - 1 , 01) ) ( RETRNP( - TOSW(OO) , 01) ) ( RETRNP(TOSW(01) + TOSW(OO), 02) ) ( RETRNP(TOSW(Ol) - TOSW(OO), 02) ) /RIGHT SIDE OF BITWISE MULTIPLY 6A ) => ( RETRNP( (TOSW(Ol) X TOSW(00) )<10:1 F>, , 02 ) /LEFT SIDE OF BITWISE MULTIPLY 6C ) => ( RETRNP( (TOSW (01) X TOSW(OO) )<00:0F>, , 02 ) /ABSOLUTE MAGNITUDE DIVIDE 6E ) => ( RETRNP(T0SW(01) / TOSW(OO) , 02) ) /ABSOLUTE MAGNITUDE REMAINDER 70 ) => ' ( RETRNP(T0SW(01) MODTOSW(02), 02) ) /BITWISE AND 72 ) => ( RETRNP(T0SW(01) & TOSW(OO), 02) ) /BITWISE INCLUSIVE OR 74 ) => ( RETRNP(T0SW(01) | TOSW(OO) , 02) ) /BITWISE EXCLUSIVE OR 76 ) => ( RETRNP(TOSW(01) X| TOSW(OO), 02) ) . /BITWISE INVERT 78 ) => ( RETRNPC'TOSW(OO) , 01) ) /LEFT SHIFT ONE, ZERO FILL 7A ) => ( RETRNP(0B || TOSW(00)<T0:l4> , 01) ) /RIGHT SHIFT ONE, ZERO FILL 7C ) => ( RETRNP(TOSW(00) 1,15 I I OB , 01) ) /LEFT SHIFT FOUR, ZERO FILL 7E ) => ( RETRNP( 0 || TOSW(00)<0:11> , 01) ) /RIGHT SHIFT FOUR, ZERO FILL 80 ) => ( RETRNP( T0SW(00>C4:15> | | 0 , 01) ) /OPCODE ERROR INST = 82 ) = > ( RUN <- OFF INST = 84 ) => ( RUN <- OFF INST = 86 ) = > ( RUN <- OFF INST = 88 ) => ( RUN <- OFF INST = 8A ) => ( RUN <- OFF INST = 8C ) => ( RUN <- OFF INST = 8E ) => ( RUN <- OFF ///////////////////// /COMPARISON FUNCTIONS /:?EQ /COMPARE FOR EQUALITY ( INST =90 ) => ( (TOSW(01) = TOSW (OO)) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) . /:?EQ /COMPARE FOR DIFFERENCE ( INST =92 ) => ( (TOSW(01) = TOSW (00)) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /:?LT /COMPARE FOR LESS THAN ( INST =94 ) => ( (TOSW(Ol) TOSW (OO)) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /:?GT /COMPARE FOR GREATER THAN ( INST =96 ) => ( (TOSW(Ol) TOSW (OO)) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02 )) /FUNCTION TO TEST STRING UNTIL DIFFERENT TSTR := (PARA <- TOSW (01) ; PARB <- TOSW (00) ;• NEXT MP (PARA) ~= 80 & MP (PARA) = MP(PARB) => ( PARA <- PARA + 1 ; PARB <- PARB + .1 ; ) /: STR?EQ /COMPARE STRINGS FOR EQUALITY ( INST =98 ) => ( TSTR ; NEXT MP (PARA) = MP (PARB) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /:STR?NE /COMPARE STRINGS FOR DIFFERENCE ( INST = 9A ) => ( TSTR ; NEXT MP (PARA) ~= MP (PARB) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /: STR?LT /COMPARE STRINGS FOR LESS THAN ( INST = 9C ) => ( TSTR ; NEXT MP (PARA) < MP (PARB) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /:STR?GT /COMPARE STRINGS FOR GREATER THAN ( INST = 9E ) => ( TSTR ; NEXT MP (PARA) > MP (PARB) => (RETRNP(OOFF, 02) ; ELSE RETRNP(0000, 02) )) /OPCODE ERROR ( INST = AO ) = > ( RUN <- OFF ) ( INST = A2 ) => ( RUN <- OFF ) ( INST = A4 ) = > ( RUN <- OFF ) (- INST = A6 ) ( RUN <- OFF ) //////////////////////// /MISCELLANEOUS FUNCTIONS /:B2W /2 BYTES TO ONE WORD CONVERSION ( INST = A8 ) => (RETRNP (TOSW(01)<8:15> II TOSW(00)<8:15>, 02 )) /:SWAPB /SWAP BYTES ( INST = AA ) => /:SEL /SELECT DATA ( INST = AC ) => (RETRNP (TOSW(00)<8:15> II T0SW(00)<0:7>, 02 )) ( TOSW(02)<8:15> =FF => ( RETRNP( TOSW(Ol), 03) ; ELSE RETRNP( TOSW(02),03) )) /:STRADV /ADVANCE TO END OF STRING ( INST = AE ) => NEXT (PARA <- TOSW (00) ; (MP (PARA) ~= FF) => (PARA <- PARA + 1) ; NEXT RETRNP (PARA + 1, 01 ) ) /OPCODE ERROR ) ( RUN <-( INST = BO => OFF ( INST = B2 ) => ( RUN <- OFF ( INST = B4 ) => ( RUN <- OFF ( INST = B6 ) => ( RUN <- OFF /////////////////////// /INPUT OUTPUT FUNCTIONS /:FOPEN /FILE OPEN ( INST = B8 ) => /:FCLOSE /FILE CLOSE ( INST = BA ) => (SY STEM-DEPENDENT) (SYSTEM-DEPENDENT ) 10(TOSW(00)), 01)) /:RDCH /READ A CHARACTER ( INST = BC ) => (RETRNP (00 /:WRCH /WRITE A CHARACTER ( INST = BE ) => (IO(TOSW(00)) <- TOSW(0l)<8:15> ; RETRNP (TOSW(00), 02) ) /:FLUSH /FLUSH 10 BUFFER ( INST = CO ) => (SYSTEM-DEPENDENT) / O P C O D E I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = I N S T = E R R O R : C 2 : CH-C6 C 8 C A C C : C E D O D 2 D4-D6 D8 D A D C D E ) =: ) -) =: ) =: ) =: ) =: ) =: ) =: ) =: ) =: > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < - O F F > ( R U N < - O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F > ( R U N < -O F F /////////////// / U S E R F U N C T I O N S I N S T I N S T I N S T I N S T I N S T I N S T I N S T I N S T EO E2 E4 E6 E8 EA EC EE = > = > = > = > = > (SYSTEM-(SYSTEM-(SYSTEM-(SYSTEM-(SYSTEM-(SYSTEM-(SYSTEM-(SYSTEM-•DEPENDENT) •DEPENDENT) •DEPENDENT) •DEPENDENT) •DEPENDENT) •DEPENDENT) •DEPENDENT ) •DEPENDENT) / O P C O D E E R R O R ( I N S T = F O ( I N S T = F 2 I N S T = F 4 I N S T = F6 I N S T = F 8 I N S T = F A I N S T = F C I N S T = F E ) = ) = ) = > > > > > > > > R U N R U N R U N R U N R U N R U N R U N R U N <-<-<-<-<-<-<-<-O F F O F F O F F O F F O F F O F F O F F O F F 70 APPENDIX B — ASCII CODE OF THE E CHARACTER SET 0 1 2 3 4 5 6 7 0 SP 0 @ P — — 1 l A Q — — 2 2 B R — — 3 # 3 C S — — 4- EOF $ 4 D T — — 5 . % 5 E U — — 6 & • 6 F V — — 7 . t 7 G w — — 8 ( 8 H X — — 9 ) 9 I Y — — A LF -X- : J Z — — B + i K — — C L — — D CR - = M — — E t N — — F _ — / V 0 — - — — NOTES: 1) — INDICATES THE ASCII SYMBOL IS NOT WITHIN THE E CHARACTER SET. 2) THE ASCII CODE FOR THE SYMBOL IS IN HEXADECIMAL. THE FIRST HEXADECIMAL DIGIT IS THE ROW ON TOP OF THE MATRIX, AND THE SECOND HEXADECIMAL DIGIT IS THE COLUMN TO THE LEFT OF THE MATRIX. FOR EXAMPLE THE CODE FOR SP IS HEXADECIMAL 20. 3) MULTIPLE CHARACTERS REPRESENT NON-PRINTING ASCII SYMBOLS. EOF REPRESENTS END OF FILE. • LF REPRESENTS LINEFEED. CR REPRESENTS CARRIAGE RETURN. SP REPRESENTS SPACE. 71 APPENDIX C — SUMMARY OF E ASSEMBLER INSTRUCTIONS C.l GLOSSARY OF TERMS THE FOLLOWING TERMS ARE USED IN THE TABLES SUMMARIZING THE E. ASSEMBLER INSTRUCTIONS: <DATA8> - VARIABLE OR CONSTANT INTERPRETED AS AN 8-BIT VALUE. <DATA16> - VARIABLE OR CONSTANT INTERPRETED AS A 16-BIT VALUE. < EXNAME >- EXTERNAL NAME <INNAME> - INTERNAL NAME - ANY CONSTANT - BYTE DECIMAL CONSTANT (8 BITS) WORD DECIMAL CONSTANT .(16 BITS) BYTE HEXADECIMAL CONSTANT (8 BITS) WORD HEXADECIMAL CONSTANT ( l6 BITS) CHARACTER CONSTANT (8 BITS) < CONST> <BDECI> <WDECI> < BHEXD > <WHEXD> <CHAR> C.2 ASSEMBLER DIRECTIVES ASSEMBLER INST. DESCRIPTION .NULL .MODULE .DEFX <EXNAME> .DEFI <INNAME> .FLINK <EXNAMEXCONST> .CLINK <EXNAMEXCONST> .ORG <CONST> .MEM <CONST> .MAPON .MAPOFF TRIGGERS PRINTING OF A LOADMAP ENTRY STARTS A NEW MODULE DEFINES EXTERNAL NAME DEFINES INTERNAL NAME DEFINES LINKAGE CHECK FOR EXTERNAL NAME DECLARES LINKAGE CHECK FOR EXTERNAL NAME SET PC TO CONST ADD CONST TO PC START LISTING OF LOAD MAP STOP LISTING OF LOAD MAP C.3 HOUSEKEEPING INSTRUCTIONS 72 ASSEMBLER INST. MACHINE ._ CODE PUSHBA DATA16 02 PUSHBI DATA8 04 PUSHBX DATA8 06 PUSHWA DATA16 08 PUSHWI DATA16 OA PUSHWX DATA8 OC PUSHWF DATA8 OE POP 10 ASGNBA <DATA16> 12 ASGNWA <DATA16> 14 ASGNBX <DATA8> 16 ASGNWX <DATA8> 18 JMP <DATA16> 20 JNT <DATA16> 22 HALT 24 NOP 26 CALL <DATA16> 28 ALST <DATA8 > 2A SETFP <DATA8XDATA8>2C RETRN 2E INST. DESCRIPTION LENGTH 3 PUSH BYTE FROM ABSOLUTE ADDR. 2 PUSH IMMEDIATE BYTE 2 PUSH BYTE FROM INDEXED ADDR. 3 PUSH WORD FROM ABSOLUTE ADDR. 3 PUSH IMMEDIATE WORD 2 PUSH WORD FROM INDEXED ADDR. 2 PUSH INDEXED ADDR. 1 POP ONE ELEMENT OFF STACK 3 ASSIGN BYTE OF TOP OF STACK TO ABSOLUTE ADDR. 3 ASSIGN WORD OF TOP OF STACK TO ASBOLUTE ADDR. 2 ASSIGN BYTE OF TOP OF STACK TO INDEXED ADDR. 2 ASSIGN WORD OF TOP OF STACK TO INDEXED ADDRESS 3 JUMP TO ABSOLUTE ADDR. 3 JUMP IF TOP OF STACK NOT FF TO ABSOLUTE ADDR. 1 SUSPEND PROCESSOR 1 NO OPERATION 3 CALL TO DEFINED FUNCTION AT ABSOLUTE ADDR. 2 ALLOCATE STACK SPACE 3 SET FP AND STACK FOR DEFINED FUNCTION EXECUTION 1 RETURN FROM FUNCTION CALL C .4 PRIMITIVE FUNCTIONS 73 ASSEMBLER PARAM. MACHINE INST. DESCRIPTION INST. NO. CODE LENGTH :=B@ 2 48 1 ASSIGN BYTE TO INDIRECT ADDR. :=W@ 2 4A 1 ASSIGN WORD TO INDIRECT ADDR. :=B# 3 4C 1 ASSIGN TO BYTE INDEXED ADDR. :=W# 3 4E 1 ASSIGN TO WORD INDEXED ADDR. :=STR 2 50 1 MOVE STRING :=ARR 3 52 1 MOVE BYTE ARRAY :B@ 1 54 1 PUSH BYTE FROM INDIRECT ADDR. :W@ 1 56 1 PUSH WORD FROM INDIRECT ADDR. :B# 2 58 1 PUSH FROM BYTE INDEXED ADDR. :W# 2 5A 1 PUSH FROM WORD INDEXED ADDR. :INC 1 60 1 INCREMENT :DEC 1 62 1 DECREMENT :NEG 1 64 1 NEGATE :ADD 2 66 1 ADD :SUB 2 68 1 SUBTRACT :RMUL 2 6A 1 RIGHT UNSIGNED MULTIPLY :LMUL 2 6C 1 LEFT UNSIGNED MULTIPLY :DIV 2 6E 1 UNSIGNED NUMBER DIVIDE -.REM 2 70 ' 1 UNSIGNED NUMBER REMAINDER : AND 2 72 1 BITWISE LOGICAL AND :OR 2 74 1 BITWISE LOGICAL OR :XOR 2 76 1 BITWISE LOGICAL EXCLUSIVE OR :N0T 1 78 1 BITWISE LOGICAL INVERT :LS 1 7A 1 LEFT SHIFT 1 BIT, 0 FILL :RS 1 7G 1 RIGHT SHIFT 1 BIT, 0 FILL :LS4 1 7E 1 LEFT SHIFT 4 BITS, 0 FILL :RS4 1 80 1 RIGHT SHIFT 4 BITS, 0 FILL :?EQ 2 90 1 COMPARE FOR EQUALITY :?NE 2 92 1 COMPARE FOR NONEQUALITY :?LT 2 94 1 COMPARE FOR UNSIGNED MAGNITUDE LESS THAN :?GT 2 96 1 COMPARE FOR UNSIGNED MAGNITUDE GREATER THAN :STR?EQ 2 98 1. COMPARE STRINGS FOR EQ :STR7NE 2 9A 1 COMPARE STRINGS FOR NE :STR?LT 2 9C 1 COMPARE STRINGS FOR LT :STR?GT 2 9E 1 COMPARE STRINGS FOR GT :B2W 2 A8 1 BYTES TO WORD CONVERSION :SWAPB 1 AA 1 SWAP BYTES :SEL 3 AC 1 SELECT 1 OF 2 PARAMETERS :STRADV 1 AE 1 ADVANCE TO END OF STRING 74 C.5 OTHER INSTRUCTIONS ASSEMBLER PARAM. MACHINE INST. INST. NO CODE.LENGTH DESCRIPTION INTON INT OFF WAIT 30 1 INTERRUPT ENABLE 32 1 INTERRUPT DISABLE 34 .1 WAIT FOR INTERRUPT INTSF 1 38 CALLS 1 3A CONSWI 1 3c CONRSV 1 3E FOPEN 2 B8 FCLOSE 1 BA RDCH 1 BC WRCH 2 BE FLUSH 2 CO 1 SOFTWARE INTERRUPT 1 INDIRECT FUNCTION CALL 1 CONTEXT SWITCH 1 SAVE RETURN CONTEXT 1 FILE OPEN 1 FILE CLOSE 1 READ A CHARACTER 1 SAVE RETURN CONTEXT 1 FLUSH 10 BUFFER UFO 1 EO 1 USER FUNCTION 0 UF1 ' 1 E2 1 USER FUNCTION 1 UF2 1 E4 1 USER FUNCTION 2 UF3 1 E6 1 USER FUNCTION 3 UF4 1 E8 1 USER FUNCTION 4 UF5 1 EA 1 USER FUNCTION 5 UF6 1 EC 1 USER FUNCTION 6 UF7 1 EE 1 USER FUNCTION 7 C.6 DATA DEFINITION INSTRUCTIONS ASSEMBLER INST. <BDECI> <WDECI> <BHEXD> <WHEXD> < CHAR> <EXNAME> <INNAME> INST. DESCRIPTION LENGTH  1 BYTE DECIMAL CONSTANT 2 WORD DECIMAL CONSTANT 1 BYTE HEXADECIMAL CONSTANT 2 WORD HEXADECIMAL CONSTANT 1 ASCII CHARACTER CONSTANT 2 EXTERNAL NAME 2 INTERNAL NAME APPENDIX D — SAMPLE E PROGRAM APPENDIX D.l — COMPILER LISTING OF E MODULES WHICH IMPLEMENTS A SYMBOL TABLE E COMPILER VERSION B.O.O. ?6 START OF COMPILE 1 /" .ORG j* * * X X X X X X X * * * * * * * * * * * * * * * * * * * * * * * X X X X - f r * * * * * - * * X X X X * * * * * * /* THE FOLLOWING ROUTINES IMPLEMENTS A HASHED SYMBOL /* TABLE WHOSE ENTRIES ARE ALLOCATED AND REMOVED IN A /* STACK LIKE FASHION. AN ENTRY IN THE SYMBOL TABLE IS A /* SERIES OF CONTIGUOUS BYTES POINTED TO BY AN ENTRY IN /* A HASH TABLE. AN ENTRY IN THE SYMBOL TABLE HAS 3 /* FIELDS: A SYMBOL STRING WHICH IS AN E STRING, A SYMBOL /* ID WHICH IS A BYTE, AND INFORMATION WHICH IS A BYTE /* ARRAY. J * ******* X X X X X X -XHf •X-*-X-X-*-X-X-X--*-X-*-X-X-*^ X -X X X •X-*-X--X--X--X--X--X--X--X-1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 9 * / V 29 14 41 42 43 44 45 46 47 48 1 1 1 1 1 1 4 9 49 14 50 19 51 19 52 24 53 29 54 . 34 55 1 DEF MCON DEF' MCON DEF MCON DEF MCON DEF MCON EOS$ $80 STB.STRL +3070 STB.HSHN +0512 STB.HSHL +1024 STB.EMPTY $FFFF /* END OF STRING MARKER /* DATA TABLE LENGTH /* HASH ENTRY NUMBER /* HASH TABLE.LENGTH /* EMPTY ENTRY IN HASH /* TABLE V /* DEF (# )# ($ •X--X--X--X-X X X X - X * W * * * W * * X X X X X ^ - X - - X - - X - ^ * - X - - X - ^ - X - - X - - X - ^ - X - X - - X - T < - ^ X X X X X X X-X--X--X-X-SYMBOL TABLE HASH FUNCTION. TAKES A STRING AS PARAMETER AND RETURNS A NUMBER . FROM +0000 TO STB.HSHN - 1 FNCTN :SYM.HASH DECL PARAM H.STR ; DECL AUTO H.TEMP WORD : V 32 11 33 11 34 18 35 23 36 25 37 28 38 30 39 30 40 37 H.STR )$ 1* EVAL $0000 =H.TEMP ; EVAL H.STR :DEC =H.STR \ WHILE. H.STR :INC=H.STR :B@ EOS$ (* EVAL H.TEMP +03 :RMUL H.STR :B@ :ADD =H.TEMP ; )* ; RETRN H.TEMP +05 :RMUL STB.HSHN /* INIT COUNT /* DEC FOR LOOP /* LOOP TO ADD :?NE /* ADD EACH CHAR V V /* RETRN VALUE */ :REM ; 08 H.TEMP 02 •X-X X X X X X X X W * W M W * * * * ^ W * » * * * M W * W * * » * FUNCTION TO LOOK FOR A GIVEN NAME IN THE SYMBOL TABLE. RETURNS INDEX"OF TABLE I F FOUND. RETURNS STB.EMPTY /* IF NOT FOUND. DEF FNCTN :SYM.LOOK (# DECL PARAM L.STR i / * TARGET NAME DECL FNCTN :SYM.HASH +1 ; /* HASH FUNCTION DECL FNCTN :FERROR.C +1 ; /* FATAL ERROR DECL EXTRN SYM.SPT STB.HSHL ; DECL AUTO LK WORD •; DECL AUTO L.TEMP WORD ; V V )# ($ 56 2 57 2 58 7 59 11 60 11 61 11 62 17 63 18 64 24 65 28 66 29 67 35 68 39 69 40 70 41 71 ^5 72 46 73 49 74 51 75 53 76 53 77 53 78 57 79 57 )$ L. STR 80 1 81 1 82 1 /* 83 1 •/* 84 1 /* 85 1 DEF 86 4 (# 87 9 88 13 89 17 90 21 91 21 92 26 93 31 94 36 95 36 96 41 97 46 98 51 99 51 100 56 101 61 )# 102 1 ($ 103 2 104 8 105 14 106 14 10? 14 108 19 109 23 110 23 111 29 112 30 /* *** SETUP FOR SEARCH LOOP EVAL L.STR :SYM.HASH =L.TEMP EVAL -0001 =LK / 77 /* *** LOOP TO SEARCH FOR ENTRY *** */ WHILE LK :INC =LK STB.HSHN :?NE " (* &SYM.SPT L.TEMP :W# STB.EMPTY RETRN STB.EMPTY ; IF (? )? ELSE &SYM.SPT L.TEMP :W# L.STR (? RETRN L.TEMP ; )? ELSE (? EVAL L.TEMP :INC STB.HSHN :REM =L.TEMP : :?EQ :STR7EQ )* ; /* *** HASH TABLE OVERFLOW EVAL "01 :FERROR.C : -X-X--X-OA LK 04 L.TEMP 02 A A A A A A A A A A A A A A A A A A A A' A A A A 7 H H t - X - X X X X X X-X-X X X X X * * i H H H H H H ( - * FNCTN : SYM.ADD DECL DECL DECL DECL DECL DECL DECL DECL DECL DECL DECL DECL PARAM PARAM PARAM PARAM FNCTN FNCTN FNCTN' EXTRN EXTRN EXTRN AUTO AUTO .NAME .ID .INFO , INFOL NAME OF ENTRY ID OF ENTRY INFO OF ENTRY INFO LENGTH SYM.HASH SYM.LOOK FERROR.C SYM, SYM, SYM, SPT STR SFS AK A.TEMP /* +i +i +i STB.HSHL STB. STRL WORD WORD ; WORD : V /* *** RETURN INDEX OF ENTRY IF ALREADY PRESENT *** * IF A.NAME :SYM.LOOK =A.TEMP STB.EMPTY :?NE (? RETRN A.TEMP ; / /* *** FIND FREE CELL AND ADD EVAL A.NAME :SYM.HASH =A.TEMP EVAL -0001 =AK #-x-x- */ WHILE (* I F AK :INC =AK STB.HSHN :?NE &SYM.SPT A.TEMP :W# STB.EMPTY :?EQ 113 36 (? 114 37 /* *** ADD ENTRY 115 37 EVAL SYM.SFS &SYM.SPT A.TEMP :=W# 116 ^3 EVAL A.INFO 117 ^5 A.ID 118 46 A.NAME 119 47 SYM.SFS 120 48 :=STR :STRADV 121 50 :=B@ :ING 122 52 A.INFOL 123 53 :=ARR A.INFOL :ADD =SYM.SFS 124 58 125 58 /* *** TEST FOR STRING TABLE OVERFLOW 126 58 IF SYM.SFS &SYM.STR :SUB 127 62 STB.STRL 128 63 :?GT 129 64 (? EVAL "00 :FERROR.C ; 130 69 )? ; 131 71 •/*• *** NORMAL RETURN 132 71 133 71 RETRN A.TEMP 134 74 )? 135 75 136 75 ELSE 137 76 (? EVAL A.TEMP :INC 138 80 STB.HSHN 139 81 :REM =A.TEMP 140 84 )? ; 141 86 142 86 )* • * 143 88 /* 144 88 *** HASH TABLE OVERFLOW 145 88 EVAL "01 :FERROR.C ; 146 92 147 92 )$ • * 78 -x-x-x- */ -x-x-x- -x-/ -x-x-x- */ A.NAME 10 A.ID OE A.INFO OC A.INFOL OA AK 04 A.TEMP 02 148 1 149 1 150 1 / * X X X X X X •X-X-X-X- X X X X •X-X-X--X-X--X--X-X--X-X--X--X--X^ X X X X X -X- *j 151 1 /* FUNCTION TO .ACCESS AN ENTRY OF SYMBOL TABLE */ 152 1 /* TAKES ERROR CODE AND POINTER INDEX AS PARAMETERS */ 153 1 /*' RETURNS POINTER TO ENTRY I F NO ERROR */ 154 1 /* EXITS TO :FERROR.C IF ERROR */ 155 1 DEF FNCTN :SYM.GPT 156 4 (# 157 158 159 160 161 162 163 164 165 2 IF G.INDEX STB.HSHN :?GT /* RANGE CHECK 166 167 168 12 ELSE &SYM.SPT G.INDEX :W# =G.TEMP /* ENTRY CHECK 5 DECL PARAM G.CODE 9 DECL PARAM G.INDEX 13 DECL FNCTN :FERROR.C +1 18 18 DECL AUTO G.TEMP WORD 23 DECL EXTRN SYM.SPT STB.HSHL 28 )# 1 ($ 2 IF G. INDEX STB.HSHN :?GT 6 (? EVAL G. CODE :FERROR.C 11 )? 12 ELSE &SYM.SPT G. INDEX :W# =G.' 169 17 170 18 171 19 172 24 173 25 174 26 175 30 176 32 177 32 )$ G. CODE 178 1 179 1 180 1 /* • 181 1 /* 182 1 DEF 183 4 (# 184 9 185 14 )# 186 1 ($ 187 7 )$ STB.EMPTY :?EQ EVAL G.CODE 79 (? )? ELSE (? RETRN G.TEMP )? ; :FERROR.C OA G. INDEX 08 G.TEMP 02 G.INDEX A A A A A A A A A A A A A A A A A A A A A " A n A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A FUNCTION RETURNS POINTER TO NAME IN SYMBOL TABLE FNCTN :SYM.GNM DECL PARAM G.INDEX ; DECL FNCTN :SYM.GPT +02 ; RETRN "40 06 G.INDEX :SYM.GPT 188 189 190 191 192 193 194 195 196 197 1 1 j_ -X--X-X-X X X X X X X X X X*-X--X--X--X--X--X-X-*-X--X--X--X-^ X X X-X-X--X--X--X-X-X--X--X-X-*-X-X-1 /* FUNCTION RETURNS POINTER TO ID IN SYMBOL TABLE 1 DEF FNCTN rSYM.GID 4 (# DECL PARAM G.INDEX ; :SYM.GPT +02 ; 14 1 ($ 8 )$ DECL FNCTN "41 G.INDEX :SYM.GPT :STRADV RETRN G.INDEX 06 198 199 200 201 202 203 204 205 206 207 208 1 1 1 / v Y Y V V V V V V V V V V V Y V Y V V V V V V Y V V V Y V V V V V V V Y V V Y V V Y Y y V y V Y V Y V Y y V y Y At I A A A A A A Tv A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A r 1 /* FUNCTION RETURNS POINTER TO INFO IN SYMBOL TABLE * 1 DEF FNCTN :SYM.GNF 4 (# DECL PARAM G. INDEX ; DECL FNCTN :SYM.GPT +02 5 9 14 )# 1 ($ 9 )$ RETRN "42 G.INDEX :SYM.GPT :STRADV :INC G. INDEX 06 209 210 211 212 213 214 215 216 / * -X-X--X-X X X X X X X X X X X X-X--X--X-*-X--X--X-*-X-X--X--X-^HHfr*** X X X X X X X X X X -1 1 1 1 •/* 1 DEF 4 (# 5 DECL 9 DECL FUNCTION TO DELETE TOP SYMBOL OF SYMBOL TABLE FNCTN :SYM.DEL PARAM EXTRN D. INDEX SYM.SPT STB.HSHL 217 14 DECL EXTRN SYM.SFS WORD ; 80 218 19 DECL AUTO D .TEMP WORD ; 219 24 )# 220 1 ($ 221 2 I F &SYM.SPT D.INDEX :W# =D:TEMP STB.EMPTY :?EQ 222 9 ( ? • RETRN FALSE ; )? > . 223 15 EVAL D.TEMP =SYM.SFS ; 224 19 RETRN STB.EMPTY &SYM.SPT D.INDEX =W# ; 225 25 )$ ! D. INDEX 08 D .TEMP 02 226 1 227 1 228 1 /* X - - X - # - X - - X - - X - X H f r - X - X - X - X - - X - - X - X ^ * 229 1 '/* FUNCTION TO CLEAR SYMBOL TABLE DOWN TO THE * 230 1 /* DATA WITH ADDRESS LOWER THAN SYM.SFS -X-231 1 DEF FNCTN :SYM.CLR 232 4 (# 233 5 DECL EXTRN SYM.SPT STB.HSHL ; 234 10 DECL EXTRN SYM.SFS WORD ; 235 15 DECL EXTRN SYM.TOS WORD ; 236 20 DECL AUTO K WORD ; 237 25 )# 238 1 ($ 239 2 EVAL -0001 =K' ; 240 6 WHILE K :INC =K STB.HSHN :?NE 241 12 (* 242 • 13 I F &SYM.SPT K :W# 243 17 SYM.TOS : :DEC 244 19 :?GT 245 20 (? EVAL STB .-EMPTY &SYM.SPT :=W# ; 246 27 )? ; 247 29 ) * 248 31 RETRN SYM.TOS =SYM.SFS • 1 249 35 250 35 )$ 9 K 02 251 1 252 253 254 255 256 257 258 1 1 1 1 1 4 1 F.MES j* X X X x - x - - x ^ - x - x - - x - - x - ^ ^ - x - - x - * - x - ^ ^ - x - - x - X X X X X X X X X * * * * X X X X X X - * * * * * * * * * * * * * * * /* THIS FUNCTION INSERTED TO COMPLETE NAME LIS T FOR LINKAGE /* OF THIS MODULE BY ITS E L F . DEF FNCTN :FERROR.C (# DECL PARAM F.MES ; )# ($ • )$ ; 06 259 1 260 1 261 1 262 1 263 1 / * X X X X X X X X X X - X - X X X X X X X X X X X X X X X * * X X X X X X - X - X X X X X X X X - X - X X X X X X * * * * * * * * * 264 1 /* SYMBOL TABLE DATA AREA DEFINITION 265 1 266 1 /" .ORG $2DFE "/ 267 1 268 1 DEF EXTRN SYM.SPT STB.HSHL 269 1 DEF EXTRN SYM.SFS WORD 2?0 1 DEF EXTRN SYM.TOS WORD 271 1 DEF EXTRN SYM.STR STB.STRL 272 1 273 1 274 1 275 1 NORMAL TERMINATION APPENDIX D.2 — LOAD MAP GENERATED FROM ASSEMBLING THE PREVIOUS E MODULES E ASSEMBLER PASS #1 E ASSEMBLER PASS #2 ****E PROGRAM LOAD MAP **** .SYM.HASH 2000. 2005 2005 2005 2008 2011 2011 2013 2014 201F 2021 2022 2024 202G 202E 2030 2031 **** :SYM.LOOK 2O36 203B 203B 203B 203D 2049 2049 204B 204C 205A 205B 205E 205F 2069 206B 206C 206E 2075 2075 2075 2077 2082 2085 2085 2085 **** :SYM.ADD 2090 2095 2095 2095 2097 20A5 20A6 20A6 20A6 20B1 20B3 20B4 20B4 .2000 20C3 20G5 20G6 20D5 20D6 20D7 20D7 20E3 20E4 20E6 20E7 20F4 20F5 20F8 20F9 2106 2106 2108 2109 210F 2110 2112 2113 211F 2120 2121 **** :SYM.GPT 2127 212C 212G 212C 212E 213B 213E 213E 2141 214D 214F 2152 2153 2159 2159 215A ****. :SYM.GNM 215A 215D 215D 215D 2160 **** : SYM. GLD 2169 216C 216C 216G 216F **** :SYM.GNF 2179 217C 217G 217G 217F **** :SYM.DEL 218A 218F 218F 218F. 2192 219E 21A0 21Al 21Al 21AA 21AD 21AF 21B0 **** :SYM.CLR 21Bl 21B6 21B6 21B6 21B9 21C4 21C5 21G8 21C8 21D6 21D6 21D9 21DG 21E6 21E6 21E9 21EG **** .FERROR.C 21ED 21 FO 21 FO 21 Fl **** SYM.SPT 2DFE **** SYM.SFS 31 FE **** SYM.TOS 3200 **** SYM.STR 3202 NORMAL TERMINATION 200A 200B 200B 2016 2017 2019 2025 2026 2028 2034 2035 2036 2040 2042 2043 204E 2051 2052 2062 2062 2065 206F 2072 2072 2078 207B 207C 2088 208B 208C 209A 2 0 9 C 209F 20A6 20A8 20AB 20B6 20B7 20B9 2 0 C 9 20CA 20CD 20D9 20DB 2 ODD 20E9 20EA 20ED 20FC 20FC 20FF 2109 2109 2109 2116 2116 2119 2131 2132 2135 2143 2144 2146 2156 2156 2156 2162 2165 2166 2171 2174 2175 2181 2184 2185 2194 2195 2197 21A1 21 Al 21 A3 21 Bl 21 Bl 21BB 21BC 21 BC 21 CB 21 CD 21 CE 21 DE 21 DF 21EO 21 ED 21 ED 200D 200E 2010 201A 201D 201D 2029 202C 202C 2036 2043 2046 2048 2055 2055 2058 2066 2066 2066 2074 2075 2075 207E 207F 2082 208D 20A0 20A3 20A3 20AD 20AE 20AE 20BC 20BD 20C0 20CD 20D0 20D3 20E0 20E1 20E2 20EE 20EE 20F1 2102 2103 2106 2109 21 OB 210C 2119 2119 211C 2135 2137 213A 2149 214A 214D 2156 2158 2159 2166 2176 2176 2186 2187 2187 219A 219B 219E 21A6 21A7 21A7 21BE 21BF 21 Cl 21D1 21D2 21D3 21E3 21E3 21E6 APPENDIX E SUMMARY OF THE LANGUAGE E 84 BNF IS USED BELOW TO SUMMARIZE THE LANGUAGE E. THE CHARACTERS // STARTS A COMMENT. THE SQUARE BRACKETS,C 1, ENCLOSES AN OPTIONAL CLAUSE. THE CURLY BRACKETS ,{ }, ENCLOSES A CLAUSE WHICH MAY BE REPEATED ANY NUMBER OF TIMES, INCLUDING ZERO. E . l KEYWORDS <KEYWORD> DEF DECL MCON EXTRN | FNCTN | INIT PARAM AUTO BYTE WORD EVAL WHILE | I F 1 ELSE INTON INTOFF | WAIT RETRN HALT | BREAK 1 NEXT (# }# 1 ($ 1 )$ (* )* 1 (? 1 )? TRUE FALSE ENDPROG E.2 OPERATORS <OPERATOR> : : = =B@ =STR m INC ADD RMUL AND LS ?EQ STR?EQ B2W INTSF CONSWI FOPEN RDCH UFO UF4 =W@ =ARR W@ DEC SUB LMUL OR RS ?NE STR?NE SWAPB CALLS CONRSV FCLOSE WRCH UF1 UF5 // PRIMITIVE FUNCTIONS | :=B# | :=W# | :B# | :NEG I :W# I I DIV XOR LS4 ?GT STR7GT | SEL | I REM NOT RS4 ?LT STR?LT STRADV // OTHER STACK INSTRUCTIONS sFLUSH iUF2 :UF6 | :UF3 J :UF7 85 E.3 — CHARACTER CLASSES <SIGN> <DCHAR> <HCHAR> <ACHAR> <PCHAR> + 1-0|l|2|3|4j5|6|?|8|9 // SIGN CHARACTERS // DECIMAL CHARACTERS // HEXADECIMAL CHARACTERS 0|1 |2|3l4|5l6|7|8|9|A|B|C|D|E|F // ALPHABET CHARACTERS A|B|C|D|E|F|G|H|I |J|K|L|M |N|0|P Q|R|S|T|U |V |W|X|Y|Z // PRINTABLE CHARACTERS <ACHAR>|<DCHAR> |,,l#l$l^l&l*l(l)l*l+l,|-l.|/|:1;l=l? E.4 — CONSTANTS <DECI> <BHEXD> :: <¥HEXD> : : <CHAR> :: <STRING> : i <CONSTANT> // DECIMAL NUMBER <SIGN><DCHAR> | <SIGN><DCHAR><DCHAR> I <SIGN>CDCHAR><DCHAR><DCHAR> I <SIGNXDCHAR><DCHAR><DCHARXDCHAR> | <SIGN><DCHAR><DCHAR><DCHARXDCHARKDCHAR> // BYTE HEXADECIMAL NUMBER $<HCHAR><JlCHAR> // WORD HEXADECIMAL NUMBER $<HCHAR> <HCHAR><HCHAR>'<HCHAR> // CHARACTER CONSTANT // STRING CONSTANT '<PCHAR> "{<PCHAR>} "// CONSTANTS := <BDECI> I <WDECI> I <BHEXD> I <WHEXD> I <CHAR> | <STRING> j TRUE: | FALSE E. 5 — NAMES <DNAME> ::= <ACHAR> <PCHAR> <FNAME> ::= :<PCHAR>{<PCHAR>} <&NAME> ::= &<DNAME> &<FNAME> =NAME ::= =<DNAME> // DATA NAME // FUNCTION NAME // ADDRESS NAME // ASSIGNMENT NAME - EXPRESSIONS <EXPR> I <CONSTANT> I <DNAME> I <&NAME> <EXPR> • <=NAME > <EXPR> INTSF <EXPR> CALLS <EXPR> CONSWI <EXPR> CONRSV <EXPRXEXPR> =B@ <EXPR><EXPR> =W@ <EXPR> <EXPR> <EXPR> =B# <EXPR> <EXPRXEXPR> =W# <EXPR> <EXPR> =STR <EXPR> <EXPR> <EXPR> =ARR <EXPR> B@ <EXPR> W@ <EXPR> <EXPR> E# <EXPRXEXPR> w# <EXPR> INC <EXPR> DEC <EXPR> NEG <EXPR><EXPR> ADD <EXPR><EXPR> SUB <EXPR> <EXPR> RMUL <EXPR><EXPR> LMUL <EXPR> <EXPR> DIV <EXPR><EXPR> REM <EXPR><EXPR> AND <EXPRXEXPR> OR <EXPR><EXPR> XOR <EXPR> NOT <EXPR> LS <EXPR> RS <EXPR> LS4 <EXPR> RS4 <EXPR> <EXPR> ?EQ <EXPR><EXPR> ?NE <EXPR> <EXPR> ?LT <EXPRXEXPR> ?GT <EXPR> <EXPR> STR?EQ <EXPR><EXPR> STR?NE <EXPR> <EXPR> STR7LT <EXPR> <EXPR> STR?GT <EXPR> <EXPR> B2W <EXPR> ' SWAPB <EXPR> <EXPR> <EXPR> SEL <EXPR> : STRADV 87 I < E X P R > * E X P R > I < E X P R > I < E X P R > I < E X P R > <EXPR> I < E X P R > <EXPR> I < E X P R > | < E X P R > I < E X P R > I < E X P R > ) < E X P R > | < E X P R > j < E X P R > | < E X P R > <EXPR?-<EXPR> <EXPR> <FNAME> <FNAME> <FNAME> I < E X P R X E X P R > < E X P R > < F N A M E > I < E X P R > < : E X P R > < E X P R > < E X P R > <FNAME> I < E X P R > <EXPR> <EXPR> < E X P R X E X P R > -CFNAME> | < E X P R > < E X P R > < E X P R > < E X P R > < E X P R > <:EXPR> < F N A M E > I < E X P R > < E X P R X E X P R > ' < E X P R > < E X P R > < E X P R > < E X P R > ,. <FNAME> J < E X P R > < E X P R > <!EXPR> < E X P R > < E X P R > <EXPR> < E X P R > <EXPR> <FNAME> / / FUNCTIONS WITH 0 PARAMETERS / / FUNCTIONS WITH 1 PARAMETER / / F U N C T I O N S WITH 2 PARAMETERS / / FUNCTIONS WITH 3 PARAMETERS / / FUNCTIONS WITH k PARAMETERS / / FUNCTIONS WITH 5 PARAMETERS / / FUNCTIONS WITH 6 PARAMETERS / / FUNCTIONS WITH 7 PARAMETERS / / F U N C T I O N S WITH 8 PARAMETERS E.7 — ACTION STATEMENTS 88 <ACTION> ::= EVAL <EXPR> ; // EVALUATION STATEMENT // WHILE STATEMENT )* ; | WHILE £<EXPR> ] (* { <ACTION> } // IF-ELSE STATEMENT | I F <EXPR> (?. { <ACTION> > C <EXITA> 1 )? -C ELSE EXPR (? { <ACTION> } t<EXITA>] )? I INTON | INTOFF | WAIT // INTERRUPT ON // INTERRUPT OFF // WATT FOR INTERRUPT <EXITA> RETRN <EXPR> ; HALT ; BREAK ; NEXT : // RETURN STATEMENT // HALT STATEMENT // BREAK STATEMENT // NEXT STATEMENT <EXITB> : := RETRN <EXPR> ; 1 HALT : E.8 — DECLARATIONS <DECLARE> ::= // PARAMETER DECLARATION DECL PARAM <DNAME> ; // AUTOMATIC DECLARATION | DECL AUTO <DNAME> <TYPE> ; // EXTERNAL DECLARATION | DECL EXTRN <DNAME> <TYPE> ; // FUNCTION DECLARATION | DECL FNCTN <TFNAME> <3TPE> ; . <TYPE> : := <BDECI> | <WDECI> | BYTE | WORD E. 9 — DEFINITIONS <DEFINE> : : = // FUNCTION DEFINITION DEF FNCTN <FNAME> (# { <DECLARE> } )# ($ { <ACTION> } I <EXTTB> 1 )$ // EXTERNAL DEFINITION | DEF EXTRN <DNAME> <TYPE> [ INIT { <INITV> } ] ; // MANIFEST CONSTANT // DEFINITION | DEF MCON <DNAME> <£CONSTANT> ; <INITV> ::= •CCONSTANT> | <T&NAME> 90 APPENDIX F — SAMPLE USE OF A PORTABLE E DEVELOPMENT SYSTEM // THE FOLLOWING. LISTS THE USE OF AN E DEVELOPMENT SYSTEM AS 11 IMPLEMENTED ON THE TEKTRONIX 8002 UPROCESSOR LAB AT THE // DEPARTMENT OF ELECTRICAL ENGINEERING OF THE UNIVERSITY OF 11 BRITISH COLUMBIA. 11 SEE TEKTRONIX 77A FOR A REFERENCE ON THE COMMANDS. BELOW. f l TWO SLASHES, //, INDICATES THE START OF A COMMENT WHICH // ANNOTATES THE COMMAND AND RESPONSE SEQUENCE. // PRESS RESTART BUTTON TO START SYSTEM. A 6800 SYSTEMS DISK fl CONTAINING THE E DEVELOPMENT SYSTEM LOAD MODULES IS IN // DISK DRIVE 0. TEKDOS > L EDEMO 6800 VERSION 2.1 FILE NAME BLOCKS TEKDOS 16 FDUMP 3 COPYSYS 2 TKEDLCMP 38 TKEULASM 29 EML 8 TOTAL FILES 61 TOTAL BLOCKS USED 207 BLOCKS AVAILABLE 97 TOTAL BAD BLOCKS 0 > EDIT ADDLOOP ** EDIT VER 1 .6** ** NEW FILE ** *I INPUT: DEF FNCTN :ADD.ARRAY (# DECL EXTRN NUM.ARRAY DECL EXTRN SUM DECL AUTO K )# ($ DEF DEF EVAL EVAL WHILE (* EVAL )* i 1 EXTRN EXTRN -1 =K +00 =SUM K :INC =K // TEKDOS STARTING MESSAGE // LIST FILES ON DISK // NAME OF DISK // TEKDOS FILES // E PORTABLE COMPILER fl E PORTABLE ASSEMBLER/LINKER // E MACHINE EMULATOR // MANY HIDDEN TEKDOS FILES // CREATE SAMPLE E PROGRAM // USING TEKDOS EDITOR // INSERT COMMAND TO EDITOR // ROUTINE TO ADD 6000 WORDS +12000 ; // WORD ARRAY WORD ; //SUM WORD ; // COUNTER // INITIALIZATION +6000 :?NE'// ADDITION LOOP &NUM.ARRAY K :W# SUM :ADD =SUM SUM NUM.ARRAY WORD +12000 // CR TO EXIT FROM INPUT MODE *FILE *DOS* EOJ 91 // EXIT FROM EDITOR > EDIT OADDLOOP ** EDIT VER 1 .6 ** NEW FILE ** *FILE *DOS* EOJ •x-x-// CREATE OBJECT FILE > A * > RHEX TKEDLCMP *RHEX* EOJ CLEAR SYSTEM // LOAD COMPILER // TAKE APP. 1 MINUTE TO LOAD > GO 10 E COMPILER VERSION P.0.1 NOV 1978 ENTER FILES: CONO OADDLOOP ADDLOOP ...EXECUTING' START.EXECUTION AT LOCATION. 10 COMPILER MESSAGE LISTING OBJECT SOURCE CONO IS CONSOLE OUTPUT COMPILER EXECUTION MESSAGE COMPILER LISTING FOLLOWS 0001 0001 0002 0004 0003 0010 0004 0015 0005 0020 0006 0001 0007 0006 0008 0010 0009 0016 0010 0025 0011 0027 DEF (# )# ($ FNCTN :ADD.ARRAY DECL .EXTRN NUM.ARRAY DECL EXTRN SUM DECL AUTO K +12000 WORD WORD EVAL EVAL WHILE (* )* -1 =K +00 =SUM K :INC =K +6000 EVAL &NUM.ARRAY K :?NE :W# SUM :ADD =SUM K 02 0012 0001 0013 0001 DEF EXTRN 0014 0001 DEF EXTRN 0015 0001 NORMAL TERMINATION SUM NUM.ARRAY WORD +12000 > A* // CLEAR SYSTEM // THE COMPILER EMITS ERROR MESSAGES IF SYNTAX ERRORS ARE DETECTED. //AN EDIT COMPILE CYCLE MAY BE USED TO CORRECT SYNTAX ERRORS. 92 > C O P Y O A D D L O O P C O N O . M O D U L E . D E F X : A D D . A R R A Y . C L I N K N U M . A R R A Y + 1 2 0 0 0 . C L I N K S U M + 2 A L S T $ 0 2 . F L I N K : A D D . A R R A Y $ 0 0 S E T F P $ 0 0 $ 0 2 . M A P O N . N U L L . N U L L P U S H W I - 1 A S G N W X $ 0 2 P O P . N U L L P U S H W I + 0 0 A S G N W A S U M P O P . D E F T , 0 2 . N U L L P U S H W X $ 0 2 : I N C A S G N W X $ 0 2 P U S H W I + 6 0 0 0 : ? N E J N T ',01 . N U L L P U S H W I N U M . A R R A Y P U S H W X $ 0 2 :W# P U S H W A S U M : A D D A S G N W A S U M P O P J M P , 0 2 . D E F I , 0 1 . N U L L H A L T . N U L L . M A P O F F . M O D U L E . M A P O F F . D E F X S U M . F L I N K S U M + 2 . M E M +2 . M O D U L E . M A P O F F . D E F X N U M . A R R A Y . F L I N K N U M . A R R A Y + 1 2 0 0 0 . M E M ' + 1 2 0 0 0 * C O P Y * E O J > - E D I T L A D D L O O P // C R E A T E L O A D M O D U L E F I L E ** E D I T V E R 1 . 6 * * ** N E W F I L E ** * F I L E * D O S * E O J > R H E X T K E U L A S M * R H E X * E O J > G O 1 0 E A S S E M B L E R / L I N K E R V E R S I O N P . 0 . 0 E N T E R F I L E S : C O N O L A D D L O O P O A D D L O O P E N T E R S T A R T A D D R E S S : O C C O E X E C U T I N G P A S S # 1 E X E C U T I N G P A S S # 2 ***** E P R O G R A M L O A D M A P ***** : A D D . A R R A Y O C C O 0CC5 0CC5 0CC5 0 C C 8 O C C A 0CD2 0CD4 0CD5 0CD7 O C D A O C E H - 0CE7 0 C E 8 O C E B O C E C ***** S U M O C F O ***** N U M . A R R A Y 0 C F 2 N O R M A L T E R M I N A T I O N // L O A D A S S E M B L E R / L I N K E R // E X E C U T E S E P T 1 9 7 8 // L I S T I N G L O A D E R O B J E C T // L I N K A G E A D D R E S S F O R T H I S S Y S T E M O C C B O C D B O C E F O C C B O C D E O C E F O C C E O C D E O C F O 0 C D 1 0 C F 1 0 C D 2 0CE3 > A > C O P Y L A D D L O O P C O N O / 0 C C 0 1 0 1 9 2 A 0 1 2 C 0 0 0 2 0 A F F F F 1 9 0 2 1 0 0 A 0 0 0 0 1 4 0 C 8 B / 0 C D 0 1 0 1 A F 0 1 0 0 C 0 2 6 0 1 8 0 2 0 A 1 7 7 0 9 2 2 2 0 C E F 0 A 0 C 96 . / 0 C E 0 1 0 1 B F 2 0 C 0 2 5 A 0 8 0 C F 0 6 6 1 H - 0 C F 0 1 0 2 0 0 C D 2 2 H A 1 -* C O P Y * E O J // P R I N T L O A D M O D U L E > R H E X E M L * R H E X * E O J // L I N K 1 T O E M A C H I N E E M U L A T O R > R H E X L A D D L O O P * R H E X * E O J > W H E X 0 0 0 0 O C F F 1 0 T K A D D L O P * W H E X * E O J // S A V E C O M P L E T E M O D U L E 93 > L // LIST FILES EDEMO FILE NAME BLOCKS TEKDOS 16 FDUMP 3 COPYSYS 2 TKEDLCMP 38 TKEULASM 29 EML 8 ADDLOOP 1 OADDLOOP 1 LADDLOOP 1 TKADDLOP 9 TOTAL FILES 65 TOTAL.BLOCKS USED 219 BLOCKS AVAILABLE 75 TOTAL BAD BLOCKS 0 // RUN THE TEST PROGRAM UNDER DEBUG CONTROL > A * > RHEX TKADDLOP *RHEX* EOJ > DEBUG > BKPT OCCO > BKPT 0CD2 > GO 10 LOC INST MNEM R OPER X/PC FADD RA RB XREG SP CC 001E E600 LDA B 00 +0CC0=0CC0 3F 2A OCCO 3FFF CO 001E BREAK > GO // BREAK AT ENTRANCE, CONTINUE EXECUTION 001E E600 LDA B 00 +0CD2=0CD2 00 OC 0CD2 3FFB CO 001E BREAK // INITIATE DEBUGGER // SET BREAKPOINT AT ENTRANCE // SET BREAKPOINT AT THE START /I OF EACH PASS THROUGH ADDITION // LOOP // START EXECUTION 94 > EXAM OCFO OCFO=00 OO > EXAM OA OOOA=3F PC > EXAM 3FFC 3FFC=00 02 FF FF >G0 001E E 6 0 0 LDA B > EXAM OCFO OCFO=FF 18 > EXAM 0CF2 0CF2=FF 18 > EXAM 3FFC 3FFC=00 02 00 00 > CLBP > GO > A * // BREAK AT START OF LOOP fl CHECK DATA INITIALIZED CORRECTLY // CHECK SUM // OA IS LOCATION OF E MACHINE FP // CHECK K IN FRAME // START ANOTHER PASS THROUGH LOOP 00 +0CD2=0CD2 FF OC 0CD2 3FFB CO // BREAK AT START OF LOOP // CHECK SUM // CHECK FIRST WORD OF ARRAY // CONSISTENT WITH INTENDED ACTION // CHECK K // K NOW 0000 // CLEAR BREAKPOINT, DO SPEED MEASUREMENT // PROGRAM WILL HALT AT COMPLETION // E PROGRAM HALTS BY RETURNING TO TEKDOS 11 SYSTEM, EXECUTION REQUIRED 8 SECONDS // CLEAR SYSTEM // INCONSISTENCIES IN CONTENTS OF DATA, OR FAILURE TO ARRIVE 11 AT A BREAKPOINT, WILL REVEAL SEMANTIC ERRORS. 11 AN EDIT, COMPILE, AND EXECUTE CYCLE MAY BE USED TO CORRECT //THE SEMANTIC ERRORS. // DEVELOPMENT SEQUENCE OF SAMPLE PROGRAM IS COMPLETE. 11 A PROGRAM HAS BEEN ENTERED, COMPILED, ASSEMBLED & LINKED, /I AND TESTED UNDER DEBUG CONTROL. 11 THE DEVELOPMENT SEQUENCE HAS CREATED A LOAD MODULE, TKADDLOP, // WHICH MAY BE EXECUTED BY USE OF THE COMMAND SEQUENCE: 11 > RHEX TKADDLOP // > GO 10 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0065612/manifest

Comment

Related Items