forked from ManasJayanth/esy-nasm
-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO
376 lines (296 loc) · 13.4 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
NASM TODO list
==============
This, like the AUTHORS file, is intended for easy readability by both human
and machine, thus the format.
F: feature
V: version you should expect it by
R: responsible person or - if unassigned
C: % complete
D: description
D: maybe on multiple lines
Anything that doesn't start with /^[FVRCD]:/ should be ignored.
F:-line triggers new entry.
Empty V,R,C assume: V: ?, R: -, C: 0%
=============
F: Extended x64 Support
D: Full FPU/MMX/SSE* instruction support for x64
F: ELF64 output format
D: Support for assembling code to the ELF64 output format
F: NDISASM x64 Support
D: Ability to disassemble respective x64 code
F: General x64 Support
V: 0.99.00
R: Keith Kanios
C: 99%
D: Support for assembling 64-bit code to various output formats
F: win64 (x86-64 COFF) output format
V: 0.99.00
R: Keith Kanios
C: 99%
D: Support for assembling code to the win64 output format
F: c99 data-type compliance
V: 0.99.00
R: Keith Kanios
C: 99%
D: Revamped entire source-code base data-types for compliance
D: with c99 (inttypes.h)
F: __BITS__ Standard Macro
V: 0.99.00
R: Keith Kanios
C: 100%
D: __BITS__ standard macro that returns current [BITS XX] mode
F: i18n via gettext
D: kkanios: be careful about that, stick to UTF-8 if anything
F: Convert shallow code model to deep code model
D: Tired of messing between lots of unrelated files (especially .c/.h stuff)
F: Automated dependency generation for Makefile
D: Current looks awful and will break if anything changes.
F: Move output modules out*.c to output/ subdir
R: madfire
C: 100%
== THESE ARE FROM old NASM's Wishlist
== THEY NEED SEVERE REVISING (seems they weren't updated for a couple of years or so)
F: Check misc/ide.cfg into RCS as Watcom IDE enhancement thingy
V: 0.98
D: ([email protected])
F: Package the Linux Assembler HOWTO
V: 0.98
F: 3DNow!, SSE and other extensions need documenting
V: 0.98
D: hpa: Does it really make sense to have a whole instruction set
D: reference packaged with the assembler?
D: kkanios: Yes, for me it was a great help... and still is.
F: prototypes of lrotate don't match in test/*. Fix.
V: 0.98
F: Build djgpp binaries for 0.98 onwards. Look into PMODE/W as a stub
V: 0.98
D: it might be a lot better than CWSDPMI. It's in PMW133.ZIP.
F: %undef operator that goes along with %define
V: ?
C: 100%
F: Fix `%error' giving error messages twice.
V: 0.99
D: Not especially important, as changes planned for 1.1x below will make
D: the preprocessor be only called once.
F: Sort out problems with OBJ
V: 0.99
D: * TLINK32 doesn't seem to like SEGDEF32 et al. So for that, we
D: should avoid xxx32 records wherever we can.
D: * However, didn't we change _to_ using xxx32 at some stage? Try
D: to remember why and when.
D: * Apparently Delphi's linker has trouble with two or more
D: globals being defined inside a PUBDEF32. Don't even know if it
D: _can_ cope with a PUBDEF16.
D: * Might need extra flags. *sigh*
F: Symbol table output may possibly be useful.
V: 0.99
D: Ken Martwick ([email protected]) wants the following format:
D: labelname type offset(hex) repetition count
D: Possibly include xref addresses after repetition count?
F: ELF fixes
V: 0.99
D: There are various other bugs in outelf.c that make certain kinds
D: of relocation not work. See zbrown.asm. Looks like we may have to do
D: a major rewrite of parts of it. Compare some NASM code output with
D: equivalent GAS code output. Look at the ELF spec. Generally fix things.
F: ELF fixes
V: 0.99
D: NASM is currently using a kludge in ELF that involves defining
D: a symbol at a zero absolute offset. This isn't needed, as the
D: documented solution to the problem that this solves is to use
D: SHN_UNDEF.
F: Debug information, in all formats it can be usefully done in.
V: 0.99
D: * including line-number record support.
D: * "George C. Lindauer" <[email protected]>
D: wants to have some say in how this goes through.
D: * Andrew Crabtree <[email protected]> wants to help out.
F: Think about a line-continuation character.
V: 0.99
F: Consider allowing declaration of two labels on the same line,
V: 0.99
D: syntax 'label1[:] label2[:] ... instruction'.
D: Need to investigate feasibility.
F: Quoting of quotes by doubling them, in string and char constants.
V: 0.99
F: Two-operand syntax for SEGMENT/SECTION macro to avoid warnings
D: of ignored section parameters on reissue of __SECT__.
D: Or maybe skip the warning if the given parameters are identical to
D: what was actually stored. Investigate.
V: 0.99
F: Apparently we are not missing a PSRAQ instruction, because it
D: doesn't exist. Check that it doesn't exist as an undocumented
D: instruction, or something stupid like that.
V: 0.99
F: Any assembled form starting 0x80 can also start 0x82.
V: 1.00
D: ndisasm should know this. New special code in instruction encodings, probably.
F: Pointing an EQU at an external symbol now generates an error.
V: 1.05
D: There may be a better way of handling this; we should look into it.
D: Ideally, the label mechanism should be changed to cope with one
D: label being declared relative to another - that may work, but could be
D: a pain to implement (or is it? it may be easy enough that you just
D: need to declare a new offset in the same segment...) This should be done
D: before v1.0 is released. There is a comment regarding this in labels.c,
D: towards the end of the file, which discusses ways of fixing this.
F: nested %rep used to cause a panic.
V: 1.10
D: Now a more informative error message is produced. This problem whould
D: be fixed before v1.0.
D: See comment in switch() statement block for PP_REP in do_directive()
D: in preproc.c (line 1585, or thereabouts)
F: Contribution
D: zgraeme.tar contains improved hash table routines
D: contributed by Graeme Defty <[email protected]> for use in the
D: label manager.
F: Contribution
D: zsyntax.zip contains a syntax-highlighting mode for
D: NASM, for use with the Aurora text editor (??).
F: Contribution
D: zvim.zip contains a syntax-highlighting mode for NASM, for use with vim.
F: Contribution
D: zkendal1.zip and zkendal2.zip contain Kendall
D: Bennett's (<[email protected]>) alternative syntax stuff,
D: providing an alternative syntax mode for NASM which allows a macro
D: set to be written that allows the same source files to be
D: assembled with NASM and TASM.
R: Kendall Bennett
C: 100%
F: Add the UD2 instruction.
C: 100%
F: Add the four instructions documented in 24368901.pdf (Intel's own document).
C: 100%
F: Some means of avoiding MOV memoffs,EAX which apparently the
D: Pentium pairing detector thinks modifies EAX. Similar means of
D: choosing instruction encodings where necessary.
V: 1.10?
F: The example of ..@ makes it clear that a ..@ label isn't just
D: local, but doesn't make it clear that it isn't just global either.
F: hpa wants an evaluator operator for ceil(log2(x)).
F: Extra reloc types in ELF
D: R_386_16 type 20, PC16 is 21, 8 is 22, PC8 is 23.
D: Add support for the 16s at least.
F: Lazy section creation or selective section output
D: in COFF/win32 at least and probably other formats: don't bother to emit a section
D: if it contains no data. Particularly the default auto-created
D: section. We believe zero-length sections crash at least WLINK (in win32).
F: Make the flags field in `struct itemplate' in insns.h a long instead of an int.
C: 100%?
F: Implement %ifref to check whether a single-line macro has ever been expanded since (last re) definition. Or maybe not. We'll see.
F: add pointer to \k{insLEAVE} and \k{insENTER} in chapters about mixed-language programming.
F: Some equivalent to TASM's GLOBAL directive
D: ie something which defines a symbol as external if it doesn't end up being defined
D: but defines it as public if it does end up being defined.
F: Documentation doesn't explain about C++ name mangling.
F: see if BITS can be made to do anything sensible in obj (eg set the default new-segment property to Use32).
F: OBJ: coalesce consecutive offset and segment fixups for the same location into full-32bit-pointer fixups.
D: This is apparently necessary because some twazzock in the PowerBASIC development
D: team didn't design to support the OMF spec the way the rest of the
D: world sees it.
F: Allow % to be separated from the rest of a preproc directive, for alternative directive indentation styles.
F: __DATE__, __TIME__, and text variants of __NASM_MAJOR__ and __NASM_MINOR__.
F: Warn on TIMES combined with multi-line macros.
V: 1.00
D: TIMES gets applied to first line only - should bring to users' attention.
F: Re-work the evaluator, again, with a per-object-format fixup
D: routine, so as to be able to cope with section offsets "really"
D: being pure numbers; should be able to allow at _least_ the two
D: common idioms
D: TIMES 510-$ DB 0 ; bootsector
D: MOV AX,(PROG_END-100H)/16 ; .COM TSR
D: Would need to call the fixup throughout the evaluator, and the
D: fixup would have to be allowed to return UNKNOWN on pass one if it
D: had to. (_Always_ returning UNKNOWN on pass one, though a lovely
D: clean design, breaks the first of the above examples.)
V: 1.10
F: Preprocessor identifier concatenation?
V: 1.10
F: Arbitrary section names in `bin'.
V: 0.98.09
D: Is this necessary? Is it even desirable?
D: hpa: Desirable, yes. Necessary? Probably not, but there are definitely cases where it becomes quite useful.
R: madfire
C: 100%
F: Ability to read from a pipe.
V: 1.10
D: Obviously not useful under dos, so memory problems with storing
D: entire input file aren't a problem either.
F: File caching under DOS/32 bit...
V: 1.10?
D: maybe even implement discardable buffers that get thrown away
D: when we get a NULL returned from malloc(). Only really useful under
D: DOS. Think about it.
F: possibly spool out the pre-processed stuff to a file, to avoid having to re-process it.
V: 1.10?
D: Possible problems with preprocessor values not known on pass 1? Have a look...
F: Or maybe we can spool out a pre-parsed version...?
V: 1.10
D: Need to investigate feasibility. Does the results from the parser
D: change from pass 1 to pass 2? Would it be feasible to alter it so that
D: the parser returns an invariant result, and this is then processed
D: afterwards to resolve label references, etc?
F: Subsection support?
F: A good ALIGN mechanism, similar to GAS's.
V: 0.98p1
D: GAS pads out space by means of the following (32-bit) instructions:
D: 8DB42600000000 lea esi,[esi+0x0]
D: 8DB600000000 lea esi,[esi+0x0]
D: 8D742600 lea esi,[esi+0x0]
D: 8D7600 lea esi,[esi+0x0]
D: 8D36 lea esi,[esi]
D: 90 nop
D: It uses up to two of these instructions to do up to 14-byte pads;
D: when more than 14 bytes are needed, it issues a (short) jump to
D: the end of the padded section and then NOPs the rest. Come up with
D: a similar scheme for 16 bit mode, and also come up with a way to
D: use it - internal to the assembler, so that programs using ALIGN
D: don't knock over preprocess-only mode.
D: Also re-work the macro form so that when given one argument in a
D: code section it calls this feature.
R: Panos Minos
C: 100%?
F: Possibly a means whereby FP constants can be specified as immediate operands to non-FP instructions.
D: * Possible syntax: MOV EAX,FLOAT 1.2 to get a single-precision FP
D: constant. Then maybe MOV EAX,HI_FLOAT 1.2 and MOV EAX,LO_FLOAT
D: 1.2 to get the two halves of a double-precision one. Best to
D: ignore extended-precision in case it bites.
D: * Alternatively, maybe MOV EAX,FLOAT(4,0-4,1.2) to get bytes 0-4
D: (ie 0-3) of a 4-byte constant. Then HI_FLOAT is FLOAT(8,4-8,x)
D: and LO_FLOAT is FLOAT(8,0-4,x). But this version allows two-byte
D: chunks, one-byte chunks, even stranger chunks, and pieces of
D: ten-byte reals to be bandied around as well.
F: A UNION macro might be quite cool
D: now that ABSOLUTE is sane enough to be able to handle it.
F: An equivalent to gcc's ## stringify operator, plus string concatenation
D: somehow implemented without undue ugliness, so as
D: to be able to do `%include "/my/path/%1"' in a macro, or something
D: similar...
F: Actually _do_ something with the processor, privileged and
D: undocumented flags in the instruction table. When this happens,
D: consider allowing PMULHRW to map to either of the Cyrix or AMD
D: versions?
D: hpa: The -p option to ndisasm now uses this to some extent.
V: 1.10
F: Maybe NEC V20/V30 instructions? ?
D: hpa: What are they? Should be trivial to implement.
F: Yet more object formats.
D: * Possibly direct support for .EXE files?
V: 1.10
F: Symbol map in binary format. Format-specific options...
V: 1.10?
F: REDESIGN: Think about EQU dependency, and about start-point specification in OBJ. Possibly re-think directive support.
V: 1.20?
F: Think about a wrapper program like gcc?
V: 2.00?
D: Possibly invent a _patch_ for gcc so that it can take .asm files on the command line?
D: If a wrapper happens, think about adding an option to cause the
D: resulting executable file to be executed immediately, thus
D: allowing NASM source files to have #!... (probably silly)
F: Multi-platform support?
D: If so: definitely Alpha; possibly Java byte code;
D: probably ARM/StrongARM; maybe Sparc; maybe Mips; maybe
D: Vax. Perhaps Z80 and 6502, just for a laugh?
F: Consider a 'verbose' option that prints information about the resulting object file onto stdout.
F: Line numbers in the .lst file don't match the line numbers in the input.
D: They probably should, rather than the current matching of the post-preprocessor line numbers.