Mercurial > hg > index.cgi
comparison docs/manual/x639.html @ 369:682524a1f32f
Updated documentation for --symbols-nolocals and --map
author | William Astle <lost@l-w.ca> |
---|---|
date | Mon, 22 Jun 2015 18:38:30 -0600 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
368:362f8fb0695b | 369:682524a1f32f |
---|---|
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="x575.html"><LINK | |
18 REL="NEXT" | |
19 TITLE="LWLINK" | |
20 HREF="c745.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="x575.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="c745.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="AEN639" | |
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 >6800compat</DT | |
164 ><DD | |
165 ><P | |
166 >When in force, this pragma enables recognition of various | |
167 compatibility instructions useful when assembling 6800 code. These | |
168 compatibility instructions are assembled into equivalent 6809 instructions. | |
169 This mode also includes several analogous instructions which are not | |
170 strictly 6800 instructions but allow the similar style to be applied to 6809 | |
171 specific features.</P | |
172 ><P | |
173 >Technically, a compliant 6809 assembler must recognize these | |
174 instructions by default since Motorola advertised the 6809 as being source | |
175 compatible with the 6800. However, most source code does not require this | |
176 compatibility and LWASM itself did not support these instructions prior to | |
177 version 4.11 so this mode is disabled by default.</P | |
178 ></DD | |
179 ><DT | |
180 >index0tonone</DT | |
181 ><DD | |
182 ><P | |
183 >When in force, this pragma enables an optimization affecting indexed addressing | |
184 modes. When the offset expression in an indexed mode evaluates to zero but is | |
185 not explicity written as 0, this will replace the operand with the equivalent | |
186 no offset mode, thus creating slightly faster code. Because of the advantages | |
187 of this optimization, it is enabled by default.</P | |
188 ></DD | |
189 ><DT | |
190 >cescapes</DT | |
191 ><DD | |
192 ><P | |
193 >This pragma will cause strings in the FCC, FCS, and FCN pseudo operations to | |
194 have C-style escape sequences interpreted. The one departure from the official | |
195 spec is that unrecognized escape sequences will return either the character | |
196 immediately following the backslash or some undefined value. Do not rely | |
197 on the behaviour of undefined escape sequences.</P | |
198 ></DD | |
199 ><DT | |
200 >importundefexport</DT | |
201 ><DD | |
202 ><P | |
203 >This pragma is only valid for targets that support external references. When | |
204 in force, it will cause the EXPORT directive to act as IMPORT if the symbol | |
205 to be exported is not defined. This is provided for compatibility with the | |
206 output of gcc6809 and should not be used in hand written code. Because of | |
207 the confusion this pragma can cause, it is disabled by default.</P | |
208 ></DD | |
209 ><DT | |
210 >undefextern</DT | |
211 ><DD | |
212 ><P | |
213 >This pragma is only valid for targets that support external references. When in | |
214 force, if the assembler sees an undefined symbol on the second pass, it will | |
215 automatically define it as an external symbol. This automatic definition will | |
216 apply for the remainder of the assembly process, even if the pragma is | |
217 subsequently turned off. Because this behaviour would be potentially surprising, | |
218 this pragma defaults to off.</P | |
219 ><P | |
220 >The primary use for this pragma is for projects that share a large number of | |
221 symbols between source files. In such cases, it is impractical to enumerate | |
222 all the external references in every source file. This allows the assembler | |
223 and linker to do the heavy lifting while not preventing a particular source | |
224 module from defining a local symbol of the same name as an external symbol | |
225 if it does not need the external symbol. (This pragma will not cause an | |
226 automatic external definition if there is already a locally defined symbol.)</P | |
227 ><P | |
228 >This pragma will often be specified on the command line for large projects. | |
229 However, depending on the specific dynamics of the project, it may be sufficient | |
230 for one or two files to use this pragma internally.</P | |
231 ></DD | |
232 ><DT | |
233 >export</DT | |
234 ><DD | |
235 ><P | |
236 >This pragma causes all symbols to be added to the export list | |
237 automatically. This is useful when a large number of symbols need to be | |
238 exported but you do not wish to include an EXPORT directive for all of them. | |
239 This is often useful on the command line but might be useful even inline | |
240 with the PRAGMA directive if a large number of symbols in a row are to be | |
241 exported.</P | |
242 ></DD | |
243 ><DT | |
244 >dollarlocal</DT | |
245 ><DD | |
246 ><P | |
247 >When set, a "$" in a symbol makes it local. When not set, "$" does not | |
248 cause a symbol to be local. It is set by default except when using the OS9 | |
249 target.</P | |
250 ></DD | |
251 ><DT | |
252 >dollarnotlocal</DT | |
253 ><DD | |
254 ><P | |
255 > This is the same as the "dollarlocal" pragma except its sense is | |
256 reversed. That is, "dollarlocal" and "nodollarnotlocal" are equivalent and | |
257 "nodollarlocal" and "dollarnotlocal" are equivalent. </P | |
258 ></DD | |
259 ><DT | |
260 >pcaspcr</DT | |
261 ><DD | |
262 ><P | |
263 > Normally, LWASM makes a distinction between PC and PCR in program | |
264 counter relative addressing. In particular, the use of PC means an absolute | |
265 offset from PC while PCR causes the assembler to calculate the offset to the | |
266 specified operand and use that as the offset from PC. By setting this | |
267 pragma, you can have PC treated the same as PCR. </P | |
268 ></DD | |
269 ><DT | |
270 >shadow</DT | |
271 ><DD | |
272 ><P | |
273 >When this pragma is in effect, it becomes possible to define a macro | |
274 that matches an internal operation code. Thus, it makes it possible to | |
275 redefine either CPU instructions or pseudo operations. Because this feature | |
276 is of dubious utility, it is disabled by default.</P | |
277 ></DD | |
278 ><DT | |
279 >nolist</DT | |
280 ><DD | |
281 ><P | |
282 >Lines where this pragma is in effect will not appear in the assembly | |
283 listing. Also, any symbols defined under this pragma will not show up in | |
284 the symbol list. This is most useful in include files to avoid spamming the | |
285 assembly listing with dozens, hundreds, or thousands of irrelevant | |
286 symbols.</P | |
287 ></DD | |
288 ><DT | |
289 >autobranchlength</DT | |
290 ><DD | |
291 ><P | |
292 >One of the perennial annoyances for 6809 programmers is that the | |
293 mneumonics for the short and long branch instructions are different (bxx vs. | |
294 lbxx), which is at odds with the rest of the instruction set. This pragma | |
295 is a solution to those annoying byte overflow errors that short branch | |
296 instructions tend to aquire.</P | |
297 ><P | |
298 >When this pragma is in effect, which is not the default, whenever any | |
299 relative branch instruction is used, its size will be automatically | |
300 determined based on the actual distance to the destination. In other words, | |
301 one can write code with long or short branches everywhere and the assembler | |
302 will choose a size for the branch.</P | |
303 ><P | |
304 >Also, while this pragma is in effect, the > and < symbols can be used | |
305 to force the branch size, analogous to their use for other instructions with | |
306 < forcing 8 bit offsets and > forcing 16 bit offets.</P | |
307 ><P | |
308 >Because this pragma leads to source that is incompatible with other | |
309 assemblers, it is strongly recommended that it be invoked using the PRAGMA | |
310 directive within the source code rather than on the command line or via the | |
311 *PRAGMA directive. This way, an error will be raised if someone tries to | |
312 assemble the code under a different assembler.</P | |
313 ></DD | |
314 ><DT | |
315 >nosymbolcase, symbolnocase</DT | |
316 ><DD | |
317 ><P | |
318 >Any symbol defined while this pragma is in force will be treated as | |
319 case insensitive, regardless whether the pragma is in force when the symbol | |
320 is referenced.</P | |
321 ><P | |
322 >It is important to note that this pragma will not work as expected in | |
323 all cases when using the object file assembly target. It is intended for | |
324 use only when the assembler will be producing the final binary.</P | |
325 ></DD | |
326 ><DT | |
327 >condundefzero</DT | |
328 ><DD | |
329 ><P | |
330 >This pragma will cause the assembler to change the way it handles | |
331 symbols in conditional expressions. Ordinarily, any symbol that is not | |
332 defined prior to the conditional will throw an undefined symbol error. With | |
333 this pragma in effect, symbols that are not yet defined at the point the | |
334 conditional is encountered will be treated as zero.</P | |
335 ><P | |
336 >This is not the default because it encourages poor code design. One | |
337 should use the "IFDEF" or "IFNDEF" conditionals to test for the presence of | |
338 a symbol.</P | |
339 ><P | |
340 >It is important to note that if a symbol is defined but it does not | |
341 yet evaluate to a constant value at the point where the conditional appears, | |
342 the assembler will still complain about a non constant condition.</P | |
343 ></DD | |
344 ><DT | |
345 >forwardrefmax</DT | |
346 ><DD | |
347 ><P | |
348 >This pragma will disable forward reference optimization completely. | |
349 Ordinarily, LWASM will attempt to select the shortest possible addressing | |
350 mode for forward references. However, in many source files, especially | |
351 those not using the PCR relative addressing modes, this optimization is | |
352 pointless since the assembler will almost certainly settle on a 16 bit | |
353 offset or address. If all variables in the direct page are defined before | |
354 the main body of the code, the benefit of forward reference optimization | |
355 almost certainly vanishes completely. However, the cost of doing that | |
356 optimization remains and can result in a very long assembly time.</P | |
357 ><P | |
358 >Enabling this pragma will cause all forward references to use the | |
359 maximum offset or address size, much the same has EDTASM and other pure | |
360 two pass assemblers do. The side effect is that all line lengths and | |
361 symbol values are fully resolved after the initial parsing pass and the | |
362 amount of work to resolve everything becomes almost nil.</P | |
363 ><P | |
364 >While this pragma can be applied selectively to sections of source | |
365 code (use *PRAGMA if doing so and compatibility with other assemblers | |
366 is desired), it is likely more useful when provided as a command line | |
367 pragma.</P | |
368 ><P | |
369 >It should be noted that the presence or absence of this pragma | |
370 will not change the correctness of the generated code unless cycle counts | |
371 or byte counts are critical (which they usually are not). It also will | |
372 not override the operand size override prefixes (< and >). It only | |
373 applies when the assembler is left to guess what the operand size is.</P | |
374 ></DD | |
375 ></DL | |
376 ></DIV | |
377 ><P | |
378 >As a convenience, each input file has a pragma state stack. This | |
379 allows, through the use of *PRAGMAPUSH and *PRAGMAPOP, a file to change a | |
380 pragma state and then restore it to the precise state it had previously. | |
381 If, at the end of an input file, all pragma states have not been popped, | |
382 they will be removed from the stack. Thus, it is critical to employ | |
383 *PRAGMAPOP correctly. Because each input file has its own pragma stack, | |
384 using *PRAGMAPUSH in one file and *PRAGMAPOP in another file will not | |
385 work.</P | |
386 ><P | |
387 >Pragma stacks are more useful in include files, in particular in | |
388 conjunction with the nolist pragma. One can push the state of the nolist | |
389 pragma, engage the nolist pragma, and then pop the state of the nolist | |
390 pragma at the end of the include file. This will cause the entire include | |
391 file to operate under the nolist pragma. However, if the file is included | |
392 while nolist is already engaged, it will not undo that state.</P | |
393 ></DIV | |
394 ><DIV | |
395 CLASS="NAVFOOTER" | |
396 ><HR | |
397 ALIGN="LEFT" | |
398 WIDTH="100%"><TABLE | |
399 SUMMARY="Footer navigation table" | |
400 WIDTH="100%" | |
401 BORDER="0" | |
402 CELLPADDING="0" | |
403 CELLSPACING="0" | |
404 ><TR | |
405 ><TD | |
406 WIDTH="33%" | |
407 ALIGN="left" | |
408 VALIGN="top" | |
409 ><A | |
410 HREF="x575.html" | |
411 ACCESSKEY="P" | |
412 >Prev</A | |
413 ></TD | |
414 ><TD | |
415 WIDTH="34%" | |
416 ALIGN="center" | |
417 VALIGN="top" | |
418 ><A | |
419 HREF="index.html" | |
420 ACCESSKEY="H" | |
421 >Home</A | |
422 ></TD | |
423 ><TD | |
424 WIDTH="33%" | |
425 ALIGN="right" | |
426 VALIGN="top" | |
427 ><A | |
428 HREF="c745.html" | |
429 ACCESSKEY="N" | |
430 >Next</A | |
431 ></TD | |
432 ></TR | |
433 ><TR | |
434 ><TD | |
435 WIDTH="33%" | |
436 ALIGN="left" | |
437 VALIGN="top" | |
438 >Object Files and Sections</TD | |
439 ><TD | |
440 WIDTH="34%" | |
441 ALIGN="center" | |
442 VALIGN="top" | |
443 ><A | |
444 HREF="c62.html" | |
445 ACCESSKEY="U" | |
446 >Up</A | |
447 ></TD | |
448 ><TD | |
449 WIDTH="33%" | |
450 ALIGN="right" | |
451 VALIGN="top" | |
452 >LWLINK</TD | |
453 ></TR | |
454 ></TABLE | |
455 ></DIV | |
456 ></BODY | |
457 ></HTML | |
458 > |