|
455
|
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="x595.html"><LINK
|
|
|
18 REL="NEXT"
|
|
|
19 TITLE="Convenience Instructions"
|
|
|
20 HREF="x800.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="x595.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="x800.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="AEN659"
|
|
|
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 >6809</DT
|
|
|
181 ><DD
|
|
|
182 ><P
|
|
|
183 >This pragma allows you to mark a section of code as 6809-only. In ths mode,
|
|
|
184 the assembler will throw an error if any 6309 instructions are used.</P
|
|
|
185 ></DD
|
|
|
186 ><DT
|
|
|
187 >6309</DT
|
|
|
188 ><DD
|
|
|
189 ><P
|
|
|
190 >This pragma enables the use of 6309 instructions and disables any 6809 specific
|
|
|
191 instructions. It also changes the cycle count listing output (if selected)
|
|
|
192 to display 6309 timings.</P
|
|
|
193 ></DD
|
|
|
194 ><DT
|
|
|
195 >6809conv, 6309conv</DT
|
|
|
196 ><DD
|
|
|
197 ><P
|
|
|
198 >These pragmas enable convenience instructions extending the 6809 and 6309
|
|
|
199 instruction sets respectively. For more information, see
|
|
|
200 <A
|
|
|
201 HREF="x800.html"
|
|
|
202 >Section 3.11</A
|
|
|
203 >.</P
|
|
|
204 ></DD
|
|
|
205 ><DT
|
|
|
206 >index0tonone</DT
|
|
|
207 ><DD
|
|
|
208 ><P
|
|
|
209 >When in force, this pragma enables an optimization affecting indexed addressing
|
|
|
210 modes. When the offset expression in an indexed mode evaluates to zero but is
|
|
|
211 not explicity written as 0, this will replace the operand with the equivalent
|
|
|
212 no offset mode, thus creating slightly faster code. Because of the advantages
|
|
|
213 of this optimization, it is enabled by default.</P
|
|
|
214 ></DD
|
|
|
215 ><DT
|
|
|
216 >cescapes</DT
|
|
|
217 ><DD
|
|
|
218 ><P
|
|
|
219 >This pragma will cause strings in the FCC, FCS, and FCN pseudo operations to
|
|
|
220 have C-style escape sequences interpreted. The one departure from the official
|
|
|
221 spec is that unrecognized escape sequences will return either the character
|
|
|
222 immediately following the backslash or some undefined value. Do not rely
|
|
|
223 on the behaviour of undefined escape sequences.</P
|
|
|
224 ></DD
|
|
|
225 ><DT
|
|
|
226 >importundefexport</DT
|
|
|
227 ><DD
|
|
|
228 ><P
|
|
|
229 >This pragma is only valid for targets that support external references. When
|
|
|
230 in force, it will cause the EXPORT directive to act as IMPORT if the symbol
|
|
|
231 to be exported is not defined. This is provided for compatibility with the
|
|
|
232 output of gcc6809 and should not be used in hand written code. Because of
|
|
|
233 the confusion this pragma can cause, it is disabled by default.</P
|
|
|
234 ></DD
|
|
|
235 ><DT
|
|
|
236 >undefextern</DT
|
|
|
237 ><DD
|
|
|
238 ><P
|
|
|
239 >This pragma is only valid for targets that support external references. When in
|
|
|
240 force, if the assembler sees an undefined symbol on the second pass, it will
|
|
|
241 automatically define it as an external symbol. This automatic definition will
|
|
|
242 apply for the remainder of the assembly process, even if the pragma is
|
|
|
243 subsequently turned off. Because this behaviour would be potentially surprising,
|
|
|
244 this pragma defaults to off.</P
|
|
|
245 ><P
|
|
|
246 >The primary use for this pragma is for projects that share a large number of
|
|
|
247 symbols between source files. In such cases, it is impractical to enumerate
|
|
|
248 all the external references in every source file. This allows the assembler
|
|
|
249 and linker to do the heavy lifting while not preventing a particular source
|
|
|
250 module from defining a local symbol of the same name as an external symbol
|
|
|
251 if it does not need the external symbol. (This pragma will not cause an
|
|
|
252 automatic external definition if there is already a locally defined symbol.)</P
|
|
|
253 ><P
|
|
|
254 >This pragma will often be specified on the command line for large projects.
|
|
|
255 However, depending on the specific dynamics of the project, it may be sufficient
|
|
|
256 for one or two files to use this pragma internally.</P
|
|
|
257 ></DD
|
|
|
258 ><DT
|
|
|
259 >export</DT
|
|
|
260 ><DD
|
|
|
261 ><P
|
|
|
262 >This pragma causes all symbols to be added to the export list
|
|
|
263 automatically. This is useful when a large number of symbols need to be
|
|
|
264 exported but you do not wish to include an EXPORT directive for all of them.
|
|
|
265 This is often useful on the command line but might be useful even inline
|
|
|
266 with the PRAGMA directive if a large number of symbols in a row are to be
|
|
|
267 exported.</P
|
|
|
268 ></DD
|
|
|
269 ><DT
|
|
|
270 >dollarlocal</DT
|
|
|
271 ><DD
|
|
|
272 ><P
|
|
|
273 >When set, a "$" in a symbol makes it local. When not set, "$" does not
|
|
|
274 cause a symbol to be local. It is set by default except when using the OS9
|
|
|
275 target.</P
|
|
|
276 ></DD
|
|
|
277 ><DT
|
|
|
278 >dollarnotlocal</DT
|
|
|
279 ><DD
|
|
|
280 ><P
|
|
|
281 > This is the same as the "dollarlocal" pragma except its sense is
|
|
|
282 reversed. That is, "dollarlocal" and "nodollarnotlocal" are equivalent and
|
|
|
283 "nodollarlocal" and "dollarnotlocal" are equivalent. </P
|
|
|
284 ></DD
|
|
|
285 ><DT
|
|
|
286 >pcaspcr</DT
|
|
|
287 ><DD
|
|
|
288 ><P
|
|
|
289 > Normally, LWASM makes a distinction between PC and PCR in program
|
|
|
290 counter relative addressing. In particular, the use of PC means an absolute
|
|
|
291 offset from PC while PCR causes the assembler to calculate the offset to the
|
|
|
292 specified operand and use that as the offset from PC. By setting this
|
|
|
293 pragma, you can have PC treated the same as PCR. </P
|
|
|
294 ></DD
|
|
|
295 ><DT
|
|
|
296 >shadow</DT
|
|
|
297 ><DD
|
|
|
298 ><P
|
|
|
299 >When this pragma is in effect, it becomes possible to define a macro
|
|
|
300 that matches an internal operation code. Thus, it makes it possible to
|
|
|
301 redefine either CPU instructions or pseudo operations. Because this feature
|
|
|
302 is of dubious utility, it is disabled by default.</P
|
|
|
303 ></DD
|
|
|
304 ><DT
|
|
|
305 >nolist</DT
|
|
|
306 ><DD
|
|
|
307 ><P
|
|
|
308 >Lines where this pragma is in effect will not appear in the assembly
|
|
|
309 listing. Also, any symbols defined under this pragma will not show up in
|
|
|
310 the symbol list. This is most useful in include files to avoid spamming the
|
|
|
311 assembly listing with dozens, hundreds, or thousands of irrelevant
|
|
|
312 symbols.</P
|
|
|
313 ></DD
|
|
|
314 ><DT
|
|
|
315 >autobranchlength</DT
|
|
|
316 ><DD
|
|
|
317 ><P
|
|
|
318 >One of the perennial annoyances for 6809 programmers is that the
|
|
|
319 mneumonics for the short and long branch instructions are different (bxx vs.
|
|
|
320 lbxx), which is at odds with the rest of the instruction set. This pragma
|
|
|
321 is a solution to those annoying byte overflow errors that short branch
|
|
|
322 instructions tend to aquire.</P
|
|
|
323 ><P
|
|
|
324 >When this pragma is in effect, which is not the default, whenever any
|
|
|
325 relative branch instruction is used, its size will be automatically
|
|
|
326 determined based on the actual distance to the destination. In other words,
|
|
|
327 one can write code with long or short branches everywhere and the assembler
|
|
|
328 will choose a size for the branch.</P
|
|
|
329 ><P
|
|
|
330 >Also, while this pragma is in effect, the > and < symbols can be used
|
|
|
331 to force the branch size, analogous to their use for other instructions with
|
|
|
332 < forcing 8 bit offsets and > forcing 16 bit offets.</P
|
|
|
333 ><P
|
|
|
334 >Because this pragma leads to source that is incompatible with other
|
|
|
335 assemblers, it is strongly recommended that it be invoked using the PRAGMA
|
|
|
336 directive within the source code rather than on the command line or via the
|
|
|
337 *PRAGMA directive. This way, an error will be raised if someone tries to
|
|
|
338 assemble the code under a different assembler.</P
|
|
|
339 ></DD
|
|
|
340 ><DT
|
|
|
341 >nosymbolcase, symbolnocase</DT
|
|
|
342 ><DD
|
|
|
343 ><P
|
|
|
344 >Any symbol defined while this pragma is in force will be treated as
|
|
|
345 case insensitive, regardless whether the pragma is in force when the symbol
|
|
|
346 is referenced.</P
|
|
|
347 ><P
|
|
|
348 >It is important to note that this pragma will not work as expected in
|
|
|
349 all cases when using the object file assembly target. It is intended for
|
|
|
350 use only when the assembler will be producing the final binary.</P
|
|
|
351 ></DD
|
|
|
352 ><DT
|
|
|
353 >condundefzero</DT
|
|
|
354 ><DD
|
|
|
355 ><P
|
|
|
356 >This pragma will cause the assembler to change the way it handles
|
|
|
357 symbols in conditional expressions. Ordinarily, any symbol that is not
|
|
|
358 defined prior to the conditional will throw an undefined symbol error. With
|
|
|
359 this pragma in effect, symbols that are not yet defined at the point the
|
|
|
360 conditional is encountered will be treated as zero.</P
|
|
|
361 ><P
|
|
|
362 >This is not the default because it encourages poor code design. One
|
|
|
363 should use the "IFDEF" or "IFNDEF" conditionals to test for the presence of
|
|
|
364 a symbol.</P
|
|
|
365 ><P
|
|
|
366 >It is important to note that if a symbol is defined but it does not
|
|
|
367 yet evaluate to a constant value at the point where the conditional appears,
|
|
|
368 the assembler will still complain about a non constant condition.</P
|
|
|
369 ></DD
|
|
|
370 ><DT
|
|
|
371 >forwardrefmax</DT
|
|
|
372 ><DD
|
|
|
373 ><P
|
|
|
374 >This pragma will disable forward reference optimization completely.
|
|
|
375 Ordinarily, LWASM will attempt to select the shortest possible addressing
|
|
|
376 mode for forward references. However, in many source files, especially
|
|
|
377 those not using the PCR relative addressing modes, this optimization is
|
|
|
378 pointless since the assembler will almost certainly settle on a 16 bit
|
|
|
379 offset or address. If all variables in the direct page are defined before
|
|
|
380 the main body of the code, the benefit of forward reference optimization
|
|
|
381 almost certainly vanishes completely. However, the cost of doing that
|
|
|
382 optimization remains and can result in a very long assembly time.</P
|
|
|
383 ><P
|
|
|
384 >Enabling this pragma will cause all forward references to use the
|
|
|
385 maximum offset or address size, much the same has EDTASM and other pure
|
|
|
386 two pass assemblers do. The side effect is that all line lengths and
|
|
|
387 symbol values are fully resolved after the initial parsing pass and the
|
|
|
388 amount of work to resolve everything becomes almost nil.</P
|
|
|
389 ><P
|
|
|
390 >While this pragma can be applied selectively to sections of source
|
|
|
391 code (use *PRAGMA if doing so and compatibility with other assemblers
|
|
|
392 is desired), it is likely more useful when provided as a command line
|
|
|
393 pragma.</P
|
|
|
394 ><P
|
|
|
395 >It should be noted that the presence or absence of this pragma
|
|
|
396 will not change the correctness of the generated code unless cycle counts
|
|
|
397 or byte counts are critical (which they usually are not). It also will
|
|
|
398 not override the operand size override prefixes (< and >). It only
|
|
|
399 applies when the assembler is left to guess what the operand size is.</P
|
|
|
400 ></DD
|
|
|
401 ><DT
|
|
|
402 >operandsizewarning</DT
|
|
|
403 ><DD
|
|
|
404 ><P
|
|
|
405 >Enabling this pragma will cause LWASM to show a warning when it
|
|
|
406 detects that a smaller addressing mode could be used for an instruction.
|
|
|
407 This is particularly useful for finding places where long branches are used
|
|
|
408 where short branches could be used instead. It will also show the warnings
|
|
|
409 for indexing offsets (regardless of whether the operand size is
|
|
|
410 forced).</P
|
|
|
411 ><P
|
|
|
412 >As of LWASM 4.16, no other checks are performed.</P
|
|
|
413 ></DD
|
|
|
414 ><DT
|
|
|
415 >qrts</DT
|
|
|
416 ><DD
|
|
|
417 ><P
|
|
|
418 > Enables the use of the ?RTS branch target. ?RTS is implemented to maintain
|
|
|
419 compatibility with the MACRO-80c assembler. It works by searching backward
|
|
|
420 in the code for an RTS instruction. If none is found, it inverts the branch
|
|
|
421 logic and inserts an RTS following the branch instruction. Below you can
|
|
|
422 see how a BMI (2B xx) has been assembled as a BPL *+1 (2A 01) to skip over an
|
|
|
423 inserted RTS (39).</P
|
|
|
424 ><PRE
|
|
|
425 CLASS="PROGRAMLISTING"
|
|
|
426 >1D1E 7D1D1D TST WHICH1
|
|
|
427 1D21 2A0139 BMI ?RTS
|
|
|
428 1D24 BD1D65 JSR INV</PRE
|
|
|
429 ></DD
|
|
|
430 ><DT
|
|
|
431 >m80ext</DT
|
|
|
432 ><DD
|
|
|
433 ><P
|
|
|
434 > This pragma (along with pragma qrts) enables some uncommon behaviors to
|
|
|
435 accomodate The Micro Works MACRO-80c assembler from 1982. This assembler
|
|
|
436 was used by a number of notable TRS-80 Color Computer applications and the
|
|
|
437 goal of this pragma is to allow them to build identical binaries from
|
|
|
438 unmodified, vintage source code.</P
|
|
|
439 ><P
|
|
|
440 > In m80ext mode, the handling of the "END" pseudo-op changes when used inside
|
|
|
441 an include file. Instead of terminating all assembly, it merely stops
|
|
|
442 processing of the current include file (this behavior matches the original
|
|
|
443 Motorola 6809 assembler). In addition, loading an ASCII value with a single
|
|
|
444 quote (e.g., LDA #'N) is extended to 16-bit registers (e.g., LDD #'NO).
|
|
|
445 LWASM normally supports this via double quote and that is the proper use in
|
|
|
446 modern code. Finally, the FCC pseudo-op is extended to handle FCB-like
|
|
|
447 behavior after the closing delimiter:</P
|
|
|
448 ><PRE
|
|
|
449 CLASS="PROGRAMLISTING"
|
|
|
450 > FCC "Greetings from 1982",13,0</PRE
|
|
|
451 ></DD
|
|
|
452 ><DT
|
|
|
453 >testmode</DT
|
|
|
454 ><DD
|
|
|
455 ><P
|
|
|
456 > This pragma is intended for internal testing purposes. In testmode, the
|
|
|
457 assembler searches for a specially-formatted comment starting with a
|
|
|
458 semicolon followed by a period. Immediately afterward are a list of hex
|
|
|
459 bytes that the assembler is expected to generate. Likewise, if the
|
|
|
460 assembler is expected to throw an error or warning on a given line, you can
|
|
|
461 check by specifying "E:" followed by the error number. In this case the
|
|
|
462 error is ignored and the assembler continues ignoring the line in question. </P
|
|
|
463 ><PRE
|
|
|
464 CLASS="PROGRAMLISTING"
|
|
|
465 >1D1E 7D1D1D TST WHICH1 ;.7d1d1d
|
|
|
466 1D21 2A0139 BMI ?RTS ;.2a0139
|
|
|
467 1D24 1D24 FDB * ;.1d24
|
|
|
468 1D26 xyz INV ;.E:32 (Error 32 is "Bad opcode")</PRE
|
|
|
469 ></DD
|
|
|
470 ></DL
|
|
|
471 ></DIV
|
|
|
472 ><P
|
|
|
473 >As a convenience, each input file has a pragma state stack. This
|
|
|
474 allows, through the use of *PRAGMAPUSH and *PRAGMAPOP, a file to change a
|
|
|
475 pragma state and then restore it to the precise state it had previously.
|
|
|
476 If, at the end of an input file, all pragma states have not been popped,
|
|
|
477 they will be removed from the stack. Thus, it is critical to employ
|
|
|
478 *PRAGMAPOP correctly. Because each input file has its own pragma stack,
|
|
|
479 using *PRAGMAPUSH in one file and *PRAGMAPOP in another file will not
|
|
|
480 work.</P
|
|
|
481 ><P
|
|
|
482 >Pragma stacks are more useful in include files, in particular in
|
|
|
483 conjunction with the nolist pragma. One can push the state of the nolist
|
|
|
484 pragma, engage the nolist pragma, and then pop the state of the nolist
|
|
|
485 pragma at the end of the include file. This will cause the entire include
|
|
|
486 file to operate under the nolist pragma. However, if the file is included
|
|
|
487 while nolist is already engaged, it will not undo that state.</P
|
|
|
488 ></DIV
|
|
|
489 ><DIV
|
|
|
490 CLASS="NAVFOOTER"
|
|
|
491 ><HR
|
|
|
492 ALIGN="LEFT"
|
|
|
493 WIDTH="100%"><TABLE
|
|
|
494 SUMMARY="Footer navigation table"
|
|
|
495 WIDTH="100%"
|
|
|
496 BORDER="0"
|
|
|
497 CELLPADDING="0"
|
|
|
498 CELLSPACING="0"
|
|
|
499 ><TR
|
|
|
500 ><TD
|
|
|
501 WIDTH="33%"
|
|
|
502 ALIGN="left"
|
|
|
503 VALIGN="top"
|
|
|
504 ><A
|
|
|
505 HREF="x595.html"
|
|
|
506 ACCESSKEY="P"
|
|
|
507 >Prev</A
|
|
|
508 ></TD
|
|
|
509 ><TD
|
|
|
510 WIDTH="34%"
|
|
|
511 ALIGN="center"
|
|
|
512 VALIGN="top"
|
|
|
513 ><A
|
|
|
514 HREF="index.html"
|
|
|
515 ACCESSKEY="H"
|
|
|
516 >Home</A
|
|
|
517 ></TD
|
|
|
518 ><TD
|
|
|
519 WIDTH="33%"
|
|
|
520 ALIGN="right"
|
|
|
521 VALIGN="top"
|
|
|
522 ><A
|
|
|
523 HREF="x800.html"
|
|
|
524 ACCESSKEY="N"
|
|
|
525 >Next</A
|
|
|
526 ></TD
|
|
|
527 ></TR
|
|
|
528 ><TR
|
|
|
529 ><TD
|
|
|
530 WIDTH="33%"
|
|
|
531 ALIGN="left"
|
|
|
532 VALIGN="top"
|
|
|
533 >Object Files and Sections</TD
|
|
|
534 ><TD
|
|
|
535 WIDTH="34%"
|
|
|
536 ALIGN="center"
|
|
|
537 VALIGN="top"
|
|
|
538 ><A
|
|
|
539 HREF="c62.html"
|
|
|
540 ACCESSKEY="U"
|
|
|
541 >Up</A
|
|
|
542 ></TD
|
|
|
543 ><TD
|
|
|
544 WIDTH="33%"
|
|
|
545 ALIGN="right"
|
|
|
546 VALIGN="top"
|
|
|
547 >Convenience Instructions</TD
|
|
|
548 ></TR
|
|
|
549 ></TABLE
|
|
|
550 ></DIV
|
|
|
551 ></BODY
|
|
|
552 ></HTML
|
|
|
553 > |
