VirtualBox

source: vbox/trunk/tools/os2.x86/nasm/v0.98.39-bird/TODO@ 62171

最後變更 在這個檔案從62171是 1,由 vboxsync 提交於 55 年 前

import

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

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette