laag-nasm 2.13.03.2

data/vendor/repo.or.cz/nasm/README

@@ -0,0 +1,23 @@
+              NASM, the Netwide Assembler.
+
+Many many developers all over the net respect NASM for what it is
+- a widespread (thus netwide), portable (thus netwide!), very
+flexible and mature assembler tool with support for many output
+formats (thus netwide!!).
+
+Now we have good news for you: NASM is licensed under the "simplified"
+(2-clause) BSD license.  This means its development is open to even
+wider society of programmers wishing to improve their lovely
+assembler.
+
+The NASM project is now situated at SourceForge.net, the most
+popular Open Source development site on the Internet.
+
+Visit our website at http://nasm.sourceforge.net/ and our
+SourceForge project at http://sourceforge.net/projects/nasm/
+
+See the file CHANGES for the description of changes between revisions,
+and the file AUTHORS for a list of contributors.
+
+                                                   With best regards,
+                                                           NASM crew.

data/vendor/repo.or.cz/nasm/SubmittingPatches

@@ -0,0 +1,116 @@
+How to submit patches into the NASM
+===================================
+
+Actually the rules are pretty simple
+
+Obtaining the source code
+-------------------------
+
+The NASM sources are tracked by Git SCM at http://repo.or.cz/w/nasm.git
+repository. You either could download packed sources or use git tool itself
+
+        git clone git://repo.or.cz/nasm.git
+
+Changin the source code
+-----------------------
+
+When you change the NASM source code keep in mind -- we prefer tabs and
+indentations to be 4 characters width, space filled.
+
+Other "rules" could be learned from NASM sources -- just make your code
+to look similar.
+
+Producing patch
+---------------
+
+There are at least two ways to make it right.
+
+ 1) git format-patch
+
+    You might need to read documentation on Git SCM how to prepare patch
+    for mail submission. Take a look on http://book.git-scm.com/ and/or
+    http://git-scm.com/documentation for details. It should not be hard
+    at all.
+
+ 2) Use "diff -up"
+ 
+    Use "diff -up" or "diff -uprN" to create patches.
+
+Signing your work
+-----------------
+
+To improve tracking of who did what we've introduced a "sign-off" procedure
+on patches that are being emailed around.
+
+The sign-off is a simple line at the end of the explanation for the
+patch, which certifies that you wrote it or otherwise have the right to
+pass it on as a open-source patch.  The rules are pretty simple: if you
+can certify the below:
+
+        Developer's Certificate of Origin 1.1
+
+        By making a contribution to this project, I certify that:
+
+        (a) The contribution was created in whole or in part by me and I
+            have the right to submit it under the open source license
+            indicated in the file; or
+
+        (b) The contribution is based upon previous work that, to the best
+            of my knowledge, is covered under an appropriate open source
+            license and I have the right under that license to submit that
+            work with modifications, whether created in whole or in part
+            by me, under the same open source license (unless I am
+            permitted to submit under a different license), as indicated
+            in the file; or
+
+        (c) The contribution was provided directly to me by some other
+            person who certified (a), (b) or (c) and I have not modified
+            it.
+
+	(d) I understand and agree that this project and the contribution
+	    are public and that a record of the contribution (including all
+	    personal information I submit with it, including my sign-off) is
+	    maintained indefinitely and may be redistributed consistent with
+	    this project or the open source license(s) involved.
+
+then you just add a line saying
+
+        Signed-off-by: Random J Developer <random@developer.example.org>
+
+using your real name (please, no pseudonyms or anonymous contributions if
+it possible)
+
+An example of patch message
+---------------------------
+
+From: Random J Developer <random@developer.example.org>
+Subject: [PATCH] Short patch description
+
+Long patch description (could be skipped if patch
+is trivial enough)
+
+Signed-off-by: Random J Developer <random@developer.example.org>
+---
+Patch body here
+
+Mailing patches
+---------------
+
+The patches should be sent to NASM development mailing list
+
+    nasm-devel@lists.sourceforge.net
+
+Please make sure the email client you're using doesn't screw
+your patch (line wrapping and so on).
+
+Wait for response
+-----------------
+
+Be patient. Most NASM developers are pretty busy people so if
+there is no immediate response on your patch -- don't
+be surprised, sometimes a patch may fly around a week(s) before
+gets reviewed. But definitely the patches will not go to /dev/null.
+
+    ---
+    With best regards,
+    NASM-team

data/vendor/repo.or.cz/nasm/TODO

@@ -0,0 +1,376 @@
+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.
+