- Email: [email protected]
Crossassembler for the TMS32010 digital signal processor
Crossassembler for the TMS32010 digital signal processor The requirements of realtime signal processing often force software developers into assembler programming. D R Campbell, C Canning and K Miller have written a crossassembler for the TMS32010, running on Prime minicomputers
Software to support the development of TMS32010 assembler programs on a Prime computer system has been written using BASIC. The software consists of three main modules: a crossassembler, a format converter and a downloader. The software, which allows macro definition and the linking of previously written source code modules, has been tested and is now being used successfully. digital signal processors
crossassemblers
TMS32010
Microprocessors specifically designed to perform common digital signal processing (DSP) operations efficiently are now available from several manufacturers. Applications of these devices are widespread, particularly in the telecommunications area. One such device is the Texas instruments (TI) TMS32010 processor. The architecture of these devices and the requirements of realtime signal processing frequently force the use of assembly language programming on software developers. Software development for the TMS32010 is at present supported by crossassemblers running on Digital Equipment VAX minicomputers and TI minicomputers and microcomputers operating under MS-DOS, PC-DOS or CP/M. At the minicomputer level the choice of machines is limited, while at the microcomputer level the number of simultaneous users per system is restricted by the cost of networking hardware and software, and by multiuser software licensing. To broaden the choice of host machines and provide a facility for a large number of users to develop TMS32010 software, cross support software has been written to run on the Paisley College computer system which is based on several Prime Series 50 minicomputers providing a time sharing and batch processing service. This software Department of Electrical and Electronic Engineerin~ Paisley College of Technology, High Street, Paisley PAl 2BE, UK
should be of interest to academic and industrial organizations that use the TMS32010 processor family. The software described here was partitioned fairly naturally between crossassembly, format conversion and downloading. Processor simulation was not addressed in this project but it is intended to attempt this ata later date. A top-down, modular, structured design process 1 was adhered to and resulted in reasonably error free, easily debugged software. A prime requirement of the crossassembler, designated XAssem320, was that it should support modular programming for the target microprocessor. The software is written in a subset of BASICwhich, if used carefully, capitalizes on the following advantages. • It is the most commonly available language on the vast array of large and small computers in use today and thus offers a large degree of portability. • It features powerful string handling routines which are required for crossassembly processing. • It is familiar to a large number of engineers and scientists from its previous widespread use as a teaching language.
DESCRIPTION OF X A S S E M 3 2 0 A comprehensive discussion of compiler design is given by Aho and UIIman 2. A straightforward approach was taken for XAssem320 which translates TMS32010 assembly language source programs into TMS32010 hexadecimal machine code, in the process creating two files. The first is the 'output listing' file generated for documentation purposes, containing a formatted version of the source program including the translated hex machine code and program address of each source statement. The second is a 'hex' file that contains only the translated machine code which will ultimately be executed by the target TMS32010 microprocessor. XAssem320 prompts for input and allows
0141-9331/86/08434-08 $03.00 © 1986 Butterworth & Co. (Publishers) Ltd 434
microprocessors and microsystems
macro definition and the linking of previously written source code modules.
Macro facility XAssem320 provides the user with the option of either defining a macro 2 in the source program, in which case the corresponding macro expansion is confined to that particular program, or predefining a macro in the 'macro library' file, in which case the macro can be expanded in any source program. A macro defined in a source program is given precedence over one with the same name existing in the macro library. Up to three parameters may be specified with each macro. Labels are allowed within macro routines. When such a macro is expanded more than once in the same source program, each label and corresponding operand reference is renamed with a unique macro code. This avoids multiple definition of labels which would result in an assembly error. Thus it is possible to write complex macros employing branching within the macro. Macros cannot be nested.
• File managemenL Before any translation process is attempted, XAssem320 performs a number of file management functions on the user file directory (U FD) which contains a list of the names and attributes of the files created by the user. This reduces the possibility of any files in the UFD being corrupted or deleted by the XAssem320 file processing. In doing this it also maintains a file name protocol. The 'source' file is required to have a '.SRC' extension and the two output files, 'output listing' and 'hex', are assigned the same name as the 'source' file but with the respective extensions '.LST' and '.HEX'. • Development option. When the translation process is completed, a yes/no option is provided to allow the user to continue with the development process and run Format320. Format320 converts the contents of the 'hex' file into a format suitable for transmission along the RS232 data link from the host computer to the target TMS32010 system. If the above option is taken, a further yes/no option is available for the user to perform the data transfer by running Download320. Format320 and Download320 can also be entered independently of XAssem320.
Linking facility OPERATION OF X A S S E M 3 2 0 Independently written source programs may be linked into a main source program using XAssem320 directives. If the origin address of each linked program is not defined and all program memory locations are referenced by labels, the linked source programs are completely relocatable. A control program may then be used to arrange the final position of each program in the microprocessor program memory. This allows program modules to be developed and evaluated independently before being merged with other programs.
The crossassembler is not a conventional two-pass assembler since it translates all source code duringthe first pass. Any forward reference labels that are encountered on the first pass will be translated to a numerical value of zero. Once the initial pass is completed and a complete 'label' table has been constructed, a'pseudo' second pass is performed solely to replace each forward reference with the appropriate numerical address from the label table. This allows XAssem320 to process faster than some conventional two-pass assemblers, although no rigorous speed optimization exercise has yet been attempted.
'User friendly' facilities User friendliness and convenience are enhanced by providing • Prompts. The crossassembler prompts the userwhen it requires information. If the user returns an illegal reply to the prompt then this is indicated at the terminal and the user is requested to re-enter the information. • Help facility. Whenever the user is prompted for an input and is uncertain of the required response, an explanatory response may be obtained by returning HELP to the prompt. On completion of the help routine, the user is given the option to either continue from where the help facility was invoked orto quit from XAssem320. • Error detection. Error checks are made during the translation process which detect illegal use of machine instructions, assembler directives and operands. XAssem320 indicates source lines which are in error and the type of error detected on the 'output listing' file. • User-defined symbols. The contents of the symbol table are written to the output listing to show each user-defined symbol with its value in the decimal and hexadecimal number system. This process is repeated for user-defined labels. The distinction between a symbol and a label is clarified below.
vol 70 no 8 october 7986
Source format A source statement for processing by XAssem320 is made up of five fields: ~LINE NO.~, (LABEL~, (MNEMONICS, ~OPERAND(S)~ and (COMMENT~). The line number field, if present is automatically removed before the source statement is translated. The label field holds a symbolic name that represents the numerical address of the machine instruction. The mnemonic field holds the TMS32010 machine instruction. The operand field holds the data to be operated on by the machine instruction; this data may be written in numerical form (decimal, binary, hex or octal) or may be represented by userdefined symbols. The comment field holds a statement (no longer than 20 characters) that is used to document the program, and it is ignored by XAssem320. Only the mnemonic field is mandatory; the rest are optional. The source program format accepted by XAssem320 is as follows: • Statements are written in free format, i.e. there is no restriction on which column the statement fields start in. All fields are delimited by at least one space. • Comments may exist independently of an instruction line if preceded by the '*' character and are limited to 120 characters.
435
• Standard TMS32010 mnemonics and operand formats are accepted. Operands to a maximum of three are delimited by a comma. The first six characters of symbols and labels must be unique. This restriction was imposed to maintain compatibility with Tl's own crossassembler product. Addressing symbols (*, * +, and *-) may be represented by user-defined symbols. A number of assembler-defined symbols may be used. These are ARO and AR1, which represent the two auxiliary registers, and PAO-PA7 which represent the eight I/O port addresses of the TMS32010. • Amongthe directives provided are AORG, DATA, EQU, SET, LINK, END and macro commands. A macro definition command consists of the macro name preceded by '$$'. A macro expansion command consists of the macro name preceded by'$'. Mnemonic symbols are predefined by the XAssem320 program and cannot be altered by the user. Operand symbols and their numerical values are defined by the user. Label names are also defined by the user but the numerical value of the label is determined by XAssem320 during the translation process.
memory may be used to reference an address in program memory. This operation is supported by XAssem320.
Instruction table The TMS32010 instruction set was classified into a number of groups and subgroups to facilitate the crossassembler translation process. A permanent instruction table was constructed to store the mnemonic, op. code and group code of each instruction. Directives are treated in much the same way as machine instructions, and are also stored in the instruction table. The format of an entry in the table is C$$$$CCC where G is the decimal group code, $$$$ is the mnemonic string and CCC is the decimal op. code. The group code is used to indicate the appropriate assembly process. The op. code is the numerical value which is assembled with the operand values to generate the corresponding TMS32010 instruction code. Table 1 gives examples of the TMS32010 instruction types 4which require different assembly processes.
Symbol table Translation process The process of translating a source statement is essentially that of replacing each label, mnemonic and operand by a predefined numerical value and assembling the values into the correct machine code 3. To do this, XAssem320 requires access to a number of look-up tables that store symbolic names and equivalent numerical values. Labels and symbols are local to the particular source program and are stored in the 'symbol', 'label' and 'forward reference' tables, which are temporary tables constructed during the translation process and later deleted. A pseudocode algorithm for the translation process is shown in Appendix 1. Assemblers for most general-purpose microprocessors place symbols and labels in the same table so that both types of symbolic name may be used as operands by any of the microprocessor instructions. However, the TMS32010 employs a modified Haward architecture in which program memory and data memory lie in two separate address spaces with machine instructions provided to operate on either program memory or data memory. It follows that, in the source program, labels are only used by program memory instructions and symbols are only used by data memory instructions. To maintain this restriction in the development process, symbols and labels are stored in separate tables, with access to each table restricted to the appropriate instructions. Although this is true for most instructions, TI has provided a crossover path between program and data memory which is especially useful for reading tables of constant coefficients from nonvolatile program memory into volatile data memory, where they may be used in arithmetic operations. The associated table read (TBLR) and table write (TBLW) instructions require a program memory address to be placed in the accumulator prior to their execution. This is often achieved using the multiply immediate (MPYK) instruction with the immediate operand being the required program memory address, e.g. the start of a data block. Thus a label may exist as a data item in program memory and an item in data
436
This table holds numerical values, which may be specified in binary, decimal, hexadecimal or octal form, and their representative symbols. The EQU directive is used in the source program to define an operand symbol. The symbol and its assigned value are both stored at the next free location in the symbol table specified by the table pointer. Once a symbol is defined by the EQU directive it can be used throughout the source program as an operand to represent either immediate data, an addressing mode ora data memory address. It cannot be used to represent a program memory address as required by program control instructions such as the branch instruction. Thus, to translate the value of a symbol operand, a search is made of the symbol table to obtain its value. If the symbol is not located in the table then the operand is translated to zero and an error flag is set to indicate an 'undefined symbol error' in the output listing. The SET directive allows symbols having an already defined numerical value in the table to be redefined with a new value.
Table 1.
Examplesof TMS32010 instruction words
Source statement
Bit position in instruction word 1514131211
10987654321
O
OP . . . . . . . .
>
< ............
PUSH XOR
D, R
< ....
OP . . . . .
ADD
D,S,R < - - O P - - > < - S - - > M < - - - D
BNZ
A
< ............ < - OP - > < . . . . . . . .
MPYK
D
<-OP-> < .......
LACK
D
< .....
OP . . . . .
> M<---
D --> -->
OP . . . . . . . . A ......
> >
D .......
>
><---
D --->
OP = op. code; A = program address; D = operand data; S = shift value; R = register pointer (concatenated with operand data); M = addressing mode (derived from operand data)
microprocessors and microsystems
Label table
A label name is used in the source program as an operand to represent a program memory address. A symbolic name defined as a label in the source statement is placed into the label table with a numerical address derived from the program location pointer. The location pointer is a counter which is used to monitor the program address of each source instruction. This counter is initialized by the AORG directive at the beginning of the source program using any of the recognized numerical formats. Multiple definitions of labels are detected by XAssem320 and result in the label definition being ignored and an error being indicated in the output listing. Forward reference table
A label name may be used as an operand before it has been defined in the program, e.g. as in a forward branch. When such a forward reference is detected, the operand is initially translated to zero and the operand name is placed into the forward reference table. The assembly process is performed with the zero operand value and the program address, the assembled hex code and the source statement are written into the temporary listing file in the same way as for any other instruction. However, in the case of a forward reference, the line in the temporary listing is also marked with a forward reference flag. This process is carded out for every forward reference operand, irrespective of the number of times the same name has been previously placed into the forward reference table.
Output process By the time the translation process is complete, the following situation exists. • A temporary listing has been generated which shows the translated code and machine address beside each source statement. Each line that contains an untranslated forward reference is marked with a forward reference flag. • The forward reference table holds the name of each forward reference operand in the sequence in which they were detected during the translation process. The table pointer is redirected to the first entry in the table. • The label table holds the label and corresponding program address of every label defined in the source program. During the output each line of the temporary listing is copied directly to the output listing. However, if the line is marked with a forward reference flag, the next entry in the forward reference table (a forward reference operand) is removed and searched for in the label table. If the name is located in the label table then the label value replaces the code which represents the untranslated forward reference operand. The forward reference flag is removed from the line and the line is copied to the output listing. If the name is not located in the label table then no substitution takes place and t h e code remains with the untranslated value of zero. The forward reference flag is left on the line to indicate an '.unresolved forward reference' error and the line is copied to the output listing.
vol 70 no 8 october 1986
Once every line from the temporary listing has been copied to the output listing the translation of the source program is complete. A pseudocode algorithm for the output process is given in Appendix 2.
INTERFACING Data transfer between the Paisley College Prime system and several user terminals is performed via a Micom contention exchange acting as a multichannel, bidirectional I/O buffer. This method is commonly used in a multiuser environment to connect several possible users to a smaller number of system ports. Replacing a user terminal with an intelligent I/O device such as a singleboard micro provides a simple means of communication and data transfer between the Prime and the external device. A method of data transfer has been devised to allow object code data files created on the Prime system to be transferred to the TI evaluation module (EVM) and extended development system (XDS). The method described here has been implemented with no additional hardware and the minimum amount of software. The techniques involved may be applied directly to any system incorporating Prime Series 50 computers, or indeed any system supporting a data terminal port where the terminal driving routines are available. Communication from the Prime system to the user terminals is made via Micom through a three-wire RS232 data link providing asynchronous bidirectional serial data transfer at a rate defined by the system operator (typically 300-2400 baud). Connection of the EVM or XDS systems between the terminal and the Prime allows serial downloading of data from the Prime system. The user maintains control of both the host Prime system and the EVM orXDS from the terminal by switching in and out of a transparency mode s'6. Figure 1 shows the data paths between the Prime, EVM or XDS and the terminal for both modes of operation.
OBJECT FILE FORMATTING AND DOWNLOADING Before transfer from the Prime, the '.HEX' object file generated by the crossassembler must be formatted to be recognizable by the EVM and the XDS. The format chosen
I
Usernal termi
me II Host systPriem Transparency-mode path~ data
,r ............
i
~'~ EMM/XDS m~n~tMiX~~DS Figure 1. Data paths between the Prime, the terminal and the EVM or XDS
437
for this purpose was the TI 'normal ASCII' format 6. This format allows easy manipulation of the object code within ASCII text files on the Prime system, using file handling procedures readily available to the BASIC programmer. In the TI normal ASCII format, each record within a data file is split into smaller data fields. Each field contains ASCII hex characters preceded by atag character which specifies the type of data field about to be downloaded. The type of field is dependent on whether the object code is absolute or relocatable. Since XAssem320 generates absolute code, the object file is formatted using only the five tag characters which are associated with absolute code. A BASICprogram (Format320) checks the existence and validity of the input '.HEX' and output '.OBJ' files before generating the formatted output file.
Program requirements and development Through use of a dummy file 'token' the formatting program may be used as a standalone program or as an extension to the crossassembler program. In the latter, XAssem320 generates the 'token' file containing the file name of the hex file to be processed. In this case no file name is required from the user and a check can be made for the existence of the given file. If the token file does not exist then the hex file has been created without XAssem320 and a file name is requested from the user. This facility allowed development of the format converter and downloader to proceed fairly independently of the crossassembler. Having verified the validity of the input and output files, the process of formatting commences. File name extensions are used to identify the file types, with '.HEX' indicating a source object file and '.OBJ' indicating a target object file. The hexadecimal data is converted to its decimal equivalent through use of a hex-dec routine prior to performing checksum calculations. The checksum is then converted from decimal to a hexadecimal value for transmission to the object file using a dec-hex routine. This routine is also used to convert the decimal count of the number of data words to be downloaded as a hex number following the 'K' tag character. The formatted object file which can now be recognized by the EVM and the XDS systems may now be transferred from the Prime. Data transfer is accomplished by a BASIC program Download320 which uses a terminal output routine (TNOUA) of the Prime operating system 7. This routine will transfer a data word specified as a parameter in the subroutine call to the terminal device, which in this application is the EVM orXDS system. Note that, since the Prime represents all data internally with the most significant bit set, then any ASCII data from the Prime requires the most significant bit to be masked off so that it can be recognized by the receiving device. It was found necessary to introduce a short delay between each character sent to the EVM, to allow the Micom output buffer time to respond to the EVM software handshake characters XON and XOFF. Without this delay the EVM input buffer overflowed due to the extra characters being transmitted from the Prime following the XOFF character from the EVM. The problem did not occur with the XDS, since it sends the XOFF character well in advance of its input buffer becoming full.
438
RESULTS The crossassembler was validated using a suite of test programs containing all legal instructions and directives, and each type of error. In addition the crossassemblerwas tested through practical use by members of a research group developing software for the TMS32010 microprocessor. An example source program called AD~XDS.SRC was used to test an A/D interface connected to the TMS32010 microcomputer. Appendix 3 shows the terminal session
Douglas R Campbell has been with the Department of Electrical and Electronic Engineering at Paisley College of Technology, UK, for six years as a lecturer and senior lecturer. He received a BSc in electrical engineering in 1972 and a PhD in the field of identification techniques applied to distributed parameter systems in 1976 from the University of Strathclyde, UK, and later worked as a principal research engineer for Rediffusion Simulation Ltd, UK, on aspects of aircraft flight simulation. His current research interests include digital signal processing and computer applications.
Chris Canning is a software development engineer in British Telecom's Network Management Division. He has held this post since graduating with a degree in electrical and electronic engineering from Paisley College of Technology, UK, in 1985. He is currently a member of a project team involved in the development of network management products for private voice and data networks. His interests lie in the fields of data communications, realtime programming and micro and minicomputer systems. His previous activities have included work on database design, hardware design for laser detection systems and high volume computer peripheral testing. Kenneth Miller is a software and hardware development engineer with GP Industrial, Plymouth, UK. He graduated with a degree in electrical and electronic engineering from Paisley College of Technology, UK, in 1985. His specialist interests lie in the field of microprocessor applications and software develop............. ment Currently he is involved in projects applying 16-bit technology for use in industrial electronics environments, particular emphasis being placed on development tools for programmable logic devices.
microprocessors and microsystems
during the development process. Appendices 4-6 show the output listing file ADAXDS.LST, the hex file ADAXDS.HEX generated by XAssem320, and the object file ADAXDS.OBJ generated by Format320.
REFERENCES 1 2
CONCLUSION 3 Software to support the development of TMS32010 assembler programs on a Prime computer system has been written using the BASICprogramming language. The software has been tested and proved successful in its operation. Since it was written in a high-level language it is fairly easy to modify to the particular requirements of an organization, e.g. by adding new assembler directives, by adding new instructions to support a change within the processor family to the TMS32020, or by transferring the software to a different host computer family.
A P P E N D I X 1:
4 5 6 7
McGowan, C / and Kelly, J R Top down structured programming techniques Petrocelli, Princetown, N J, USA (1975) Aho, A V and UIIman, l O Principles of compiler design Addison-Wesley, Wokingham, U K (1977) Heath, R and Patel, S R 'How to write a universal cross-assembler' IEEE Micro (August 1981) pp 45-66 TMS32010users guide Texas Instruments, Houston, TX, USA (1983) EVM users guide Texas Instruments, Houston, TX, USA (1983) XDS users guide Texas Instruments, Houston, TX, USA (I 983) PRIME users guide Prime Computers, Natick, MA, USA (I 982)
A L G O R I T H M S FOR T R A N S L A T I O N PROCESS
While (not end of source program) { Read next line If line number exists, remove Isolate fields, delimiter = ' ' (min of 1, max of 4) While (not end of Instruction Table) { Read next entry in table If 1st field matches, no label present, identify fields If 2nd field matches, label present, identify fields
}
If match found, read opcode and group code from Instruction Table Else set error flag: 'illegal instruction' Isolate operand fields, delimiter = ',' (max of 3) Do for each operand { If operand is numeric, convert to decimal value If operand is an addressing symbol, translate to decimal value If operand is a symbol { If group code indicates a data memory instruction { Search Symbol Table if symbol found, remove decimal value Else value is zero, set error flag: 'undefined symbol'
}
If group code indicates a program memory instruction { Search Label Table If symbol found, remove decimal value Else } Translate value to zero Write symbol in Forward Reference Table Set forward reference flag
} }
}
}
If group code indicates a Directive { Select internal process indicated from opcode Perform process
}
If group code indicates a Machine Instruction { If label field present { Search Label Table for label name If label already exists in Table { Set error flag: 'duplicate label' Ignore label definition
vol 10 no 8 october 1986
439
} } }
Else write label in Table with value of location pointer
Select assembly process from group code Assemble Instruction Code from opcode and operand data
Convert code and program address (location pointer) to hex Write line to temporary listing file Adjust location pointer Clear error and forward refererence flags
APPENDIX 2:
ALGORITHM FOR OUTPUT PROCESS
While (not end of temporary listing) { Read next line If forward reference flag present { Read next name in Forward Reference Table Search Label Table for name If found { Remove decimal value from Label Table Convert to hex Substitute onto listing line Remove forward reference flag
} }
Write line to Output Listing
Copy contents of Symbol Table to Output Listing Copy contents of Label Table to Output Listing Write number of errors to Output Listing
APPENDIX 3:
DEVELOPMENT SESSION (USER RESPONSES ARE SHOWN IN ITALICS)
OK, BASICV XASSEM320 .......................... enter source file warning: ok to replace warning: ok to replace renamed:
TMS32010 CROSS-ASSEMBLER . . . . . . . . . . . . . . . . . . . . . . . . . . !ADAXDS.SRC
ADAXDS.LST
exists
ADAXDS.OBJ
exists
ADAXDS.SRC
listing file: ok to list ok to format object file: ok to download OK,
ADAXDS.LST ADAXDS.OBJ
440
Y/N
!N
Y/N Y/N
!N
Y/N
!N
created !Y
created
ADAXDS.LST
Assembled on 30-05-86 at 10:01 I 2 3
!Y
ADAXDS.OBJ.BAK
assembling: 54 lines 0 errors
APPENDIX 4:
Y/N
* * * tms320 evm text editor * * ** adc/dac test routine ** ..................
O0A INPUT OUTPUT ONE MINUS CLEAR
AORG EQU EQU EQU EQU EQU
10 0 34 127 126 125
microprocessors and microsystems
10 11 12 13 14 15 16 17 18 19 2O 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
00A 00B 00C 00D 00E 00F 010 011 012 013 014 015 016 017 018 019 01A 01 B 01C 01D 01E 01F 020 021 022 023 024 025 026 027 028
MAX EQU OFFSET EQU LACK SACL ZAC SACL SUB SACL LACK SACL LACK ADD SACL ADD SACL IN OUT READ IN NOP IN WAIT BIOZ
7E01 507F 7F89 507C I07F 507E 7E7F 507D 7EFF 087D 507D 007F 507B 4000 4B7D 4100 7F80 4100 F600 001C 4200 2000 FA00 0025 7A7B F900 0026 797D POS 5000 CONT 5022 2022
A P P E N D I X 5:
124 123 1 ONE MAX ONE MINUS > 7F CLEAR > FF CLEAR,8 CLEAR ONE OFFSET 0, 0 CLEAR, 3 O, 1
43 44 45 46 47 48 49 50 51 52 53 54
029 02.A 02B 02C 02D 02E 02F 030 031 032 033
787E FD00 002F 7A7B F900 0030 797D PLUS 5022 DAC 4B22 F900 0019
INPUT, 2 INPUT POS
OR B
OFFSET CONT
AND SACL SACL LAC
CLEAR INPUT OUTPUT OUTPUT
MINUS PLUS
OR B
OFFSET DAC
AND SACL OUT B
CLEAR OUTPUT OUTPUT, 3 READ
END
Symbol Table
0, 1 WAIT
IN LAC BLZ
XOR BGEZ
INPUT OUTPUT ONE MINUS CLEAR MAX OFFSET
= = = = = = = =
> > > > > > > >
0000 0000 0022 007F 007E 007D 007C 007B
0 0 34 127 126 125 124 123
origin READ WAIT POS CONT PLUS DAC
= = = = = = =
> > > > > > >
00A 019 01C 025 026 02F 030
10 25 28 37 38 47 48
Label Table
0 Errors
ADAXDS,HEX
. = , 000A, 7E01, 507F, 7F89, 507C, 107F, 507E, 7E7F, 507D, 7EFF, 087D, 507D, 007F, 507B, 4000, 4B7D, 4100, 7F80, 4100, F600, 001 C, 4200, 2000, FA00, 0025, 7A7B, F900, 0026, 797D, 5000, 5022, 2022, 787E, FD00, 002F, 7A7B, F900, 0030, 797D, 5022, 4B22, F900, 0019,
A P P E N D I X 6:
ADAXDS.OBJ
K002ATADAXDS 9000AB7E01 BS07FB7F89BSO7CB107FB507EB7E7FB507D7F244F B7EFFB087DB507DB007FB507BB400084B7DB4100B7F80B4100BF600B001C7F257F B4200B2000BFA00B0025 B7A7BBF900B0026B797DBS000B5022B2022B787E7F2BgF BFD00B002 FB7A7BBF900B0030B797DBS022B4B22BF900B00197F4AgF 30-05-86 10:02 PRIME TI LOADER
vol 10 no 8 october 1986
441
Software to support the development of TMS32010 assembler programs on a Prime computer system has been written using BASIC. The software consists of three main modules: a crossassembler, a format converter and a downloader. The software, which allows macro definition and the linking of previously written source code modules, has been tested and is now being used successfully. digital signal processors
crossassemblers
TMS32010
Microprocessors specifically designed to perform common digital signal processing (DSP) operations efficiently are now available from several manufacturers. Applications of these devices are widespread, particularly in the telecommunications area. One such device is the Texas instruments (TI) TMS32010 processor. The architecture of these devices and the requirements of realtime signal processing frequently force the use of assembly language programming on software developers. Software development for the TMS32010 is at present supported by crossassemblers running on Digital Equipment VAX minicomputers and TI minicomputers and microcomputers operating under MS-DOS, PC-DOS or CP/M. At the minicomputer level the choice of machines is limited, while at the microcomputer level the number of simultaneous users per system is restricted by the cost of networking hardware and software, and by multiuser software licensing. To broaden the choice of host machines and provide a facility for a large number of users to develop TMS32010 software, cross support software has been written to run on the Paisley College computer system which is based on several Prime Series 50 minicomputers providing a time sharing and batch processing service. This software Department of Electrical and Electronic Engineerin~ Paisley College of Technology, High Street, Paisley PAl 2BE, UK
should be of interest to academic and industrial organizations that use the TMS32010 processor family. The software described here was partitioned fairly naturally between crossassembly, format conversion and downloading. Processor simulation was not addressed in this project but it is intended to attempt this ata later date. A top-down, modular, structured design process 1 was adhered to and resulted in reasonably error free, easily debugged software. A prime requirement of the crossassembler, designated XAssem320, was that it should support modular programming for the target microprocessor. The software is written in a subset of BASICwhich, if used carefully, capitalizes on the following advantages. • It is the most commonly available language on the vast array of large and small computers in use today and thus offers a large degree of portability. • It features powerful string handling routines which are required for crossassembly processing. • It is familiar to a large number of engineers and scientists from its previous widespread use as a teaching language.
DESCRIPTION OF X A S S E M 3 2 0 A comprehensive discussion of compiler design is given by Aho and UIIman 2. A straightforward approach was taken for XAssem320 which translates TMS32010 assembly language source programs into TMS32010 hexadecimal machine code, in the process creating two files. The first is the 'output listing' file generated for documentation purposes, containing a formatted version of the source program including the translated hex machine code and program address of each source statement. The second is a 'hex' file that contains only the translated machine code which will ultimately be executed by the target TMS32010 microprocessor. XAssem320 prompts for input and allows
0141-9331/86/08434-08 $03.00 © 1986 Butterworth & Co. (Publishers) Ltd 434
microprocessors and microsystems
macro definition and the linking of previously written source code modules.
Macro facility XAssem320 provides the user with the option of either defining a macro 2 in the source program, in which case the corresponding macro expansion is confined to that particular program, or predefining a macro in the 'macro library' file, in which case the macro can be expanded in any source program. A macro defined in a source program is given precedence over one with the same name existing in the macro library. Up to three parameters may be specified with each macro. Labels are allowed within macro routines. When such a macro is expanded more than once in the same source program, each label and corresponding operand reference is renamed with a unique macro code. This avoids multiple definition of labels which would result in an assembly error. Thus it is possible to write complex macros employing branching within the macro. Macros cannot be nested.
• File managemenL Before any translation process is attempted, XAssem320 performs a number of file management functions on the user file directory (U FD) which contains a list of the names and attributes of the files created by the user. This reduces the possibility of any files in the UFD being corrupted or deleted by the XAssem320 file processing. In doing this it also maintains a file name protocol. The 'source' file is required to have a '.SRC' extension and the two output files, 'output listing' and 'hex', are assigned the same name as the 'source' file but with the respective extensions '.LST' and '.HEX'. • Development option. When the translation process is completed, a yes/no option is provided to allow the user to continue with the development process and run Format320. Format320 converts the contents of the 'hex' file into a format suitable for transmission along the RS232 data link from the host computer to the target TMS32010 system. If the above option is taken, a further yes/no option is available for the user to perform the data transfer by running Download320. Format320 and Download320 can also be entered independently of XAssem320.
Linking facility OPERATION OF X A S S E M 3 2 0 Independently written source programs may be linked into a main source program using XAssem320 directives. If the origin address of each linked program is not defined and all program memory locations are referenced by labels, the linked source programs are completely relocatable. A control program may then be used to arrange the final position of each program in the microprocessor program memory. This allows program modules to be developed and evaluated independently before being merged with other programs.
The crossassembler is not a conventional two-pass assembler since it translates all source code duringthe first pass. Any forward reference labels that are encountered on the first pass will be translated to a numerical value of zero. Once the initial pass is completed and a complete 'label' table has been constructed, a'pseudo' second pass is performed solely to replace each forward reference with the appropriate numerical address from the label table. This allows XAssem320 to process faster than some conventional two-pass assemblers, although no rigorous speed optimization exercise has yet been attempted.
'User friendly' facilities User friendliness and convenience are enhanced by providing • Prompts. The crossassembler prompts the userwhen it requires information. If the user returns an illegal reply to the prompt then this is indicated at the terminal and the user is requested to re-enter the information. • Help facility. Whenever the user is prompted for an input and is uncertain of the required response, an explanatory response may be obtained by returning HELP to the prompt. On completion of the help routine, the user is given the option to either continue from where the help facility was invoked orto quit from XAssem320. • Error detection. Error checks are made during the translation process which detect illegal use of machine instructions, assembler directives and operands. XAssem320 indicates source lines which are in error and the type of error detected on the 'output listing' file. • User-defined symbols. The contents of the symbol table are written to the output listing to show each user-defined symbol with its value in the decimal and hexadecimal number system. This process is repeated for user-defined labels. The distinction between a symbol and a label is clarified below.
vol 70 no 8 october 7986
Source format A source statement for processing by XAssem320 is made up of five fields: ~LINE NO.~, (LABEL~, (MNEMONICS, ~OPERAND(S)~ and (COMMENT~). The line number field, if present is automatically removed before the source statement is translated. The label field holds a symbolic name that represents the numerical address of the machine instruction. The mnemonic field holds the TMS32010 machine instruction. The operand field holds the data to be operated on by the machine instruction; this data may be written in numerical form (decimal, binary, hex or octal) or may be represented by userdefined symbols. The comment field holds a statement (no longer than 20 characters) that is used to document the program, and it is ignored by XAssem320. Only the mnemonic field is mandatory; the rest are optional. The source program format accepted by XAssem320 is as follows: • Statements are written in free format, i.e. there is no restriction on which column the statement fields start in. All fields are delimited by at least one space. • Comments may exist independently of an instruction line if preceded by the '*' character and are limited to 120 characters.
435
• Standard TMS32010 mnemonics and operand formats are accepted. Operands to a maximum of three are delimited by a comma. The first six characters of symbols and labels must be unique. This restriction was imposed to maintain compatibility with Tl's own crossassembler product. Addressing symbols (*, * +, and *-) may be represented by user-defined symbols. A number of assembler-defined symbols may be used. These are ARO and AR1, which represent the two auxiliary registers, and PAO-PA7 which represent the eight I/O port addresses of the TMS32010. • Amongthe directives provided are AORG, DATA, EQU, SET, LINK, END and macro commands. A macro definition command consists of the macro name preceded by '$$'. A macro expansion command consists of the macro name preceded by'$'. Mnemonic symbols are predefined by the XAssem320 program and cannot be altered by the user. Operand symbols and their numerical values are defined by the user. Label names are also defined by the user but the numerical value of the label is determined by XAssem320 during the translation process.
memory may be used to reference an address in program memory. This operation is supported by XAssem320.
Instruction table The TMS32010 instruction set was classified into a number of groups and subgroups to facilitate the crossassembler translation process. A permanent instruction table was constructed to store the mnemonic, op. code and group code of each instruction. Directives are treated in much the same way as machine instructions, and are also stored in the instruction table. The format of an entry in the table is C$$$$CCC where G is the decimal group code, $$$$ is the mnemonic string and CCC is the decimal op. code. The group code is used to indicate the appropriate assembly process. The op. code is the numerical value which is assembled with the operand values to generate the corresponding TMS32010 instruction code. Table 1 gives examples of the TMS32010 instruction types 4which require different assembly processes.
Symbol table Translation process The process of translating a source statement is essentially that of replacing each label, mnemonic and operand by a predefined numerical value and assembling the values into the correct machine code 3. To do this, XAssem320 requires access to a number of look-up tables that store symbolic names and equivalent numerical values. Labels and symbols are local to the particular source program and are stored in the 'symbol', 'label' and 'forward reference' tables, which are temporary tables constructed during the translation process and later deleted. A pseudocode algorithm for the translation process is shown in Appendix 1. Assemblers for most general-purpose microprocessors place symbols and labels in the same table so that both types of symbolic name may be used as operands by any of the microprocessor instructions. However, the TMS32010 employs a modified Haward architecture in which program memory and data memory lie in two separate address spaces with machine instructions provided to operate on either program memory or data memory. It follows that, in the source program, labels are only used by program memory instructions and symbols are only used by data memory instructions. To maintain this restriction in the development process, symbols and labels are stored in separate tables, with access to each table restricted to the appropriate instructions. Although this is true for most instructions, TI has provided a crossover path between program and data memory which is especially useful for reading tables of constant coefficients from nonvolatile program memory into volatile data memory, where they may be used in arithmetic operations. The associated table read (TBLR) and table write (TBLW) instructions require a program memory address to be placed in the accumulator prior to their execution. This is often achieved using the multiply immediate (MPYK) instruction with the immediate operand being the required program memory address, e.g. the start of a data block. Thus a label may exist as a data item in program memory and an item in data
436
This table holds numerical values, which may be specified in binary, decimal, hexadecimal or octal form, and their representative symbols. The EQU directive is used in the source program to define an operand symbol. The symbol and its assigned value are both stored at the next free location in the symbol table specified by the table pointer. Once a symbol is defined by the EQU directive it can be used throughout the source program as an operand to represent either immediate data, an addressing mode ora data memory address. It cannot be used to represent a program memory address as required by program control instructions such as the branch instruction. Thus, to translate the value of a symbol operand, a search is made of the symbol table to obtain its value. If the symbol is not located in the table then the operand is translated to zero and an error flag is set to indicate an 'undefined symbol error' in the output listing. The SET directive allows symbols having an already defined numerical value in the table to be redefined with a new value.
Table 1.
Examplesof TMS32010 instruction words
Source statement
Bit position in instruction word 1514131211
10987654321
O
OP . . . . . . . .
>
< ............
PUSH XOR
D, R
< ....
OP . . . . .
ADD
D,S,R < - - O P - - > < - S - - > M < - - - D
BNZ
A
< ............ < - OP - > < . . . . . . . .
MPYK
D
<-OP-> < .......
LACK
D
< .....
OP . . . . .
> M<---
D --> -->
OP . . . . . . . . A ......
> >
D .......
>
><---
D --->
OP = op. code; A = program address; D = operand data; S = shift value; R = register pointer (concatenated with operand data); M = addressing mode (derived from operand data)
microprocessors and microsystems
Label table
A label name is used in the source program as an operand to represent a program memory address. A symbolic name defined as a label in the source statement is placed into the label table with a numerical address derived from the program location pointer. The location pointer is a counter which is used to monitor the program address of each source instruction. This counter is initialized by the AORG directive at the beginning of the source program using any of the recognized numerical formats. Multiple definitions of labels are detected by XAssem320 and result in the label definition being ignored and an error being indicated in the output listing. Forward reference table
A label name may be used as an operand before it has been defined in the program, e.g. as in a forward branch. When such a forward reference is detected, the operand is initially translated to zero and the operand name is placed into the forward reference table. The assembly process is performed with the zero operand value and the program address, the assembled hex code and the source statement are written into the temporary listing file in the same way as for any other instruction. However, in the case of a forward reference, the line in the temporary listing is also marked with a forward reference flag. This process is carded out for every forward reference operand, irrespective of the number of times the same name has been previously placed into the forward reference table.
Output process By the time the translation process is complete, the following situation exists. • A temporary listing has been generated which shows the translated code and machine address beside each source statement. Each line that contains an untranslated forward reference is marked with a forward reference flag. • The forward reference table holds the name of each forward reference operand in the sequence in which they were detected during the translation process. The table pointer is redirected to the first entry in the table. • The label table holds the label and corresponding program address of every label defined in the source program. During the output each line of the temporary listing is copied directly to the output listing. However, if the line is marked with a forward reference flag, the next entry in the forward reference table (a forward reference operand) is removed and searched for in the label table. If the name is located in the label table then the label value replaces the code which represents the untranslated forward reference operand. The forward reference flag is removed from the line and the line is copied to the output listing. If the name is not located in the label table then no substitution takes place and t h e code remains with the untranslated value of zero. The forward reference flag is left on the line to indicate an '.unresolved forward reference' error and the line is copied to the output listing.
vol 70 no 8 october 1986
Once every line from the temporary listing has been copied to the output listing the translation of the source program is complete. A pseudocode algorithm for the output process is given in Appendix 2.
INTERFACING Data transfer between the Paisley College Prime system and several user terminals is performed via a Micom contention exchange acting as a multichannel, bidirectional I/O buffer. This method is commonly used in a multiuser environment to connect several possible users to a smaller number of system ports. Replacing a user terminal with an intelligent I/O device such as a singleboard micro provides a simple means of communication and data transfer between the Prime and the external device. A method of data transfer has been devised to allow object code data files created on the Prime system to be transferred to the TI evaluation module (EVM) and extended development system (XDS). The method described here has been implemented with no additional hardware and the minimum amount of software. The techniques involved may be applied directly to any system incorporating Prime Series 50 computers, or indeed any system supporting a data terminal port where the terminal driving routines are available. Communication from the Prime system to the user terminals is made via Micom through a three-wire RS232 data link providing asynchronous bidirectional serial data transfer at a rate defined by the system operator (typically 300-2400 baud). Connection of the EVM or XDS systems between the terminal and the Prime allows serial downloading of data from the Prime system. The user maintains control of both the host Prime system and the EVM orXDS from the terminal by switching in and out of a transparency mode s'6. Figure 1 shows the data paths between the Prime, EVM or XDS and the terminal for both modes of operation.
OBJECT FILE FORMATTING AND DOWNLOADING Before transfer from the Prime, the '.HEX' object file generated by the crossassembler must be formatted to be recognizable by the EVM and the XDS. The format chosen
I
Usernal termi
me II Host systPriem Transparency-mode path~ data
,r ............
i
~'~ EMM/XDS m~n~tMiX~~DS Figure 1. Data paths between the Prime, the terminal and the EVM or XDS
437
for this purpose was the TI 'normal ASCII' format 6. This format allows easy manipulation of the object code within ASCII text files on the Prime system, using file handling procedures readily available to the BASIC programmer. In the TI normal ASCII format, each record within a data file is split into smaller data fields. Each field contains ASCII hex characters preceded by atag character which specifies the type of data field about to be downloaded. The type of field is dependent on whether the object code is absolute or relocatable. Since XAssem320 generates absolute code, the object file is formatted using only the five tag characters which are associated with absolute code. A BASICprogram (Format320) checks the existence and validity of the input '.HEX' and output '.OBJ' files before generating the formatted output file.
Program requirements and development Through use of a dummy file 'token' the formatting program may be used as a standalone program or as an extension to the crossassembler program. In the latter, XAssem320 generates the 'token' file containing the file name of the hex file to be processed. In this case no file name is required from the user and a check can be made for the existence of the given file. If the token file does not exist then the hex file has been created without XAssem320 and a file name is requested from the user. This facility allowed development of the format converter and downloader to proceed fairly independently of the crossassembler. Having verified the validity of the input and output files, the process of formatting commences. File name extensions are used to identify the file types, with '.HEX' indicating a source object file and '.OBJ' indicating a target object file. The hexadecimal data is converted to its decimal equivalent through use of a hex-dec routine prior to performing checksum calculations. The checksum is then converted from decimal to a hexadecimal value for transmission to the object file using a dec-hex routine. This routine is also used to convert the decimal count of the number of data words to be downloaded as a hex number following the 'K' tag character. The formatted object file which can now be recognized by the EVM and the XDS systems may now be transferred from the Prime. Data transfer is accomplished by a BASIC program Download320 which uses a terminal output routine (TNOUA) of the Prime operating system 7. This routine will transfer a data word specified as a parameter in the subroutine call to the terminal device, which in this application is the EVM orXDS system. Note that, since the Prime represents all data internally with the most significant bit set, then any ASCII data from the Prime requires the most significant bit to be masked off so that it can be recognized by the receiving device. It was found necessary to introduce a short delay between each character sent to the EVM, to allow the Micom output buffer time to respond to the EVM software handshake characters XON and XOFF. Without this delay the EVM input buffer overflowed due to the extra characters being transmitted from the Prime following the XOFF character from the EVM. The problem did not occur with the XDS, since it sends the XOFF character well in advance of its input buffer becoming full.
438
RESULTS The crossassembler was validated using a suite of test programs containing all legal instructions and directives, and each type of error. In addition the crossassemblerwas tested through practical use by members of a research group developing software for the TMS32010 microprocessor. An example source program called AD~XDS.SRC was used to test an A/D interface connected to the TMS32010 microcomputer. Appendix 3 shows the terminal session
Douglas R Campbell has been with the Department of Electrical and Electronic Engineering at Paisley College of Technology, UK, for six years as a lecturer and senior lecturer. He received a BSc in electrical engineering in 1972 and a PhD in the field of identification techniques applied to distributed parameter systems in 1976 from the University of Strathclyde, UK, and later worked as a principal research engineer for Rediffusion Simulation Ltd, UK, on aspects of aircraft flight simulation. His current research interests include digital signal processing and computer applications.
Chris Canning is a software development engineer in British Telecom's Network Management Division. He has held this post since graduating with a degree in electrical and electronic engineering from Paisley College of Technology, UK, in 1985. He is currently a member of a project team involved in the development of network management products for private voice and data networks. His interests lie in the fields of data communications, realtime programming and micro and minicomputer systems. His previous activities have included work on database design, hardware design for laser detection systems and high volume computer peripheral testing. Kenneth Miller is a software and hardware development engineer with GP Industrial, Plymouth, UK. He graduated with a degree in electrical and electronic engineering from Paisley College of Technology, UK, in 1985. His specialist interests lie in the field of microprocessor applications and software develop............. ment Currently he is involved in projects applying 16-bit technology for use in industrial electronics environments, particular emphasis being placed on development tools for programmable logic devices.
microprocessors and microsystems
during the development process. Appendices 4-6 show the output listing file ADAXDS.LST, the hex file ADAXDS.HEX generated by XAssem320, and the object file ADAXDS.OBJ generated by Format320.
REFERENCES 1 2
CONCLUSION 3 Software to support the development of TMS32010 assembler programs on a Prime computer system has been written using the BASICprogramming language. The software has been tested and proved successful in its operation. Since it was written in a high-level language it is fairly easy to modify to the particular requirements of an organization, e.g. by adding new assembler directives, by adding new instructions to support a change within the processor family to the TMS32020, or by transferring the software to a different host computer family.
A P P E N D I X 1:
4 5 6 7
McGowan, C / and Kelly, J R Top down structured programming techniques Petrocelli, Princetown, N J, USA (1975) Aho, A V and UIIman, l O Principles of compiler design Addison-Wesley, Wokingham, U K (1977) Heath, R and Patel, S R 'How to write a universal cross-assembler' IEEE Micro (August 1981) pp 45-66 TMS32010users guide Texas Instruments, Houston, TX, USA (1983) EVM users guide Texas Instruments, Houston, TX, USA (1983) XDS users guide Texas Instruments, Houston, TX, USA (I 983) PRIME users guide Prime Computers, Natick, MA, USA (I 982)
A L G O R I T H M S FOR T R A N S L A T I O N PROCESS
While (not end of source program) { Read next line If line number exists, remove Isolate fields, delimiter = ' ' (min of 1, max of 4) While (not end of Instruction Table) { Read next entry in table If 1st field matches, no label present, identify fields If 2nd field matches, label present, identify fields
}
If match found, read opcode and group code from Instruction Table Else set error flag: 'illegal instruction' Isolate operand fields, delimiter = ',' (max of 3) Do for each operand { If operand is numeric, convert to decimal value If operand is an addressing symbol, translate to decimal value If operand is a symbol { If group code indicates a data memory instruction { Search Symbol Table if symbol found, remove decimal value Else value is zero, set error flag: 'undefined symbol'
}
If group code indicates a program memory instruction { Search Label Table If symbol found, remove decimal value Else } Translate value to zero Write symbol in Forward Reference Table Set forward reference flag
} }
}
}
If group code indicates a Directive { Select internal process indicated from opcode Perform process
}
If group code indicates a Machine Instruction { If label field present { Search Label Table for label name If label already exists in Table { Set error flag: 'duplicate label' Ignore label definition
vol 10 no 8 october 1986
439
} } }
Else write label in Table with value of location pointer
Select assembly process from group code Assemble Instruction Code from opcode and operand data
Convert code and program address (location pointer) to hex Write line to temporary listing file Adjust location pointer Clear error and forward refererence flags
APPENDIX 2:
ALGORITHM FOR OUTPUT PROCESS
While (not end of temporary listing) { Read next line If forward reference flag present { Read next name in Forward Reference Table Search Label Table for name If found { Remove decimal value from Label Table Convert to hex Substitute onto listing line Remove forward reference flag
} }
Write line to Output Listing
Copy contents of Symbol Table to Output Listing Copy contents of Label Table to Output Listing Write number of errors to Output Listing
APPENDIX 3:
DEVELOPMENT SESSION (USER RESPONSES ARE SHOWN IN ITALICS)
OK, BASICV XASSEM320 .......................... enter source file warning: ok to replace warning: ok to replace renamed:
TMS32010 CROSS-ASSEMBLER . . . . . . . . . . . . . . . . . . . . . . . . . . !ADAXDS.SRC
ADAXDS.LST
exists
ADAXDS.OBJ
exists
ADAXDS.SRC
listing file: ok to list ok to format object file: ok to download OK,
ADAXDS.LST ADAXDS.OBJ
440
Y/N
!N
Y/N Y/N
!N
Y/N
!N
created !Y
created
ADAXDS.LST
Assembled on 30-05-86 at 10:01 I 2 3
!Y
ADAXDS.OBJ.BAK
assembling: 54 lines 0 errors
APPENDIX 4:
Y/N
* * * tms320 evm text editor * * ** adc/dac test routine ** ..................
O0A INPUT OUTPUT ONE MINUS CLEAR
AORG EQU EQU EQU EQU EQU
10 0 34 127 126 125
microprocessors and microsystems
10 11 12 13 14 15 16 17 18 19 2O 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
00A 00B 00C 00D 00E 00F 010 011 012 013 014 015 016 017 018 019 01A 01 B 01C 01D 01E 01F 020 021 022 023 024 025 026 027 028
MAX EQU OFFSET EQU LACK SACL ZAC SACL SUB SACL LACK SACL LACK ADD SACL ADD SACL IN OUT READ IN NOP IN WAIT BIOZ
7E01 507F 7F89 507C I07F 507E 7E7F 507D 7EFF 087D 507D 007F 507B 4000 4B7D 4100 7F80 4100 F600 001C 4200 2000 FA00 0025 7A7B F900 0026 797D POS 5000 CONT 5022 2022
A P P E N D I X 5:
124 123 1 ONE MAX ONE MINUS > 7F CLEAR > FF CLEAR,8 CLEAR ONE OFFSET 0, 0 CLEAR, 3 O, 1
43 44 45 46 47 48 49 50 51 52 53 54
029 02.A 02B 02C 02D 02E 02F 030 031 032 033
787E FD00 002F 7A7B F900 0030 797D PLUS 5022 DAC 4B22 F900 0019
INPUT, 2 INPUT POS
OR B
OFFSET CONT
AND SACL SACL LAC
CLEAR INPUT OUTPUT OUTPUT
MINUS PLUS
OR B
OFFSET DAC
AND SACL OUT B
CLEAR OUTPUT OUTPUT, 3 READ
END
Symbol Table
0, 1 WAIT
IN LAC BLZ
XOR BGEZ
INPUT OUTPUT ONE MINUS CLEAR MAX OFFSET
= = = = = = = =
> > > > > > > >
0000 0000 0022 007F 007E 007D 007C 007B
0 0 34 127 126 125 124 123
origin READ WAIT POS CONT PLUS DAC
= = = = = = =
> > > > > > >
00A 019 01C 025 026 02F 030
10 25 28 37 38 47 48
Label Table
0 Errors
ADAXDS,HEX
. = , 000A, 7E01, 507F, 7F89, 507C, 107F, 507E, 7E7F, 507D, 7EFF, 087D, 507D, 007F, 507B, 4000, 4B7D, 4100, 7F80, 4100, F600, 001 C, 4200, 2000, FA00, 0025, 7A7B, F900, 0026, 797D, 5000, 5022, 2022, 787E, FD00, 002F, 7A7B, F900, 0030, 797D, 5022, 4B22, F900, 0019,
A P P E N D I X 6:
ADAXDS.OBJ
K002ATADAXDS 9000AB7E01 BS07FB7F89BSO7CB107FB507EB7E7FB507D7F244F B7EFFB087DB507DB007FB507BB400084B7DB4100B7F80B4100BF600B001C7F257F B4200B2000BFA00B0025 B7A7BBF900B0026B797DBS000B5022B2022B787E7F2BgF BFD00B002 FB7A7BBF900B0030B797DBS022B4B22BF900B00197F4AgF 30-05-86 10:02 PRIME TI LOADER
vol 10 no 8 october 1986
441