Mercurial > hg-old > index.cgi
annotate doc/manual.docbook.sgml @ 404:0324fd09c7ac
Added documentation for the --symbol option for lwasm
| author | lost@l-w.ca |
|---|---|
| date | Fri, 23 Jul 2010 18:31:33 -0600 |
| parents | 62cb50c50976 |
| children | b2e007c28b8f |
| rev | line source |
|---|---|
| 331 | 1 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.5//EN"> |
| 2 <book> | |
| 3 <bookinfo> | |
| 4 <title>LW Tool Chain</title> | |
| 5 <author><firstname>William</firstname><surname>Astle</surname></author> | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
6 <copyright><year>2009, 2010</year><holder>William Astle</holder></copyright> |
| 331 | 7 </bookinfo> |
| 8 <chapter> | |
| 9 | |
| 10 <title>Introduction</title> | |
| 11 | |
| 12 <para> | |
| 13 The LW tool chain provides utilities for building binaries for MC6809 and | |
| 14 HD6309 CPUs. The tool chain includes a cross-assembler and a cross-linker | |
| 15 which support several styles of output. | |
| 16 </para> | |
| 17 | |
| 18 <section> | |
| 19 <title>History</title> | |
| 20 <para> | |
| 21 For a long time, I have had an interest in creating an operating system for | |
| 22 the Coco3. I finally started working on that project around the beginning of | |
| 23 2006. I had a number of assemblers I could choose from. Eventually, I settled | |
| 24 on one and started tinkering. After a while, I realized that assembler was not | |
| 25 going to be sufficient due to lack of macros and issues with forward references. | |
| 26 Then I tried another which handled forward references correctly but still did | |
| 27 not support macros. I looked around at other assemblers and they all lacked | |
| 28 one feature or another that I really wanted for creating my operating system. | |
| 29 </para> | |
| 30 | |
| 31 <para> | |
| 32 The solution seemed clear at that point. I am a fair programmer so I figured | |
| 33 I could write an assembler that would do everything I wanted an assembler to | |
| 34 do. Thus the LWASM probject was born. After more than two years of on and off | |
| 35 work, version 1.0 of LWASM was released in October of 2008. | |
| 36 </para> | |
| 37 | |
| 38 <para> | |
| 39 As the aforementioned operating system project progressed further, it became | |
| 40 clear that while assembling the whole project through a single file was doable, | |
| 41 it was not practical. When I found myself playing some fancy games with macros | |
| 42 in a bid to simulate sections, I realized I needed a means of assembling | |
| 43 source files separately and linking them later. This spawned a major development | |
| 44 effort to add an object file support to LWASM. It also spawned the LWLINK | |
| 45 project to provide a means to actually link the files. | |
| 46 </para> | |
| 47 | |
| 48 </section> | |
| 49 | |
| 50 </chapter> | |
| 51 | |
| 52 <chapter> | |
| 53 <title>Output Formats</title> | |
| 54 | |
| 55 <para> | |
| 56 The LW tool chain supports multiple output formats. Each format has its | |
| 57 advantages and disadvantages. Each format is described below. | |
| 58 </para> | |
| 59 | |
| 60 <section> | |
| 61 <title>Raw Binaries</title> | |
| 62 <para> | |
| 63 A raw binary is simply a string of bytes. There are no headers or other | |
| 64 niceties. Both LWLINK and LWASM support generating raw binaries. ORG directives | |
| 65 in the source code only serve to set the addresses that will be used for | |
| 66 symbols but otherwise have no direct impact on the resulting binary. | |
| 67 </para> | |
| 68 | |
| 69 </section> | |
| 70 <section> | |
| 71 <title>DECB Binaries</title> | |
| 72 | |
| 73 <para>A DECB binary is compatible with the LOADM command in Disk Extended | |
| 74 Color Basic on the CoCo. They are also compatible with CLOADM from Extended | |
| 75 Color Basic. These binaries include the load address of the binary as well | |
| 76 as encoding an execution address. These binaries may contain multiple loadable | |
| 77 sections, each of which has its own load address.</para> | |
| 78 | |
| 79 <para> | |
| 80 Each binary starts with a preamble. Each preamble is five bytes long. The | |
| 81 first byte is zero. The next two bytes specify the number of bytes to load | |
| 82 and the last two bytes specify the address to load the bytes at. Then, a | |
| 83 string of bytes follows. After this string of bytes, there may be another | |
| 84 preamble or a postamble. A postamble is also five bytes in length. The first | |
| 85 byte of the postamble is $FF, the next two are zero, and the last two are | |
| 86 the execution address for the binary. | |
| 87 </para> | |
| 88 | |
| 89 <para> | |
| 90 Both LWASM and LWLINK can output this format. | |
| 91 </para> | |
| 92 </section> | |
| 93 | |
| 94 <section> | |
| 95 <title>OS9 Modules</title> | |
| 96 <para> | |
| 97 | |
| 98 Since version 2.5, LWASM is able to generate OS9 modules. The syntax is | |
| 99 basically the same as for other assemblers. A module starts with the MOD | |
| 100 directive and ends with the EMOD directive. The OS9 directive is provided | |
| 101 as a shortcut for writing system calls. | |
| 102 | |
| 103 </para> | |
| 104 | |
| 105 <para> | |
| 106 | |
| 107 LWASM does NOT provide an OS9Defs file. You must provide your own. Also note | |
| 108 that the common practice of using "ifp1" around the inclusion of the OS9Defs | |
| 109 file is discouraged as it is pointless and can lead to unintentional | |
| 110 problems and phasing errors. Because LWASM reads each file exactly once, | |
| 111 there is no benefit to restricting the inclusion to the first assembly pass. | |
| 112 | |
| 113 </para> | |
| 114 | |
| 115 <para> | |
| 116 | |
| 117 It is also critical to understand that unlike many OS9 assemblers, LWASM | |
| 118 does NOT maintain a separate data address counter. Thus, you must define | |
| 119 all your data offsets and so on outside of the mod/emod segment. It is, | |
| 120 therefore, likely that source code targeted at other assemblers will require | |
| 121 edits to build correctly. | |
| 122 | |
| 123 </para> | |
| 124 | |
| 125 <para> | |
| 126 | |
| 127 LWLINK does not, yet, have the ability to create OS9 modules from object | |
| 128 files. | |
| 129 | |
| 130 </para> | |
| 131 </section> | |
| 132 | |
| 133 <section> | |
| 134 <title>Object Files</title> | |
| 135 <para>LWASM supports generating a proprietary object file format which is | |
| 136 described in <xref linkend="objchap">. LWLINK is then used to link these | |
| 137 object files into a final binary in any of LWLINK's supported binary | |
| 138 formats.</para> | |
| 139 | |
| 140 <para>Object files also support the concept of sections which are not valid | |
| 141 for other output types. This allows related code from each object file | |
| 142 linked to be collapsed together in the final binary.</para> | |
| 143 | |
| 144 <para> | |
| 145 Object files are very flexible in that they allow references that are not | |
| 146 known at assembly time to be resolved at link time. However, because the | |
| 147 addresses of such references are not known at assembly time, there is no way | |
| 148 for the assembler to deduce that an eight bit addressing mode is possible. | |
| 149 That means the assember will default to using sixteen bit addressing | |
| 150 whenever an external or cross-section reference is used. | |
| 151 </para> | |
| 152 | |
| 153 <para> | |
| 154 As of LWASM 2.4, it is possible to force direct page addressing for an | |
| 155 external reference. Care must be taken to ensure the resulting addresses | |
| 156 are really in the direct page since the linker does not know what the direct | |
| 157 page is supposed to be and does not emit errors for byte overflows. | |
| 158 </para> | |
| 159 | |
| 160 <para> | |
| 161 It is also possible to use external references in an eight bit immediate | |
| 162 mode instruction. In this case, only the low order eight bits will be used. | |
| 163 Again, no byte overflows will be flagged. | |
| 164 </para> | |
| 165 | |
| 166 | |
| 167 </section> | |
| 168 | |
| 169 </chapter> | |
| 170 | |
| 171 <chapter> | |
| 172 <title>LWASM</title> | |
| 173 <para> | |
| 174 The LWTOOLS assembler is called LWASM. This chapter documents the various | |
| 175 features of the assembler. It is not, however, a tutorial on 6x09 assembly | |
| 176 language programming. | |
| 177 </para> | |
| 178 | |
| 179 <section> | |
| 180 <title>Command Line Options</title> | |
| 181 <para> | |
| 182 The binary for LWASM is called "lwasm". Note that the binary is in lower | |
| 183 case. lwasm takes the following command line arguments. | |
| 184 </para> | |
| 185 | |
| 186 <variablelist> | |
| 187 | |
| 188 <varlistentry> | |
| 189 <term><option>--6309</option></term> | |
| 190 <term><option>-3</option></term> | |
| 191 <listitem> | |
| 192 <para> | |
| 193 This will cause the assembler to accept the additional instructions available | |
| 194 on the 6309 processor. This is the default mode; this option is provided for | |
| 195 completeness and to override preset command arguments. | |
| 196 </para> | |
| 197 </listitem> | |
| 198 </varlistentry> | |
| 199 | |
| 200 <varlistentry> | |
| 201 <term><option>--6809</option></term> | |
| 202 <term><option>-9</option></term> | |
| 203 <listitem> | |
| 204 <para> | |
| 205 This will cause the assembler to reject instructions that are only available | |
| 206 on the 6309 processor. | |
| 207 </para> | |
| 208 </listitem> | |
| 209 </varlistentry> | |
| 210 | |
| 211 <varlistentry> | |
| 212 <term><option>--decb</option></term> | |
| 213 <term><option>-b</option></term> | |
| 214 <listitem> | |
| 215 <para> | |
| 216 Select the DECB output format target. Equivalent to <option>--format=decb</option>. | |
| 217 </para> | |
| 218 <para>While this is the default output format currently, it is not safe to rely | |
| 219 on that fact. Future versions may have different defaults. It is also trivial | |
| 220 to modify the source code to change the default. Thus, it is recommended to specify | |
| 221 this option if you need DECB output. | |
| 222 </listitem> | |
| 223 </varlistentry> | |
| 224 | |
| 225 <varlistentry> | |
| 226 <term><option>--format=type</option></term> | |
| 227 <term><option>-f type</option></term> | |
| 228 <listitem> | |
| 229 <para> | |
| 230 Select the output format. Valid values are <option>obj</option> for the | |
| 231 object file target, <option>decb</option> for the DECB LOADM format, | |
| 232 <option>os9</option> for creating OS9 modules, and <option>raw</option> for | |
| 233 a raw binary. | |
| 234 </para> | |
| 235 </listitem> | |
| 236 </varlistentry> | |
| 237 | |
| 238 <varlistentry> | |
| 239 <term><option>--list[=file]</option></term> | |
| 240 <term><option>-l[file]</option></term> | |
| 241 <listitem> | |
| 242 <para> | |
| 243 Cause LWASM to generate a listing. If <option>file</option> is specified, | |
| 244 the listing will go to that file. Otherwise it will go to the standard output | |
|
404
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
245 stream. By default, no listing is generated. Unless <option>--symbols</option> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
246 is specified, the list will not include the symbol table. |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
247 </para> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
248 </listitem> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
249 </varlistentry> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
250 |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
251 <varlistentry> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
252 <term><option>--symbols</option></term> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
253 <term><option>-s</option></term> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
254 <listitem> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
255 <para> |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
256 Causes LWASM to generate a list of symbols when generating a listing. |
|
0324fd09c7ac
Added documentation for the --symbol option for lwasm
lost@l-w.ca
parents:
396
diff
changeset
|
257 It has no effect unless a listing is being generated. |
| 331 | 258 </para> |
| 259 </listitem> | |
| 260 </varlistentry> | |
| 261 | |
| 262 <varlistentry> | |
| 263 <term><option>--obj</option></term> | |
| 264 <listitem> | |
| 265 <para> | |
| 266 Select the proprietary object file format as the output target. | |
| 267 </para> | |
| 268 </listitem> | |
| 269 </varlistentry> | |
| 270 | |
| 271 <varlistentry> | |
| 272 <term><option>--output=FILE</option></term> | |
| 273 <term><option>-o FILE</option></term> | |
| 274 <listitem> | |
| 275 <para> | |
| 276 This option specifies the name of the output file. If not specified, the | |
| 277 default is <option>a.out</option>. | |
| 278 </para> | |
| 279 </listitem> | |
| 280 </varlistentry> | |
| 281 | |
| 282 <varlistentry> | |
| 283 <term><option>--pragma=pragma</option></term> | |
| 284 <term><option>-p pragma</option></term> | |
| 285 <listitem> | |
| 286 <para> | |
| 287 Specify assembler pragmas. Multiple pragmas are separated by commas. The | |
| 288 pragmas accepted are the same as for the PRAGMA assembler directive described | |
| 289 below. | |
| 290 </para> | |
| 291 </listitem> | |
| 292 </varlistentry> | |
| 293 | |
| 294 <varlistentry> | |
| 295 <term><option>--raw</option></term> | |
| 296 <term><option>-r</option></term> | |
| 297 <listitem> | |
| 298 <para> | |
| 299 Select raw binary as the output target. | |
| 300 </para> | |
| 301 </listitem> | |
| 302 </varlistentry> | |
| 303 | |
| 304 <varlistentry> | |
| 305 <term><option>--includedir=path</option></term> | |
| 306 <term><option>-I path</option></term> | |
| 307 <listitem> | |
| 308 <para> | |
| 309 Add <option>path</option> to the end of the include path. | |
| 310 </para> | |
| 311 </listitem> | |
| 312 </varlistentry> | |
| 313 | |
| 314 <varlistentry> | |
| 315 <term><option>--help</option></term> | |
| 316 <term><option>-?</option></term> | |
| 317 <listitem> | |
| 318 <para> | |
| 319 Present a help screen describing the command line options. | |
| 320 </para> | |
| 321 </listitem> | |
| 322 </varlistentry> | |
| 323 | |
| 324 <varlistentry> | |
| 325 <term><option>--usage</option></term> | |
| 326 <listitem> | |
| 327 <para> | |
| 328 Provide a summary of the command line options. | |
| 329 </para> | |
| 330 </listitem> | |
| 331 </varlistentry> | |
| 332 | |
| 333 <varlistentry> | |
| 334 <term><option>--version</option></term> | |
| 335 <term><option>-V</option></term> | |
| 336 <listitem> | |
| 337 <para> | |
| 338 Display the software version. | |
| 339 </para> | |
| 340 </listitem> | |
| 341 </varlistentry> | |
| 342 | |
| 343 <varlistentry> | |
| 344 <term><option>--debug</option></term> | |
| 345 <term><option>-d</option></term> | |
| 346 <listitem> | |
| 347 <para> | |
| 348 Increase the debugging level. Only really useful to people hacking on the | |
| 349 LWASM source code itself. | |
| 350 </para> | |
| 351 </listitem> | |
| 352 </varlistentry> | |
| 353 | |
| 354 </variablelist> | |
| 355 | |
| 356 </section> | |
| 357 | |
| 358 <section> | |
| 359 <title>Dialects</title> | |
| 360 <para> | |
| 361 LWASM supports all documented MC6809 instructions as defined by Motorola. | |
| 362 It also supports all known HD6309 instructions. While there is general | |
| 363 agreement on the pneumonics for most of the 6309 instructions, there is some | |
| 364 variance with the block transfer instructions. TFM for all four variations | |
| 365 seems to have gained the most traction and, thus, this is the form that is | |
| 366 recommended for LWASM. However, it also supports COPY, COPY-, IMP, EXP, | |
| 367 TFRP, TFRM, TFRS, and TFRR. It further adds COPY+ as a synomym for COPY, | |
| 368 IMPLODE for IMP, and EXPAND for EXP. | |
| 369 </para> | |
| 370 | |
| 371 <para>By default, LWASM accepts 6309 instructions. However, using the | |
| 372 <parameter>--6809</parameter> parameter, you can cause it to throw errors on | |
| 373 6309 instructions instead.</para> | |
| 374 | |
| 375 <para> | |
| 376 The standard addressing mode specifiers are supported. These are the | |
| 377 hash sign ("#") for immediate mode, the less than sign ("<") for forced | |
| 378 eight bit modes, and the greater than sign (">") for forced sixteen bit modes. | |
| 379 </para> | |
| 380 | |
| 381 <para> | |
| 382 Additionally, LWASM supports using the asterisk ("*") to indicate | |
| 383 base page addressing. This should not be used in hand-written source code, | |
| 384 however, because it is non-standard and may or may not be present in future | |
| 385 versions of LWASM. | |
| 386 </para> | |
| 387 | |
| 388 </section> | |
| 389 | |
| 390 <section> | |
| 391 <title>Source Format</title> | |
| 392 | |
| 393 <para> | |
| 394 LWASM accepts plain text files in a relatively free form. It can handle | |
| 395 lines terminated with CR, LF, CRLF, or LFCR which means it should be able | |
| 396 to assemble files on any platform on which it compiles. | |
| 397 </para> | |
| 398 <para> | |
| 399 Each line may start with a symbol. If a symbol is present, there must not | |
| 400 be any whitespace preceding it. It is legal for a line to contain nothing | |
| 401 but a symbol.</para> | |
| 402 <para> | |
| 403 The op code is separated from the symbol by whitespace. If there is | |
| 404 no symbol, there must be at least one white space character preceding it. | |
| 405 If applicable, the operand follows separated by whitespace. Following the | |
| 406 opcode and operand is an optional comment. | |
| 407 </para> | |
| 408 <para> | |
| 409 A comment can also be introduced with a * or a ;. The comment character is | |
| 410 optional for end of statement comments. However, if a symbol is the only | |
| 411 thing present on the line other than the comment, the comment character is | |
| 412 mandatory to prevent the assembler from interpreting the comment as an opcode. | |
| 413 </para> | |
| 414 | |
| 415 <para> | |
| 416 For compatibility with the output generated by some C preprocessors, LWASM | |
| 417 will also ignore lines that begin with a #. This should not be used as a general | |
| 418 comment character, however. | |
| 419 </para> | |
| 420 | |
| 421 <para> | |
| 422 The opcode is not treated case sensitively. Neither are register names in | |
| 423 the operand fields. Symbols, however, are case sensitive. | |
| 424 </para> | |
| 425 | |
| 426 <para> As of version 2.6, LWASM supports files with line numbers. If line | |
| 427 numbers are present, the line must start with a digit. The line number | |
| 428 itself must consist only of digits. The line number must then be followed | |
| 429 by either the end of the line or exactly one white space character. After | |
| 430 that white space character, the lines are interpreted exactly as above. | |
| 431 </para> | |
| 432 | |
| 433 </section> | |
| 434 | |
| 435 <section> | |
| 436 <title>Symbols</title> | |
| 437 | |
| 438 <para> | |
| 439 Symbols have no length restriction. They may contain letters, numbers, dots, | |
| 440 dollar signs, and underscores. They must start with a letter, dot, or | |
| 441 underscore. | |
| 442 </para> | |
| 443 | |
| 444 <para> | |
| 445 LWASM also supports the concept of a local symbol. A local symbol is one | |
| 446 which contains either a "?" or a "@", which can appear anywhere in the symbol. | |
| 447 The scope of a local symbol is determined by a number of factors. First, | |
| 448 each included file gets its own local symbol scope. A blank line will also | |
| 449 be considered a local scope barrier. Macros each have their own local symbol | |
| 450 scope as well (which has a side effect that you cannot use a local symbol | |
| 451 as an argument to a macro). There are other factors as well. In general, | |
| 452 a local symbol is restricted to the block of code it is defined within. | |
| 453 </para> | |
| 454 | |
| 455 <para> | |
| 456 By default, unless assembling to the os9 target, a "$" in the symbol will | |
| 457 also make it local. This can be controlled by the "dollarlocal" and | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
458 "nodollarlocal" pragmas. In the absence of a pragma to the contrary, for |
| 331 | 459 the os9 target, a "$" in the symbol will not make it considered local while |
| 460 for all other targets it will. | |
| 461 </para> | |
| 462 | |
| 463 </section> | |
| 464 | |
| 465 <section> | |
| 466 <title>Numbers and Expressions</title> | |
| 467 <para> | |
| 468 | |
| 469 Numbers can be expressed in binary, octal, decimal, or hexadecimal. Binary | |
| 470 numbers may be prefixed with a "%" symbol or suffixed with a "b" or "B". | |
| 471 Octal numbers may be prefixed with "@" or suffixed with "Q", "q", "O", or | |
| 472 "o". Hexadecimal numbers may be prefixed with "$", "0x" or "0X", or suffixed | |
| 473 with "H". No prefix or suffix is required for decimal numbers but they can | |
| 474 be prefixed with "&" if desired. Any constant which begins with a letter | |
| 475 must be expressed with the correct prefix base identifier or be prefixed | |
| 476 with a 0. Thus hexadecimal FF would have to be written either 0FFH or $FF. | |
| 477 Numbers are not case sensitive. | |
| 478 | |
| 479 </para> | |
| 480 | |
| 481 <para> A symbol may appear at any point where a number is acceptable. The | |
| 482 special symbol "*" can be used to represent the starting address of the | |
| 483 current source line within expressions. </para> | |
| 484 | |
| 485 <para>The ASCII value of a character can be included by prefixing it with a | |
| 486 single quote ('). The ASCII values of two characters can be included by | |
| 487 prefixing the characters with a quote (").</para> | |
| 488 | |
| 489 <para> | |
| 490 | |
| 491 LWASM supports the following basic binary operators: +, -, *, /, and %. | |
| 492 These represent addition, subtraction, multiplication, division, and | |
| 493 modulus. It also supports unary negation and unary 1's complement (- and ^ | |
| 494 respectively). It is also possible to use ~ for the unary 1's complement | |
| 495 operator. For completeness, a unary positive (+) is supported though it is | |
| 496 a no-op. LWASM also supports using |, &, and ^ for bitwise or, bitwise and, | |
| 497 and bitwise exclusive or respectively. | |
| 498 | |
| 499 </para> | |
| 500 | |
| 501 <para> | |
| 502 | |
| 503 Operator precedence follows the usual rules. Multiplication, division, and | |
| 504 modulus take precedence over addition and subtraction. Unary operators take | |
| 505 precedence over binary operators. Bitwise operators are lower precdence | |
| 506 than addition and subtraction. To force a specific order of evaluation, | |
| 507 parentheses can be used in the usual manner. | |
| 508 | |
| 509 </para> | |
| 510 | |
| 511 <para> | |
| 512 | |
| 513 As of LWASM 2.5, the operators && and || are recognized for boolean and and | |
| 514 boolean or respectively. They will return either 0 or 1 (false or true). | |
| 515 They have the lowest precedence of all the binary operators. | |
| 516 | |
| 517 </para> | |
| 518 | |
| 519 </section> | |
| 520 | |
| 521 <section> | |
| 522 <title>Assembler Directives</title> | |
| 523 <para> | |
| 524 Various directives can be used to control the behaviour of the | |
| 525 assembler or to include non-code/data in the resulting output. Those directives | |
| 526 that are not described in detail in other sections of this document are | |
| 527 described below. | |
| 528 </para> | |
| 529 | |
| 530 <section> | |
| 531 <title>Data Directives</title> | |
| 532 <variablelist> | |
| 533 <varlistentry><term>FCB <parameter>expr[,...]</parameter></term> | |
| 534 <term>.DB <parameter>expr[,...]</parameter></term> | |
| 535 <term>.BYTE <parameter>expr[,...]</parameter></term> | |
| 536 <listitem> | |
| 537 <para>Include one or more constant bytes (separated by commas) in the output.</para> | |
| 538 </listitem> | |
| 539 </varlistentry> | |
| 540 | |
| 541 <varlistentry> | |
| 542 <term>FDB <parameter>expr[,...]</parameter></term> | |
| 543 <term>.DW <parameter>expr[,...]</parameter></term> | |
| 544 <term>.WORD <parameter>expr[,...]</parameter></term> | |
| 545 <listitem> | |
| 546 <para>Include one or more words (separated by commas) in the output.</para> | |
| 547 </listitem> | |
| 548 </varlistentry> | |
| 549 | |
| 550 <varlistentry> | |
| 551 <term>FQB <parameter>expr[,...]</parameter></term> | |
| 552 <term>.QUAD <parameter>expr[,...]</parameter></term> | |
| 553 <term>.4BYTE <parameter>expr[,...]</parameter></term> | |
| 554 <listitem> | |
| 555 <para>Include one or more double words (separated by commas) in the output.</para> | |
| 556 </listitem> | |
| 557 </varlistentry> | |
| 558 | |
| 559 <varlistentry> | |
| 560 <term>FCC <parameter>string</parameter></term> | |
| 561 <term>.ASCII <parameter>string</parameter></term> | |
| 562 <term>.STR <parameter>string</parameter></term> | |
| 563 <listitem> | |
| 564 <para> | |
| 565 Include a string of text in the output. The first character of the operand | |
| 566 is the delimiter which must appear as the last character and cannot appear | |
| 567 within the string. The string is included with no modifications> | |
| 568 </para> | |
| 569 </listitem> | |
| 570 </varlistentry> | |
| 571 | |
| 572 <varlistentry> | |
| 573 <term>FCN <parameter>string</parameter></term> | |
| 574 <term>.ASCIZ <parameter>string</parameter></term> | |
| 575 <term>.STRZ <parameter>string</parameter></term> | |
| 576 <listitem> | |
| 577 <para> | |
| 578 Include a NUL terminated string of text in the output. The first character of | |
| 579 the operand is the delimiter which must appear as the last character and | |
| 580 cannot appear within the string. A NUL byte is automatically appended to | |
| 581 the string. | |
| 582 </para> | |
| 583 </listitem> | |
| 584 </varlistentry> | |
| 585 | |
| 586 <varlistentry> | |
| 587 <term>FCS <parameter>string</parameter></term> | |
| 588 <term>.ASCIS <parameter>string</parameter></term> | |
| 589 <term>.STRS <parameter>string</parameter></term> | |
| 590 <listitem> | |
| 591 <para> | |
| 592 Include a string of text in the output with bit 7 of the final byte set. The | |
| 593 first character of the operand is the delimiter which must appear as the last | |
| 594 character and cannot appear within the string. | |
| 595 </para> | |
| 596 </listitem> | |
| 597 </varlistentry> | |
| 598 | |
| 599 <varlistentry><term>ZMB <parameter>expr</parameter></term> | |
| 600 <listitem> | |
| 601 <para> | |
| 602 Include a number of NUL bytes in the output. The number must be fully resolvable | |
| 603 during pass 1 of assembly so no forward or external references are permitted. | |
| 604 </para> | |
| 605 </listitem> | |
| 606 </varlistentry> | |
| 607 | |
| 608 <varlistentry><term>ZMD <parameter>expr</parameter></term> | |
| 609 <listitem> | |
| 610 <para> | |
| 611 Include a number of zero words in the output. The number must be fully | |
| 612 resolvable during pass 1 of assembly so no forward or external references are | |
| 613 permitted. | |
| 614 </para> | |
| 615 </listitem> | |
| 616 </varlistentry> | |
| 617 | |
| 618 <varlistentry><term>ZMQ <parameter>expr<parameter></term> | |
| 619 <listitem> | |
| 620 <para> | |
| 621 Include a number of zero double-words in the output. The number must be fully | |
| 622 resolvable during pass 1 of assembly so no forward or external references are | |
| 623 permitted. | |
| 624 </para> | |
| 625 </listitem> | |
| 626 </varlistentry> | |
| 627 | |
| 628 <varlistentry> | |
| 629 <term>RMB <parameter>expr</parameter></term> | |
| 630 <term>.BLKB <parameter>expr</parameter></term> | |
| 631 <term>.DS <parameter>expr</parameter></term> | |
| 632 <term>.RS <parameter>expr</parameter></term> | |
| 633 <listitem> | |
| 634 <para> | |
| 635 Reserve a number of bytes in the output. The number must be fully resolvable | |
| 636 during pass 1 of assembly so no forward or external references are permitted. | |
| 637 The value of the bytes is undefined. | |
| 638 </para> | |
| 639 </listitem> | |
| 640 </varlistentry> | |
| 641 | |
| 642 <varlistentry><term>RMD <parameter>expr</parameter></term> | |
| 643 <listitem> | |
| 644 <para> | |
| 645 Reserve a number of words in the output. The number must be fully | |
| 646 resolvable during pass 1 of assembly so no forward or external references are | |
| 647 permitted. The value of the words is undefined. | |
| 648 </para> | |
| 649 </listitem> | |
| 650 </varlistentry> | |
| 651 | |
| 652 <varlistentry><term>RMQ <parameter>expr</parameter></term> | |
| 653 <listitem> | |
| 654 <para> | |
| 655 Reserve a number of double-words in the output. The number must be fully | |
| 656 resolvable during pass 1 of assembly so no forward or external references are | |
| 657 permitted. The value of the double-words is undefined. | |
| 658 </para> | |
| 659 </listitem> | |
| 660 </varlistentry> | |
| 661 | |
| 662 <varlistentry> | |
| 663 <term>INCLUDEBIN <parameter>filename</parameter></term> | |
| 664 <listitem> | |
| 665 <para> | |
| 666 Treat the contents of <parameter>filename</parameter> as a string of bytes to | |
| 667 be included literally at the current assembly point. This has the same effect | |
| 668 as converting the file contents to a series of FCB statements and including | |
| 669 those at the current assembly point. | |
| 670 </para> | |
| 671 | |
| 672 <para> If <parameter>filename</parameter> beings with a /, the file name | |
| 673 will be taken as absolute. Otherwise, the current directory will be | |
| 674 searched followed by the search path in the order specified.</para> | |
| 675 | |
| 676 <para> Please note that absolute path detection including drive letters will | |
| 677 not function correctly on Windows platforms. Non-absolute inclusion will | |
| 678 work, however.</para> | |
| 679 | |
| 680 </listitem> | |
| 681 </varlistentry> | |
| 682 | |
| 683 </variablelist> | |
| 684 | |
| 685 </section> | |
| 686 | |
| 687 <section> | |
| 688 <title>Address Definition</title> | |
| 689 <para>The directives in this section all control the addresses of symbols | |
| 690 or the assembly process itself.</para> | |
| 691 | |
| 692 <variablelist> | |
| 693 <varlistentry><term>ORG <parameter>expr</parameter></term> | |
| 694 <listitem> | |
| 695 <para>Set the assembly address. The address must be fully resolvable on the | |
| 696 first pass so no external or forward references are permitted. ORG is not | |
| 697 permitted within sections when outputting to object files. For the DECB | |
| 698 target, each ORG directive after which output is generated will cause | |
| 699 a new preamble to be output. ORG is only used to determine the addresses | |
| 700 of symbols when the raw target is used. | |
| 701 </para> | |
| 702 </listitem> | |
| 703 </varlistentry> | |
| 704 | |
| 705 <varlistentry> | |
| 706 <term><parameter>sym</parameter> EQU <parameter>expr</parameter></term> | |
| 707 <term><parameter>sym</parameter> = <parameter>expr</parameter></term> | |
| 708 <listitem> | |
| 709 <para>Define the value of <parameter>sym</parameter> to be <parameter>expr</parameter>. | |
| 710 </listitem> | |
| 711 </varlistentry> | |
| 712 | |
| 713 <varlistentry> | |
| 714 <term><parameter>sym</parameter> SET <parameter>expr</parameter></term> | |
| 715 <listitem> | |
| 716 <para>Define the value of <parameter>sym</parameter> to be <parameter>expr</parameter>. | |
| 717 Unlike EQU, SET permits symbols to be defined multiple times as long as SET | |
| 718 is used for all instances. Use of the symbol before the first SET statement | |
| 719 that sets its value is undefined.</para> | |
| 720 </listitem> | |
| 721 </varlistentry> | |
| 722 | |
| 723 <varlistentry> | |
| 724 <term>SETDP <parameter>expr</parameter></term> | |
| 725 <listitem> | |
| 726 <para>Inform the assembler that it can assume the DP register contains | |
| 727 <parameter>expr</parameter>. This directive is only advice to the assembler | |
| 728 to determine whether an address is in the direct page and has no effect | |
| 729 on the contents of the DP register. The value must be fully resolved during | |
| 730 the first assembly pass because it affects the sizes of subsequent instructions. | |
| 731 </para> | |
| 732 <para>This directive has no effect in the object file target. | |
| 733 </para> | |
| 734 </listitem> | |
| 735 </varlistentry> | |
| 736 | |
| 737 <varlistentry> | |
| 738 <term>ALIGN <parameter>expr</parameter>[,<parameter>value</parameter>]</term> | |
| 739 <listitem> | |
| 740 | |
| 741 <para>Force the current assembly address to be a multiple of | |
| 742 <parameter>expr</parameter>. If <parameter>value</parameter> is not | |
| 743 specified, a series of NUL bytes is output to force the alignment, if | |
| 744 required. Otherwise, the low order 8 bits of <parameter>value</parameter> | |
| 745 will be used as the fill. The alignment value must be fully resolved on the | |
| 746 first pass because it affects the addresses of subsquent instructions. | |
| 747 However, <parameter>value</parameter> may include forward references; as | |
| 748 long as it resolves to a constant for the second pass, the value will be | |
| 749 accepted.</para> | |
| 750 | |
| 751 <para>Unless <parameter>value</parameter> is specified as something like $12, | |
| 752 this directive is not suitable for inclusion in the middle of actual code. | |
| 753 The default padding value is $00 which is intended to be used within data | |
| 754 blocks. </para> | |
| 755 | |
| 756 </listitem> | |
| 757 </varlistentry> | |
| 758 | |
| 759 </variablelist> | |
| 760 | |
| 761 </section> | |
| 762 | |
| 763 <section> | |
| 764 <title>Conditional Assembly</title> | |
| 765 <para> | |
| 766 Portions of the source code can be excluded or included based on conditions | |
| 767 known at assembly time. Conditionals can be nested arbitrarily deeply. The | |
| 768 directives associated with conditional assembly are described in this section. | |
| 769 </para> | |
| 770 <para>All conditionals must be fully bracketed. That is, every conditional | |
| 771 statement must eventually be followed by an ENDC at the same level of nesting. | |
| 772 </para> | |
| 773 <para>Conditional expressions are only evaluated on the first assembly pass. | |
| 774 It is not possible to game the assembly process by having a conditional | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
775 change its value between assembly passes. Due to the underlying architecture |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
776 of LWASM, there is no possible utility to IFP1 and IFP2, nor can they, as of LWASM 3.0, actually |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
777 be implemented meaningfully. Thus there is not and never will |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
778 be any equivalent of IFP1 or IFP2 as provided by other assemblers. Use of those opcodes |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
779 will throw a warning and be ignored.</para> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
780 |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
781 <para>It is important to note that if a conditional does not resolve to a constant |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
782 during the first parsing pass, an error will be thrown. This is unavoidable because the assembler |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
783 must make a decision about which source to include and which source to exclude at this stage. |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
784 Thus, expressions that work normally elsewhere will not work for conditions.</para> |
| 331 | 785 |
| 786 <variablelist> | |
| 787 <varlistentry> | |
| 788 <term>IFEQ <parameter>expr</parameter></term> | |
| 789 <listitem> | |
| 790 <para>If <parameter>expr</parameter> evaluates to zero, the conditional | |
| 791 will be considered true. | |
| 792 </para> | |
| 793 </listitem> | |
| 794 </varlistentry> | |
| 795 | |
| 796 <varlistentry> | |
| 797 <term>IFNE <parameter>expr</parameter></term> | |
| 798 <term>IF <parameter>expr</parameter></term> | |
| 799 <listitem> | |
| 800 <para>If <parameter>expr</parameter> evaluates to a non-zero value, the conditional | |
| 801 will be considered true. | |
| 802 </para> | |
| 803 </listitem> | |
| 804 </varlistentry> | |
| 805 | |
| 806 <varlistentry> | |
| 807 <term>IFGT <parameter>expr</parameter></term> | |
| 808 <listitem> | |
| 809 <para>If <parameter>expr</parameter> evaluates to a value greater than zero, the conditional | |
| 810 will be considered true. | |
| 811 </para> | |
| 812 </listitem> | |
| 813 </varlistentry> | |
| 814 | |
| 815 <varlistentry> | |
| 816 <term>IFGE <parameter>expr</parameter></term> | |
| 817 <listitem> | |
| 818 <para>If <parameter>expr</parameter> evaluates to a value greater than or equal to zero, the conditional | |
| 819 will be considered true. | |
| 820 </para> | |
| 821 </listitem> | |
| 822 </varlistentry> | |
| 823 | |
| 824 <varlistentry> | |
| 825 <term>IFLT <parameter>expr</parameter></term> | |
| 826 <listitem> | |
| 827 <para>If <parameter>expr</parameter> evaluates to a value less than zero, the conditional | |
| 828 will be considered true. | |
| 829 </para> | |
| 830 </listitem> | |
| 831 </varlistentry> | |
| 832 | |
| 833 <varlistentry> | |
| 834 <term>IFLE <parameter>expr</parameter></term> | |
| 835 <listitem> | |
| 836 <para>If <parameter>expr</parameter> evaluates to a value less than or equal to zero , the conditional | |
| 837 will be considered true. | |
| 838 </para> | |
| 839 </listitem> | |
| 840 </varlistentry> | |
| 841 | |
| 842 <varlistentry> | |
| 843 <term>IFDEF <parameter>sym</parameter></term> | |
| 844 <listitem> | |
| 845 <para>If <parameter>sym</parameter> is defined at this point in the assembly | |
| 846 process, the conditional | |
| 847 will be considered true. | |
| 848 </para> | |
| 849 </listitem> | |
| 850 </varlistentry> | |
| 851 | |
| 852 <varlistentry> | |
| 853 <term>IFNDEF <parameter>sym</parameter></term> | |
| 854 <listitem> | |
| 855 <para>If <parameter>sym</parameter> is not defined at this point in the assembly | |
| 856 process, the conditional | |
| 857 will be considered true. | |
| 858 </para> | |
| 859 </listitem> | |
| 860 </varlistentry> | |
| 861 | |
| 862 <varlistentry> | |
| 863 <term>ELSE</term> | |
| 864 <listitem> | |
| 865 <para> | |
| 866 If the preceding conditional at the same level of nesting was false, the | |
| 867 statements following will be assembled. If the preceding conditional at | |
| 868 the same level was true, the statements following will not be assembled. | |
| 869 Note that the preceding conditional might have been another ELSE statement | |
| 870 although this behaviour is not guaranteed to be supported in future versions | |
| 871 of LWASM. | |
| 872 </para> | |
| 873 </listitem> | |
| 874 | |
| 875 <varlistentry> | |
| 876 <term>ENDC</term> | |
| 877 <listitem> | |
| 878 <para> | |
| 879 This directive marks the end of a conditional construct. Every conditional | |
| 880 construct must end with an ENDC directive. | |
| 881 </para> | |
| 882 </listitem> | |
| 883 </varlistentry> | |
| 884 | |
| 885 </variablelist> | |
| 886 </section> | |
| 887 | |
| 888 <section> | |
| 889 <title>OS9 Target Directives</title> | |
| 890 | |
| 891 <para>This section includes directives that apply solely to the OS9 | |
| 892 target.</para> | |
| 893 | |
| 894 <variablelist> | |
| 895 | |
| 896 <varlistentry> | |
| 897 <term>OS9 <parameter>syscall</parameter></term> | |
| 898 <listitem> | |
| 899 <para> | |
| 900 | |
| 901 This directive generates a call to the specified system call. <parameter>syscall</parameter> may be an arbitrary expression. | |
| 902 | |
| 903 </para> | |
| 904 </listitem> | |
| 905 </varlistentry> | |
| 906 | |
| 907 <varlistentry> | |
| 908 <term>MOD <parameter>size</parameter>,<parameter>name</parameter>,<parameter>type</parameter>,<parameter>flags</parameter>,<parameter>execoff</parameter>,<parameter>datasize</parameter></term> | |
| 909 <listitem> | |
| 910 <para> | |
| 911 | |
| 912 This tells LWASM that the beginning of the actual module is here. It will | |
| 913 generate a module header based on the parameters specified. It will also | |
| 914 begin calcuating the module CRC. | |
| 915 | |
| 916 </para> | |
| 917 | |
| 918 <para> | |
| 919 | |
| 920 The precise meaning of the various parameters is beyond the scope of this | |
| 921 document since it is not a tutorial on OS9 module programming. | |
| 922 | |
| 923 </para> | |
| 924 | |
| 925 </listitem> | |
| 926 </varlistentry> | |
| 927 | |
| 928 <varlistentry> | |
| 929 <term>EMOD</term> | |
| 930 <listitem> | |
| 931 <para> | |
| 932 | |
| 933 This marks the end of a module and causes LWASM to emit the calculated CRC | |
| 934 for the module. | |
| 935 | |
| 936 </para> | |
| 937 </varlistentry> | |
| 938 | |
| 939 </variablelist> | |
| 940 </section> | |
| 941 | |
| 942 <section> | |
| 943 <title>Miscelaneous Directives</title> | |
| 944 | |
| 945 <para>This section includes directives that do not fit into the other | |
| 946 categories.</para> | |
| 947 | |
| 948 <variablelist> | |
| 949 | |
| 950 <varlistentry> | |
| 951 <term>INCLUDE <parameter>filename</parameter></term> | |
| 952 <term>USE <parameter>filename</parameter></term> | |
| 953 | |
| 954 <listitem> <para> Include the contents of <parameter>filename</parameter> at | |
| 955 this point in the assembly as though it were a part of the file currently | |
| 956 being processed. Note that if whitespace appears in the name of the file, | |
| 957 you must enclose <parameter>filename</parameter> in quotes. | |
| 958 </para> | |
| 959 | |
| 960 <para> | |
| 961 Note that the USE variation is provided only for compatibility with other | |
| 962 assemblers. It is recommended to use the INCLUDE variation.</para> | |
| 963 | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
964 <para>If <parameter>filename</parameter> begins with a "/", it is |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
965 interpreted as an absolute path. If it does not, the search path will be used |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
966 to find the file. First, the directory containing the file that contains this |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
967 directive. (Includes within an included file are relative to the included file, |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
968 not the file that included it.) If the file is not found there, the include path |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
969 is searched. If it is still not found, an error will be thrown. Note that the |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
970 current directory as understood by your shell or operating system is not searched. |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
971 </para> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
972 |
| 331 | 973 </listitem> |
| 974 </varlistentry> | |
| 975 | |
| 976 <varlistentry> | |
| 977 <term>END <parameter>[expr]</parameter></term> | |
| 978 <listitem> | |
| 979 <para> | |
| 980 This directive causes the assembler to stop assembling immediately as though | |
| 981 it ran out of input. For the DECB target only, <parameter>expr</parameter> | |
| 982 can be used to set the execution address of the resulting binary. For all | |
| 983 other targets, specifying <parameter>expr</parameter> will cause an error. | |
| 984 </para> | |
| 985 </listitem> | |
| 986 </varlistentry> | |
| 987 | |
| 988 <varlistentry> | |
| 989 <term>ERROR <parameter>string</parameter></term> | |
| 990 <listitem> | |
| 991 <para> | |
| 992 Causes a custom error message to be printed at this line. This will cause | |
| 993 assembly to fail. This directive is most useful inside conditional constructs | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
994 to cause assembly to fail if some condition that is known bad happens. Everything |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
995 from the directive to the end of the line is considered the error message. |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
996 </para> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
997 </listitem> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
998 </varlistentry> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
999 |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1000 <varlistentry> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1001 <term>WARNING <parameter>string</parameter></term> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1002 <listitem> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1003 <para> |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1004 Causes a custom warning message to be printed at this line. This will not cause |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1005 assembly to fail. This directive is most useful inside conditional constructs |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1006 or include files to alert the programmer to a deprecated feature being used |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1007 or some other condition that may cause trouble later, but which may, in fact, |
|
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1008 not cause any trouble. |
| 331 | 1009 </para> |
| 1010 </listitem> | |
| 1011 </varlistentry> | |
| 1012 | |
| 1013 <varlistentry> | |
| 1014 <term>.MODULE <parameter>string</parameter></term> | |
| 1015 <listitem> | |
| 1016 <para> | |
| 1017 This directive is ignored for most output targets. If the output target | |
| 1018 supports encoding a module name into it, <parameter>string</parameter> | |
| 1019 will be used as the module name. | |
| 1020 </para> | |
| 1021 <para> | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1022 As of version 3.0, no supported output targets support this directive. |
| 331 | 1023 </para> |
| 1024 </listitem> | |
| 1025 </varlistentry> | |
| 1026 | |
| 1027 </variablelist> | |
| 1028 </section> | |
| 1029 | |
| 1030 </section> | |
| 1031 | |
| 1032 <section> | |
| 1033 <title>Macros</title> | |
| 1034 <para> | |
| 1035 LWASM is a macro assembler. A macro is simply a name that stands in for a | |
| 1036 series of instructions. Once a macro is defined, it is used like any other | |
| 1037 assembler directive. Defining a macro can be considered equivalent to adding | |
| 1038 additional assembler directives. | |
| 1039 </para> | |
| 1040 <para>Macros may accept parameters. These parameters are referenced within | |
| 1041 a macro by the a backslash ("\") followed by a digit 1 through 9 for the first | |
| 1042 through ninth parameters. They may also be referenced by enclosing the | |
| 1043 decimal parameter number in braces ("{num}"). These parameter references | |
| 1044 are replaced with the verbatim text of the parameter passed to the macro. A | |
| 1045 reference to a non-existent parameter will be replaced by an empty string. | |
| 1046 Macro parameters are expanded everywhere on each source line. That means | |
| 1047 the parameter to a macro could be used as a symbol or it could even appear | |
| 1048 in a comment or could cause an entire source line to be commented out | |
| 1049 when the macro is expanded. | |
| 1050 </para> | |
| 1051 <para> | |
| 1052 Parameters passed to a macro are separated by commas and the parameter list | |
| 1053 is terminated by any whitespace. This means that neither a comma nor whitespace | |
| 1054 may be included in a macro parameter. | |
| 1055 </para> | |
| 1056 <para> | |
| 1057 Macro expansion is done recursively. That is, within a macro, macros are | |
| 1058 expanded. This can lead to infinite loops in macro expansion. If the assembler | |
| 1059 hangs for a long time while assembling a file that uses macros, this may be | |
| 1060 the reason.</para> | |
| 1061 | |
| 1062 <para>Each macro expansion receives its own local symbol context which is not | |
| 1063 inherited by any macros called by it nor is it inherited from the context | |
| 1064 the macro was instantiated in. That means it is possible to use local symbols | |
| 1065 within macros without having them collide with symbols in other macros or | |
| 1066 outside the macro itself. However, this also means that using a local symbol | |
| 1067 as a parameter to a macro, while legal, will not do what it would seem to do | |
| 1068 as it will result in looking up the local symbol in the macro's symbol context | |
| 1069 rather than the enclosing context where it came from, likely yielding either | |
| 1070 an undefined symbol error or bizarre assembly results. | |
| 1071 </para> | |
| 1072 <para> | |
| 1073 Note that there is no way to define a macro as local to a symbol context. All | |
| 1074 macros are part of the global macro namespace. However, macros have a separate | |
| 1075 namespace from symbols so it is possible to have a symbol with the same name | |
| 1076 as a macro. | |
| 1077 </para> | |
| 1078 | |
| 1079 <para> | |
| 1080 Macros are defined only during the first pass. Macro expansion also | |
| 1081 only occurs during the first pass. On the second pass, the macro | |
| 1082 definition is simply ignored. Macros must be defined before they are used. | |
| 1083 </para> | |
| 1084 | |
| 1085 <para>The following directives are used when defining macros.</para> | |
| 1086 | |
| 1087 <variablelist> | |
| 1088 <varlistentry> | |
| 1089 <term><parameter>macroname</parameter> MACRO</term> | |
| 1090 <listitem> | |
| 1091 <para>This directive is used to being the definition of a macro called | |
| 1092 <parameter>macroname</parameter>. If <parameter>macroname</parameter> already | |
| 1093 exists, it is considered an error. Attempting to define a macro within a | |
| 1094 macro is undefined. It may work and it may not so the behaviour should not | |
| 1095 be relied upon. | |
| 1096 </para> | |
| 1097 </listitem> | |
| 1098 </varlistentry> | |
| 1099 | |
| 1100 <varlistentry> | |
| 1101 <term>ENDM</term> | |
| 1102 <listitem> | |
| 1103 <para> | |
| 1104 This directive indicates the end of the macro currently being defined. It | |
| 1105 causes the assembler to resume interpreting source lines as normal. | |
| 1106 </para> | |
| 1107 </listitem> | |
| 1108 </variablelist> | |
| 1109 | |
| 1110 </section> | |
| 1111 | |
| 1112 <section> | |
| 1113 <title>Structures</title> | |
| 1114 <para> | |
| 1115 | |
| 1116 Structures are used to group related data in a fixed structure. A structure | |
| 1117 consists a number of fields, defined in sequential order and which take up | |
| 1118 specified size. The assembler does not enforce any means of access within a | |
| 1119 structure; it assumes that whatever you are doing, you intended to do. | |
| 1120 There are two pseudo ops that are used for defining structures. | |
| 1121 | |
| 1122 </para> | |
| 1123 | |
| 1124 <variablelist> | |
| 1125 <varlistentry> | |
| 1126 <term><parameter>structname</parameter> STRUCT</term> | |
| 1127 <listitem> | |
| 1128 <para> | |
| 1129 | |
| 1130 This directive is used to begin the definition of a structure with name | |
| 1131 <parameter>structname</parameter>. Subsequent statements all form part of | |
| 1132 the structure definition until the end of the structure is declared. | |
| 1133 | |
| 1134 </para> | |
| 1135 </listitem> | |
| 1136 </varlistentry> | |
| 1137 <varlistentry> | |
| 1138 <term>ENDSTRUCT</term> | |
| 1139 <listitem> | |
| 1140 <para> | |
| 1141 This directive ends the definition of the structure. | |
| 1142 </para> | |
| 1143 </listitem> | |
| 1144 </varlistentry> | |
| 1145 </variablelist> | |
| 1146 | |
| 1147 <para> | |
| 1148 | |
| 1149 Within a structure definition, only reservation pseudo ops are permitted. | |
| 1150 Anything else will cause an assembly error. | |
| 1151 </para> | |
| 1152 | |
| 1153 <para> Once a structure is defined, you can reserve an area of memory in the | |
| 1154 same structure by using the structure name as the opcode. Structures can | |
| 1155 also contain fields that are themselves structures. See the example | |
| 1156 below.</para> | |
| 1157 | |
| 1158 <programlisting> | |
| 1159 tstruct2 STRUCT | |
| 1160 f1 rmb 1 | |
| 1161 f2 rmb 1 | |
| 1162 ENDSTRUCT | |
| 1163 | |
| 1164 tstruct STRUCT | |
| 1165 field1 rmb 2 | |
| 1166 field2 rmb 3 | |
| 1167 field3 tstruct2 | |
| 1168 ENDSTRUCT | |
| 1169 | |
| 1170 ORG $2000 | |
| 1171 var1 tstruct | |
| 1172 var2 tstruct2 | |
| 1173 </programlisting> | |
| 1174 | |
| 1175 <para>Fields are referenced using a dot (.) as a separator. To refer to the | |
| 1176 generic offset within a structure, use the structure name to the left of the | |
| 1177 dot. If referring to a field within an actual variable, use the variable's | |
| 1178 symbol name to the left of the dot.</para> | |
| 1179 | |
| 1180 <para>You can also refer to the actual size of a structure (or a variable | |
| 1181 declared as a structure) using the special symbol sizeof{structname} where | |
| 1182 structname will be the name of the structure or the name of the | |
| 1183 variable.</para> | |
| 1184 | |
| 1185 <para>Essentially, structures are a shortcut for defining a vast number of | |
| 1186 symbols. When a structure is defined, the assembler creates symbols for the | |
| 1187 various fields in the form structname.fieldname as well as the appropriate | |
| 1188 sizeof{structname} symbol. When a variable is declared as a structure, the | |
| 1189 assembler does the same thing using the name of the variable. You will see | |
| 1190 these symbols in the symbol table when the assembler is instructed to | |
| 1191 provide a listing. For instance, the above listing will create the | |
| 1192 following symbols (symbol values in parentheses): tstruct2.f1 (0), | |
| 1193 tstruct2.f2 (1), sizeof{tstruct2} (2), tstruct.field1 (0), tstruct.field2 | |
| 1194 (2), tstruct.field3 (5), tstruct.field3.f1 (5), tstruct.field3.f2 (6), | |
| 1195 sizeof{tstruct.field3} (2), sizeof{tstruct} (7), var1 {$2000}, var1.field1 | |
| 1196 {$2000}, var1.field2 {$2002}, var1.field3 {$2005}, var1.field3.f1 {$2005}, | |
| 1197 var1.field3.f2 {$2006}, sizeof(var1.field3} (2), sizeof{var1} (7), var2 | |
| 1198 ($2007), var2.f1 ($2007), var2.f2 ($2008), sizeof{var2} (2). </para> | |
| 1199 | |
| 1200 </section> | |
| 1201 | |
| 1202 <section> | |
| 1203 <title>Object Files and Sections</title> | |
| 1204 <para> | |
| 1205 The object file target is very useful for large project because it allows | |
| 1206 multiple files to be assembled independently and then linked into the final | |
| 1207 binary at a later time. It allows only the small portion of the project | |
| 1208 that was modified to be re-assembled rather than requiring the entire set | |
| 1209 of source code to be available to the assembler in a single assembly process. | |
| 1210 This can be particularly important if there are a large number of macros, | |
| 1211 symbol definitions, or other metadata that uses resources at assembly time. | |
| 1212 By far the largest benefit, however, is keeping the source files small enough | |
| 1213 for a mere mortal to find things in them. | |
| 1214 </para> | |
| 1215 | |
| 1216 <para> | |
| 1217 With multi-file projects, there needs to be a means of resolving references to | |
| 1218 symbols in other source files. These are known as external references. The | |
| 1219 addresses of these symbols cannot be known until the linker joins all the | |
| 1220 object files into a single binary. This means that the assembler must be | |
| 1221 able to output the object code without knowing the value of the symbol. This | |
| 1222 places some restrictions on the code generated by the assembler. For | |
| 1223 example, the assembler cannot generate direct page addressing for instructions | |
| 1224 that reference external symbols because the address of the symbol may not | |
| 1225 be in the direct page. Similarly, relative branches and PC relative addressing | |
| 1226 cannot be used in their eight bit forms. Everything that must be resolved | |
| 1227 by the linker must be assembled to use the largest address size possible to | |
| 1228 allow the linker to fill in the correct value at link time. Note that the | |
| 1229 same problem applies to absolute address references as well, even those in | |
| 1230 the same source file, because the address is not known until link time. | |
| 1231 </para> | |
| 1232 | |
| 1233 <para> | |
| 1234 It is often desired in multi-file projects to have code of various types grouped | |
| 1235 together in the final binary generated by the linker as well. The same applies | |
| 1236 to data. In order for the linker to do that, the bits that are to be grouped | |
| 1237 must be tagged in some manner. This is where the concept of sections comes in. | |
| 1238 Each chunk of code or data is part of a section in the object file. Then, | |
| 1239 when the linker reads all the object files, it coalesces all sections of the | |
| 1240 same name into a single section and then considers it as a unit. | |
| 1241 </para> | |
| 1242 | |
| 1243 <para> | |
| 1244 The existence of sections, however, raises a problem for symbols even | |
| 1245 within the same source file. Thus, the assembler must treat symbols from | |
| 1246 different sections within the same source file in the same manner as external | |
| 1247 symbols. That is, it must leave them for the linker to resolve at link time, | |
| 1248 with all the limitations that entails. | |
| 1249 </para> | |
| 1250 | |
| 1251 <para> | |
| 1252 In the object file target mode, LWASM requires all source lines that | |
| 1253 cause bytes to be output to be inside a section. Any directives that do | |
| 1254 not cause any bytes to be output can appear outside of a section. This includes | |
| 1255 such things as EQU or RMB. Even ORG can appear outside a section. ORG, however, | |
| 1256 makes no sense within a section because it is the linker that determines | |
| 1257 the starting address of the section's code, not the assembler. | |
| 1258 </para> | |
| 1259 | |
| 1260 <para> | |
| 1261 All symbols defined globally in the assembly process are local to the | |
| 1262 source file and cannot be exported. All symbols defined within a section are | |
| 1263 considered local to the source file unless otherwise explicitly exported. | |
| 1264 Symbols referenced from external source files must be declared external, | |
| 1265 either explicitly or by asking the assembler to assume that all undefined | |
| 1266 symbols are external. | |
| 1267 </para> | |
| 1268 | |
| 1269 <para> | |
| 1270 It is often handy to define a number of memory addresses that will be | |
| 1271 used for data at run-time but which need not be included in the binary file. | |
| 1272 These memory addresses are not initialized until run-time, either by the | |
| 1273 program itself or by the program loader, depending on the operating environment. | |
| 1274 Such sections are often known as BSS sections. LWASM supports generating | |
| 1275 sections with a BSS attribute set which causes the section definition including | |
| 1276 symbols exported from that section and those symbols required to resolve | |
| 1277 references from the local file, but with no actual code in the object file. | |
| 1278 It is illegal for any source lines within a BSS flagged section to cause any | |
| 1279 bytes to be output. | |
| 1280 </para> | |
| 1281 | |
| 1282 <para>The following directives apply to section handling.</para> | |
| 1283 | |
| 1284 <variablelist> | |
| 1285 <varlistentry> | |
| 1286 <term>SECTION <parameter>name[,flags]</parameter></term> | |
| 1287 <term>SECT <parameter>name[,flags]</parameter></term> | |
| 1288 <term>.AREA <parameter>name[,flags]</parameter></term> | |
| 1289 <listitem> | |
| 1290 <para> | |
| 1291 Instructs the assembler that the code following this directive is to be | |
| 1292 considered part of the section <parameter>name</parameter>. A section name | |
| 1293 may appear multiple times in which case it is as though all the code from | |
| 1294 all the instances of that section appeared adjacent within the source file. | |
| 1295 However, <parameter>flags</parameter> may only be specified on the first | |
| 1296 instance of the section. | |
| 1297 </para> | |
| 1298 <para>There is a single flag supported in <parameter>flags</parameter>. The | |
| 1299 flag <parameter>bss</parameter> will cause the section to be treated as a BSS | |
| 1300 section and, thus, no code will be included in the object file nor will any | |
| 1301 bytes be permitted to be output.</para> | |
| 1302 <para> | |
| 1303 If the section name is "bss" or ".bss" in any combination of upper and | |
| 1304 lower case, the section is assumed to be a BSS section. In that case, | |
| 1305 the flag <parameter>!bss</parameter> can be used to override this assumption. | |
| 1306 </para> | |
| 1307 <para> | |
| 1308 If assembly is already happening within a section, the section is implicitly | |
| 1309 ended and the new section started. This is not considered an error although | |
| 1310 it is recommended that all sections be explicitly closed. | |
| 1311 </para> | |
| 1312 </listitem> | |
| 1313 </varlistentry> | |
| 1314 | |
| 1315 <varlistentry> | |
| 1316 <term>ENDSECTION</term> | |
| 1317 <term>ENDSECT</term> | |
| 1318 <term>ENDS</term> | |
| 1319 <listitem> | |
| 1320 <para> | |
| 1321 This directive ends the current section. This puts assembly outside of any | |
| 1322 sections until the next SECTION directive. | |
| 1323 </listitem> | |
| 1324 </varlistentry> | |
| 1325 | |
| 1326 <varlistentry> | |
| 1327 <term><parameter>sym</parameter> EXTERN</term> | |
| 1328 <term><parameter>sym</parameter> EXTERNAL</term> | |
| 1329 <term><parameter>sym</parameter> IMPORT</term> | |
| 1330 <listitem> | |
| 1331 <para> | |
| 1332 This directive defines <parameter>sym</parameter> as an external symbol. | |
| 1333 This directive may occur at any point in the source code. EXTERN definitions | |
| 1334 are resolved on the first pass so an EXTERN definition anywhere in the | |
| 1335 source file is valid for the entire file. The use of this directive is | |
| 1336 optional when the assembler is instructed to assume that all undefined | |
| 1337 symbols are external. In fact, in that mode, if the symbol is referenced | |
| 1338 before the EXTERN directive, an error will occur. | |
| 1339 </para> | |
| 1340 </listitem> | |
| 1341 </varlistentry> | |
| 1342 | |
| 1343 <varlistentry> | |
| 1344 <term><parameter>sym</parameter> EXPORT</term> | |
| 1345 <term><parameter>sym</parameter> .GLOBL</term> | |
| 1346 | |
| 1347 <term>EXPORT <parameter>sym</parameter></term> | |
| 1348 <term>.GLOBL <parameter>sym</parameter></term> | |
| 1349 | |
| 1350 <listitem> | |
| 1351 <para> | |
| 1352 This directive defines <parameter>sym</parameter> as an exported symbol. | |
| 1353 This directive may occur at any point in the source code, even before the | |
| 1354 definition of the exported symbol. | |
| 1355 </para> | |
| 1356 <para> | |
| 1357 Note that <parameter>sym</parameter> may appear as the operand or as the | |
| 1358 statement's symbol. If there is a symbol on the statement, that will | |
| 1359 take precedence over any operand that is present. | |
| 1360 </para> | |
| 1361 </listitem> | |
| 1362 | |
| 1363 </varlistentry> | |
| 1364 | |
| 1365 <varlistentry> | |
|
396
62cb50c50976
Cosmetic updates to documentation; added warning pseudo op
lost@l-w.ca
parents:
331
diff
changeset
|
1366 <term><parameter>sym</parameter> EXTDEP</term> |
| 331 | 1367 <listitem> |
| 1368 | |
| 1369 <para>This directive forces an external dependency on | |
| 1370 <parameter>sym</parameter>, even if it is never referenced anywhere else in | |
| 1371 this file.</para> | |
| 1372 | |
| 1373 </listitem> | |
| 1374 </varlistentry> | |
| 1375 </variablelist> | |
| 1376 | |
| 1377 </section> | |
| 1378 | |
| 1379 <section> | |
| 1380 <title>Assembler Modes and Pragmas</title> | |
| 1381 <para> | |
| 1382 There are a number of options that affect the way assembly is performed. | |
| 1383 Some of these options can only be specified on the command line because | |
| 1384 they determine something absolute about the assembly process. These include | |
| 1385 such things as the output target. Other things may be switchable during | |
| 1386 the assembly process. These are known as pragmas and are, by definition, | |
| 1387 not portable between assemblers. | |
| 1388 </para> | |
| 1389 | |
| 1390 <para>LWASM supports a number of pragmas that affect code generation or | |
| 1391 otherwise affect the behaviour of the assembler. These may be specified by | |
| 1392 way of a command line option or by assembler directives. The directives | |
| 1393 are as follows. | |
| 1394 </para> | |
| 1395 | |
| 1396 <variablelist> | |
| 1397 <varlistentry> | |
| 1398 <term>PRAGMA <parameter>pragma[,...]</parameter></term> | |
| 1399 <listitem> | |
| 1400 <para> | |
| 1401 Specifies that the assembler should bring into force all <parameter>pragma</parameter>s | |
| 1402 specified. Any unrecognized pragma will cause an assembly error. The new | |
| 1403 pragmas will take effect immediately. This directive should be used when | |
| 1404 the program will assemble incorrectly if the pragma is ignored or not supported. | |
| 1405 </para> | |
| 1406 </listitem> | |
| 1407 </varlistentry> | |
| 1408 | |
| 1409 <varlistentry> | |
| 1410 <term>*PRAGMA <parameter>pragma[,...]</parameter></term> | |
| 1411 <listitem> | |
| 1412 <para> | |
| 1413 This is identical to the PRAGMA directive except no error will occur with | |
| 1414 unrecognized or unsupported pragmas. This directive, by virtue of starting | |
| 1415 with a comment character, will also be ignored by assemblers that do not | |
| 1416 support this directive. Use this variation if the pragma is not required | |
| 1417 for correct functioning of the code. | |
| 1418 </para> | |
| 1419 </listitem> | |
| 1420 </varlistentry> | |
| 1421 </variablelist> | |
| 1422 | |
| 1423 <para>Each pragma supported has a positive version and a negative version. | |
| 1424 The positive version enables the pragma while the negative version disables | |
| 1425 it. The negatitve version is simply the positive version with "no" prefixed | |
| 1426 to it. For instance, "pragma" vs. "nopragma". Only the positive version is | |
| 1427 listed below.</para> | |
| 1428 | |
| 1429 <para>Pragmas are not case sensitive.</para> | |
| 1430 | |
| 1431 <variablelist> | |
| 1432 <varlistentry> | |
| 1433 <term>index0tonone</term> | |
| 1434 <listitem> | |
| 1435 <para> | |
| 1436 When in force, this pragma enables an optimization affecting indexed addressing | |
| 1437 modes. When the offset expression in an indexed mode evaluates to zero but is | |
| 1438 not explicity written as 0, this will replace the operand with the equivalent | |
| 1439 no offset mode, thus creating slightly faster code. Because of the advantages | |
| 1440 of this optimization, it is enabled by default. | |
| 1441 </para> | |
| 1442 </listitem> | |
| 1443 </varlistentry> | |
| 1444 | |
| 1445 <varlistentry> | |
| 1446 <term>cescapes</term> | |
| 1447 <listitem> | |
| 1448 <para> | |
| 1449 This pragma will cause strings in the FCC, FCS, and FCN pseudo operations to | |
| 1450 have C-style escape sequences interpreted. The one departure from the official | |
| 1451 spec is that unrecognized escape sequences will return either the character | |
| 1452 immediately following the backslash or some undefined value. Do not rely | |
| 1453 on the behaviour of undefined escape sequences. | |
| 1454 </para> | |
| 1455 </listitem> | |
| 1456 </varlistentry> | |
| 1457 | |
| 1458 <varlistentry> | |
| 1459 <term>importundefexport</term> | |
| 1460 <listitem> | |
| 1461 <para> | |
| 1462 This pragma is only valid for targets that support external references. When | |
| 1463 in force, it will cause the EXPORT directive to act as IMPORT if the symbol | |
| 1464 to be exported is not defined. This is provided for compatibility with the | |
| 1465 output of gcc6809 and should not be used in hand written code. Because of | |
| 1466 the confusion this pragma can cause, it is disabled by default. | |
| 1467 </para> | |
| 1468 </listitem> | |
| 1469 </varlistentry> | |
| 1470 | |
| 1471 <varlistentry> | |
| 1472 <term>undefextern</term> | |
| 1473 <listitem> | |
| 1474 <para> | |
| 1475 This pragma is only valid for targets that support external references. When in | |
| 1476 force, if the assembler sees an undefined symbol on the second pass, it will | |
| 1477 automatically define it as an external symbol. This automatic definition will | |
| 1478 apply for the remainder of the assembly process, even if the pragma is | |
| 1479 subsequently turned off. Because this behaviour would be potentially surprising, | |
| 1480 this pragma defaults to off. | |
| 1481 </para> | |
| 1482 <para> | |
| 1483 The primary use for this pragma is for projects that share a large number of | |
| 1484 symbols between source files. In such cases, it is impractical to enumerate | |
| 1485 all the external references in every source file. This allows the assembler | |
| 1486 and linker to do the heavy lifting while not preventing a particular source | |
| 1487 module from defining a local symbol of the same name as an external symbol | |
| 1488 if it does not need the external symbol. (This pragma will not cause an | |
| 1489 automatic external definition if there is already a locally defined symbol.) | |
| 1490 </para> | |
| 1491 <para> | |
| 1492 This pragma will often be specified on the command line for large projects. | |
| 1493 However, depending on the specific dynamics of the project, it may be sufficient | |
| 1494 for one or two files to use this pragma internally. | |
| 1495 </para> | |
| 1496 </listitem> | |
| 1497 </varlistentry> | |
| 1498 | |
| 1499 <varlistentry> | |
| 1500 <term>dollarlocal</term> | |
| 1501 <listitem> | |
| 1502 | |
| 1503 <para>When set, a "$" in a symbol makes it local. When not set, "$" does not | |
| 1504 cause a symbol to be local. It is set by default except when using the OS9 | |
| 1505 target.</para> | |
| 1506 | |
| 1507 </listitem> | |
| 1508 </varlistentry> | |
| 1509 | |
| 1510 <varlistentry> | |
| 1511 <term>dollarnotlocal</term> | |
| 1512 <listitem> | |
| 1513 | |
| 1514 <para> This is the same as the "dollarlocal" pragma except its sense is | |
| 1515 reversed. That is, "dollarlocal" and "nodollarnotlocal" are equivalent and | |
| 1516 "nodollarlocal" and "dollarnotlocal" are equivalent. </para> | |
| 1517 | |
| 1518 </listitem> | |
| 1519 </varlistentry> | |
| 1520 | |
| 1521 </variablelist> | |
| 1522 | |
| 1523 </section> | |
| 1524 | |
| 1525 </chapter> | |
| 1526 | |
| 1527 <chapter> | |
| 1528 <title>LWLINK</title> | |
| 1529 <para> | |
| 1530 The LWTOOLS linker is called LWLINK. This chapter documents the various features | |
| 1531 of the linker. | |
| 1532 </para> | |
| 1533 | |
| 1534 <section> | |
| 1535 <title>Command Line Options</title> | |
| 1536 <para> | |
| 1537 The binary for LWLINK is called "lwlink". Note that the binary is in lower | |
| 1538 case. lwlink takes the following command line arguments. | |
| 1539 </para> | |
| 1540 <variablelist> | |
| 1541 <varlistentry> | |
| 1542 <term><option>--decb</option></term> | |
| 1543 <term><option>-b</option></term> | |
| 1544 <listitem> | |
| 1545 <para> | |
| 1546 Selects the DECB output format target. This is equivalent to <option>--format=decb</option> | |
| 1547 </para> | |
| 1548 </listitem> | |
| 1549 </varlistentry> | |
| 1550 | |
| 1551 <varlistentry> | |
| 1552 <term><option>--output=FILE</option></term> | |
| 1553 <term><option>-o FILE</option></term> | |
| 1554 <listitem> | |
| 1555 <para> | |
| 1556 This option specifies the name of the output file. If not specified, the | |
| 1557 default is <option>a.out</option>. | |
| 1558 </para> | |
| 1559 </listitem> | |
| 1560 </varlistentry> | |
| 1561 | |
| 1562 <varlistentry> | |
| 1563 <term><option>--format=TYPE</option></term> | |
| 1564 <term><option>-f TYPE</option></term> | |
| 1565 <listitem> | |
| 1566 <para> | |
| 1567 This option specifies the output format. Valid values are <option>decb</option> | |
| 1568 and <option>raw</option> | |
| 1569 </para> | |
| 1570 </listitem> | |
| 1571 </varlistentry> | |
| 1572 | |
| 1573 <varlistentry> | |
| 1574 <term><option>--raw</option></term> | |
| 1575 <term><option>-r</option></term> | |
| 1576 <listitem> | |
| 1577 <para> | |
| 1578 This option specifies the raw output format. | |
| 1579 It is equivalent to <option>--format=raw</option> | |
| 1580 and <option>-f raw</option> | |
| 1581 </para> | |
| 1582 </listitem> | |
| 1583 </varlistentry> | |
| 1584 | |
| 1585 <varlistentry> | |
| 1586 <term><option>--script=FILE</option></term> | |
| 1587 <term><option>-s</option></term> | |
| 1588 <listitem> | |
| 1589 <para> | |
| 1590 This option allows specifying a linking script to override the linker's | |
| 1591 built in defaults. | |
| 1592 </para> | |
| 1593 </listitem> | |
| 1594 </varlistentry> | |
| 1595 | |
| 1596 <varlistentry> | |
| 1597 <term><option>--section-base=SECT=BASE</option></term> | |
| 1598 <listitem> | |
| 1599 <para> | |
| 1600 Cause section SECT to load at base address BASE. This will be prepended | |
| 1601 to the built-in link script. It is ignored if a link script is provided. | |
| 1602 </para> | |
| 1603 </listitem> | |
| 1604 </varlistentry> | |
| 1605 | |
| 1606 <varlistentry> | |
| 1607 <term><option>--map=FILE</option></term> | |
| 1608 <term><option>-m FILE</option></term> | |
| 1609 <listitem> | |
| 1610 <para> | |
| 1611 This will output a description of the link result to FILE. | |
| 1612 </para> | |
| 1613 </listitem> | |
| 1614 </varlistentry> | |
| 1615 | |
| 1616 <varlistentry> | |
| 1617 <term><option>--library=LIBSPEC</option></term> | |
| 1618 <term><option>-l LIBSPEC</option></term> | |
| 1619 <listitem> | |
| 1620 <para> | |
| 1621 Load a library using the library search path. LIBSPEC will have "lib" prepended | |
| 1622 and ".a" appended. | |
| 1623 </para> | |
| 1624 </listitem> | |
| 1625 </varlistentry> | |
| 1626 | |
| 1627 <varlistentry> | |
| 1628 <term><option>--library-path=DIR</option></term> | |
| 1629 <term><option>-L DIR</option></term> | |
| 1630 <listitem> | |
| 1631 <para> | |
| 1632 Add DIR to the library search path. | |
| 1633 </para> | |
| 1634 </listitem> | |
| 1635 </varlistentry> | |
| 1636 | |
| 1637 <varlistentry> | |
| 1638 <term><option>--debug</option></term> | |
| 1639 <term><option>-d</option></term> | |
| 1640 <listitem> | |
| 1641 <para> | |
| 1642 This option increases the debugging level. It is only useful for LWTOOLS | |
| 1643 developers. | |
| 1644 </para> | |
| 1645 </listitem> | |
| 1646 </varlistentry> | |
| 1647 | |
| 1648 <varlistentry> | |
| 1649 <term><option>--help</option></term> | |
| 1650 <term><option>-?</option></term> | |
| 1651 <listitem> | |
| 1652 <para> | |
| 1653 This provides a listing of command line options and a brief description | |
| 1654 of each. | |
| 1655 </para> | |
| 1656 </listitem> | |
| 1657 </varlistentry> | |
| 1658 | |
| 1659 <varlistentry> | |
| 1660 <term><option>--usage</option></term> | |
| 1661 <listitem> | |
| 1662 <para> | |
| 1663 This will display a usage summary | |
| 1664 of each command line option. | |
| 1665 </para> | |
| 1666 </listitem> | |
| 1667 </varlistentry> | |
| 1668 | |
| 1669 | |
| 1670 <varlistentry> | |
| 1671 <term><option>--version</option></term> | |
| 1672 <term><option>-V</option></term> | |
| 1673 <listitem> | |
| 1674 <para> | |
| 1675 This will display the version of LWLINK. | |
| 1676 </para> | |
| 1677 </listitem> | |
| 1678 </varlistentry> | |
| 1679 | |
| 1680 </section> | |
| 1681 | |
| 1682 <section> | |
| 1683 <title>Linker Operation</title> | |
| 1684 | |
| 1685 <para> | |
| 1686 | |
| 1687 LWLINK takes one or more files in supported input formats and links them | |
| 1688 into a single binary. Currently supported formats are the LWTOOLS object | |
| 1689 file format and the archive format used by LWAR. While the precise method is | |
| 1690 slightly different, linking can be conceptualized as the following steps. | |
| 1691 | |
| 1692 </para> | |
| 1693 | |
| 1694 <orderedlist> | |
| 1695 <listitem> | |
| 1696 <para> | |
| 1697 First, the linker loads a linking script. If no script is specified, it | |
| 1698 loads a built-in default script based on the output format selected. This | |
| 1699 script tells the linker how to lay out the various sections in the final | |
| 1700 binary. | |
| 1701 </para> | |
| 1702 </listitem> | |
| 1703 | |
| 1704 <listitem> | |
| 1705 <para> | |
| 1706 Next, the linker reads all the input files into memory. At this time, it | |
| 1707 flags any format errors in those files. It constructs a table of symbols | |
| 1708 for each object at this time. | |
| 1709 </para> | |
| 1710 </listitem> | |
| 1711 | |
| 1712 <listitem> | |
| 1713 <para> | |
| 1714 The linker then proceeds with organizing the sections loaded from each file | |
| 1715 according to the linking script. As it does so, it is able to assign addresses | |
| 1716 to each symbol defined in each object file. At this time, the linker may | |
| 1717 also collapse different instances of the same section name into a single | |
| 1718 section by appending the data from each subsequent instance of the section | |
| 1719 to the first instance of the section. | |
| 1720 </para> | |
| 1721 </listitem> | |
| 1722 | |
| 1723 <listitem> | |
| 1724 <para> | |
| 1725 Next, the linker looks through every object file for every incomplete reference. | |
| 1726 It then attempts to fully resolve that reference. If it cannot do so, it | |
| 1727 throws an error. Once a reference is resolved, the value is placed into | |
| 1728 the binary code at the specified section. It should be noted that an | |
| 1729 incomplete reference can reference either a symbol internal to the object | |
| 1730 file or an external symbol which is in the export list of another object | |
| 1731 file. | |
| 1732 </para> | |
| 1733 </listitem> | |
| 1734 | |
| 1735 <listitem> | |
| 1736 <para> | |
| 1737 If all of the above steps are successful, the linker opens the output file | |
| 1738 and actually constructs the binary. | |
| 1739 </para> | |
| 1740 </listitem> | |
| 1741 </orderedlist> | |
| 1742 | |
| 1743 </section> | |
| 1744 | |
| 1745 <section | |
| 1746 <title>Linking Scripts</title> | |
| 1747 <para> | |
| 1748 A linker script is used to instruct the linker about how to assemble the | |
| 1749 various sections into a completed binary. It consists of a series of | |
| 1750 directives which are considered in the order they are encountered. | |
| 1751 </para> | |
| 1752 <para> | |
| 1753 The sections will appear in the resulting binary in the order they are | |
| 1754 specified in the script file. If a referenced section is not found, the linker will behave as though the | |
| 1755 section did exist but had a zero size, no relocations, and no exports. | |
| 1756 A section should only be referenced once. Any subsequent references will have | |
| 1757 an undefined effect. | |
| 1758 </para> | |
| 1759 | |
| 1760 <para> | |
| 1761 All numbers are in linking scripts are specified in hexadecimal. All directives | |
| 1762 are case sensitive although the hexadecimal numbers are not. | |
| 1763 </para> | |
| 1764 | |
| 1765 <para>A section name can be specified as a "*", then any section not | |
| 1766 already matched by the script will be matched. The "*" can be followed | |
| 1767 by a comma and a flag to narrow the section down slightly, also. | |
| 1768 If the flag is "!bss", then any section that is not flagged as a bss section | |
| 1769 will be matched. If the flag is "bss", then any section that is flagged as | |
| 1770 bss will be matched. | |
| 1771 </para> | |
| 1772 | |
| 1773 <para>The following directives are understood in a linker script.</para> | |
| 1774 <variablelist> | |
| 1775 <varlistentry> | |
| 1776 <term>section <parameter>name</parameter> load <parameter>addr</parameter></term> | |
| 1777 <listitem><para> | |
| 1778 | |
| 1779 This causes the section <parameter>name</parameter> to load at | |
| 1780 <parameter>addr</parameter>. For the raw target, only one "load at" entry is | |
| 1781 allowed for non-bss sections and it must be the first one. For raw targets, | |
| 1782 it affects the addresses the linker assigns to symbols but has no other | |
| 1783 affect on the output. bss sections may all have separate load addresses but | |
| 1784 since they will not appear in the binary anyway, this is okay. | |
| 1785 </para><para> | |
| 1786 For the decb target, each "load" entry will cause a new "block" to be | |
| 1787 output to the binary which will contain the load address. It is legal for | |
| 1788 sections to overlap in this manner - the linker assumes the loader will sort | |
| 1789 everything out. | |
| 1790 </para></listitem> | |
| 1791 </varlistentry> | |
| 1792 | |
| 1793 <varlistentry> | |
| 1794 <term>section <parameter>name</parameter></term> | |
| 1795 <listitem><para> | |
| 1796 | |
| 1797 This will cause the section <parameter>name</parameter> to load after the previously listed | |
| 1798 section. | |
| 1799 </para></listitem></varlistentry> | |
| 1800 <varlistentry> | |
| 1801 <term>exec <parameter>addr or sym</parameter></term> | |
| 1802 <listitem> | |
| 1803 <para> | |
| 1804 This will cause the execution address (entry point) to be the address | |
| 1805 specified (in hex) or the specified symbol name. The symbol name must | |
| 1806 match a symbol that is exported by one of the object files being linked. | |
| 1807 This has no effect for targets that do not encode the entry point into the | |
| 1808 resulting file. If not specified, the entry point is assumed to be address 0 | |
| 1809 which is probably not what you want. The default link scripts for targets | |
| 1810 that support this directive automatically starts at the beginning of the | |
| 1811 first section (usually "init" or "code") that is emitted in the binary. | |
| 1812 </para> | |
| 1813 </listitem> | |
| 1814 </varlistentry> | |
| 1815 | |
| 1816 <varlistentry> | |
| 1817 <term>pad <parameter>size</parameter></term> | |
| 1818 <listitem><para> | |
| 1819 This will cause the output file to be padded with NUL bytes to be exactly | |
| 1820 <parameter>size</parameter> bytes in length. This only makes sense for a raw target. | |
| 1821 </para> | |
| 1822 </listitem> | |
| 1823 </varlistentry> | |
| 1824 </variablelist> | |
| 1825 | |
| 1826 | |
| 1827 | |
| 1828 </section> | |
| 1829 | |
| 1830 </chapter> | |
| 1831 | |
| 1832 <chapter> | |
| 1833 <title>Libraries and LWAR</title> | |
| 1834 | |
| 1835 <para> | |
| 1836 LWTOOLS also includes a tool for managing libraries. These are analogous to | |
| 1837 the static libraries created with the "ar" tool on POSIX systems. Each library | |
| 1838 file contains one or more object files. The linker will treat the object | |
| 1839 files within a library as though they had been specified individually on | |
| 1840 the command line except when resolving external references. External references | |
| 1841 are looked up first within the object files within the library and then, if | |
| 1842 not found, the usual lookup based on the order the files are specified on | |
| 1843 the command line occurs. | |
| 1844 </para> | |
| 1845 | |
| 1846 <para> | |
| 1847 The tool for creating these libary files is called LWAR. | |
| 1848 </para> | |
| 1849 | |
| 1850 <section> | |
| 1851 <title>Command Line Options</title> | |
| 1852 <para> | |
| 1853 The binary for LWAR is called "lwar". Note that the binary is in lower | |
| 1854 case. The options lwar understands are listed below. For archive manipulation | |
| 1855 options, the first non-option argument is the name of the archive. All other | |
| 1856 non-option arguments are the names of files to operate on. | |
| 1857 </para> | |
| 1858 | |
| 1859 <variablelist> | |
| 1860 <varlistentry> | |
| 1861 <term><option>--add</option></term> | |
| 1862 <term><option>-a</option></term> | |
| 1863 <listitem> | |
| 1864 <para> | |
| 1865 This option specifies that an archive is going to have files added to it. | |
| 1866 If the archive does not already exist, it is created. New files are added | |
| 1867 to the end of the archive. | |
| 1868 </para> | |
| 1869 </listitem> | |
| 1870 </varlistentry> | |
| 1871 | |
| 1872 <varlistentry> | |
| 1873 <term><option>--create</option></term> | |
| 1874 <term><option>-c</option></term> | |
| 1875 <listitem> | |
| 1876 <para> | |
| 1877 This option specifies that an archive is going to be created and have files | |
| 1878 added to it. If the archive already exists, it is truncated. | |
| 1879 </para> | |
| 1880 </listitem> | |
| 1881 </varlistentry> | |
| 1882 | |
| 1883 <varlistentry> | |
| 1884 <term><option>--merge</option></term> | |
| 1885 <term><option>-m</option></term> | |
| 1886 <listitem> | |
| 1887 <para> | |
| 1888 If specified, any files specified to be added to an archive will be checked | |
| 1889 to see if they are archives themselves. If so, their constituent members are | |
| 1890 added to the archive. This is useful for avoiding archives containing archives. | |
| 1891 </para> | |
| 1892 </listitem> | |
| 1893 </varlistentry> | |
| 1894 | |
| 1895 <varlistentry> | |
| 1896 <term><option>--list</option></term> | |
| 1897 <term><option>-l</option></term> | |
| 1898 <listitem> | |
| 1899 <para> | |
| 1900 This will display a list of the files contained in the archive. | |
| 1901 </para> | |
| 1902 </listitem> | |
| 1903 </varlistentry> | |
| 1904 | |
| 1905 <varlistentry> | |
| 1906 <term><option>--debug</option></term> | |
| 1907 <term><option>-d</option></term> | |
| 1908 <listitem> | |
| 1909 <para> | |
| 1910 This option increases the debugging level. It is only useful for LWTOOLS | |
| 1911 developers. | |
| 1912 </para> | |
| 1913 </listitem> | |
| 1914 </varlistentry> | |
| 1915 | |
| 1916 <varlistentry> | |
| 1917 <term><option>--help</option></term> | |
| 1918 <term><option>-?</option></term> | |
| 1919 <listitem> | |
| 1920 <para> | |
| 1921 This provides a listing of command line options and a brief description | |
| 1922 of each. | |
| 1923 </para> | |
| 1924 </listitem> | |
| 1925 </varlistentry> | |
| 1926 | |
| 1927 <varlistentry> | |
| 1928 <term><option>--usage</option></term> | |
| 1929 <listitem> | |
| 1930 <para> | |
| 1931 This will display a usage summary | |
| 1932 of each command line option. | |
| 1933 </para> | |
| 1934 </listitem> | |
| 1935 </varlistentry> | |
| 1936 | |
| 1937 | |
| 1938 <varlistentry> | |
| 1939 <term><option>--version</option></term> | |
| 1940 <term><option>-V</option></term> | |
| 1941 <listitem> | |
| 1942 <para> | |
| 1943 This will display the version of LWLINK. | |
| 1944 of each. | |
| 1945 </para> | |
| 1946 </listitem> | |
| 1947 </varlistentry> | |
| 1948 | |
| 1949 </section> | |
| 1950 | |
| 1951 </chapter> | |
| 1952 | |
| 1953 <chapter id="objchap"> | |
| 1954 <title>Object Files</title> | |
| 1955 <para> | |
| 1956 LWTOOLS uses a proprietary object file format. It is proprietary in the sense | |
| 1957 that it is specific to LWTOOLS, not that it is a hidden format. It would be | |
| 1958 hard to keep it hidden in an open source tool chain anyway. This chapter | |
| 1959 documents the object file format. | |
| 1960 </para> | |
| 1961 | |
| 1962 <para> | |
| 1963 An object file consists of a series of sections each of which contains a | |
| 1964 list of exported symbols, a list of incomplete references, and a list of | |
| 1965 "local" symbols which may be used in calculating incomplete references. Each | |
| 1966 section will obviously also contain the object code. | |
| 1967 </para> | |
| 1968 | |
| 1969 <para> | |
| 1970 Exported symbols must be completely resolved to an address within the | |
| 1971 section it is exported from. That is, an exported symbol must be a constant | |
| 1972 rather than defined in terms of other symbols.</para> | |
| 1973 | |
| 1974 <para> | |
| 1975 Each object file starts with a magic number and version number. The magic | |
| 1976 number is the string "LWOBJ16" for this 16 bit object file format. The only | |
| 1977 defined version number is currently 0. Thus, the first 8 bytes of the object | |
| 1978 file are <code>4C574F424A313600</code> | |
| 1979 </para> | |
| 1980 | |
| 1981 <para> | |
| 1982 Each section has the following items in order: | |
| 1983 </para> | |
| 1984 | |
| 1985 <itemizedlist> | |
| 1986 <listitem><para>section name</para></listitem> | |
| 1987 <listitem><para>flags</para></listitem> | |
| 1988 <listitem><para>list of local symbols (and addresses within the section)</para></listitem> | |
| 1989 <listitem><para>list of exported symbols (and addresses within the section)</para></listitem> | |
| 1990 <listitem><para>list of incomplete references along with the expressions to calculate them</para></listitem> | |
| 1991 <listitem><para>the actual object code (for non-BSS sections)</para></listitem> | |
| 1992 </itemizedlist> | |
| 1993 | |
| 1994 <para> | |
| 1995 The section starts with the name of the section with a NUL termination | |
| 1996 followed by a series of flag bytes terminated by NUL. There are only two | |
| 1997 flag bytes defined. A NUL (0) indicates no more flags and a value of 1 | |
| 1998 indicates the section is a BSS section. For a BSS section, no actual | |
| 1999 code is included in the object file. | |
| 2000 </para> | |
| 2001 | |
| 2002 <para> | |
| 2003 Either a NULL section name or end of file indicate the presence of no more | |
| 2004 sections. | |
| 2005 </para> | |
| 2006 | |
| 2007 <para> | |
| 2008 Each entry in the exported and local symbols table consists of the symbol | |
| 2009 (NUL terminated) followed by two bytes which contain the value in big endian | |
| 2010 order. The end of a symbol table is indicated by a NULL symbol name. | |
| 2011 </para> | |
| 2012 | |
| 2013 <para> | |
| 2014 Each entry in the incomplete references table consists of an expression | |
| 2015 followed by a 16 bit offset where the reference goes. Expressions are | |
| 2016 defined as a series of terms up to an "end of expression" term. Each term | |
| 2017 consists of a single byte which identifies the type of term (see below) | |
| 2018 followed by any data required by the term. Then end of the list is flagged | |
| 2019 by a NULL expression (only an end of expression term). | |
| 2020 </para> | |
| 2021 | |
| 2022 <table frame="all"><title>Object File Term Types</title> | |
| 2023 <tgroup cols="2"> | |
| 2024 <thead> | |
| 2025 <row> | |
| 2026 <entry>TERMTYPE</entry> | |
| 2027 <entry>Meaning</entry> | |
| 2028 </row> | |
| 2029 </thead> | |
| 2030 <tbody> | |
| 2031 <row> | |
| 2032 <entry>00</entry> | |
| 2033 <entry>end of expression</entry> | |
| 2034 </row> | |
| 2035 | |
| 2036 <row> | |
| 2037 <entry>01</entry> | |
| 2038 <entry>integer (16 bit in big endian order follows)</entry> | |
| 2039 </row> | |
| 2040 <row> | |
| 2041 <entry>02</entry> | |
| 2042 <entry> external symbol reference (NUL terminated symbol name follows)</entry> | |
| 2043 </row> | |
| 2044 | |
| 2045 <row> | |
| 2046 <entry>03</entry> | |
| 2047 <entry>local symbol reference (NUL terminated symbol name follows)</entry> | |
| 2048 </row> | |
| 2049 | |
| 2050 <row> | |
| 2051 <entry>04</entry> | |
| 2052 <entry>operator (1 byte operator number)</entry> | |
| 2053 </row> | |
| 2054 <row> | |
| 2055 <entry>05</entry> | |
| 2056 <entry>section base address reference</entry> | |
| 2057 </row> | |
| 2058 | |
| 2059 <row> | |
| 2060 <entry>FF</entry> | |
| 2061 <entry>This term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).</entry> | |
| 2062 </row> | |
| 2063 </tbody> | |
| 2064 </tgroup> | |
| 2065 </table> | |
| 2066 | |
| 2067 | |
| 2068 <para> | |
| 2069 External references are resolved using other object files while local | |
| 2070 references are resolved using the local symbol table(s) from this file. This | |
| 2071 allows local symbols that are not exported to have the same names as | |
| 2072 exported symbols or external references. | |
| 2073 </para> | |
| 2074 | |
| 2075 <table frame="all"><title>Object File Operator Numbers</title> | |
| 2076 <tgroup cols="2"> | |
| 2077 <thead> | |
| 2078 <row> | |
| 2079 <entry>Number</entry> | |
| 2080 <entry>Operator</entry> | |
| 2081 </row> | |
| 2082 </thead> | |
| 2083 <tbody> | |
| 2084 <row> | |
| 2085 <entry>01</entry> | |
| 2086 <entry>addition (+)</entry> | |
| 2087 </row> | |
| 2088 <row> | |
| 2089 <entry>02</entry> | |
| 2090 <entry>subtraction (-)</entry> | |
| 2091 </row> | |
| 2092 <row> | |
| 2093 <entry>03</entry> | |
| 2094 <entry>multiplication (*)</entry> | |
| 2095 </row> | |
| 2096 <row> | |
| 2097 <entry>04</entry> | |
| 2098 <entry>division (/)</entry> | |
| 2099 </row> | |
| 2100 <row> | |
| 2101 <entry>05</entry> | |
| 2102 <entry>modulus (%)</entry> | |
| 2103 </row> | |
| 2104 <row> | |
| 2105 <entry>06</entry> | |
| 2106 <entry>integer division (\) (same as division)</entry> | |
| 2107 </row> | |
| 2108 | |
| 2109 <row> | |
| 2110 <entry>07</entry> | |
| 2111 <entry>bitwise and</entry> | |
| 2112 </row> | |
| 2113 | |
| 2114 <row> | |
| 2115 <entry>08</entry> | |
| 2116 <entry>bitwise or</entry> | |
| 2117 </row> | |
| 2118 | |
| 2119 <row> | |
| 2120 <entry>09</entry> | |
| 2121 <entry>bitwise xor</entry> | |
| 2122 </row> | |
| 2123 | |
| 2124 <row> | |
| 2125 <entry>0A</entry> | |
| 2126 <entry>boolean and</entry> | |
| 2127 </row> | |
| 2128 | |
| 2129 <row> | |
| 2130 <entry>0B</entry> | |
| 2131 <entry>boolean or</entry> | |
| 2132 </row> | |
| 2133 | |
| 2134 <row> | |
| 2135 <entry>0C</entry> | |
| 2136 <entry>unary negation, 2's complement (-)</entry> | |
| 2137 </row> | |
| 2138 | |
| 2139 <row> | |
| 2140 <entry>0D</entry> | |
| 2141 <entry>unary 1's complement (^)</entry> | |
| 2142 </row> | |
| 2143 </tbody> | |
| 2144 </tgroup> | |
| 2145 </table> | |
| 2146 | |
| 2147 <para> | |
| 2148 An expression is represented in a postfix manner with both operands for | |
| 2149 binary operators preceding the operator and the single operand for unary | |
| 2150 operators preceding the operator. | |
| 2151 </para> | |
| 2152 | |
| 2153 </chapter> | |
| 2154 </book> | |
| 2155 |