Rev 1189 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
1053 | heavyiron | 1 | |
2 | |||
3 | |||
4 | |||
1363 | IgorA | 5 | |
6 | |||
7 | |||
8 | |||
9 | mode - fixed. |
||
10 | |||
11 | |||
12 | |||
13 | |||
14 | |||
15 | generated with "qword" keyword inside square brackets. |
||
16 | |||
17 | |||
18 | |||
19 | |||
20 | |||
21 | symbol was encountered. |
||
22 | |||
23 | |||
24 | |||
25 | |||
26 | |||
27 | |||
28 | |||
29 | |||
30 | |||
31 | |||
32 | |||
33 | |||
34 | |||
1189 | heavyiron | 35 | |
36 | |||
37 | correctly generated - fixed. |
||
38 | |||
39 | |||
40 | in ELF executables. |
||
41 | |||
42 | |||
43 | |||
44 | |||
45 | |||
46 | "format ELF executable" setting. |
||
47 | |||
48 | |||
49 | special segments in ELF executables. |
||
50 | |||
51 | |||
52 | |||
53 | |||
54 | |||
55 | |||
56 | |||
57 | |||
58 | |||
59 | |||
60 | "pblendvb" instructions. |
||
61 | |||
62 | |||
63 | |||
64 | |||
65 | |||
66 | |||
67 | |||
68 | |||
69 | |||
70 | |||
71 | |||
72 | |||
73 | |||
74 | |||
75 | |||
76 | |||
77 | |||
78 | to be calculated by preprocessor in its arguments. |
||
79 | |||
80 | |||
81 | this allowed to use code segmentation in DOS unREAL mode, so the code is |
||
82 | no longer limited to 64 kilobytes. |
||
83 | |||
84 | |||
85 | |||
1115 | heavyiron | 86 | |
1053 | heavyiron | 87 | |
1115 | heavyiron | 88 | |
1053 | heavyiron | 89 | |
1115 | heavyiron | 90 | |
1053 | heavyiron | 91 | |
1115 | heavyiron | 92 | 64-bit variants of respective instructions. |
93 | |||
1053 | heavyiron | 94 | |
1115 | heavyiron | 95 | mnemonics to allow choosing between 16-bit and 32-bit variants of |
96 | structures used by the "fstenv", "fsave" and "frstor" instructions. |
||
97 | |||
1053 | heavyiron | 98 | |
1115 | heavyiron | 99 | |
1053 | heavyiron | 100 | |
1115 | heavyiron | 101 | added "static" keyword for the "public" directive. |
102 | |||
1053 | heavyiron | 103 | |
1115 | heavyiron | 104 | |
1053 | heavyiron | 105 | |
1115 | heavyiron | 106 | should be used, depending on whether the fixups directory is placed |
107 | somewhere into executable by programer, or not. This makes possible the |
||
108 | more flexible use of the addressing symbols in case of PE executable fixed |
||
109 | at some position. |
||
110 | |||
1053 | heavyiron | 111 | |
1115 | heavyiron | 112 | 64-bit object formats and PE executable. This makes some specific |
113 | instructions compilable, but it also forces linker to put such |
||
114 | generated code into the low 2 gigabytes of addressing space. |
||
115 | |||
1053 | heavyiron | 116 | |
1115 | heavyiron | 117 | |
1053 | heavyiron | 118 | |
1115 | heavyiron | 119 | The symbol escaping now has always the higher priority than symbol conversion, |
120 | and both have higher precedence than concatenation. |
||
121 | |||
1053 | heavyiron | 122 | |
123 | |||
124 | |||
125 | placed at the end of the "format" directive line. |
||
126 | |||
127 | |||
1115 | heavyiron | 128 | is no longer allowed. |
129 | |||
1053 | heavyiron | 130 | |
1115 | heavyiron | 131 | to help improve long numbers readability. |
132 | |||
1053 | heavyiron | 133 | |
1115 | heavyiron | 134 | various kinds of information from it. |
135 | |||
1053 | heavyiron | 136 | |
1115 | heavyiron | 137 | |
1053 | heavyiron | 138 | |
139 | |||
140 | |||
141 | |||
1115 | heavyiron | 142 | the same kind as "equ" directive, however there's an important difference |
143 | that "define" doesn't process symbolic constants in the value before |
||
144 | assigning it. For example: |
||
1053 | heavyiron | 145 | |
146 | |||
1189 | heavyiron | 147 | a equ a+a |
148 | |||
1053 | heavyiron | 149 | |
1189 | heavyiron | 150 | define b b+b |
151 | |||
1053 | heavyiron | 152 | |
153 | value "b+b". This directive may be useful in some advanced |
||
154 | macroinstructions. |
||
155 | |||
156 | |||
157 | for slightly better performance and lesser memory usage by assembler. |
||
158 | The logical values defined with "eq", "eqtype" and "in" operators are now |
||
159 | evaluated by the parser and if they are enough to determine the condition, |
||
160 | the whole block is processed accordingly. Thus this block: |
||
161 | |||
162 | |||
1189 | heavyiron | 163 | nop |
164 | end if |
||
165 | |||
1053 | heavyiron | 166 | |
1115 | heavyiron | 167 | that the condition is true, even though one of the logical values makes no |
1053 | heavyiron | 168 | sense - but since this is none of the "eq", "eqtype" and "in" expressions, |
169 | the parser doesn't investigate. |
||
170 | |||
171 | |||
172 | needs to determine the condition. So this block: |
||
173 | |||
174 | |||
1189 | heavyiron | 175 | |
1053 | heavyiron | 176 | |
1189 | heavyiron | 177 | |
1053 | heavyiron | 178 | |
179 | versions. This is because after checking that "defined alpha" is false |
||
180 | condition it doesn't need to know the second logical value to determine the |
||
181 | value of conjunction. |
||
182 | |||
183 | |||
184 | obsolete and no longer correct - use "jmp short" instead. |
||
185 | |||
186 | |||
187 | displacement - now it applies to the size of target address. |
||
188 | |||
189 | |||
1115 | heavyiron | 190 | unless you force using the 16-bit immediate with "word" operator. |
1053 | heavyiron | 191 | |
192 | |||
193 | |||
194 | |||
195 | |||
196 | |||
197 | when making position-independent code for shared libraries. For any label |
||
198 | you can get its offset relative to GOT by preceding it with "rva" operator |
||
199 | (the same keyword as for PE format is used, to avoid adding a new one, |
||
200 | while this one has very similar meaning). |
||
201 | |||
202 | |||
203 | to make the distinction between the run-time segments and linkable |
||
204 | sections. If you had a "section" directive in your ELF executables and they |
||
205 | no longer assemble, replace it with "segment". |
||
206 | |||
207 | |||
208 | even when there are no fixups to be put there (in such case it creates the |
||
209 | directory with one empty block). |
||
210 | |||
211 | |||
212 | possibility of making extensive symbol dumps. |
||
213 | |||
214 | |||
1115 | heavyiron | 215 | prioritized constant. |
1053 | heavyiron | 216 | |
217 | |||
218 | string it simply does nothing. Thus the sequence of ` operators applied to |
||
219 | one symbol work the same as if there was just one. In similar manner, the |
||
220 | sequence of # operators now works as if it was a single one - using such a |
||
221 | sequence instead of escaping, which was kept for some backward |
||
222 | compatibility, is now deprecated. |
||
223 | |||
224 | |||
225 | incorrectly interpreted as data definition). |
||
226 | |||
227 | |||
228 | |||
229 | |||
230 | |||
231 | |||
232 | |||
233 | setting). |
||
234 | |||
235 | |||
236 | |||
237 | |||
238 | |||
239 | |||
240 | |||
241 | |||
242 | must always fit in the range of signed 64 integer now. |
||
243 | |||
244 | |||
245 | as a second addressing register - fixed. |
||
246 | |||
247 | |||
248 | |||
249 | |||
250 | wrongly signaled - fixed. |
||
251 | |||
252 | |||
253 | |||
254 | |||
255 | |||
256 | |||
257 | |||
258 | |||
259 | |||
260 | (with "format MS64 COFF" setting). |
||
261 | |||
262 | |||
263 | |||
264 | |||
265 | |||
266 | |||
267 | |||
268 | |||
269 | label. |
||
270 | |||
271 | |||
272 | than one resource of the same string name, the separate resource |
||
273 | directories were created with the same names - fixed. |
||
274 | |||
275 | |||
276 | |||
277 | |||
278 | |||
279 | |||
280 | macros to be processed the wrong way. |
||
281 |