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