Mercurial > hg-old > index.cgi

comparison doc/manual.docbook.sgml @ 227:4c60c3a09597

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Various updates to the manual
author lost
date Fri, 12 Jun 2009 00:06:24 +0000
parents bc2fae9438eb
children 10abe422efce
comparison
equal deleted inserted replaced
226:c8787fad0f9f 227:4c60c3a09597
96 <para>LWASM supports generating a proprietary object file format which is 96 <para>LWASM supports generating a proprietary object file format which is
97 described in <xref linkend="objchap">. LWLINK is then used to link these 97 described in <xref linkend="objchap">. LWLINK is then used to link these
98 object files into a final binary in any of LWLINK's supported binary 98 object files into a final binary in any of LWLINK's supported binary
99 formats.</para> 99 formats.</para>
100 100
101 <para>Object files are very flexible in that they allow references that are not
102 known at assembly time to be resolved at link time. However, because the
103 addresses of such references are not known, there is no way for the assembler
104 has to use sixteen bit addressing modes for these references. The linker
105 will always use sixteen bits when resolving a reference which means any
106 instruction that requires an eight bit operand cannot use external references.
107 </para>
108
109 <para>Object files also support the concept of sections which are not valid 101 <para>Object files also support the concept of sections which are not valid
110 for other output types. This allows related code from each object file 102 for other output types. This allows related code from each object file
111 linked to be collapsed together in the final binary.</para> 103 linked to be collapsed together in the final binary.</para>
104
105 <para>
106 Object files are very flexible in that they allow references that are not
107 known at assembly time to be resolved at link time. However, because the
108 addresses of such references are not known at assembly time, there is no way
109 for the assembler to deduce that an eight bit addressing mode is possible.
110 That means the assember will default to using sixteen bit addressing
111 whenever an external or cross-section reference is used.
112 </para>
113
114 <para>
115 As of LWASM 2.4, it is possible to force direct page addressing for an
116 external reference. Care must be taken to ensure the resulting addresses
117 are really in the direct page since the linker does not know what the direct
118 page is supposed to be and does not emit errors for byte overflows.
119 </para>
120
121 <para>
122 It is also possible to use external references in an eight bit immediate
123 mode instruction. In this case, only the low order eight bits will be used.
124 Again, no byte overflows will be flagged.
125 </para>
126
112 127
113 </section> 128 </section>
114 129
115 </chapter> 130 </chapter>
116 131
365 <para>The ASCII value of a character can be included by prefixing it with a 380 <para>The ASCII value of a character can be included by prefixing it with a
366 single quote ('). The ASCII values of two characters can be included by 381 single quote ('). The ASCII values of two characters can be included by
367 prefixing the characters with a quote (").</para> 382 prefixing the characters with a quote (").</para>
368 383
369 <para> 384 <para>
370 LWASM supports the following basic binary operators: +, -, *, /, and %. 385
371 These represent addition, subtraction, multiplication, division, and modulus. 386 LWASM supports the following basic binary operators: +, -, *, /, and %.
372 It also supports unary negation and unary 1's complement (- and ^ respectively). 387 These represent addition, subtraction, multiplication, division, and
373 For completeness, a unary positive (+) is supported though it is a no-op. 388 modulus. It also supports unary negation and unary 1's complement (- and ^
374 </para> 389 respectively). It is also possible to use ~ for the unary 1's complement
375 390 operator. For completeness, a unary positive (+) is supported though it is
376 <para>Operator precedence follows the usual rules. multiplication, division, 391 a no-op. LWASM also supports using |, &, and ^ for bitwise or, bitwise and,
377 and modulus take precedence over addition and subtraction. Unary operators 392 and bitwise exclusive or respectively.
378 take precedence over binary operators. To force a specific order of evaluation, 393
394 </para>
395
396 <para>
397
398 Operator precedence follows the usual rules. Multiplication, division, and
399 modulus take precedence over addition and subtraction. Unary operators take
400 precedence over binary operators. Bitwise operators are lower precdence
401 than addition and subtraction. To force a specific order of evaluation,
379 parentheses can be used in the usual manner. 402 parentheses can be used in the usual manner.
380 </para> 403
404 </para>
405
406 <para>
407
408 As of LWASM 2.5, the operators && and || are recognized for boolean and and
409 boolean or respectively. They will return either 0 or 1 (false or true).
410 They have the lowest precedence of all the binary operators.
411
412 </para>
413
381 </section> 414 </section>
382 415
383 <section> 416 <section>
384 <title>Assembler Directives</title> 417 <title>Assembler Directives</title>
385 <para> 418 <para>
518 resolvable during pass 1 of assembly so no forward or external references are 551 resolvable during pass 1 of assembly so no forward or external references are
519 permitted. The value of the double-words is undefined. 552 permitted. The value of the double-words is undefined.
520 </para> 553 </para>
521 </listitem> 554 </listitem>
522 </varlistentry> 555 </varlistentry>
556
557 <varlistentry>
558 <term>INCLUDEBIN <parameter>filename</parameter></term>
559 <listitem>
560 <para>
561 Treat the contents of <parameter>filename</parameter> as a string of bytes to
562 be included literally at the current assembly point. This has the same effect
563 as converting the file contents to a series of FCB statements and including
564 those at the current assembly point.
565 </para>
566 </listitem>
567 </varlistentry>
568
523 </variablelist> 569 </variablelist>
524 570
525 </section> 571 </section>
526 572
527 <section> 573 <section>
1093 </para> 1139 </para>
1094 </listitem> 1140 </listitem>
1095 </varlistentry> 1141 </varlistentry>
1096 1142
1097 <varlistentry> 1143 <varlistentry>
1144 <term>importundefexport</term>
1145 <listitem>
1146 <para>
1147 This pragma is only valid for targets that support external references. When
1148 in force, it will cause the EXPORT directive to act as IMPORT if the symbol
1149 to be exported is not defined. This is provided for compatibility with the
1150 output of gcc6809 and should not be used in hand written code. Because of
1151 the confusion this pragma can cause, it is disabled by default.
1152 </para>
1153 </listitem>
1154 </varlistentry>
1155
1156 <varlistentry>
1098 <term>undefextern</term> 1157 <term>undefextern</term>
1099 <listitem> 1158 <listitem>
1100 <para> 1159 <para>
1101 This pragma is only valid for targets that support external references. When in 1160 This pragma is only valid for targets that support external references. When in
1102 force, if the assembler sees an undefined symbol on the second pass, it will 1161 force, if the assembler sees an undefined symbol on the second pass, it will