0000 FINAL REPORT(Part i)

A MICROCODE COMPILER THAT RUNS ON THE IBM AT

in AND SUPPORTS CASCADABLE MICROCOMPUTERSSby

Thomas H. Weight,Ph.D.

0 Period Covered: 23 Sept 87 to 22 Sept 89Contract DAAD07-87-C-0119

forWhite Sands Missile Range, New Mexico 88002

D TIC 11 Nov 89ELETEDEC 15 1989 PENGUIN SOFTWARE,Inc.

7005 E. Spring St.- Long Beach, Calif. 90808

FD y'- L T ?NT A Wehas / WPh.Approvd icr putic refeasel Principal Investigator

D4tnbuton PENGUIN SOFTWARE,Inc.

The views, opinions, and findings contained in this reportare those of the author and should not be construed as anofficial Department of the Army position, policy, ordecision, unless so designated by other documentation.

89 12 '1.4.

SCUAIT"vCLAS R WCATIO OP 'RGE

REPORT DOCUMENTATION PAGEFomApveIS. REPORT SECURITY CLSSIICATION b RESTRICTIVE MARKINGS

00 o 7"1

UNCLASSIFIED2a. SECURITY CLASSW

intentionally left blank

SUMMARY

The microcode compiler being developed at PENGUIN SOFTWARE,Inc. is based on the concept of a retargetable compiler. Thisapproach does not have a fixed machine-independent language,but allows the user to develop a language specific to eachparticular target machine. This provides a means for the userto incorporate knowledge of target machine design into thelanguage definition, and avoid the necessity for resourceallocation and code compaction in the application program.

Previous microcode compilers have evolved from traditionalcompiler concepts and design methodologies. They have adoptedan approach involving machine-dependent languages and haveattempted to capitalize on the associated advantages. Thisapproach invariably gets bogged down in the problemsassociated with microcode compaction and resource allocation.Until these problems are solved, this approach has to beconsidered very high risk.

The Microcode Compiler being developed at PENGUIN SOFTWARE,Inc. has evolved from the classic microprogramming tool i.e.the meta-assembler. Our microcompiler starts out with anunderlying meta-assembler and builds up a higher levellanguage capability around it. This approach results in amicrocode development tool which is a very low risk, and iscapable of supporting virtually any digital hardwarearchitecture.

This microcode compiler is a new type of program. Accordingto one source, this approach has never been tried before; atleast no other retargetable microcode compiler exists. ThLsstudy has established the advantages of this approach to be:

1. Low Risk : There are no high risk algorithmsremaining to be developed.

2. Robustness : This compiler can support anyprocessor architecture supported by the currentstate-of-the-art meta-assemblers.

3. Speed : This comp '.. is competitive withmeta-assemblers in te."'s -f speed. This is in sharpcontrast to other micrL apiler designs. 0

04. Timeliness : This approach is working now.

Currently, PENGUIN SOFTWARE, Inc. is involved in acontinueing development effort to produce a commerciallymarketable microcompiler which is capable of supporting thedevelopment of microcode for cascadable, parallel, and Cdessystolic arrays of microprocessors. ',

iii ~ZJ

PREFACE

This report describes the microcode compiler feasibilitystudy and the compiler development undertaken at PENGUINSOFTWARE,Inc. under the phase two SBIR contractDAAD07-87-C-0119 sponsored by White Sands Missile Range.

There is currently a critcal need for a fully retargetablemicrocode compiler and for an effective development tool tosupport programming the new non-von Neuman architecturemicroprocessors. As more parallel processors, systolicarrays, and cascadable processors become available, theseneeds can only become more acute. Most of the chips resultingfrom the VHSIC program and all near-term gallium arsenidedevices will require microcoding. For the benefits of theseadvances to be fully realized, microcode development willhave to be automated in the relatively near future.

Our feasibilty study required the development of twocompilers: the Syntax Compiler and the Microcode Compiler.The Syntax Compiler generates a file which defines the syntaxand semantics of a machine dependent language. The MicrocodeCompiler along with this "Syntax File" then becomes tailoredto a particular target machine and a particular language. Anapplication program is then written in this new language andcompiled into an intermediate language file.

This intermediate language is typically a lower levellanguage than the application programing language but higherthan the binary object file. We choose to use HILEVELTechnology's HALE meta-assembler language as our intermediatelevel language. Since HALE is more or less campatible withMICROTEK Research, using HALE is not as restrictive as it'mayat first appear.

The advantages of using a state-of-the-art meta-assemblylanguage as an intermediate level language were quitesignificant. The intermediate file is easily modified by theprogrammer in a familiar language; the meta-assembler handlesthe actual assembly, linking, and PROM formatting.

While there are very few research journal articles related toour work, we have not been forced to work in a vacuum. Wewould like to thank the marketing staff at HILEVEI Technologyin Irvine, and we would especially like to thank Mr. WarrenLong, Product Marketing Manager at HILEVEL technology for hismany suggestions in the areas of requirements and engineeringdesign. We would also like to thank the engineers andmanagers of Rockwell International, Hughes Aircraft,Northrop, and TRW that have contributed tlieir time andallowed themselves to be interviewed.

iv

Part I - FINAL REPORT

TABLE OF CONTENTSpage

1.0 INTRODUCTION ...................................... 12.0 MICROCODE COMPILER STUDY ......................... 4

2.1 Define Machine Dependant Languages ............1.42.1.1 Statement Notation ........................ 42.1.2 Entity Notation ........................... 4

2.2 Define Syntax Definition Language .............. 62.2.1 Syntax Definition ................. ... 62.2.2 Semantics Definition .................. .... 9

2.3 Compiler Capabilities ...................... 122.3.1 MACRO's ........................ 122.3.2 Structured Control ....................... 122.3.3 Compiler Evaluation of Expressions ....... 132.3.4 Pseudo Operations ....................... .132.3.5 Conditional Compilation ............ . ..... 132.3.6 Relocatable Object Code .................. 132.3.7 Linkable Object Modules .................. 15

2.4 Support Cascadable Microprocessors ............ 152.5 Dynamic Memory Allocation.. ................... 152.6 Optimize Compilers for Speed ................. 162.7 Generate Design Modifications ................. 162.8 Make Code Changes ............................. 172.9 Generate Test Cases ........................... 172.10 Integrate Software Modifications ....... * ...... 18

3.0 STATUS OF ACCOMPLISHMENTS ......................... 193.1 Develop Operational Concept ................... 193.2 Upgrade Existing Software ..................... 193.3 Output HALE Source Code ....................... 193.4 Support Cascadable Micrprocessors ............. 193.5 Dynamic Memory Allocation .................... 193.6 Optimize Compilers For Speed ................. 20

4.0 CONCLUSIONS AND RECOMMENDATIONS .................. 214.1 Conclusions ................................... 21

4.1.1 Tasks completed and Objectives Attained..214.1.2 Low Risk Approach ........................ 21

4.1.3 High Speed ............................... 214.1.4 Graceful Degradation ..................... 214.1.5 Language Level ........................... 224.1.6 Comparing the Two Approaches ............. 22

4.2 Recommendations ........ ........ ........... . 234.2.1 Rethink Expectations ............... ...... 234.2.2 Design Hardware To Match Compilers ....... 24

APPENDIX A PROJECT OVERVIEW

Part II - PRELIMINARY USER'S MANUAL(separate document)

Part III- PROPRIETARY SOURCE PROGRAM(separate document)

V

LIST OF TABLES

Figure No. Page No.1 List Notation Format ............................ 52 Compiler Sentence Format ........................ 53 CLAUSE Definition Format ........ .................... 54 Example: Literal Strings Definition ............. 75 Example: When Not to Use Literal Strings ........ 76 Simple ARRAY DEfinition Format .................. 87 Example: Using ARRAY Definition ................. 88 Example: When Not to Use Simple ARRAY's ........ 109 Dimensioned ARRAY Definition Format ............ 10

10 Example: Using Dimensioned ARRAY ............... 1011 LITERAL Definition Format ...................... 11

12 Example: Using LITERAL ......................... 1113 Using Internal Compiler Resources............. 14

HILEVEL and HALE are registered Trademarks of HILEVELTechnology, Inc.

IBM AT is a registered trademark of IBM,Corp.

vi

1.0 INTRODUCTION

The microcode compiler being developed at PENGUIN SOFTWARE,Inc. is a retargetable compiler. This compiler does not havea fixed machine-independent language, but allows the user todevelop a language specific to each particular target machineand application.

The microcode compiler is a two stage translation scheme. Thefirst stage provides a fixed high-level design language topermit the easy definition of the machine-dependent high-level language. The language definition compiler, called theSyntax Compiler, produces syntax files which define both thesyntax and semantics of the target machine language.

The application program is compiled by the Microcompiler toproduce the object file microcode. The application programsare written in a language specifically designed for theparticular target processor. This language is almostcompletely free from constraints with just enough underlyinglanguage structure to facilitate the application languagecompilation process.

The approach to automated microcode generation beingdeveloped at PENGUIN SOFTWARE, Inc. is based on the conceptof machine-dependent languages. This provides a means for theuser to incorporate knowledge of the target machine into thelanguage definition. There are some obvious advantages anddisadvantages to this approach.

Some of the advantages of this approach are expressiveness,robustness, and low risk.

a. This approach allows the programmer to design amachine-language tailored to the needs of a particularapplication. This can result in a highly expressive andefficient language.

b. Because of this microcode compiler's relationship to theunderlying HALE meta-assembler, this microcode compiler isextremely unlikely to fail due to a particular target machinedesign.

c. Finally, this approach avoids the tough problems ofmicrocode compaction and resource allocation.

Some of the disadvantages of this approach are lack of astable application language, and the difficulties associatedwith trying to imbed low-level hardware details in a high-level language.

a. A stable application language is desireable because it

makes application programs more transportable and facilitatesthe development of microcode simulators.

b. Because of the hardware design, it may be difficult todesign a suitable high-level language for a particularapplication.

The basic requirement of our Phase II effort was todemonstrate the feasibility of PENGUIN SOFTWARE's approach tomicrocode development. Section 2.0 describes, in some detail,the research and development efforts expended at PENGUINSOFTWARE, Inc. to meet the Phase II requirement andsummarizes the important results from Phase I. These resultswere essentially the design specification of the class oflanguages supported by the Microcode Compiler.

Section 3.0 describes the objectives of the Phase IIcontract. Under the current contract, the followingobjectives were completed at PENGUIN SOFTWARE, Inc.:

a. Developed the operational concept based on using HALE asan intermediate level language. We had to varify that wecould use our Microcode Compiler essentially as an HALEpreprocessor.

b. Upgraded existing software to reflect our new philosophy.The Microcode Compiler now functions more generally as asemantic action processor, and not just a high-level languageprocessor designed to produce binary object files.

c. Modified source code to output HALE as an intermediate-level language. In addition to modifying the Syntax andMicrocode Compilers to output ascii code, the capability tosupport HALE pseudo-operations was also required.

d. Included the capability to support cascadablemicroprocessors. The Microcode Compiler now supports one ormore cascaded processors as specified by parameteric commandline input.

e. Developed a dynamic memory allocation scheme. Now keyarrays are stored either in lower RAM or in extended memoryabove one million bytes. This feature is designed to keep theMicrocode Compiler from becoming obsoleted by a largeprogram.

f. Optimized the Microcode Compiler for Speed. The MicrocodeCompiler was restructed in order to speed up processingduring the time critical compilation of the applicationprogram.

Section 4.0 gives a summary of conclusions and

2

recommendations. We concluded that all technical objectiveswere attained. This project shows that this is the low riskapproach to developing a Microcode Compiler. This followsfrom the evolutionary (rather than revolutionary) nature ofour relationship to the proven meta-assembler technology.After restructuring the Microcode Compiler runs quite fast,and should be completely satisfactory commercially. Our

approach to high-level language microcoding has proven to bequite robust. We have found that for difficult problems, thelevel of the application language may degrade. But thereappears to be no significant tendency for the efficiency ofthe microcode to be impaired.

2.0 MICROCODE COMPILER STUDY

PENGUIN SOFTWARE's retargetable microcode generator systememulates a wide range of computer architectures. By allowingthe user to define a machine-dependent high-level language,and then write an application program in this new language,the microcode generator is able to translate the applicationprogram into efficient horizonal microcode.

Our minimum goal was to produce a working microcode compilerwhich would be a useful tool in industry. In order to achievethis goal, we determined to start with the most powerfulmeta-assembler that we could find and then enhance itscapabilities to achieve a higher-level language capability.For a project overview, see Appendix A. Many of the projecttasks were divided into two parts. The first part, the syntaxanalysis, determines the readability of the language. Thesecond part, the semantic action, determines to a largeextent the level of the language.

2.1 Define Machine Dependant Languages

2.1.1 Statement Notation

Two types of statement notation were considered. The firsttype, "action verb", is similiar to the standard assemblylanguage statement. Unfortunately, "action verb" does notseem compatible with the requirements of horizonalmicroprogramming. The second type of statement notation,"list notation", is ideal for horizonal microcoding. Thisstatement has the basic form shown in Fig. 1. We have adoptedthe convention that all labels are immediately followed by acolon, the entities are separated by ampersands, and the lastentity is followed by a semicolon. Everything to the right ofthe semicolon is a comment.

2.1.2 Entity Notation

The lowest level of entity notation identified is "positionalnotation." In positional notation each entity is related toone particular field. This notation does not appear to haveany role in our high-level language except possibly to forcespecific values into a specific microword, and even thenthere seems to be better ways to accomplish that.

Several nonpositional entity notations were identified. Theseinclude "function reference notation", "value mnemonicnotation", and "keyword notation". All of these notations aredesireable in different applications. Rather than decide onanyone of them, a different notation has been selected whichincludes all of the above: this is the "free notation". Inthe free notation there are almost no constraints on the

J4

: &entity>&...&;

FIGURE 1. List Notation Format.

: && ... &;

FIGURE 2. Compiler Sentence Format.

CLAUSE {}{}

FIGURE 3. CLAUSE Definition Format.

5 e

M I

notation used. The only constraints imposed on the entitynotation are those derived from the design requirements andthe implementation of the program.

2.2 Define Syntax Definition Language

We have adopted the terms "sentence" for the entire line fromthe label to the end of the comment, and the term "clause"for the entity as shown in Fig.2. Since only the structure ofthe sentence is hard-wired into the microcode compiler, itremains to the syntax compiler to define the syntax andsemantics of the clauses. A syntax compiler source file isconstructed using the language outlined below. This file willdefine all of the legal application language clauses anddefine what these clauses mean. The basic clause definitionappears as shown in Fig. 3.

2.2.1 Syntax Definition

The syntax definition process for each clause is accomplishedby using three related contructs: literal strings, arrays,and literals.

Literal strings are the simplest and in some cases the mostefficient means for defining the syntax of a clause. Aliteral string is a string of alphabetic or specialcharacters enclosed in double quotes. Numerical digits canalso be included, but they must be preceeded by an alphabeticcharacter. Ignoring the semantic definitions for the moment,the examples as shown in Fig. 4 show clauses defined usingthe literal string.

Literal strings are most useful for clauses, such as "NOP",which are, in a sense, one-of-a-kind. Literal strings are notvery efficicient in situations like "REGI = REG12" wherethere are several registers that may appear on either side ofthe equation such as shown in Fig. 5. This situation ishandled by the two types of arrays described below.

First, the ARRAY is identified by an array name, then theARRAY is defined by an array of tokens and their associatedsemantic actions. Fig. 6 is a simple example of an ARRAYstructure. An ARRAY is used in a CLAUSE definition simply byspecifying the ARRAY name. Using an ARRAY in a CLAUSEdefinition can considerably reduce the amount of effortrequired as can be seen by the example in Fig. 7. In thisexample, we have a very simple situation where the contentsof any source register can be moved into any destinationregister. Experience has shown that quite often these ARRAY'swill be used repeatedly to define other CLAUSE's. Thisresults in a tremendous savings of programming effort.

6

CLAUSE t "NOP" }

CLAUSE{ "REGI = REG12" }

CLAUSE { "REPEAT(FOREVER)" }

FIGURE 4. Example: Literal String Definitions.

CLAUSE { "REGI = REGI" }CLAUSE { "REG2 = REG" }CLAUSE { "REG3 = REGI" }

CLAUSE { "REGIF = REGI" CLAUSE { "REGI = REG2" }CLAUSE { "REG2 = REG2" I

CLAUSE { "REGiF = REG2" }CLAUSE { "REGI = REG3" }

CLAUSE { "REGIF = REGIF" I

FIGURE 5. Example: When NOT to use Literal Strings.

m.. -. nmmm m ~ m m m | m7

ARRAY ={ semantic action };

{ semantic action 1;

semantic action };

FIGURE 6. ARRAY Definition Format.

CLAUSE { REGD " REGS }

ARRAY REGD = {REGI{ semantic action 1;REG2( semantic action );REG3{ semantic action };

REGlf( semantic action };}ARRAY REGS :

REGif semantic action };

REG2{ semantic action };REG3{ semantic action };

REGIf{ semantic action };

FIGURE 7. Example: Using ARRAY Definitions.

8

Occasionally, we have a situation, unlike the preceedingexample, where the source and destination registers are notorthogonal. That means, in this case, only certain sourceregisters can be used with certain corresponding destinationregisters. The result is that simple ARRAY's would no longer

work efficiently. Now we could fall back on the use ofliteral strings as discussed before and define severalCLAUSE's as shown in Fig. 8. Although this approach wouldwork, it is still possibly quite inefficient. For thisreason, we have adopted an approach using dimensionedARRAY's. Dimensioned ARRAY's have the particular propertythat if more than one column of the ARRAY is used in a CLAUSEdefinition, then the tokens must all come from the same row.The definition of a dimensioned ARRAY is shown in Fig. 9. Adimensioned ARRAY is used to solve the CLAUSE definitionproblem discussed above as shown in Fig. 10.

The final construct is the LITERAL. LITERAL's are used todefine the processing of numbers and statement labels. The

LITERAL is defined as shown in Fig. 11 and is used in aclause as shown in Fig. 12. The LITERAL allows theapplication programmer to include values in the program atcompile time.

2.2.2 Semantics Definition

The semantics of a particular statement is defined in termsof the semantic actions to be performed when that statementis encountered in an application program. For eachapplication program statement, the microcode compiler mustreconstruct the statement definition to determine the

particular CLAUSE, ARRAY row, and LITERAL as appropriate.These semantic actions are associated with the CLAUSE's, rowsof the ARRAY's, and with the LITERAL's.

The semantic actions which have been implemented are desribedbelow:

a. DEF'ed statement: A DEF'ed statement with field values

specified or left blank. This statement is to be insertedinto the HALE source file, along with any other statementsassociated with the current line of microcode.

b. LBL: LBL appearing in a DEF'ed statement will causethe contents of the Active Label Register to be inserted intothe corresponding field.

c. PSH: PSH will cause the contents of the Active LabelRegister to be pushed onto the Microcode Compiler InternalStack.

d. PPS: PPS will cause the Microcode Compiler Internal

9

CLAUSE { "REGi = REG5" }CLAUSE { "REGI = REG7" }CLAUSE { "REG2 = REGI" }

CLAUSE { "REGIF REG12" }

FIGURE 8. Example: When NOT to use simple ARRAYs.

ARRAY (dim #1,dim #2,...,dim #m) z( sematic action }{ sematic action }

{ sematic action }}

FIGURE 9. Dimensioned ARRAY Definition Format.

CLAUSE ( REGDS(1) ": REGS(2) }

ARRAY REGDS(1,2) = {REG1,REG5( semantic action };REGI,REG7T semantic action I;REG2,REG1{ semantic action };REG3,REG5{ semantic action };

REGIF,REG12{ semantic action };}

FIGURE 10. Example: Using Dimensioned ARRAYs.

10

LITERAL( ) = semantic action }

FIGURE 11. LITERAL Definition Format.

CLAUSE { REGD "=" LITERAL(1) }

LITERAL(1) = { semantic action I

ARRAY REGD = defined as above in figure 7.

FIGURE 12. Example: Using LITERAL.

11

Stack to be popped, and the value popped will be insertedinto the Active Label Register.

e. MAK: MAK will cause a label to be created and storedin the Active Label Register.

f. PLB: PLB will cause the label stored in the ActiveLabel Register to be inserted into the HALE source file atthe current microcode address.

g. LBLn: LBLn (where n = 1,2,3,4,5) will cause thecontents of the Active Label Register to be stored inMicrocode Compiler Internal Register n.

h. SWP: SWP will cause the top two labels stored in theMicrocode Compiler Internal Stack to be swapped.

i. LIT: LIT used in a LITERAL pseudo operation will causethe corresponding literal to be stored in the Active LabelRegister.

j. LITn: LITn (where n = 1,2,3,4,5) will cause MicrocodeCompiler Internal Register n to be copied into the ActiveLabel Register.

2.3 Compiler Capabilities

One of the key design decisions was to use the HILEVELTechnology HALE Meta-assembler language as an intermediatelanguage for our compiler. As a consequence, the compiler wasmodified to output HALE compatible code, to handle HALEpseudo-operations, and to process HALE Definition Phasesource files. Our compiler gained flexibility and many ofHALE's most important capabilities at very little cost.

2.3.1 MACRO's

One of the advantages of using a high-level langauge is theability to generate more than one line of object code fromone line of source code. This capability has been included inthe microcode compiler.

2.3.2 Structured Control

Structured control statements allow the development of blockstructured code and an orderly approach to program controlflow. Structured control is included as an important part ofthe microcode compiler. Since developing structured controlstatements requires the use of Microcode Compiler internalresources, a brief example may be appropriate.

Suppose you intend to provide in your language the DO...WHILE

12

instruction as shown in figure 13. Reasonably, the DO

statement must provide for:

1) The creation of a statement label (MAK).

2) The assignment of the newly created label to the currentlocation in the microcode (PLB).

3) The saving of the label on the Microcode Compiler InternalStack (PSH).

The WHILE statement must then:

4) Retrieve the label from the stack (PPS).

5) Insert the label into the microcode as the destination ofa conditional jump statement using the LBL pseudo opcode.

For further examples, see the PSI Microcompiler User's Manual

2.3.3 Compiler Evaluation Of Expressions

Arithmetic expressions are not evaluated during the compilephase. There are inserted into the HALE source file outputfrom the compiler. The final evaluation of the expressions isperformed during the HALE assembly phase.

2.3.4 Pseudo Operations

PENGUIN SOFTWARE's microcode compiler was modified to use allof the HALE meta-assembler pseudo-operations. Most of thepsuedo-ops are just inserted into the HALE source file at theappropriate places e.g MAP. Other pseudo-ops are processed inthe microcode compiler or the HALE meta-assembler as requirede.g. LIST.

2.3.5 Conditional Compilation

There were essentially two ways to handle conditionalcompilation. One was to evaluate the condition and justinsert the appropriate microcode into the HALE source file.The other approach, the one adopted, was to insert theconditional statements and both parts of the microcode intothe source file. This final approach is much closer to theway things are commonly done, and was much easily toimplement.

2.3.6 Relocatable Object Code

Relocatable microcode is produced by including theappropriate pseudo-ops in the Microcode Compiler source file.These pseudo-ops are then inserted into the HALE source file

13

DO

WHILE( )

13.a EXAMPLE: Application Program use of DO...WHILE

CLAUSE { "DO" H MAK & PLB & PSH ICLAUSE { "WHILE(" ")" }

PPS & AM2910 ,LBL,,CJP }

13.b EXAMPLE: Possible Definition of DO...While

FIGURE 13. Using Internal Compiler Resources.

14

at the appropriate places.

2.3.7 Linkable Object Modules

The HALE meta-assembler produces relocatable microcodemodules which are then linked using the HILEVEL Technologylinker program.

2.4 Support Cascadable Microprocessors

The decision to use HALE as an intermediate language has hadthe severist consequences in the requirement to supportcascadable microprocessors. This requirement involvesessentially multiplying the microword produced for oneprocessor by some number n representing the number ofcascaded processors. While this was not difficult to achievein the Syntax and Microcode Compilers, the maximum HALE wordwidth represents a significant limitation.

2.5 Dynamic Memory Allocation

This concept was originally based on a misconception aboutthe architecture of the IBM/AT and the operation of the MSDOSoperating system. The original concept was based on themisconception that the MICROSOFT "C" compiler runnig on MSDOSallowed easy access to memory above the 640K limit. This, ofcourse, proved to be wrong.

We were forced to develop an approach similiar to the way RAMDisks are implemented. This involves paging data in and outof Extended Memory. Using MSDOS interrupts called through "C"functions data is moved in or out of Extended Memeory asrequired. This requires maintaining page counters and pagepointers down in local memory.

Also we were required to. develop an appropriate pagereplacement strategy. We finally settled on leaving the firstand last pages resident in local memory, while pagingintermediate pages in and out as required. This has severaladvantages which are based on the construction of our symboltables and hash tables. After hashing a symbol, we are leftwith a pointer into a list of linked lists. All of theselinked lists begin on the first page. Any symbol not found inthe symbol table is inserted at the end of the list, which isalways on the last page.

WARNING: Since this approach is similiar to RAM Disks, I't isnot suprising that all data stored in RAM Disks is subject tobe destroyed unless care is taken addressing this problem.

a. One solution might be to not use RAM Disks.

15

b. Another solution might be to locate the RAM Disk above thetwo megabyte boundary and reserve the second megabyte for themicrocode compiler.

2.6 Optimize Compilers For Speed

The original concept was to identify certain code segmentswhich were consuming large percentages of the processingtime. Once these segments where identified, we were goingimmediately into an assembly language recode of those areas.This approach was modified considerably.

Asembly language routines where coded and inserted into thetwo compilers. An interrupt was used to stop the programperiodically, and a table of location counters wasincremented based on where each interrupt occured. After arun through each compiler, the location counter tables wheredumped to a file for further analysis.

The analysis of this data showed that optimizing the syntaxcompiler was not worth while short of recoding the wholeprogram. As a consequence, the Syntax Compiler was notmodified. We decided to focus all of other recoding effort onthe Microcode Compiler. Recoding in assembly language carriesa heavy penalty in terms of reliability and maintainability.As a consequence, it was decided initially to tryrestructuring the "C" program in order to obtain the requiredincrease in speed. This restructuring was performed with theresult that the Microcode Compiler is now running in timescomparable to most meta-assemblers.

2.7 Generate Design Modifications

One of the most substantial design modifications involvedconverting the compilers to "semantic action machines". Wetook this to mean that the compilers would be designed tohandle a wide range of semantic actions and would be designedto facillitate incorporating new semantic actions in thefuture. This change reflects our intensions to push the levelof the languages supported to higher levels, and to support amuch wider spectrum of application than just microcoding.Several suggestions have been recieved for enhancements alongthese lines e.g.

a. Allow creating a label from any arbitrary symbol. Thiswould be extremely useful when the user is creatingsubroutines or functions.

b. Allow creating variables and assigning storage classes atcompile time. Currently these variables are assigned a fixedstorage class at syntax definition time.

16

c. Process (for example) SIMSCRIPT pseudo operations inprograms. This would allow the use of this compiler for therapid prototyping of ultra high level simulation languages.

2.8 Make Code Changes

Code modifications where intended to adhere to standardsoftware engineering practices. We tried to avoid thetemptation to patch in changes and cutting other corners. Asa consequence, there were few problems with our level zerotesting (software debug at the lowest level).

2.9 Generate Test Cases

Test cases were generated to satisfy three requirements: todebug the program; to perform the compiler timing studies;and to demonstrate the capabilities of the microcodecompiler.

The debugging effort was automated as much as possible toencourage and facilitate frequent testing. Both a test file(or files) and an answer file were created. DOS commands werethen issued from a ".BAT" file to automatically run a testcase and verify the results.

WARNING: Inspite of these efforts, no effort was made to testthese programs to any standard appropriate for a commercialproduct or to a standard adequate for a military deliverableitem.

Test files were constructed for use in the timing studies.The Syntax compiler was timed with one large and one small.test case, while the Microcode Compiler was timed with alarge, a medium, and a small test case for each of the SyntaxCompiler output files.

Our original goal was to be as fast as the state-of-the-artmeta-assemblers. With our current approach, this wasimpossible. Since the compiler produces a HALE source filewhich must in turn be processed by the HALE meta-assembler,we were forced to include the assembly times in our analysis.

The third type of test case was designed to demonstrate theexpressive power and flexibility of the Microcode Compiler.Various languages were developed. These languages wererealistic in the sense that the were designed to solvecertain problems; they were complete only to the extent thatthey solved the required problems. Some languages weregenerated to support the customers in-house microprogrammablecomputers and were intended to prove the Microcode Compiler'sability to support a wide range of machines.

17

2.10 Integrate Software Modifications

Perhaps the biggest problem we encountered was involved withthe interface between HALE and the PENGUIN SOFTWARE MicrocodeCompiler. HILEVEL Technology provided us with a set ofdocumentation for a new version of HALE. Unfortunately, thisversion does not seem to have ever been developed. Thisrequired back tracking to an earlier version of HALE whichwas in fact released. Our Microcode Compiler now works withthe latest versions of the HALE meta-assembler.

WARNING: Our Microcode Compiler is known not to work with theout dated versions of HALE. In particular, the HALE versionmust be able to handle labels on empty sentences i.e.sentences which do not contain DEF'ed statements.

18

3.0 STATUS OF ACCOMPLISHMENTS

During this period, a full scale retargetable microcodecompiler was specified, designed and constructed. The purposeof this development effort was to demonstrate the feasibilityof our approach to automated microcode development. Atcompletion of this feasibility study, we had produced a fullyoperational microcode compiler and had applied it to severaldifferent test cases for evaluation.

3.1 Develop Operational Concept

An operational concept was developed which integrated ourmicrocode compiler into the already existing HILEVELTechnology HALE meta-assembler microcode development system.This approach has several advantages. By outputing HALE asour intermediate level language, we are able to fully exploitthe features and capabilities of that state-of-the-artmeta-assembler. Some of these features include expressionevaluation, relocatable microcode, and linkable microcode.

3.2 Upgrade Existing Software

The design of our final product was based on the design ofthe Phase I prototype. The development of this prototypeunfortunately involved generating a lot of kludges whichreduced reliability and maintainability. The entire programwas reviewed and recoded as necessary in line with modernsoftware engineering practices.

3.3 Output HALE Source Code

The microcode compiler now outputs ASCII strings of HALEsource code instead of a binary object file. At first glancethe may appear to be a step backward, and it is. Thisapproach however does have several advantages. In addition toadding all of the power of the HALE development system to ourmicrocode compiler, it also generates output in a form whichcan be easily modified by a microprogrammer.

3.4 Support Cascadable Micrprocessors

The microcode compiler now contains the option of expand themicroword by some operator input factor in order toaccomodate cascadable microprocessors. Unfortunately thiscapability is somewhat limited by the need to process ouroutput through the HALE system which has a limited microwordwide.

3.5 Dynamic Memory Allocation

As the need for larger and larger microprograms continues,

19

any microcode compiler is in danger of running out of mainmemory and becoming obsolete. In an attempt to extend thelife of our microcode compiler and investigate the lastremaining new algorithm, we included the capability to useextended memory where available and specifically permitted.Various predefined large arrays can be located in an openended manner in otherwise useless extended memory.

3.6 Optimize Compilers For Speed

It was ultimately determined that our microcode compiler wastoo slow. An analysis of CPU time useage showed that only themicrocode compiler (and not the syntax compiler) needed to beaccelerated. While it was originally intended to recodecertain critical functions in assembly language, thisapproach was finally rejected as too unreliable, anddifficult to maintain. What we did was use our timinganalysis to guide a restructuring of the "C" code.

20

4.0 CONCLUSIONS AND RECOMMENDATAIONS

4.1 Conclusions

A new and powerful approach to microcode development has beeninvestigated at PENGUIN SOFTWARE, Inc. under the contractDAAD07-87-C-0119 sponsored by White Sands Missile Range. Thisapproach has required the development of two prototypecompilers. The first compiler is used to design and define amachine-dependent language for a particular target machine.The definition of this language is contained in a syntax andsemantic definition file. This syntax file is inverted andinput to the microcode compiler. This microcode compiler thenfunctions somewhat as a HIGH LEVEL Technology HALEpreprocessor which converts the application program into anHALE source program.

4.1.1 Tasks Completed and Objectives Attained

All proposed tasks have been completed and all technicalobjectives have been attained resulting in a demonstratiionof the feasibility of our proposed approach.

4.1.2 Low Risk Approach

After running several test cases during the software debug,software validation, timing study, and the demonstrations, wehave gained confidence not only in the correctness of thesoftware but also in the validity of nur approach. This beinga new approach, it had several conjectured disadvantages. Wehave found that there were indeed no undeveloped algorithmswaiting to trip us up. We were able to proceed to a full upworking production-quality microcode development system.

4.1.3 High Speed

In the real world, program speed is certainly an importantissue. We were concerned that the microcode compiler would benon-competitive with state-of-the-art microcode developmentsystems because of the added algorithm complexity. Ourapproach involved using proprietary algorithms and datastructures developed here at PENGUIN SOFTWARE, Inc. over thepast five years. The result is that the existing microcodecompiler runs in times more than competitive with existingmeta-assemblers.

4.1.4 Graceful Degradation

All commercially successful meta-assemblers have at least onecapability in common: This is the capability to support anymachine that may be designed. Using the traditional approachwith microcode compilers. It is easy to envision target

21

machine designs that would render a traditional microcodecompiler uselessly inefficient. The complexity andsensitivity of the resource allocation schemes and themicrocode compaction algorithms leave these compilersextremely vulnerable to total failure.

With our approach, a situation involving total failure due totarget machine complexity is avoided. In the worst cases, the

high-level language supported will fail to meet user

expectations with respect to the level of the language. Inthis case the greatest concern has to do with howsuccessfully low level hardware design features can beincorporated into a high level language. This is a smallissue compared to a case were the microcode compiler simplyno longer works or produces unacceptably inefficientmicrocode.

4.1.5 Language Level

PENGUIN SOFTWARE's microcode compiler supports some popularand important language features. These features include thecommon arithmetic expressions appearing in languages likeFORTRAN, "C", and ADA. In addition, our compiler supportssemantic actions which allow the definition of various"structured" programming constructs e.g. DO...WHILE,REPEAT...UNTIL, IF...THEN...ELSE...ENDIF, CASE, etc.

PENGUIN SOFTWARE's microcode compiler does not achieve thelanguage level of "C", and ADA. We fail to achieve thiscapability in two important areas.

Firstly, there is resource allocation. Typically inhigh-level languages, the programmer has the ability toeither specify resource allocation at compile time or havethe compiler allocate resources automatically. With ourcompiler, resources must be allocated during languagedefinition or at compile time: there is no automaticallocation of resources.

Secondly, there is code compaction. An ideal microcodecompiler would automatically produce compact and efficientmicrocode. While our compiler is capable of producing goodmicrocode, it does not do it automatically. Essentially, ourcompiler produces efficient microcode by a combination ofdesigning efficiency into the high-level language and byrequiring the application programmer to apply knowledge aboutthe target hardware.

4.1.6 Comparing The Two Approaches

There are several advantages to having a microcode compilersupport a machine independent language e.g "C", or ADA. These

22

4

languages free the programmer from needing any hardwareknowledge and drastically reduces the skill level needed inthe programming staff. In addition, there is a large supplyof programmers already skilled in using the common machineindependent languages. Finally, a language written in "C"(for instance) automatically provives a microcode simulator.This follows from the fact that "C" compilers are common anda "C" programm can be compiled and ran on practically anymicrocomputer.

The main advantage of our approach is that it works. Ourapproach to automated microcode generation was initiallyconsidered to be low risk in two important respects.

a. During our development effort, there were no high riskalgorithms to be developed. We were quickly able to generateworking compilers which were then refined through severalstages of improvement.

b. For the end user, our approach is much more robust thanthe competition. This follows from the current state of codecompaction algorithms.

The result is that we have developed a microcode developmentsystem which we can use and evaluate in the short term. Inthe long term, when the code compaction and resourceallocation algorithms are perfected, the machine independentlanguage approach based on ADA or "C" will be far superior tothe machine dependent approach.

4.2 Recommendations

We have two recommendations that are contrary to conventionalwisdom.

4.2.1 Rethink Expectations

The advantages of automated microcode generation resultmostly from the readability of high-level languages. Codethat is easier to read is easier to write, debug, test, andmaintain. High-level language microcode can more than pay itsway with these advantages. Unfortunately, many people haveunrealistic expectations about productivity improvementsresulting from code expansion.

QUESTION: Many high-level language statements expand into tenassembly language statements. Likewise, many assemblylanguage statements expand into ten microcode statements. Canwe reasonably expect high-level language statements to expandinto one hundred microcode statements?

Our answer, with a few obvious exceptions, is no. The fact of

23

the matter is that the code expansion mentioned above resultsmostly from mismatches between the hardware structure and thelanguages being supported. Our examples of "C" statements andtheir handcoded microcode equivalents show that a wellmatched machine and high-level language will result in aone-to-one translation of high-level language to microcodevery similar to a meta-assembler with MACRO capability.

4.2.2 Design Hardware To Match Compilers

There is one fact about high-level languages which seems tobe consistently overlooked: modern computers are designed tosupport these compilers. The microcoding community mustaccept the obvious consequences of this fact: hardware designrequirements will have to include provisions for supportingmicrocode compilers.

24

APPENDIX A

PROJECT OVERVIEW

A1.0 MAINSTREAM APPROACH TO AUTOMATED MICROCODE GENERATION

Most efforts at automated microcode generation have turnedtoward high-level languages and hence microcode compilers. Inaddition, all research efforts appearing in technicaljournals have adopted a similiar approach to developing amicocode compiler. We call this approach the "mainstream"approach.

The mainstream approach to automated microcode generationstarts with a high-level language capability and attempts towork toward efficient microcode. This approach is basedessentially on the existing compiler technology(see Fig.A-I). The main idea is to start with some appropriatemachine-independent language as a target language, design acompiler to expand source code (written in the targetlanguage) into some intermediate language, expand theintermediate language into microcode, allocate resources inthe microcode, and finally process the microcode in anattempt to improve the efficiency of the microcode to asatisfactory level.

A2.0 PENGUIN SOFTWARE'S APPROACH

PENGUIN SOFTWARE's approach to automated microcode generationstarts with efficient microcode and works towards ahigh-level language capability. Rather than start withexisting compiler design technologies, we start with existingmeta-assembler capabilities. To the typical meta-assemblercapabilities, we have added more semantic actions upgradingthe level of the languages supported.

Our approach requires two compilers: the first compiler farthe language definition, and the second compiler for themicrocode generation (see Fig. A-2). A language DescriptiionFile is prepared which defines the target language. This fileis compiled to produce a set of drive tables (SyntaxDefinition File) which define the target language for theMicrocode Compiler. Finally, the application program (writtenin the target language) and the drive tables are processed bythe Microcode Compiler which in turn produces the microcodeObject Program.

A3.0 state of microcode compilers

Figure A-3 attempts to show our analysis of the current stateof the Microcode Compiler effort. The upper left hand cornerrepresents the current state-of-the-art in compilertechnology: very high-level language and very low efficiencymicrocode. The lower right hand corner represents the currentstate-of-the-art in meta-assembler technology: very highefficiency microcode and very low-level languages.

A-i

Appl icatiLonProg ram

7PartialCompiler

Machine IndependentIntermediate Program

Exbansion MCR

BindingOperands

Compaction JObjectProgram

Figure A-1. MAINSTREAM APPROACH

A-2

LanguageDescri~ption File

Application SyntaxProgram Compile

Figure mile A-2. PENtJ. SOTWRnSAPRax

Deiito3Fl

-~unacceptable acceptableefficiency efficiency

compiler optimal0 technology microcode

-

compiler T

C-4

PS4U

U

c-

m-

~meta-assembler

~technologylow high

microcode efficiency

14S = state of MainstreamPS = state of PENGUI7N SOFTWARE

Figure A-3. STATE OF AUTOMATED MICROCODE

A-4

0Ed

The mainstream approach (represented by "MS") is essentiallya standard compiler with a microcode compaction algorithmadded on at the end. This allows a substantial improvement inefficiency but still fails to achieve an acceptable level ofperformance. The mainstream approach attempts to capitalizeon the substantial benefits of providing a machine-independent language. The success of this approach isdependent on the development of acceptable resourceallocation and code compaction algorithms. Without thesealgorithms, this whole approach fails catastrophically and isnot commercially useful as a microcode development tool.After decades of research, useful algorithms are still notavailable.

The PENGUIN SOFTWARE approach (represented by "PS") isessentially a standard meta-assembler with additionalsemantic actions. This allows a substantial improvement inthe language level without necessarily sacrificing microcodeefficiency. When this approach fails, it fails gracefully.The success of our approach, for a particular application, isdetermined by the level of the language supported and thelevel of customer satisfaction with that language. Theminimum level of the language and the minimum level ofefficiency of the microcode need never be any worse than forthe underlying meta-assembler. Since this meta-assemblerrepresents the current state-of-the-art, the MicrocodeCompiler should never fail to be a useful development tool.

A-5