Mercurial > hg > index.cgi
comparison docs/manual/x619.html @ 324:b30091890d62
Add documentation of the new hex output formats.
Thanks to text contributed by Tom LeMense, the manual now includes
documentation of the hex formats he contributed. This also includes some
updated text on the ORG directive. Only minor editorial changes vary the
text from Tom's original.
author | William Astle <lost@l-w.ca> |
---|---|
date | Tue, 04 Mar 2014 23:10:13 -0700 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
323:ba9a0434b115 | 324:b30091890d62 |
---|---|
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd"> | |
2 <HTML | |
3 ><HEAD | |
4 ><TITLE | |
5 >Assembler Modes and Pragmas</TITLE | |
6 ><META | |
7 NAME="GENERATOR" | |
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK | |
9 REL="HOME" | |
10 TITLE="LW Tool Chain" | |
11 HREF="index.html"><LINK | |
12 REL="UP" | |
13 TITLE="LWASM" | |
14 HREF="c62.html"><LINK | |
15 REL="PREVIOUS" | |
16 TITLE="Object Files and Sections" | |
17 HREF="x555.html"><LINK | |
18 REL="NEXT" | |
19 TITLE="LWLINK" | |
20 HREF="c713.html"></HEAD | |
21 ><BODY | |
22 CLASS="SECTION" | |
23 BGCOLOR="#FFFFFF" | |
24 TEXT="#000000" | |
25 LINK="#0000FF" | |
26 VLINK="#840084" | |
27 ALINK="#0000FF" | |
28 ><DIV | |
29 CLASS="NAVHEADER" | |
30 ><TABLE | |
31 SUMMARY="Header navigation table" | |
32 WIDTH="100%" | |
33 BORDER="0" | |
34 CELLPADDING="0" | |
35 CELLSPACING="0" | |
36 ><TR | |
37 ><TH | |
38 COLSPAN="3" | |
39 ALIGN="center" | |
40 >LW Tool Chain</TH | |
41 ></TR | |
42 ><TR | |
43 ><TD | |
44 WIDTH="10%" | |
45 ALIGN="left" | |
46 VALIGN="bottom" | |
47 ><A | |
48 HREF="x555.html" | |
49 ACCESSKEY="P" | |
50 >Prev</A | |
51 ></TD | |
52 ><TD | |
53 WIDTH="80%" | |
54 ALIGN="center" | |
55 VALIGN="bottom" | |
56 >Chapter 3. LWASM</TD | |
57 ><TD | |
58 WIDTH="10%" | |
59 ALIGN="right" | |
60 VALIGN="bottom" | |
61 ><A | |
62 HREF="c713.html" | |
63 ACCESSKEY="N" | |
64 >Next</A | |
65 ></TD | |
66 ></TR | |
67 ></TABLE | |
68 ><HR | |
69 ALIGN="LEFT" | |
70 WIDTH="100%"></DIV | |
71 ><DIV | |
72 CLASS="SECTION" | |
73 ><H1 | |
74 CLASS="SECTION" | |
75 ><A | |
76 NAME="AEN619" | |
77 >3.10. Assembler Modes and Pragmas</A | |
78 ></H1 | |
79 ><P | |
80 >There are a number of options that affect the way assembly is performed. | |
81 Some of these options can only be specified on the command line because | |
82 they determine something absolute about the assembly process. These include | |
83 such things as the output target. Other things may be switchable during | |
84 the assembly process. These are known as pragmas and are, by definition, | |
85 not portable between assemblers.</P | |
86 ><P | |
87 >LWASM supports a number of pragmas that affect code generation or | |
88 otherwise affect the behaviour of the assembler. These may be specified by | |
89 way of a command line option or by assembler directives. The directives | |
90 are as follows.</P | |
91 ><P | |
92 ></P | |
93 ><DIV | |
94 CLASS="VARIABLELIST" | |
95 ><DL | |
96 ><DT | |
97 >PRAGMA <CODE | |
98 CLASS="PARAMETER" | |
99 >pragma[,...]</CODE | |
100 ></DT | |
101 ><DD | |
102 ><P | |
103 >Specifies that the assembler should bring into force all <CODE | |
104 CLASS="PARAMETER" | |
105 >pragma</CODE | |
106 >s | |
107 specified. Any unrecognized pragma will cause an assembly error. The new | |
108 pragmas will take effect immediately. This directive should be used when | |
109 the program will assemble incorrectly if the pragma is ignored or not supported.</P | |
110 ></DD | |
111 ><DT | |
112 >*PRAGMA <CODE | |
113 CLASS="PARAMETER" | |
114 >pragma[,...]</CODE | |
115 ></DT | |
116 ><DD | |
117 ><P | |
118 >This is identical to the PRAGMA directive except no error will occur with | |
119 unrecognized or unsupported pragmas. This directive, by virtue of starting | |
120 with a comment character, will also be ignored by assemblers that do not | |
121 support this directive. Use this variation if the pragma is not required | |
122 for correct functioning of the code.</P | |
123 ></DD | |
124 ><DT | |
125 >*PRAGMAPUSH <CODE | |
126 CLASS="PARAMETER" | |
127 >pragma[,...]</CODE | |
128 ></DT | |
129 ><DD | |
130 ><P | |
131 >This directive saves the current state of the specified pragma(s) for later retrieval. See discussion below for more information.</P | |
132 ><P | |
133 >This directive will not throw any errors for any reason.</P | |
134 ></DD | |
135 ><DT | |
136 >*PRAGMAPOP <CODE | |
137 CLASS="PARAMETER" | |
138 >pragma[,...]</CODE | |
139 ></DT | |
140 ><DD | |
141 ><P | |
142 >This directive restores the previously saved state of the specified pragma(s). See discussion below for more information.</P | |
143 ><P | |
144 >This directive will not throw any errors for any reason.</P | |
145 ></DD | |
146 ></DL | |
147 ></DIV | |
148 ><P | |
149 >Each pragma supported has a positive version and a negative version. | |
150 The positive version enables the pragma while the negative version disables | |
151 it. The negatitve version is simply the positive version with "no" prefixed | |
152 to it. For instance, "pragma" vs. "nopragma". When only one version is | |
153 listed below, its opposite can be obtained by prepending "no" if it is not | |
154 present or removing "no" from the beginning if it is present.</P | |
155 ><P | |
156 >Pragmas are not case sensitive.</P | |
157 ><P | |
158 ></P | |
159 ><DIV | |
160 CLASS="VARIABLELIST" | |
161 ><DL | |
162 ><DT | |
163 >index0tonone</DT | |
164 ><DD | |
165 ><P | |
166 >When in force, this pragma enables an optimization affecting indexed addressing | |
167 modes. When the offset expression in an indexed mode evaluates to zero but is | |
168 not explicity written as 0, this will replace the operand with the equivalent | |
169 no offset mode, thus creating slightly faster code. Because of the advantages | |
170 of this optimization, it is enabled by default.</P | |
171 ></DD | |
172 ><DT | |
173 >cescapes</DT | |
174 ><DD | |
175 ><P | |
176 >This pragma will cause strings in the FCC, FCS, and FCN pseudo operations to | |
177 have C-style escape sequences interpreted. The one departure from the official | |
178 spec is that unrecognized escape sequences will return either the character | |
179 immediately following the backslash or some undefined value. Do not rely | |
180 on the behaviour of undefined escape sequences.</P | |
181 ></DD | |
182 ><DT | |
183 >importundefexport</DT | |
184 ><DD | |
185 ><P | |
186 >This pragma is only valid for targets that support external references. When | |
187 in force, it will cause the EXPORT directive to act as IMPORT if the symbol | |
188 to be exported is not defined. This is provided for compatibility with the | |
189 output of gcc6809 and should not be used in hand written code. Because of | |
190 the confusion this pragma can cause, it is disabled by default.</P | |
191 ></DD | |
192 ><DT | |
193 >undefextern</DT | |
194 ><DD | |
195 ><P | |
196 >This pragma is only valid for targets that support external references. When in | |
197 force, if the assembler sees an undefined symbol on the second pass, it will | |
198 automatically define it as an external symbol. This automatic definition will | |
199 apply for the remainder of the assembly process, even if the pragma is | |
200 subsequently turned off. Because this behaviour would be potentially surprising, | |
201 this pragma defaults to off.</P | |
202 ><P | |
203 >The primary use for this pragma is for projects that share a large number of | |
204 symbols between source files. In such cases, it is impractical to enumerate | |
205 all the external references in every source file. This allows the assembler | |
206 and linker to do the heavy lifting while not preventing a particular source | |
207 module from defining a local symbol of the same name as an external symbol | |
208 if it does not need the external symbol. (This pragma will not cause an | |
209 automatic external definition if there is already a locally defined symbol.)</P | |
210 ><P | |
211 >This pragma will often be specified on the command line for large projects. | |
212 However, depending on the specific dynamics of the project, it may be sufficient | |
213 for one or two files to use this pragma internally.</P | |
214 ></DD | |
215 ><DT | |
216 >export</DT | |
217 ><DD | |
218 ><P | |
219 >This pragma causes all symbols to be added to the export list | |
220 automatically. This is useful when a large number of symbols need to be | |
221 exported but you do not wish to include an EXPORT directive for all of them. | |
222 This is often useful on the command line but might be useful even inline | |
223 with the PRAGMA directive if a large number of symbols in a row are to be | |
224 exported.</P | |
225 ></DD | |
226 ><DT | |
227 >dollarlocal</DT | |
228 ><DD | |
229 ><P | |
230 >When set, a "$" in a symbol makes it local. When not set, "$" does not | |
231 cause a symbol to be local. It is set by default except when using the OS9 | |
232 target.</P | |
233 ></DD | |
234 ><DT | |
235 >dollarnotlocal</DT | |
236 ><DD | |
237 ><P | |
238 > This is the same as the "dollarlocal" pragma except its sense is | |
239 reversed. That is, "dollarlocal" and "nodollarnotlocal" are equivalent and | |
240 "nodollarlocal" and "dollarnotlocal" are equivalent. </P | |
241 ></DD | |
242 ><DT | |
243 >pcaspcr</DT | |
244 ><DD | |
245 ><P | |
246 > Normally, LWASM makes a distinction between PC and PCR in program | |
247 counter relative addressing. In particular, the use of PC means an absolute | |
248 offset from PC while PCR causes the assembler to calculate the offset to the | |
249 specified operand and use that as the offset from PC. By setting this | |
250 pragma, you can have PC treated the same as PCR. </P | |
251 ></DD | |
252 ><DT | |
253 >shadow</DT | |
254 ><DD | |
255 ><P | |
256 >When this pragma is in effect, it becomes possible to define a macro | |
257 that matches an internal operation code. Thus, it makes it possible to | |
258 redefine either CPU instructions or pseudo operations. Because this feature | |
259 is of dubious utility, it is disabled by default.</P | |
260 ></DD | |
261 ><DT | |
262 >nolist</DT | |
263 ><DD | |
264 ><P | |
265 >Lines where this pragma is in effect will not appear in the assembly | |
266 listing. Also, any symbols defined under this pragma will not show up in | |
267 the symbol list. This is most useful in include files to avoid spamming the | |
268 assembly listing with dozens, hundreds, or thousands of irrelevant | |
269 symbols.</P | |
270 ></DD | |
271 ><DT | |
272 >autobranchlength</DT | |
273 ><DD | |
274 ><P | |
275 >One of the perennial annoyances for 6809 programmers is that the | |
276 mneumonics for the short and long branch instructions are different (bxx vs. | |
277 lbxx), which is at odds with the rest of the instruction set. This pragma | |
278 is a solution to those annoying byte overflow errors that short branch | |
279 instructions tend to aquire.</P | |
280 ><P | |
281 >When this pragma is in effect, which is not the default, whenever any | |
282 relative branch instruction is used, its size will be automatically | |
283 determined based on the actual distance to the destination. In other words, | |
284 one can write code with long or short branches everywhere and the assembler | |
285 will choose a size for the branch.</P | |
286 ><P | |
287 >Also, while this pragma is in effect, the > and < symbols can be used | |
288 to force the branch size, analogous to their use for other instructions with | |
289 < forcing 8 bit offsets and > forcing 16 bit offets.</P | |
290 ><P | |
291 >Because this pragma leads to source that is incompatible with other | |
292 assemblers, it is strongly recommended that it be invoked using the PRAGMA | |
293 directive within the source code rather than on the command line or via the | |
294 *PRAGMA directive. This way, an error will be raised if someone tries to | |
295 assemble the code under a different assembler.</P | |
296 ></DD | |
297 ><DT | |
298 >nosymbolcase, symbolnocase</DT | |
299 ><DD | |
300 ><P | |
301 >Any symbol defined while this pragma is in force will be treated as | |
302 case insensitive, regardless whether the pragma is in force when the symbol | |
303 is referenced.</P | |
304 ><P | |
305 >It is important to note that this pragma will not work as expected in | |
306 all cases when using the object file assembly target. It is intended for | |
307 use only when the assembler will be producing the final binary.</P | |
308 ></DD | |
309 ><DT | |
310 >condundefzero</DT | |
311 ><DD | |
312 ><P | |
313 >This pragma will cause the assembler to change the way it handles | |
314 symbols in conditional expressions. Ordinarily, any symbol that is not | |
315 defined prior to the conditional will throw an undefined symbol error. With | |
316 this pragma in effect, symbols that are not yet defined at the point the | |
317 conditional is encountered will be treated as zero.</P | |
318 ><P | |
319 >This is not the default because it encourages poor code design. One | |
320 should use the "IFDEF" or "IFNDEF" conditionals to test for the presence of | |
321 a symbol.</P | |
322 ><P | |
323 >It is important to note that if a symbol is defined but it does not | |
324 yet evaluate to a constant value at the point where the conditional appears, | |
325 the assembler will still complain about a non constant condition.</P | |
326 ></DD | |
327 ></DL | |
328 ></DIV | |
329 ><P | |
330 >As a convenience, each input file has a pragma state stack. This | |
331 allows, through the use of *PRAGMAPUSH and *PRAGMAPOP, a file to change a | |
332 pragma state and then restore it to the precise state it had previously. | |
333 If, at the end of an input file, all pragma states have not been popped, | |
334 they will be removed from the stack. Thus, it is critical to employ | |
335 *PRAGMAPOP correctly. Because each input file has its own pragma stack, | |
336 using *PRAGMAPUSH in one file and *PRAGMAPOP in another file will not | |
337 work.</P | |
338 ><P | |
339 >Pragma stacks are more useful in include files, in particular in | |
340 conjunction with the nolist pragma. One can push the state of the nolist | |
341 pragma, engage the nolist pragma, and then pop the state of the nolist | |
342 pragma at the end of the include file. This will cause the entire include | |
343 file to operate under the nolist pragma. However, if the file is included | |
344 while nolist is already engaged, it will not undo that state.</P | |
345 ></DIV | |
346 ><DIV | |
347 CLASS="NAVFOOTER" | |
348 ><HR | |
349 ALIGN="LEFT" | |
350 WIDTH="100%"><TABLE | |
351 SUMMARY="Footer navigation table" | |
352 WIDTH="100%" | |
353 BORDER="0" | |
354 CELLPADDING="0" | |
355 CELLSPACING="0" | |
356 ><TR | |
357 ><TD | |
358 WIDTH="33%" | |
359 ALIGN="left" | |
360 VALIGN="top" | |
361 ><A | |
362 HREF="x555.html" | |
363 ACCESSKEY="P" | |
364 >Prev</A | |
365 ></TD | |
366 ><TD | |
367 WIDTH="34%" | |
368 ALIGN="center" | |
369 VALIGN="top" | |
370 ><A | |
371 HREF="index.html" | |
372 ACCESSKEY="H" | |
373 >Home</A | |
374 ></TD | |
375 ><TD | |
376 WIDTH="33%" | |
377 ALIGN="right" | |
378 VALIGN="top" | |
379 ><A | |
380 HREF="c713.html" | |
381 ACCESSKEY="N" | |
382 >Next</A | |
383 ></TD | |
384 ></TR | |
385 ><TR | |
386 ><TD | |
387 WIDTH="33%" | |
388 ALIGN="left" | |
389 VALIGN="top" | |
390 >Object Files and Sections</TD | |
391 ><TD | |
392 WIDTH="34%" | |
393 ALIGN="center" | |
394 VALIGN="top" | |
395 ><A | |
396 HREF="c62.html" | |
397 ACCESSKEY="U" | |
398 >Up</A | |
399 ></TD | |
400 ><TD | |
401 WIDTH="33%" | |
402 ALIGN="right" | |
403 VALIGN="top" | |
404 >LWLINK</TD | |
405 ></TR | |
406 ></TABLE | |
407 ></DIV | |
408 ></BODY | |
409 ></HTML | |
410 > |