The internals of gas need documenting.
-Roland's going to work on removing the m4 processing from the user
-documentation. With the latest texinfo code, it's not needed.
+The documentation should also contain a "Trouble" section similar to gcc's
+manual: real bugs, common problems, incompatibilities, etc.
Anyone want to offer to maintain a man page?
Eliminate, as much as possible, anything not in config that is conditionalized
on a CPU, format, or environment.
+Merge COFF support into one version, supporting all the pseudo-ops used in
+either versions now, but using BFD for high-level operations. (See second
+following item.) Currently there are two versions (plus the new BFD code),
+which support different features, and are used on different targets.
+
+Convert remaining a.out/b.out targets to using the BFD_ASSEMBLER code by
+default.
+
Finish conversion to using BFD for all object file writing. (This is the
BFD_ASSEMBLER code, not BFD or BFD_HEADERS.) VMS might be the tough one here,
-since there's no BFD support for it at all yet. Eliminate the old code.
+since there's no BFD support for it at all yet. Eliminate the old code. Some
+of this can be done target by target, so doing a target where the CPU or
+format already supports BFD_ASSEMBLER mode may be easiest.
Fix lots of uses of empty strings to use null pointers. Will improve
efficiency, and should make code clearer too.
another previous maintainer, unrelated to the code. (And with no names,
they're not so fun to read. :-)
-Lots of documentation.
+For sparc: "call 0" becomes "jmpl %g0,%l7", and similarly for absolute
+addresses in -4096...4095. (Solaris assembler does this. No
+relocation required, no absolute symbol needed.) For addresses
+outside the range, for COFF, keep generating an absolute symbol to use
+for relocs.
+
+Get Steve to document H8/500 stuff (and others).
+
+Improve test suite. Incorporate more reported net bugs, and non-confidential
+Cygnus customer bugs, and anything else.
+
+Add support for i386/i486 16-bit mode, so operating system initialization code
+doesn't require a separate assembler nor lots of `.byte' directives.
+
+See if it's more maintainable (and not too much of a performance loss) to use
+a yacc grammar for parsing input. The lexer will have to be flexible, and the
+grammar will have to contain any construct used on any platform, but it may be
+easier to maintain, instead of having code in most of the back ends.
+
+PIC support.
+
+Torbjorn Granlund <tege@cygnus.com> writes, regarding alpha .align:
+
+ Please make sure the .align directive works as in digital's assembler.
+ They fill the space with a sequence of "bis $31,$31,$31;ldq_u $31,0($30)"
+ since these two instructions can dual-issue. Since .align is ued a lot by
+ gcc, it is an important optimization.
+
+Torbjorn Granlund <tege@cygnus.com> writes, regarding i386/i486/pentium:
+
+ In a new publication from Intel, "Optimization for Intel's 32 bit
+ Processors", they recommended code alignment on a 16 byte boundary if that
+ requires less than 8 bytes of fill instructions. The Pentium is not
+ affected by such alignment, the 386 wants alignment on a 4 byte boundary.
+ It is the 486 that is most helped by large alignment.
+
+ Recommended nop instructions:
+ 1 byte: 90 xchg %eax,%eax
+ 2 bytes: 8b c0 movl %eax,%eax
+ 3 bytes: 8d 76 00 leal 0(%esi),%esi
+ 4 bytes: 8d 74 26 00 leal 0(%esi),%esi
+ 5 bytes: 8b c0 8d 76 00 movl %eax,%eax; leal 0(%esi),%esi
+ 6 bytes: 8d b6 00 00 00 00 leal 0(%esi),%esi
+ 7 bytes: 8d b4 26 00 00 00 00 leal 0(%esi),%esi
-Get Steve to document H8/500 stuff.
+ Note that `leal 0(%esi),%esi' has a few different encodings...
-Put together a test suite, using DejaGnu.
+ There are faster instructions for certain lengths, that are not true nops.
+ If you can determine that a register and the condition code is dead (by
+ scanning forwards for a register that is written before it is read, and
+ similar for cc) you can use a `incl reg' for a 3 times faster 1 cycle nop...
(From old "NOTES" file to-do list, not really reviewed:)