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
|
NASM Wishlist
=============
- forward-reference tracking is instruction-granular not operand-
granular. Bummer.
- see if BITS can be made to do anything sensible in obj (eg set the
default new-segment property to Use32).
- __DATE__, __TIME__, and text variants of __NASM_MAJOR__ and
__NASM_MINOR__.
- Warn on TIMES combined with multi-line macros. TIMES gets applied
to first line only - should bring to users' attention.
- Add support for lcc 4.0.
* If-when this happens, remember to bump the `supported lcc
version' number in Readme.
- Re-work the evaluator, again, with a per-object-format fixup
routine, so as to be able to cope with section offsets "really"
being pure numbers; should be able to allow at _least_ the two
common idioms
TIMES 510-$ DB 0 ; bootsector
MOV AX,(PROG_END-100H)/16 ; .COM TSR
Would need to call the fixup throughout the evaluator, and the
fixup would have to be allowed to return UNKNOWN on pass one if it
had to. (_Always_ returning UNKNOWN on pass one, though a lovely
clean design, breaks the first of the above examples.)
- Preprocessor identifier concatenation?
- Arbitrary section names in `bin'.
- Ability to read from a pipe. Obviously not useful under dos, so
memory problems with storing entire input file aren't a problem
either.
- Subsection support?
- A good ALIGN mechanism, similar to GAS's. GAS pads out space by
means of the following (32-bit) instructions:
8DB42600000000 lea esi,[esi+0x0]
8DB600000000 lea esi,[esi+0x0]
8D742600 lea esi,[esi+0x0]
8D7600 lea esi,[esi+0x0]
8D36 lea esi,[esi]
90 nop
It uses up to two of these instructions to do up to 14-byte pads;
when more than 14 bytes are needed, it issues a (short) jump to
the end of the padded section and then NOPs the rest. Come up with
a similar scheme for 16 bit mode, and also come up with a way to
use it - internal to the assembler, so that programs using ALIGN
don't knock over preprocess-only mode.
Also re-work the macro form so that when given one argument in a
code section it calls this feature.
- Possibly a means whereby FP constants can be specified as
immediate operands to non-FP instructions.
* Possible syntax: MOV EAX,FLOAT 1.2 to get a single-precision FP
constant. Then maybe MOV EAX,HI_FLOAT 1.2 and MOV EAX,LO_FLOAT
1.2 to get the two halves of a double-precision one. Best to
ignore extended-precision in case it bites.
* Alternatively, maybe MOV EAX,FLOAT(4,0-4,1.2) to get bytes 0-4
(ie 0-3) of a 4-byte constant. Then HI_FLOAT is FLOAT(8,4-8,x)
and LO_FLOAT is FLOAT(8,0-4,x). But this version allows two-byte
chunks, one-byte chunks, even stranger chunks, and pieces of
ten-byte reals to be bandied around as well.
- A UNION macro might be quite cool, now that ABSOLUTE is sane
enough to be able to handle it.
- An equivalent to gcc's ## stringify operator, plus string
concatenation, somehow implemented without undue ugliness, so as
to be able to do `%include "/my/path/%1"' in a macro, or something
similar...
- Actually _do_ something with the processor, privileged and
undocumented flags in the instruction table.
- Maybe NEC V20/V30 instructions?
- Yet more object formats.
* Possibly direct support for .EXE files?
- Debug information, in all formats it can be usefully done in.
* including line-number record support.
- Symbol map in binary format. Format-specific options...
- REDESIGN: Think about EQU dependency, and about start-point
specification in OBJ. Possibly re-think directive support.
- Think about a wrapper program like gcc? Possibly invent a _patch_
for gcc so that it can take .asm files on the command line?
- If a wrapper happens, think about adding an option to cause the
resulting executable file to be executed immediately, thus
allowing NASM source files to have #!... (probably silly)
- Multi-platform support? If so: definitely Alpha; possibly Java
byte code; probably ARM/StrongARM; maybe Sparc; maybe Mips; maybe
Vax. Perhaps Z80 and 6502, just for a laugh?
|
