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?