summaryrefslogtreecommitdiff
path: root/Wishlist
blob: 17ef699807cf8aa7457191d1f55ef3c81e023a1c (plain)
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
NASM Wishlist
=============

- PUSH WORD EAX silently becomes PUSH EAX. Should warn.

- ndisasm hangs at eof.

- missing heading in documentation - some subsect in chapter 4.

- 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?