NASM 0.96

1 files changed, 97 insertions, 0 deletions

diff --git a/Wishlist b/Wishlist
new file mode 100644
index 0000000..17ef699
--- /dev/null
+++ b/Wishlist
@@ -0,0 +1,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?