NASM TODO list

==============

This, like the AUTHORS file, is intended for easy readability by both human 

and machine, thus the format.

  F: feature

  V: version you should expect it by

  R: responsible person or - if unassigned

  C: % complete

  D: description

  D: maybe on multiple lines

Anything that doesn't start with /^[FVRCD]:/ should be ignored.

  F:-line triggers new entry.

  Empty V,R,C assume: V: ?, R: -, C: 0%

=============

F: Extended x64 Support

D: Full FPU/MMX/SSE* instruction support for x64

F: ELF64 output format

D: Support for assembling code to the ELF64 output format

F: NDISASM x64 Support

D: Ability to disassemble respective x64 code

F: General x64 Support

V: 0.99.00

R: Keith Kanios

C: 99%

D: Support for assembling 64-bit code to various output formats

F: win64 (x86-64 COFF) output format

V: 0.99.00

R: Keith Kanios

C: 99%

D: Support for assembling code to the win64 output format

F: c99 data-type compliance

V: 0.99.00

R: Keith Kanios

C: 99%

D: Revamped entire source-code base data-types for compliance

D: with c99 (inttypes.h)

F: __BITS__ Standard Macro

V: 0.99.00

R: Keith Kanios

C: 100%

D: __BITS__ standard macro that returns current [BITS XX] mode

F: i18n via gettext

D: kkanios: be careful about that, stick to UTF-8 if anything

F: Convert shallow code model to deep code model

D: Tired of messing between lots of unrelated files (especially .c/.h stuff)

F: Automated dependency generation for Makefile

D: Current looks awful and will break if anything changes.

F: Move output modules out*.c to output/ subdir

R: madfire

C: 100%

== THESE ARE FROM old NASM's Wishlist

== THEY NEED SEVERE REVISING (seems they weren't updated for a couple of years or so)

F: Check misc/ide.cfg into RCS as Watcom IDE enhancement thingy

V: 0.98

D: (nop@dlc.fi)

F: Package the Linux Assembler HOWTO

V: 0.98

F: 3DNow!, SSE and other extensions need documenting

V: 0.98

D: hpa: Does it really make sense to have a whole instruction set

D: reference packaged with the assembler?

D: kkanios: Yes, for me it was a great help... and still is.

F: prototypes of lrotate don't match in test/*. Fix.

V: 0.98

F: Build djgpp binaries for 0.98 onwards. Look into PMODE/W as a stub

V: 0.98

D: it might be a lot better than CWSDPMI. It's in PMW133.ZIP.

F: %undef operator that goes along with %define

V: ?

C: 100%

F: Fix `%error' giving error messages twice.

V: 0.99

D: Not especially important, as changes planned for 1.1x below will make

D: the preprocessor be only called once.

F: Sort out problems with OBJ

V: 0.99

D: * TLINK32 doesn't seem to like SEGDEF32 et al. So for that, we

D:   should avoid xxx32 records wherever we can.

D: * However, didn't we change _to_ using xxx32 at some stage? Try

D:   to remember why and when.

D: * Apparently Delphi's linker has trouble with two or more

D:   globals being defined inside a PUBDEF32. Don't even know if it

D:   _can_ cope with a PUBDEF16.

D: * Might need extra flags. *sigh*

F: Symbol table output may possibly be useful.

V: 0.99

D: Ken Martwick (kenm@efn.org) wants the following format:

D: 	labelname	type	offset(hex)	repetition count

D: Possibly include xref addresses after repetition count?

F: ELF fixes

V: 0.99

D: There are various other bugs in outelf.c that make certain kinds

D: of relocation not work. See zbrown.asm. Looks like we may have to do

D: a major rewrite of parts of it. Compare some NASM code output with

D: equivalent GAS code output. Look at the ELF spec. Generally fix things.

F: ELF fixes

V: 0.99

D: NASM is currently using a kludge in ELF that involves defining

D: a symbol at a zero absolute offset. This isn't needed, as the

D: documented solution to the problem that this solves is to use

D: SHN_UNDEF.

F: Debug information, in all formats it can be usefully done in.

V: 0.99

D: * including line-number record support.

D: * "George C. Lindauer" <gclind01@starbase.spd.louisville.edu>

D:   wants to have some say in how this goes through.

D: * Andrew Crabtree <andrewc@rosemail.rose.hp.com> wants to help out.

F: Think about a line-continuation character.

V: 0.99

F: Consider allowing declaration of two labels on the same line,

V: 0.99

D: syntax 'label1[:] label2[:] ... instruction'.

D: Need to investigate feasibility.

F: Quoting of quotes by doubling them, in string and char constants.

V: 0.99

F: Two-operand syntax for SEGMENT/SECTION macro to avoid warnings

D: of ignored section parameters on reissue of __SECT__.

D: Or maybe skip the warning if the given parameters are identical to

D: what was actually stored. Investigate.				

V: 0.99

F: Apparently we are not missing a PSRAQ instruction, because it

D: doesn't exist.  Check that it doesn't exist as an undocumented

D: instruction, or something stupid like that.

V: 0.99

F: Any assembled form starting 0x80 can also start 0x82.

V: 1.00

D: ndisasm should know this. New special code in instruction encodings, probably.

F: Pointing an EQU at an external symbol now generates an error.

V: 1.05

D: There may be a better way of handling this; we should look into it.

D: Ideally, the label mechanism should be changed to cope with one

D: label being declared relative to another - that may work, but could be

D: a pain to implement (or is it? it may be easy enough that you just

D: need to declare a new offset in the same segment...) This should be done

D: before v1.0 is released. There is a comment regarding this in labels.c,

D: towards the end of the file, which discusses ways of fixing this.

F: nested %rep used to cause a panic.

V: 1.10

D: Now a more informative error message is produced. This problem whould

D: be fixed before v1.0.

D: See comment in switch() statement block for PP_REP in do_directive()

D: in preproc.c (line 1585, or thereabouts)

F: Contribution

D: zgraeme.tar contains improved hash table routines

D: contributed by Graeme Defty <graeme@HK.Super.NET> for use in the

D: label manager.

F: Contribution

D: zsyntax.zip contains a syntax-highlighting mode for

D: NASM, for use with the Aurora text editor (??).

F: Contribution

D: zvim.zip contains a syntax-highlighting mode for NASM, for use with vim.

F: Contribution

D: zkendal1.zip and zkendal2.zip contain Kendall

D: Bennett's (<KendallB@scitechsoft.com>) alternative syntax stuff,

D: providing an alternative syntax mode for NASM which allows a macro

D: set to be written that allows the same source files to be

D: assembled with NASM and TASM.

R: Kendall Bennett

C: 100%

F: Add the UD2 instruction.

C: 100%

F: Add the four instructions documented in 24368901.pdf (Intel's own document).

C: 100%

F: Some means of avoiding MOV memoffs,EAX which apparently the

D: Pentium pairing detector thinks modifies EAX. Similar means of

D: choosing instruction encodings where necessary.

V: 1.10?

F: The example of ..@ makes it clear that a ..@ label isn't just

D: local, but doesn't make it clear that it isn't just global either.

F: hpa wants an evaluator operator for ceil(log2(x)).

F: Extra reloc types in ELF

D: R_386_16 type 20, PC16 is 21, 8 is 22, PC8 is 23.

D: Add support for the 16s at least.

F: Lazy section creation or selective section output

D: in COFF/win32 at least and probably other formats: don't bother to emit a section

D: if it contains no data. Particularly the default auto-created

D: section. We believe zero-length sections crash at least WLINK (in win32).

F: Make the flags field in `struct itemplate' in insns.h a long instead of an int.

C: 100%?

F: Implement %ifref to check whether a single-line macro has ever been expanded since (last re) definition. Or maybe not. We'll see.

F: add pointer to \k{insLEAVE} and \k{insENTER} in chapters about	mixed-language programming.

F: Some equivalent to TASM's GLOBAL directive

D: ie something which defines a symbol as external if it doesn't end up being defined

D: but defines it as public if it does end up being defined.

F: Documentation doesn't explain about C++ name mangling.

F: see if BITS can be made to do anything sensible in obj (eg set the default new-segment property to Use32).

F: OBJ: coalesce consecutive offset and segment fixups for the same location into full-32bit-pointer fixups.

D: This is apparently necessary because some twazzock in the PowerBASIC development

D: team didn't design to support the OMF spec the way the rest of the

D: world sees it.

F: Allow % to be separated from the rest of a preproc directive, for	alternative directive indentation styles.

F: __DATE__, __TIME__, and text variants of __NASM_MAJOR__ and __NASM_MINOR__.

F: Warn on TIMES combined with multi-line macros.

V: 1.00

D: TIMES gets applied to first line only - should bring to users' attention.

F: Re-work the evaluator, again, with a per-object-format fixup

D: routine, so as to be able to cope with section offsets "really"

D: being pure numbers; should be able to allow at _least_ the two

D: common idioms

D:   TIMES 510-$ DB 0            ; bootsector

D:   MOV AX,(PROG_END-100H)/16   ; .COM TSR

D: Would need to call the fixup throughout the evaluator, and the

D: fixup would have to be allowed to return UNKNOWN on pass one if it

D: had to. (_Always_ returning UNKNOWN on pass one, though a lovely

D: clean design, breaks the first of the above examples.)

V: 1.10

F: Preprocessor identifier concatenation?

V: 1.10

F: Arbitrary section names in `bin'.

V: 0.98.09

D: Is this necessary? Is it even desirable?

D: hpa: Desirable, yes.  Necessary?  Probably not, but there are definitely cases where it becomes quite useful.

R: madfire

C: 100%

F: Ability to read from a pipe.

V: 1.10

D: Obviously not useful under dos, so memory problems with storing

D: entire input file aren't a problem either.

F: File caching under DOS/32 bit...

V: 1.10?

D: maybe even implement discardable buffers that get thrown away

D: when we get a NULL returned from malloc(). Only really useful under

D: DOS. Think about it.

F: possibly spool out the pre-processed stuff to a file, to avoid having to re-process it.

V: 1.10?

D: Possible problems with preprocessor values not known on pass 1? Have a look...

F: Or maybe we can spool out a pre-parsed version...?

V: 1.10

D: Need to investigate feasibility. Does the results from the parser

D: change from pass 1 to pass 2? Would it be feasible to alter it so that

D: the parser returns an invariant result, and this is then processed

D: afterwards to resolve label references, etc?

F: Subsection support?

F: A good ALIGN mechanism, similar to GAS's.

V: 0.98p1

D: GAS pads out space by means of the following (32-bit) instructions:

D:         8DB42600000000    lea esi,[esi+0x0]

D:         8DB600000000      lea esi,[esi+0x0]

D:         8D742600          lea esi,[esi+0x0]

D:         8D7600            lea esi,[esi+0x0]

D:         8D36              lea esi,[esi]

D:         90                nop

D: It uses up to two of these instructions to do up to 14-byte pads;

D: when more than 14 bytes are needed, it issues a (short) jump to

D: the end of the padded section and then NOPs the rest. Come up with

D: a similar scheme for 16 bit mode, and also come up with a way to

D: use it - internal to the assembler, so that programs using ALIGN

D: don't knock over preprocess-only mode.

D:   Also re-work the macro form so that when given one argument in a

D: code section it calls this feature.

R: Panos Minos

C: 100%?

F: Possibly a means whereby FP constants can be specified as immediate operands to non-FP instructions.

D: * Possible syntax: MOV EAX,FLOAT 1.2 to get a single-precision FP

D:   constant. Then maybe MOV EAX,HI_FLOAT 1.2 and MOV EAX,LO_FLOAT

D:   1.2 to get the two halves of a double-precision one. Best to

D:   ignore extended-precision in case it bites.

D: * Alternatively, maybe MOV EAX,FLOAT(4,0-4,1.2) to get bytes 0-4

D:   (ie 0-3) of a 4-byte constant. Then HI_FLOAT is FLOAT(8,4-8,x)

D:   and LO_FLOAT is FLOAT(8,0-4,x). But this version allows two-byte

D:   chunks, one-byte chunks, even stranger chunks, and pieces of

D:   ten-byte reals to be bandied around as well.

F: A UNION macro might be quite cool

D: now that ABSOLUTE is sane enough to be able to handle it.

F: An equivalent to gcc's ## stringify operator, plus string concatenation

D: somehow implemented without undue ugliness, so as

D: to be able to do `%include "/my/path/%1"' in a macro, or something

D: similar...

F: Actually _do_ something with the processor, privileged and

D: undocumented flags in the instruction table. When this happens,

D: consider allowing PMULHRW to map to either of the Cyrix or AMD

D: versions?

D: hpa: The -p option to ndisasm now uses this to some extent.

V: 1.10

F: Maybe NEC V20/V30 instructions?					?

D: hpa: What are they?  Should be trivial to implement.

F: Yet more object formats.

D: * Possibly direct support for .EXE files?

V: 1.10

F: Symbol map in binary format. Format-specific options...

V: 1.10?

F: REDESIGN: Think about EQU dependency, and about start-point specification in OBJ. Possibly re-think directive support.

V: 1.20?

F: Think about a wrapper program like gcc?

V: 2.00?

D: Possibly invent a _patch_ for gcc so that it can take .asm files on the command line?

D: If a wrapper happens, think about adding an option to cause the

D: resulting executable file to be executed immediately, thus

D: allowing NASM source files to have #!... (probably silly)

F: Multi-platform support?

D: If so: definitely Alpha; possibly Java byte code;

D: probably ARM/StrongARM; maybe Sparc; maybe Mips; maybe

D: Vax. Perhaps Z80 and 6502, just for a laugh?

F: Consider a 'verbose' option that prints information about the resulting object file onto stdout.

F: Line numbers in the .lst file don't match the line numbers in the input.

D: They probably should, rather than the current matching of the post-preprocessor line numbers.