 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| july 1998 1/134 rev. 1.2 ST7ASMLK assembler, linker, formatter, and librarian for the st7 family preface purpose of the manual this manual describes how to use the st7 software tools, allowing you to develop applica- tions for the st7 family of microcontrollers: these tools are part of a generic tool-chain development system that includes: ? a meta-assembler: asm ? a generic linker: ly n ? a generic formatter: obsend ? a generic librarian: lib audience this book is intended for persons who need to know how to write, assemble and run programs designed for st7 microcontrollers. no preliminary knowledge in the field of microcontrollers is required, however. related publications the reading of the following publications will be profitable: ? st7-family data sheets , ? st7-family starter kit, getting started , ref. doc-st7mdtx-kit ? st7-family development kit, getting started , ref. doc-st7mdtx-dvp ? st7-family programming manual , ? windows debugger for the st7 family , ref. doc-st7-wgdb7. this manual will help you debug and finalize your programs. 15
2/134 table of contents 134 16 st7 software tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 tool-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 asm (assembler) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 lyn (linker) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 obsend (formatter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 st7 addressing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 inherent addressing mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 immediate operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 short and long addressing modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 x and y indexed modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 relative mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 memory indirect addressing modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8 high, low addressing modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 source code format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1 source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2 assembly source code format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3 labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.4 opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.5 operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.6 comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.7 a source code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.2 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.3 copying code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4 macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.1 defining macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4.2 parameter substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5 conditional assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5.1 if/#else#endif directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6 running the assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.1 command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.2 options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5 linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1 what the linker does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2 invoking the linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.1 command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.2 response files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 5.3 linking in detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3/134 table of contents 5.3.1 publics and externs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2 segments in the linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.3 symbol files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 the linker in more detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.4.1 the composition of the .obj files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.4.2 the composition of the .cod files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.4.3 reading a mapfile listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6 obsend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1 what obsend does for you . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2 invoking obsend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1 destination type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.2 destination arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.3 format definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3.1 straight binary format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.2 intel hex format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.3 motorola s-record format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3.4 st 2 and st 4 s-record format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.3.5 gp binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7 librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.2 invoking the librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.3 adding modules to a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.4 deleting modules from a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.5 copying modules from a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 7.6 getting details in your library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 a assembler directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 b error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 b.1 format of error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 b.2 file cbe.err . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 b.3 assembler errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 b.4 linker errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 26 17 4/134 ST7ASMLK organization of the manual this manual is made up of seven chapters, and two appendixes: chapter 2 installation, describes how to install the software package on vari- ous computers. chapter 3 , st7 address- ing model , discusses the ad- dressing structure of the st7 proces- sor family. chapter 4 , assembler , explains how to use the assem- bler. appendix a provides informa- tion on assembler directives . chapter 7 , librarian , explains the role of the librarian. chapter 6 , obsend , explains the role of the formatter in the program prepara- tion process. chapter 1 introduction, introduces you to the components of the st7 software tools. chapter 5 , linker , describes the link- ing process. appendix b provides informa- tion on assembler and linker error messages . 18 5/134 ST7ASMLK 1 introduction 1.1 tool-chain the tool-chain development system includes: ? a meta-assembler: asm ? a generic linker: ly n ? a generic formatter: obsend ? a generic librarian: lib 1.2 asm (assembler) the role of the assembler is to translate the code you have written (the source code) into a code specific to the target machine, the so-called object code. the assembler takes as input file an assembly file " .asm " and produces as output an object file " .obj ". if desired, a listing file " .lst " can be obtained. the meta-assembler can be targeted to various processors, using machine description files. the machine description file name for the st7 processor family is st7.tab . 1.3 lyn (linker) the linker takes as input one or several object files " .obj " files produced by the assembler, and produces as output an object code file " .cod ". lyn resolves all cross-references be- tween object files, and locates all the modules in memory. 1.4 obsend (formatter) once your application is linked, you must output it in a suitable format. the formatter takes as input the object code file " .cod " produced by the linker. the default suffix for the output file is " .fin ", but it is possible to specify other suffixes, for example: obsend 6/134 ST7ASMLK 2 installation to install the st7 software tools, run the setup.exe file from the cd-rom included in the delivery package, and follow the instructions displayed on screen. when the installation is completed, the installation directory (typically c:\st7tools\asm ) contains the following files: look at file readme.txt for up-to-date release notes. other files contain examples. note: with windows 3.1x or windows 95, the installation process updates the autoexec.bat file so as to provide suitable path specifications to access the assembler tool-chain. to take into account the the new autoexec.bat file contents, reboot your computer. you may also di- rectly access the assembler tool-chain from any ms-dos window by running c:\st7tools\asm\st7vars.bat . table 1: asm.exe assembler lyn.exe linker obsend.exe formatter lib.exe librarian st7.tab st7 description file asli.bat batch file asm+lyn+obsend readme.txt release notes 20 7/134 ST7ASMLK 3 st7 addressing model 3.1 overview the st7 provides a single source-coding model regardless of which components are oper- ands, the accumulator (a), an index register (x or y), the stack pointer (s), the condition code register (cc), or a memory location. for example, a single instruction, ld , originates register to register transfers as well as memory to accumulator data movements. two-operand instructions are coded with destination operand appearing at first position. examples : 3.2 inherent addressing mode this concept is hardware-oriented: it means that instruction operand(s) is (are) coded inside the operation code; at source coding level, operand(s) is (are) explicitly written. examples : 3.3 immediate operand this kind of operand is introduced by a sharp sign (#). examples : lab01 ld a,memory ; load accumulator a with memory contents lab02 ld memory,a ; load memory location with a contents ld x,a ; load x with accumulator contents lab06 push a ; put accumulator a onto the stack lab07 mul x,a ; multiply x by a lab08 ld a, #1 ; load a with immediate value 1 lab09 bset memory,#3 ; set bit #3 in memory location btjt memory,#3,label ; test bit #3 of memory and ; jump if true (set) 21 8/134 ST7ASMLK unsigned notations are accepted for defining the immediate value (0 to 255 values for an 8-bit immediate operand). 3.4 short and long addressing modes these two modes differ by the size of the memory address (one or two bytes) and thus by the target address range of the operand: 0-$ff for short addressing mode $100-$ffff for long addressing mode some instructions accept both types of addressing modes, and some others only short ad- dressing: examples : for instructions supporting both formats, short and long, when external symbol are refer- enced, long mode is chosen by the assembler: example: lab10 add a,memory ; both types of addressing modes lab11 inc memory ; only short addressing mode extern symb3 ; symb1 equ $10 ; ... ld a,symb1 ; short mode ld a,symb3 ; long mode chosen 22 9/134 ST7ASMLK 3.5 x and y indexed modes the st7 hardware supports three variants of indexed modes: ? indexed without offset, ? indexed with 8-bit unsigned offset [0 ,255 range], ? indexed with 16-bit offset. source coding form is: (x) or (y) for no-offset indexing (offset,x) or (offset,y) for the two others some instructions - ld a, add , ... - support the three forms, some others - inc , ... -, only the first two. the st7 assembler performs the same kind of 8-bit / 16-bit offset selection than be- tween short/long modes described in previous sections. examples : 3.6 relative mode this mode is used by jrxx, callr, and btjx instructions. a conditional jump is done to a program label in the [-128 , 127] range from the value of the pc for the instruction following the jump. at source coding level, the target label is specified (and the assembler computes the displace- ment). ld a, (x) ; no-offset mode ld a, (0,x) ; 8-bit offset mode ld a, (127,x) ; idem ld a, (259,x) ; 16-bit offset mode 23 10/134 ST7ASMLK 3.7 memory indirect addressing modes this last group consists in memory indirect variants of short indirect, long indirect, short indi- rect indexed, long indirect indexed. the address specified must always be in page 0 (i.e. its address must be less than $100). examples : to make the distinction between short and long indirect addressing mode, the suffix .w is specified to indicate that you want to work in long indirect mode (idem with indexed addressing mode). implicitly, if nothing is specified, the short indirect addressing mode is assumed. you can also use .b to specify short indirect addressing mode.(idem with indexed addressing mode). 3.8 high, low addressing modes in some instances, it may be necessary to access the highest part of an address (8 highest bits) or the lowest part of an address (8 lowest bits) as well. for this feature, the syntax is the following one: 11/134 ST7ASMLK examples : for more information about each instruction and the various addressing modes, refer to the st7 programming manual . lab12 equ $0012 nop ld a, #lab12.h ; load a with $00 ld a, #lab12.l ; load a with $12 25 12/134 ST7ASMLK 4 assembler 4.1 overview the assembler is a cross-assembler, i.e., it produces code for a target machine, the sgs- thomson st7 microprocessor family, different from the host machine. the assembler will turn your source code files into relocatable objects modules ready for link- ing. during the process, it checks for many different types of errors. they are recorded in an ascii file: cbe.err . the linker also writes to this file. error messages are explained in the appendix b error messages on page 125. to produce code ready for execution, you must run the assembler ( asm ), the linker ( lyn ), and the object code formatter( obsend ). ? segmentation ?macros ? conditional assembly ? source file inclusion ? absolute patch on assembly listing ? symbol cross reference listing 4.2 source code format 4.2.1 source files source program code is organised in an ascii text file named source file . a source file has the extension .asm . it is made up of lines, each of which is terminated by a new line character. 4.2.2 assembly source code format the first line of an assembly source code file is reserved for specifying the target proc- essor . even comments are prohibited. the '.tab' suffix may be left out. for example, to use the st7 processor: c:\st7tools\asm\st7/ file st7.tab must be located in the directory c:\st7tools\asm . 26 13/134 ST7ASMLK if it can't be found in the given directory, then an error is produced and assembly is aborted. there is also an environment variable 'metai'. this variable specifies the directory where the file 'st7.tab' is located. examples: if the environment variable metai is defined, the first line of the assembly program is: st7/ note the installation process automatically sets the metai variable in the autoexec.bat file. remaining source code lines have the following general format: [label[:]] 14/134 ST7ASMLK 4.2.3 labels 4.2.3.1 label structure labels must start in column one. a label may contain up to eight of any of the following characters: ? upper case letters (a-z) ? lower case letters (a-z) ?digits (0-9) ? underscore (_) the first letter of a label must be a letter or an underscore. note that upper and lower case are treated as different because the assembler is case sensitive. when labels are defined there are several attributes defined along with the value. these are: ? size (byte, word or long) ? relativity (linker relative or absolute) ? scope (internally or externally defined) the function of each attribute is explained in the following paragraphs. 4.2.3.2 label size the size of a label allows the assembler to make decisions on what kind of addressing mode to choose even if the label value itself is undefined . you can force a label to refer to a certain size of memory location by giving the label name a suffix when it is defined. the suffix isn't used when the label is referred to. if you give no suffix, then the default size is assumed. bytes, words and longs directives allow to change the default. without directives, the default is words. 28 15/134 ST7ASMLK examples: 4.2.3.3 label relativity there are two sorts of labels: absolute labels and relative labels. absolute labels are usually assigned to constants, such as io port addresses, or common values used within the program. relative labels are defined as (or derived from) an external label or a label derived from the position of some program code. they are exclusively used for labels defined within pieces of program or data. example: only the linker can sort out the actual address of the code, as the assembler has no idea how many segments precede this one in the class. at assembly time, labels such as ' start ' or ' loop ' lab equ 0 ; word (default) label label1.b equ 5 ; byte label label2.l equ 123 ; long label segment byte at: 80 ram bytes ; force size of label to bytes count ds.b ; byte default label pointer ds.w ; a word space is defined ; at this label lab equ 0 ; absolute label count ioport equ $8000 ; absolute word label ioport segment eprom start ld x,#count ld a,#* loop ld ioport,a dec x jrne loop stop jp stop ; then loop for ever 29 16/134 ST7ASMLK are actually allocated 'blank' values ($0000). these values will be filled later by the linker. la- bels such as ' count ' or ' ioport ', which were defined absolutely will be filled by the assembler. source code lines that have arguments containing relative labels are marked with an 'r' on the listing, showing that they are 'linker relative'. segments are discussed in segmentation on page 25. 4.2.3.4 label scope often, in multi-module programs, a piece of code will need to refer to a label that is actually de- fined in another module. to do this, the module that exports the label must declare it public, and the module which imports the label must declare it extern. the two directives extern and public go together as a pair. most labels in a program will be of no interest for other pieces of the program: these are known as 'internal' labels since they are only used in the module where they are defined. labels are 'internal' by default. here are two incomplete example modules that pass labels between them: module 1 extern _sig1.w ; import _sig1 extern _sig2.w ; import _sig2 public _handlers ; export _handlers segment byte p _handlers: ; define _handlers jp _sig1 ; refer to _sig1 jp _sig2 ; refer to _sig2 end module 2 extern _handlers.w ; import _handlers (addr. is a word) public _sig2 ; export _sig2 30 17/134 ST7ASMLK as you can see, module 1 refers to the ' _sig2' subroutine which is defined in module 2. note that when module 1 refers to the ' _sig2 ' label in an extern directive it specifies a word size with the ' .w ' suffix. because the assembler cannot look up the definition of ' _sig2 ' it has to be told its address size explicitly. it doesn't need to be told relativity: all external labels are assumed to be relative . absolute labels declared between modules should be defined in an include file that is called by all modules in the program; this idea of using include files is very important since it can cut down the number of public symbols - and therefore the link time - significantly. lines in the source code listing which refer to external labels are marked with an x and given 'empty' values for the linker to fill. as a short cut, labels may be declared as public by preceding them with a ' . ' at their defini- tion. if this is done the label name need not be given in a public directive. for example, the following code fragment declares the label ' lab4 ' as public automatically: example: 4.2.4 opcodes the opcode field may serve three different purposes. it may contain: ? the opcode mnemonic for an assembly instruction, ? the name of a directive, ? the name of a macro to be invoked. segment byte p _sig2: ; define _sig2 ... call _handlers ; refer to _handlers ... ret end lab3 ld a,#0 ret .lab4 nop ret 31 18/134 ST7ASMLK opcodes must be separated from the preceding field (label, if there is one) by a space or a tab. a comprehensive opcode description can be found in the st7 programming manual . macros are discussed in macros on page 30 directives are discussed in assembler directives on page 63 . 4.2.5 operands 4.2.5.1 general operands may be: ? numbers, ? string and character constants, ? program counter references, ? expressions. 4.2.5.2 number and address representation by default, the representation of numbers and addresses follows the motorola syntax. when you want to use hexadecimal number with instructions or labels, they must be preceded by $. when nothing is specified, the default base is decimal. examples: you can change the motorola format representation by using directives (.intel,.texas) to indicate the new setting format. for more information, refer to the appendix assembler direc- tives on page 63. lab03 equ 10 ; decimal 10 lab04 equ $10 ; hexadecimal 10 ld a,$ffff ; long addressing mode ld a,#$cb ; immediate addressing mode ld a,#100 ; decimal representation 32 19/134 ST7ASMLK 4.2.5.3 numeric constants and radix constants may need special characters to define the radix of the given number. the assembler supports the motorola format by default. intel, texas, zilog formats are also available if the format is forced by .intel .texas or.zilog directives. (decimal constants are always the default, and require no special characters). motorola format hex $abcd or &abcd binary %100 octal ~665 current pc * (use mult for multiply) intel format hex 0abcdh binary 100b octal 665o or 665q current pc $ texas format hex >abcd binary ?100 octal ~665 current pc $ zilog format hex %abcd caution addresses for segment definition are always given in hexadecimal: segment byte at: 100-1ff 'test' the segment ' test ' is defined within the 256-511 address range. 33 20/134 ST7ASMLK binary %(2)100 octal %(8)665 current pc $ 4.2.5.4 string constants string constants are strings of ascii characters surrounded by double quotes . example: 4.2.5.5 ascii character constants the assembler's arithmetic parser also handles ascii characters in single quotes , returning the ascii of the given character(s). examples: up to 4 characters may be used within a single pair of quotes to give a long constant. the fol- lowing special sequences are used to denote special characters: this is an ascii string a $41 6 $06 ab $4142 \b $7f backspace \f $0c formfeed \n $0a linefeed \r $0d carriage return \t $09 tabulation \\ $5c slash \ $27 single-quote 34 21/134 ST7ASMLK 4.2.5.6 program counter reference the current value of the program counter (pc) can be specified by * example: 4.2.5.7 expressions and operators expressions expressions are numeric values that may be made up from labels, constants, brackets and operators. labels and constants have been discussed in previous paragraphs. arithmetic brackets are allowed up to 8 nested levels : the curly braces {} are used instead of the common ( and ) because instructions may use a parenthesis to denote indexed ad- dressing modes. operators there are 4 levels of precedence. operators in level #1 take precedence over operators in lev- el #2, and so on. in each level, operators have same precedence: they are evaluated from left to right. . \0 $00 null \ $22 double-quote lab05 jra * table 2: operation result, level #1 -a negated a 35 22/134 ST7ASMLK a and b logical and of a and b a or b logical or of a and b a xor b logical xor of a and b a shr b a shifted right b times a shl b a shifted left b times a lt b 1 if a 23/134 ST7ASMLK operator names longer than one character must be followed by a space character. for exam- ple, ' 1 and 2 ' is correct, ' 1and2 ' is not. place the curly braces { } around arithmetic expressions. also, always use curly braces at the top-level, when defining a numeric expression. not doing so may produce unexpected results. table 3: operation result, level #2 a/b a divided by b a div b a divided by b table 4: operation result, level #3 a * b a multiplied by b a mult b as above for motorola (character * is reserved) table 5: operation result, level #4 a-b a minus b a+b a plus b 37 24/134 ST7ASMLK 4.2.6 comments comments are preceded by a semicolon. characters following a semicolon are ignored by the assembler. 4.2.7 a source code example don't worry if some directives don't make sense yet; they will be covered soon; also, take spe- cial notice of the segment directive. wrong syntax: #define size 128 ds.w size+1 ; wrong, syntax error #if size eq 1 ; wrong, same as #if size #endif correct syntax: #define size 128 ds.w {size+1} ; ok #if {size eq 1} ; ok #endif st7/ ; small example module showing source formats ioport equ $8000 ; 8 bit i0 port a handshake equ $9000 ; write xx here to strobe segment 'program' start ld a,#0 ; zero counter loop ld ioport,x ; store into ioport segment word at: fffc 'code' word start end 38 25/134 ST7ASMLK 4.3 segmentation 4.3.1 introduction segments are very, very important. you have to know about segments before you can use the assembler. take the time now to understand them and you'll save yourself a lot of puzzling. segmentation is a way of 'naming' areas of your code and making sure that the linker collates areas of the same name together in the same memory area, whatever the order of the seg- ments in the object files. up to 128 different segments may be defined in each module. the segment directive itself has four arguments, separated by spaces: [ 26/134 ST7ASMLK file1 and file2 are two separate modules belonging to the same program. file1 introduces two classes: 'ram0' and 'eprom' . the class-names may be any names you choose up to 30 characters. the first time a class is used - introduced - you have to tell the default alignment, the start and the end addresses of the class, and, of course the name of the class. users generally specify a new class for each 'area' of their target system. in the examples above the user has one class for the 128 bytes of on-chip ram from 0080 to 00ff ( 'ram0' ) and another for the 'eprom' . the code is stored from e000 to ffff ( 'eprom' ). you have to supply all this information the very first time you use a new class, else only the class-name is necessary, as in file2. 4.3.2 parameters the following paragraphs describe each argument in detail. 4.3.2.1 name the 27/134 ST7ASMLK looking back to our examples earlier, you should now be able to see that the 'ram0' class will allocate 80 to counter , 81 to address , 92 to stack in file1, and when the linker meets the segment in file2 of the same class, serialtemp will be allocated 93 , and seri- alcou 94 . the same processing happens to the two 'eprom ' class segments: the second, in file2 will be tacked on to the end of the first in file1. if the file2 'eprom' class segment had specified, say, the long align type instead of the default byte , then that segment would have been put on the next long-word boundary after the end of the file1 'eprom' class seg- ment. 4.3.2.3 combine the 28/134 ST7ASMLK the at -type 29/134 ST7ASMLK the values for labels lab1 , lab2 , lab3 , lab4, and lab5 are 12 , 12 , 1a , 1a and 1e, re- spectively. note: since you can't specify both at and common combines simultaneously, the only way to spec- ify the exact location of commons is to insert an empty at combine segment before the first common declaration. example: 4.3.2.4 cod parameter, output file control the last field of a segment directive controls where the linker places the code for a given class. when introducing a class, if this field is not specified, the code for this class will be sent to the normal, default .cod file by the linker. if the [cod] file is given a number between 0 and 9 then all code generated under the class being introduced will be sent to a different '.cod ' file by the linker. if the linker produces a file called ' prog.cod ', for example, then all code produced under classes with no [cod] field will go into that file, as normal. if one class is introduced with a [cod] field of 1 , though, then all code produced under that class is sent instead to a file prog_1.cod . the code produced under the other classes is sent on as usual to prog.cod . dat2 segment 'data' .lab5 ds.w 2 end com1 segment byte at: 10 'data' com1 segment common 'data' ... com1 segment common 'data' ... 43 30/134 ST7ASMLK using this scheme, you can do bank switching schemes quickly and directly, even when mul- tiple eproms share the same addressing space. simply allocate each eprom class of its own, and introduce each class with a different [cod] field. this will result in the linker collating eprom's contents into a different .cod file for you to obsend independently. example: 4.3.3 copying code it sometimes happens that you need to copy a block of code from eprom to ram. this presents some difficulties because all labels in that piece of code must have the ram ad- dresses, otherwise any absolute address references in the code will point back to the eprom copy. you can specify a class for execution , and use a different class for storage . in the following example: the code starting from ' label1 ' will be stored in the ' code ' class as usual, but all the labels in that special segment will be given addresses in the ' ram ' class, and memory will also be re- served in the ram class for the contents of the special segment. 4.4 macros macros are assembly-time subroutines . when you call an execution-time subroutine you have to go through several time-consuming steps: loading registers with the arguments for the subroutine, having saved out the old con- segment byte at:8000-bfff 'eprom1' 1 segment byte at:8000-bfff 'eprom2' 2 segment byte at: 0 'code' segment byte at: 8000 'ram' segment 'ram>code' label1: nop 44 31/134 ST7ASMLK tents of the registers if necessary, pushing registers used by the subroutine (with its attendant stack activity) and returning from the subroutine (more stack activity) then popping off pre- served registers and continuing. although macros don't get rid of all these problems, they can go a long way toward making your program execute faster than using subroutines - at a cost. the cost is program size. each time you invoke a macro to do a particular job, the whole macro assembly code is inserted into your source code . this means there is no stacking for return addresses: your program just runs straight into the code; but it's obviously not feasible to do this for subroutines above certain size. the true use of macros is in small snippets of code that you use repeatedly - perhaps with dif- ferent arguments - which can be formalized into a 'template' for the macros' definition. 4.4.1 defining macros macros are defined using three directives: macro, mend and local . the format is: 32/134 ST7ASMLK ld a,index adc a,offset ld index.x,a note that the formal parameters given in the definition have been replaced by the actual parameters given on the calling line . these new parameters may be expressions or strings as well as label names or constants: it's because they may be complex expression that they are bracketed when there is any extra numeric activity: this is to make sure they come out with the precedence correctly parsed. macros do not need to have any parameters: in which case leave the macro argument field blank, and give none on the calling line. there is one further problem: because a macro may be called several times in the same mod- ule, any labels defined in the macro will be duplicated. the local directive gets around this problem: example: this macro creates the code for a loop to await io port at $c000 to go low. without the local directive, the label ' loop ' would be defined as many times as the macro is called, producing syntax errors at assembly time. because it's been declared local at the start of the macro definition, the assembler takes care of it. wherever it sees the label ' loop ' inside the macro, it changes the name ' loop ' to ' locxxxx ' where xxxx is a hex number from 0000 to ffff . each time a local label is used, xxxx is incremented. so, the first time the getio macro is called, ' loop ' is actually defined as ' loc0 ', the second time as ' loc1 ' and so on, each of these being a unique reference name. the reference to ' loop ' in the 'if' statement is also de- tected and changed to the appropriate new local variable. getio macro local loop loop ld a,$c000 jra loop mend 46 33/134 ST7ASMLK the following directives are very useful, in conjunction with macros: 4.4.2 parameter substitution the assembler looks for macro parameters after every space character. if you want to embed a parameter, for example, in the middle of a label, you must precede the parameter name with an ampersand ' & ' character, to make the parameter visible to the preprocessor. for example, if we have a parameter called ' param ': dc.w param it works as expected but the ampersand is necessary on: label¶m: nop label¶m&_¶m: nop otherwise ' labelparam ' would be left as a valid label name; if the macro parameter ' param ' had the value ' 5 ', then ' label5 ' and ' label5_5 ' would be created. 4.5 conditional assembly conditional assembly is used to choose to ignore or to select whole areas of assembler code. this is useful for generating different versions of a program by setting a particular variable in an include file that forces the use of special pieces of code instead of others. 4.5.1 if/#else#endif directives there are three main directives used to perform conditional assembly: table 8: directive usage #ifb to implement macro optional parameters. #ifdef to test if a parameter is defined. #iflab to test if a parameter is a label. #ifidn to compare a parameter to a given string. 47 34/134 ST7ASMLK the condition given with the ' #if ' may take the form of any numeric expression; the rule for deciding whether it resolves to 'true' or 'false' is simple: if it has a zero value then it's false, else it's true. these directives should not start at column 1 of line, reserved for labels. example: this sequence would print ' true ' if the label ' count ' did equal 1, and false if it didn't. example: table 9: directive usage #if marks the start of the conditional and decides whether the following zone will be assembled or not. #else optionally reserves the condition of the previous #if for the following zone. #endif marks the end of the previous #if's. #if {count eq 1} %out 'true' #else %out 'false' #endif #if {count gt 1} %out count more than one #if {count gt 2} %out ...and more of two ! #else %out ...but not more than two! #endif 48 35/134 ST7ASMLK as you can see, conditionals may be nested: the #else and #endif directive are assumed to be assumed to the most recent unterminated #if . other special #if directives are available: 4.6 running the assembler 4.6.1 command line the assembler needs the following arguments: asm 36/134 ST7ASMLK if any or all the arguments are left out of the command line, you'll be prompted for the remain- ing arguments. example: in the example above, no parameters were given on the command line, so all the parameters were prompted for. the 37/134 ST7ASMLK 4.6.2.1 sym option description: this option allows the generation of a symbol table. format: asm 38/134 ST7ASMLK 4.6.2.4 fi option description: one side effect of using a linker is that all modules are assembled separately, leaving inter modules' cross-references to be fixed up by the linker. as a result the assembler listing file set all unresolved references to 0, and displays a warning character. the ' -fi ' option enables you to perform an absolute patch on the desired list- ing. therefore, you must have produced a listing file ( .lst ) and linked your application to compute relocations and produce a .cod file and a map file. when you want a full listing to be generated, you must not have made any ed- its since the last link (otherwise the named map-file would be 'out of date' for the module being assembled). this is not usually a problem since full listings are only needed after all the code has been completed. -fi automatically se- lects a complete listing. format: asm 39/134 ST7ASMLK example: asm ex1 -d eprom 1 -d ram 2 4.6.2.6 pa option description: request to generate a pass-1 listing. it means that in this listing internal for- ward references are not yet known. they are marked as undefined with a 'u' in the listing file. format: asm 40/134 ST7ASMLK 5 linker 5.1 what the linker does after having separately assembled all the component modules in your program, the next step is to link them together into a .cod file which can then be sent on to its final destination using obsend. this linking process is not just as a simple concatenation of the object modules. it resolves all the external references. if a referenced label is not defined as public , an error is detected. it also checks the type of relocation to do, places the segment according to your mapping, and checks if any of them is overrun. 5.2 invoking the linker 5.2.1 command line the linker needs the following arguments: lyn <.obj file>[+<.obj file>...], [<.cod file>],[ 41/134 ST7ASMLK the .cod file has a default name formed of the first object file's name with forced suffix of ' .cod '. this will be the name of the file produced at the end of the link session: it contains all the information from the link session in a special format: however, obsend must be used on the .cod file before it is ready to use. if the default filename is not what you want, the filename given at the prompt is used instead. the suffix will be forced to .cod if left blank. the default is selected by leaving this argument blank at the command line, or pressing 42/134 ST7ASMLK the filename is assumed to have a suffix ' .rsp ' if none is supplied. repeating our example used as earlier, but this time with a response file called game.rsp : lyn @game.rsp is all that needs to be typed, and the file game.rsp must contain: game+scores+keys+ game1+ game2+game3 prog which echoes what would have been typed at the keyboard. if the response file ends prema- turely, the remaining arguments are prompted for at the keyboard. in very large session, the .obj files argument won't fit on one line: it can be continued to the next by ending the last .obj file on the first line with a ' + '. note that when using response files, there must be at least two carriage returns at the end of the file. 5.3 linking in detail 5.3.1 publics and externs all labels declared external in the modules being linked together must have a corresponding public definition in another module. if it doesn't, it may be an error. similarly, there must only be one public definition of a given label. the bulk of the linker's job is filling those relative or external blanks left by the assembler in the .obj files; to a lesser extent, it also handles special functions such as date or skip direc- tives. equally important, it has to collate together and allocate addresses to segments. 5.3.2 segments in the linker a typical system may look like the diagram alongside: a good candidate for four different seg- ments, perhaps named 'ram0', 'ram1', 'eprom' and 'rom'. if the reset and interrupt vectors live at the end of the map, perhaps from ffee-ffff then we might mark a fifth segment called 'vectors' at those addresses and truncate 'rom' to end at ffed; that way the linker will warn us if 'rom' has so much code in it that it overflows into where the vectors live. 56 43/134 ST7ASMLK these classes would be introduced as follows: segment byte at: 0-ff 'ram0' segment byte at: 100-027f 'ram1' segment byte at: 8000-bfff 'eprom' segment byte at: c000-ffdf 'rom' segment byte at: ffe0-ffff 'vectors' after their full introduction that needs only be done once in the whole program, the rest of the program can refer to the classes just by giving the class names in quotes: example: if this example followed immediately after the class instruction the ' xtemp ' label would be giv- en the value 0 , time would be given 2 and hex c000 . if, however, the code was several modules away from the introduction with segments of the classes ' ram0 ' or ' rom ', then the val- ue allocated to all the labels will depend on how much space was used up by those modules. the linker takes care of all this allocation. this is the way the linker handles the problems of re- locatability; keep in mind that this link system is going to have to handle compiled code from high level languages and you'll perhaps begin to understand why things have to be general- ized so much. so far the segments we've looked at, had no 44/134 ST7ASMLK this complex sequence of segments shows now instances of the class ' ram1 ' being used with a segment name of ' grafix '. because the first instance of the class ' ram1 ' had the name ' grafix ' the two ' grafix ' ram1 segments are placed in memory first followed by the null- name ram1 segment (which defines ' field_buf '). note this is not the order of the segments in the code: segments with the same name are collated together (even from separate .obj files), and the lumps of segments of the same name are put into memory in the order that the names are found in the .obj files. as explained in the assembler sections (assembler on page 12), if x is your cod file suffix when introducing a class, all code for that code is sent into a new cod-file named file_x.cod , where file is the name of the first cod file, and x is the cod-file suffix ( 1-9 ). 5.3.3 symbol files at the end of a successful link, one or more .obj files will have been combined into a single .cod file. a .map file will have been produced, containing textual information about the seg- ments, classes and external labels used by the .obj module(s). finally a compact .sym file is generated, containing all public symbols found in the link with their final values. the linker supports a special feature - you can link in .sym files from other link sessions. this means with huge programs, you cannot only partition your code at assembler level, but divide the code up into 'lumps' which are linked and loaded separately, but have access to each oth- er's label as externs . you can 'link in' a symbol table simply by giving its name with the suffix .sym . always give symbol tables at the start of the object file list. grafix segment byte at: 100-027f 'ram1' cursor_buf ds.b 64 ; buffer for map under cursor segment byte at: 8000-bfff 'rom' show_page nop segment 'ram1' field-buf ds.b {{256 mult 256}/8} segment 'rom' dump_buf ld a,field_buffer grafix segment 'ram1' cursor_temp ds.b 64 58 45/134 ST7ASMLK obj file example: lyn prog1.sym+prog2,vectors,irq; once this is done, all the public symbols from prog1.sym are now available as publics to prog2.obj , vectors.obj and irq.obj . because changes in one link will not automatically update references to the changed link code in other links, it's necessary when using this technique to 'fix' each link in an area of memory, and have a 'jump table' at the top of each area. this means that all 'function' addresses are permanently fixed as jump table offset, and changes to each link will result in automatic redi- rection of the jump targets to the new start of each routine. put another way, each link must have entry fixed points to all its routine, otherwise re-linking one 'lump' of a program could make references to its addresses in other modules out of date. 5.4 the linker in more detail. 5.4.1 the composition of the .obj files the .obj files produced by the assembler contain an enormous amount of overhead, mostly as coded expressions describing exactly what needs to go into the 'blank spaces' the assem- bler has been so liberal with. the linker contains a full arithmetic parser for 'working out' com- plex expressions that include external labels: this means (unlike most other assemblers) there are few restrictions on where external labels may appear. the assembler also includes line-number information with the .obj file, connecting each piece of generated object code with a line number from a given source file. obj files also contain 'special' markers for handling skip and date type directive. 5.4.2 the composition of the .cod files .cod files, on the other hand, contain very little overhead: there are six bytes per segment that describe the start address and length of that segment; besides that, the rest of the code is in its final form. a segment of zero length marks the end of the file. it only remains for obsend to take the code segment by segment and send it on to its destination. 59 46/134 ST7ASMLK 5.4.3 reading a mapfile listing the linker also generates files with the suffix .sym and .map in addition to the .cod file we have already discussed. the .sym file contains a compact symbol table list suitable with the debuggers and simulators. the .map file listing shows three important things: a table of segments with their absolute ad- dress, a table of all classes in the program, and a list of all external labels with their true val- ues, modules they were defined in and size. here is an example mapfile , where one of the class, rom , has gone past its limit, overwriting (or more correctly, having part of itself overwritten by) vectors . the [void] on some segments in the segment list says that these segments were not used to create object code, but were used for non-coding-creating tasks such as allocating label values with ds.b etc. the number in straight brackets on the segment as true address list shows how many segments 'into' the module this segment is, i.e., the 1s t , 2 nd etc. of the given module. the first x-y shows the range of addresses. the def (line) field on the external la- bels list shows the source code file and line number that his label was defined in. the number at the start of each class list line is the cod-file that the class contents were sent to (default is 0 ). segment address list: prog [1] 10- 86 0- 6 ram0' [void] prog [2] 88- 278 100- 138 'ram1' [void] main [1] 8- 563 8000- 875b 'eprom' prog [4] 282- 889 c000- c508 'rom' main [2] 568- 1456 c509- f578 'rom' monitor [1] 8- 446 f579- fff9 'rom' monitor [2] 448- 467 ffee- ffff 'vectors 60 47/134 ST7ASMLK class list: external label list: the external label list only includes labels that were declared public : labels used internally to the module are not included. this table is most useful for debugging purposes, since the values of labels are likely to be relocated between assemblies. the labels are given in first- character-alphabetic order. 0 ram0' byte from 0 to 78 (lim ff) 45% d 0 ram1' byte from 100 to 138 (lim 27f) 50% d 0 eprom' byte from 8000 to 875b (lim bfff) 21% c 0 rom' byte from c000 to fff9 (lim ffdf) c*overrun* 0 vectors' byte from ffee to ffff (lim ffff) 100% d symbol name value size def(line) char 64 byte game.obj(10) char1 66 byte game.obj(11) label abcd word game.obj(25) 3 labels 61 48/134 ST7ASMLK 6 obsend 6.1 what obsend does for you after your program has been assembled and linked to form a ' .cod ' file it needs to be sent on to the place where it'll be executed; now your code is just sitting in a disc file where the target system can't get at it. obsend is a general purpose utility for .cod files in various ways using various formats. 6.2 invoking obsend obsend follows the same standard formats as the rest of the assembler / linker; arguments can be given from the command line, keyboard or response file. the general syntax is: obsend 49/134 ST7ASMLK example: the command generates the file ' image.s19 ' containing the code from ' test.cod ', in st s- record s format. when the destination code is " v " (video), this field is void. 6.3 format definitions 50/134 ST7ASMLK 6.3.1 straight binary format 51/134 ST7ASMLK the next two characters are the record type for this line: 00 is a data line, and 01 signals eof. the following characters until the last two are up the 16 data bytes for this line and, the last two are a checksum for the line, calculated by starting with $00 subtracting the real value of all characters sent after the ' : ' until the checksum itself. 'real value' means that for example, the two characters 3 and 0 should subtract $30 from the checksum, not 51 and 48 . every line ends with a cr-lf combination, $0a and $0d . the last line sent must be an end-of-file line, which is denoted by a line with no data bytes and a record type of 01 instead of 00. giving i32 or i32 instead of intel as the argument uses the same format, but sends 32 bytes of data per line. 6.3.3 motorola s-record format 52/134 ST7ASMLK the record is concluded by a cr-lf combination $0a , $0d . the s0 and s9 (i.e., header and eof) records are always the same: s0 06 0000 484452 1b and: s9 03 0000 fc a complete example of s-record transmission may look like: s0 06 0000 484452 1b s1 13 001a ff120094ff130094d08aff390094ff12 50 s2 08 01c0 04ffc00000 73 53/134 ST7ASMLK 7 librarian 7.1 overview if you do a lot of work on similar boards especially those with the same processor, it makes a great deal of sense to reuse lumps of code you've already written to do the same task in a dif- ferent program. at the simplest level, you could just copy the source code as a block of text into the new program. this works fine, but has a subtle disadvantage: if you update the sub- routine, you have to hunt around all the usages of it, performing the update on each. to get around this problem, many people have the source for common routines in one place, and link the .obj module with each program needing routine. then you only need to update the source code once, reassemble it to get a new .obj file, then link again all the users of the routine, who will now have the new .obj file. this scheme works good, too. but it generates some problems of its own. for example, each routine needs its own .obj file. by their nature, these common routines tend to be small, so you end up giving dozens of extra .obj modules to the linker, and having the .obj modules scattered around your disc. the base concept of a librarian is to combine all these small, useful .obj modules into one large .lib library file. you could then tell the linker about the library, and it would take care of sorting out which .obj modules to pull into link. it would know which ones to pull by the fact that the main code being linked would have undefined externals, for example, to call the miss- ing library routines. the librarian simply takes each undefined external in turn, and checks it against all the modules in the library. if any of the modules declares a public of the same name, it knows you need that .obj module and it includes it automatically. 7.2 invoking the librarian the librarian is called lib , and takes one command line argument that is the name of the li- brary to operate on. if not given, you'll be prompted for it. lib [library name] .lib is added if the suffix is left off. if the library you gave doesn't exist, lib asks you if it's a new library. 67 54/134 ST7ASMLK example: if the answer is ' n ', lib aborts. if the library exists, lib prints up a report on the library. next you're faced with the main prompt: pressing enter gives you access to the following options: lib lib1 sgs-thomson microelectronics - librarian - rel 1.00 couldn't open library file 'lib1.lib' is it a new file? (y/n): y library lib1.lib is 2k long. 16/1024 public labels used in 2/128 modules. lib1.lib: operation ( 55/134 ST7ASMLK 7.3 adding modules to a library typing for example: +user1\board would look for a file, called user1\board.obj , and add it to the library. if lib can't find the named file, lib reports the fact and returns to the operations prompt. else lib issues the following message: adding new board.obj ... 15 labels added done. if the library already contained a file board.obj , it would prompt you with: board.obj already in library lib1.lib, replace with board.obj (y/n): responding with ' n returns you to the operations prompt, while ' y ' first removes the old board.obj then continues as above. 7.4 deleting modules from a library this is done by, for example: -board if lib cannot find board.obj in the current library, it reports an error and aborts back to the operation prompt. if it can find it, it makes sure you know what you are doing with: board.obj to be deleted from library lib1.lib: are you sure (y/n): n aborts to operation prompt. 'y' continues, reporting: removing old board.obj ... done. 69 56/134 ST7ASMLK 7.5 copying modules from a library to make a copy of a .obj module in a library back to disc, use, for example: *board this will check the existence of board.obj in the current library, if not it'll report the failure and abort the operation prompt. if it does find it, it invites you to give it the name of the disc file to create to contain the copy of the .obj module. copy into .obj file [board.obj]: if you type < enter >, it'll select the original name of the object module as the copy's name. otherwise, give it a path spec. if the file you give already exists, lib says: file board.obj already exists; overwrite? (y/n): again, responding ' n ' aborts to the operations prompt, while ' y ' does the copy with the mes- sage: copying board.obj to disk... done. 7.6 getting details in your library the last operation: ? causes lib to print out details on the current library. library lib1.lib is 2k long 16/1024 publics labels used on 2/128 modules 0: z1.obj (z1.asm) length 2de 1: board.obj (board.asm) length 7fff the name in brackets is the source module from which the named object module was assem- bled. 70 57/134 ST7ASMLK appendix a a assembler directives a.1 introduction each directive has been given a new section to itself, and an entry in the index. the name of the directive, which will always appear in the second field is given in the heading at the top of the section. next there is a line showing arguments allowed (if any) for this directive. the penultimate sec- tion describes the action of the directive and the format and nature of the argument specified in the previous section, and the last section gives one or more example of the directive in use. there is a 'see also' cross reference at the bottom of the page. all the directives must be placed in the second, opcode, field, with any arguments one tab away in the argument field. 71 58/134 ST7ASMLK a.2 .bell purpose: ring bell on console. format: . bell description: this directive simply rings the bell at the console; it can be used to signal the end of pass-1 or pass-2 with #if1 or #if2. this directive does not generate assembly code or data. example: see also: .bell 72 59/134 ST7ASMLK a.3 byte purpose: define byte in object code. format: byte 60/134 ST7ASMLK a.4 bytes purpose: label type definition type=byte. format: bytes description: when a label is defined, 4 separate attributes are defined with it: scope (in- ternally or externally defined), value (actual numerical value of the label), relativity (absolute or relative), and length, (byte, word and long). all these attributes except length are defined explicitly before or at the def- inition: you can force the label to be a certain length by giving a dot suffix, eg. 'label.b' forces it to be byte length. you may also define a default state for label length: labels are created to this length unless otherwise forced with a suffix. the default is set to word at the start of the assembly, but may be changed by bytes, words or longs to the appropriate length. example: see also: longs, words bytes lab1 equ 5 ; byte length for lab1 74 61/134 ST7ASMLK a.5 cequ purpose: equate preexisting label to expression. format: label cequ 62/134 ST7ASMLK a.6 .ctrl purpose: send control codes to the printer. format: .ctrl 63/134 ST7ASMLK a.7 date purpose: define 12-byte ascii date into object code. format: date description: this directive leaves a message for the linker to place the date of the link in a 12-byte block the assembler leaves spare at the position of the date di- rective. this means that every link will leave its date in the object code, al- lowing automatic version control. the date takes the form (in ascii) dd_mmm_yyyy where character '_' represents a space; for example 18 jul. 1988. the date is left for the linker to fill instead of the assembler since the source code module containing the date directive may not be reassembled after every editing session and it would be possible to lose track. example: see also: date 77 64/134 ST7ASMLK a.8 dc.b purpose: define byte(s) in object code. format: dc.b 65/134 ST7ASMLK a.9 dc.w purpose: define word(s) in object code. format: dc.w 66/134 ST7ASMLK a.10 dc.l purpose: define long word(s) in object code. format: dc.l 67/134 ST7ASMLK a.11 #define purpose: define manifest constant. format: #define 68/134 ST7ASMLK a.12 ds.b purpose: define byte space in object code. format: ds.b [optional number of bytes] description: this directive is used to 'space out' label definitions. for example let's say we need a set of byte-sized temporary storage locations to be defined in ram, starting at address $4000. we could write: segment byte at 4000 'ram' temp1 equ $4000 temp2 equ $4001 which would work fine, however, we recommend you to write: segment byte at 4000 'ram' temp1 ds.b temp2 ds.b which does the same job. the advantage is that the pc is incremented au- tomatically. there are two other types of ds instructions available for doing word and long length storage areas: ds.w and ds.l. note that the ar- eas in question are not initialised to any value; it's merely a way of allocat- ing values to labels. the optional argument specifies how many bytes to allocate; the default is 1. because no code is generated to fill the space, you are not allowed to use ds.b in segments containing code, only for segments with data definitions. example: see also: ds.w, ds.l labl ds.b 82 69/134 ST7ASMLK a.13 ds.w purpose: define word space in object code. format: ds.w [optional number of words] description: this directive is used to 'space out' label definitions. for example let's say we need a set of word-sized temporary storage locations to be defined in ram, starting at address $4000. we could write: segment byte at 4000 'ram' temp1 equ $4000 temp2 equ $4002 which would work fine, however, we recommend you to write: segment byte at 4000 'ram' temp1 ds.w temp2 ds.w which does the same job. the advantage is that the pc is incremented au- tomatically. there are two other types of ds instructions available for doing byte and long length storage areas: ds.b and ds.l. note that the are- as in question are not initialised to any value; it's merely a way of allocating values to labels. the optional argument specifies how many bytes to allocate; the default is 1. because no code is generated to fill the space, you are not allowed to use ds.w in segments containing code, only for segments with data defini- tions. example: see also: ds.b, ds.l labl ds.w 83 70/134 ST7ASMLK a.14 ds.l purpose: define long space in object code. format: ds.l [optional number of long words] description: this directive is used to 'space out' label definitions. for example let's say we need a set of long-word-sized temporary storage locations to be de- fined in ram, starting at address $4000. we could write: segment byte at 4000 'ram' temp1 equ $4000 temp2 equ $4004 which would work fine, however, we recommend you to write: segment byte at 4000 'ram' temp1 ds.l temp2 ds.l which does the same job. the advantage is that the pc is incremented au- tomatically. there are two other types of ds instructions available for doing byte and word length storage areas: ds.b and ds.w. note that the ar- eas in question are not initialised to any value; it's merely a way of allocat- ing values to labels. the optional argument specifies how many bytes to allocate; the default is 1. because no code is generated to fill the space, you are not allowed to use ds.l in segments containing code, only for segments with data definitions. example: see also: ds.b, ds.w labl ds.l 84 71/134 ST7ASMLK a.15 end purpose: end of source code. format: end description: this directive marks the end of the assembly on the main source code file. if no end directive is supplied in a source-code file then an illegal eof er- ror will be generated by the assembler. include files do not require an end directive. example: see also: end 85 72/134 ST7ASMLK a.16 equ purpose: equate the label to expression. format: label equ 73/134 ST7ASMLK a.17 extern purpose: declare external labels. format: extern description: when your program consists of several modules, some modules need to refer to labels that are defined in other modules. since the modules are as- sembled separately, it is not until the link stage that all the necessary label values are going to be known. whenever a label appears in an extern directive, a note is made for the linker to resolve the reference. declaring a label external is just a way of telling the assembler not to ex- pect that label to be defined in this module, although it will be used. obvi- ously, external labels must be defined in other modules at link stage, so that all the gaps left by the assembler can be filled with the right values. because the labels declared external are not actually defined, the assem- bler has no way of knowing the length, i.e., (byte, word or long) of the label. therefore, a suffix must be used on each label in an extern directive de- claring its type; if the type is undefined, the current default label scope (set by bytes, words, longs directives) is assumed. example: see also: public extern label.w, label1.b, label2.l 87 74/134 ST7ASMLK a.18 #else purpose: conditional else. format: #else description: this directive forces execution of the statements until the next #endif if the last #if statement was found false or disables execution of the state- ments until the next #endif if the last #if statement was found true. the #else is optional in #if / #endif structures. in case of nested #else statements, a #else refers to the last # if . example: see also: #if, #endif #if{1eq0} ; ; block a ... not assembled #else ; block b ... assembled #endif 88 75/134 ST7ASMLK a.19 #endif purpose: conditional terminator. format: #endif description: this is the non optional terminator of a #if structure. if there is only one level of #if nesting in force, then the statements after this directive will nev- er be ignored, no matter what the result of the previous #if was. in other words, the #endif ends the capability of the previous #if to suppress as- sembly. when used in a nested situation it does the same job, but if the last #if / #endif structure was in a block of source suppressed by a previous #if still in force, the whole of the last #if / #endif structure will be ignored no matter what the result of the previous #if was. example: see also: #if, #else #if {count gt 0} ... #endif 89 76/134 ST7ASMLK a.20 fcs purpose: form constant string. format: fcs <"string"> | 77/134 ST7ASMLK a.21 .form purpose: set form length of the listing device. format: .form 78/134 ST7ASMLK a.22 group purpose: name area of source code. format: group 79/134 ST7ASMLK a.23 #if purpose: start conditional assembly. format: #if 80/134 ST7ASMLK a.24 #if1 conditional purpose: conditional on being in pass #1. format: #if1 description: this directive works just like #if except it has no argument and only eval- uates itself as true if the assembler is on its first pass through the source code. can use #else and requires #endif. example: see also: #if2, #else, #if, #endif #if1 %out "starting assembly" #endif 94 81/134 ST7ASMLK a.25 #if2 purpose: conditional on being in pass #2. format: #if2 description: this directive works just like #if except it has no argument and evaluates itself as true only if the assembler is on its second pass through the source code. example: see also: #if1, #if, #endif, #else #if2 %out "gone through pass-1 ok" #endif 95 82/134 ST7ASMLK a.26 #ifb purpose: conditional on argument being blank. format: #ifb 83/134 ST7ASMLK a.27 #ifidn purpose: conditional on arguments being identical. format: #ifidn 84/134 ST7ASMLK a.28 #ifdef purpose: conditional on argument being defined. format: #ifdef 85/134 ST7ASMLK a.29 #iflab purpose: conditional on argument being a label. format: #iflab 86/134 ST7ASMLK a.30 #include purpose: insert external source code file. format: #include " 87/134 ST7ASMLK a.31 intel purpose: force intel-style radix specifier. format: intel description: the intel style: 0abh hexadecimal 17o or 17q octal 100b binary 17 decimal (default) $ current program counter this directive forces the intel format to be required during the assembly. example: see also: motorola, texas, zilog intel ld x,0ffffh 101 88/134 ST7ASMLK a.32 .lall purpose: list whole body of macro calls. format: .lall description: this directive forces the complete listing of a macro expansion each time a macro is invoked. this is the default. this directive does not generate as- sembly code or data. example: see also: .xall, .sall .lall 102 89/134 ST7ASMLK a.33 .list purpose: enable listing (default). format: .list description: this directive switches on the listing if a previous . nolist has disabled it. the -'pa ' or -'li ' options must also have been set from the command line to generate a listing. this directive, in conjunction with the directive .nolist , can be used to control the listing of macro definitions. this directive does not generate assembly code or data. example: see also: .nolist .list 103 90/134 ST7ASMLK a.34 #load purpose: load named object file at link time. format: #load "path-name[.ext]" description: this directive leaves a message for the linker to load the contents of the named file at the current position in the current segment. the file should be in 'straight binary' format, i.e., a direct image of the bytes you want into the object code. example: see also: segment byte at 8000-c000 'eprom1' #load "table.hex" 104 91/134 ST7ASMLK a.35 local purpose: define labels as local to macro. format: local 92/134 ST7ASMLK a.36 long purpose: define long word in object code. format: long 93/134 ST7ASMLK a.37 longs purpose: default new label length long. format: longs description: when a label is defined, four separate attributes are defined with it: scope (internally or externally defined), value (actual numerical value of the label), relativity ( absolute or relative ), and lastly, length (byte, word or long). all these attributes except length are defined explicitly before or at the end of the definition: you can force a label to be a certain length by giving a dot suffix, eg. 'label.b' forces it to be byte length. you may also define a default state for label length: labels are created to this length unless otherwise forced with a suffix. the default is set to word at the start of the assembly, but may be changed by bytes, words or longs to the appropriate length. example: see also: bytes, words longs lab1 equ 5 ; long length for lab1 107 94/134 ST7ASMLK a.38 macro purpose: define macro template. format: 95/134 ST7ASMLK a.39 mend purpose: end of macro definition. format: mend description: end of macro definition. example: see also: macro cmp16 macro first,second,result local trylow ld a,first add a,second cp a,#0 jreq trylow cpl a trylow ld result,a mend 109 96/134 ST7ASMLK a.40 motorola purpose: force motorola-style radix specifier. format: motorola description: the motorola style: $ab hexadecimal ~17 octal %100 binary 17 decimal (default) * current program counter this directive forces the motorola format to be required during the assem- bly. the default format is motorola . example: see also: intel, texas, zilog motorola ld x,$ffff 110 97/134 ST7ASMLK a.41 .nochange purpose: list original #define strings. format: .nochange description: strings named in the first argument of a #define directive will be changed to the second argument of the #define: the default is that the changed strings will be listed. if you want the original source code to be listed in- stead, place a .nochange directive near the start of your source code. this directive does not generate assembly code or data. example: see also: #define .nochange 111 98/134 ST7ASMLK a.42 .nolist purpose: turn off listing. format: .nolist description: certain parts of your modules may not be required on a listing; this direc- tive disables the listing until the next .list directive. the default is for the listing to be enabled. this directive, in conjunction with the directive .list , can be used to control the listing of macro definitions. this directive does not generate assembly code or data. example: see also: list .nolist 112 99/134 ST7ASMLK a.43 %out purpose: output string to the console. format: %out string description: this directive prints its argument (which does not need to be enclosed in quotes) to the console. this directive does not generate assembly code or data. example: see also: %out hello! 113 100/134 ST7ASMLK a.44 .page purpose: perform a form feed. format: .page description: forces a new page listing. this directive does not generate assembly code or data. example: see also: .page 114 101/134 ST7ASMLK a.45 public purpose: make labels public. format: public 102/134 ST7ASMLK a.46 repeat purpose: assembly-time loop initiator. format: repeat description: used together with until to make assembly-time loops; it is useful for making tables etc. this directive should not be used within macros. example: see also: cequ, until repeat 116 103/134 ST7ASMLK a.47 .sall purpose: suppress all body of called macro. format: .sall description: this directive forces the complete suppression of the listing of a macro ex- pansion each time a macro is invoked. this instruction itself is never listed. note: this directive may produce confusing listings. example: see also: .lall, .xall .sall 117 104/134 ST7ASMLK a.48 segment purpose: start of new segment. format: [ 105/134 ST7ASMLK segment (continued) combine:at x[-y] introduces new class that starts from x and goes through to address y. address y is optional. 106/134 ST7ASMLK a.49 .setdp purpose: set base address for direct page. format: .setdp 107/134 ST7ASMLK a.50 skip purpose: inserts given number of bytes with an initialization value. format: skip 108/134 ST7ASMLK a.51 string purpose: define a byte-level string. format: string 109/134 ST7ASMLK a.52 subttl purpose: define a subtitle for listing heading. format: subttl " 110/134 ST7ASMLK a.53 .tab purpose: set listing field lengths. format: .tab |
Price & Availability of ST7ASMLK
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |