diff options
Diffstat (limited to 'doc/nasmdoc.txt')
| -rw-r--r-- | doc/nasmdoc.txt | 12394 |
1 files changed, 0 insertions, 12394 deletions
diff --git a/doc/nasmdoc.txt b/doc/nasmdoc.txt deleted file mode 100644 index 5a7286b..0000000 --- a/doc/nasmdoc.txt +++ /dev/null @@ -1,12394 +0,0 @@ - The Netwide Assembler: NASM - =========================== - -Chapter 1: Introduction ------------------------ - - 1.1 What Is NASM? - - The Netwide Assembler, NASM, is an 80x86 and x86-64 assembler - designed for portability and modularity. It supports a range of - object file formats, including Linux and `*BSD' `a.out', `ELF', - `COFF', `Mach-O', Microsoft 16-bit `OBJ', `Win32' and `Win64'. It - will also output plain binary files. Its syntax is designed to be - simple and easy to understand, similar to Intel's but less complex. - It supports all currently known x86 architectural extensions, and - has strong support for macros. - - 1.1.1 Why Yet Another Assembler? - - The Netwide Assembler grew out of an idea on `comp.lang.asm.x86' (or - possibly `alt.lang.asm' - I forget which), which was essentially - that there didn't seem to be a good _free_ x86-series assembler - around, and that maybe someone ought to write one. - - (*) `a86' is good, but not free, and in particular you don't get any - 32-bit capability until you pay. It's DOS only, too. - - (*) `gas' is free, and ports over to DOS and Unix, but it's not very - good, since it's designed to be a back end to `gcc', which - always feeds it correct code. So its error checking is minimal. - Also, its syntax is horrible, from the point of view of anyone - trying to actually _write_ anything in it. Plus you can't write - 16-bit code in it (properly.) - - (*) `as86' is specific to Minix and Linux, and (my version at least) - doesn't seem to have much (or any) documentation. - - (*) `MASM' isn't very good, and it's (was) expensive, and it runs - only under DOS. - - (*) `TASM' is better, but still strives for MASM compatibility, - which means millions of directives and tons of red tape. And its - syntax is essentially MASM's, with the contradictions and quirks - that entails (although it sorts out some of those by means of - Ideal mode.) It's expensive too. And it's DOS-only. - - So here, for your coding pleasure, is NASM. At present it's still in - prototype stage - we don't promise that it can outperform any of - these assemblers. But please, _please_ send us bug reports, fixes, - helpful information, and anything else you can get your hands on - (and thanks to the many people who've done this already! You all - know who you are), and we'll improve it out of all recognition. - Again. - - 1.1.2 License Conditions - - Please see the file `LICENSE', supplied as part of any NASM - distribution archive, for the license conditions under which you may - use NASM. NASM is now under the so-called 2-clause BSD license, also - known as the simplified BSD license. - - Copyright 1996-2009 the NASM Authors - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - (*) Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - (*) Redistributions in binary form must reproduce the above - copyright notice, this list of conditions and the following - disclaimer in the documentation and/or other materials provided - with the distribution. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS - FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, - INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; - LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER - CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN - ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - POSSIBILITY OF SUCH DAMAGE. - - 1.2 Contact Information - - The current version of NASM (since about 0.98.08) is maintained by a - team of developers, accessible through the `nasm-devel' mailing list - (see below for the link). If you want to report a bug, please read - section 12.2 first. - - NASM has a website at `http://www.nasm.us/'. If it's not there, - google for us! - - New releases, release candidates, and daily development snapshots of - NASM are available from the official web site. - - Announcements are posted to `comp.lang.asm.x86', and to the web site - `http://www.freshmeat.net/'. - - If you want information about the current development status, please - subscribe to the `nasm-devel' email list; see link from the website. - - 1.3 Installation - - 1.3.1 Installing NASM under MS-DOS or Windows - - Once you've obtained the appropriate archive for NASM, - `nasm-XXX-dos.zip' or `nasm-XXX-win32.zip' (where `XXX' denotes the - version number of NASM contained in the archive), unpack it into its - own directory (for example `c:\nasm'). - - The archive will contain a set of executable files: the NASM - executable file `nasm.exe', the NDISASM executable file - `ndisasm.exe', and possibly additional utilities to handle the RDOFF - file format. - - The only file NASM needs to run is its own executable, so copy - `nasm.exe' to a directory on your PATH, or alternatively edit - `autoexec.bat' to add the `nasm' directory to your `PATH' (to do - that under Windows XP, go to Start > Control Panel > System > - Advanced > Environment Variables; these instructions may work under - other versions of Windows as well.) - - That's it - NASM is installed. You don't need the nasm directory to - be present to run NASM (unless you've added it to your `PATH'), so - you can delete it if you need to save space; however, you may want - to keep the documentation or test programs. - - If you've downloaded the DOS source archive, `nasm-XXX.zip', the - `nasm' directory will also contain the full NASM source code, and a - selection of Makefiles you can (hopefully) use to rebuild your copy - of NASM from scratch. See the file `INSTALL' in the source archive. - - Note that a number of files are generated from other files by Perl - scripts. Although the NASM source distribution includes these - generated files, you will need to rebuild them (and hence, will need - a Perl interpreter) if you change insns.dat, standard.mac or the - documentation. It is possible future source distributions may not - include these files at all. Ports of Perl for a variety of - platforms, including DOS and Windows, are available from - www.cpan.org. - - 1.3.2 Installing NASM under Unix - - Once you've obtained the Unix source archive for NASM, - `nasm-XXX.tar.gz' (where `XXX' denotes the version number of NASM - contained in the archive), unpack it into a directory such as - `/usr/local/src'. The archive, when unpacked, will create its own - subdirectory `nasm-XXX'. - - NASM is an auto-configuring package: once you've unpacked it, `cd' - to the directory it's been unpacked into and type `./configure'. - This shell script will find the best C compiler to use for building - NASM and set up Makefiles accordingly. - - Once NASM has auto-configured, you can type `make' to build the - `nasm' and `ndisasm' binaries, and then `make install' to install - them in `/usr/local/bin' and install the man pages `nasm.1' and - `ndisasm.1' in `/usr/local/man/man1'. Alternatively, you can give - options such as `--prefix' to the configure script (see the file - `INSTALL' for more details), or install the programs yourself. - - NASM also comes with a set of utilities for handling the `RDOFF' - custom object-file format, which are in the `rdoff' subdirectory of - the NASM archive. You can build these with `make rdf' and install - them with `make rdf_install', if you want them. - -Chapter 2: Running NASM ------------------------ - - 2.1 NASM Command-Line Syntax - - To assemble a file, you issue a command of the form - - nasm -f <format> <filename> [-o <output>] - - For example, - - nasm -f elf myfile.asm - - will assemble `myfile.asm' into an `ELF' object file `myfile.o'. And - - nasm -f bin myfile.asm -o myfile.com - - will assemble `myfile.asm' into a raw binary file `myfile.com'. - - To produce a listing file, with the hex codes output from NASM - displayed on the left of the original sources, use the `-l' option - to give a listing file name, for example: - - nasm -f coff myfile.asm -l myfile.lst - - To get further usage instructions from NASM, try typing - - nasm -h - - As `-hf', this will also list the available output file formats, and - what they are. - - If you use Linux but aren't sure whether your system is `a.out' or - `ELF', type - - file nasm - - (in the directory in which you put the NASM binary when you - installed it). If it says something like - - nasm: ELF 32-bit LSB executable i386 (386 and up) Version 1 - - then your system is `ELF', and you should use the option `-f elf' - when you want NASM to produce Linux object files. If it says - - nasm: Linux/i386 demand-paged executable (QMAGIC) - - or something similar, your system is `a.out', and you should use - `-f aout' instead (Linux `a.out' systems have long been obsolete, - and are rare these days.) - - Like Unix compilers and assemblers, NASM is silent unless it goes - wrong: you won't see any output at all, unless it gives error - messages. - - 2.1.1 The `-o' Option: Specifying the Output File Name - - NASM will normally choose the name of your output file for you; - precisely how it does this is dependent on the object file format. - For Microsoft object file formats (`obj', `win32' and `win64'), it - will remove the `.asm' extension (or whatever extension you like to - use - NASM doesn't care) from your source file name and substitute - `.obj'. For Unix object file formats (`aout', `as86', `coff', - `elf32', `elf64', `ieee', `macho32' and `macho64') it will - substitute `.o'. For `dbg', `rdf', `ith' and `srec', it will use - `.dbg', `.rdf', `.ith' and `.srec', respectively, and for the `bin' - format it will simply remove the extension, so that `myfile.asm' - produces the output file `myfile'. - - If the output file already exists, NASM will overwrite it, unless it - has the same name as the input file, in which case it will give a - warning and use `nasm.out' as the output file name instead. - - For situations in which this behaviour is unacceptable, NASM - provides the `-o' command-line option, which allows you to specify - your desired output file name. You invoke `-o' by following it with - the name you wish for the output file, either with or without an - intervening space. For example: - - nasm -f bin program.asm -o program.com - nasm -f bin driver.asm -odriver.sys - - Note that this is a small o, and is different from a capital O , - which is used to specify the number of optimisation passes required. - See section 2.1.22. - - 2.1.2 The `-f' Option: Specifying the Output File Format - - If you do not supply the `-f' option to NASM, it will choose an - output file format for you itself. In the distribution versions of - NASM, the default is always `bin'; if you've compiled your own copy - of NASM, you can redefine `OF_DEFAULT' at compile time and choose - what you want the default to be. - - Like `-o', the intervening space between `-f' and the output file - format is optional; so `-f elf' and `-felf' are both valid. - - A complete list of the available output file formats can be given by - issuing the command `nasm -hf'. - - 2.1.3 The `-l' Option: Generating a Listing File - - If you supply the `-l' option to NASM, followed (with the usual - optional space) by a file name, NASM will generate a source-listing - file for you, in which addresses and generated code are listed on - the left, and the actual source code, with expansions of multi-line - macros (except those which specifically request no expansion in - source listings: see section 4.3.10) on the right. For example: - - nasm -f elf myfile.asm -l myfile.lst - - If a list file is selected, you may turn off listing for a section - of your source with `[list -]', and turn it back on with `[list +]', - (the default, obviously). There is no "user form" (without the - brackets). This can be used to list only sections of interest, - avoiding excessively long listings. - - 2.1.4 The `-M' Option: Generate Makefile Dependencies - - This option can be used to generate makefile dependencies on stdout. - This can be redirected to a file for further processing. For - example: - - nasm -M myfile.asm > myfile.dep - - 2.1.5 The `-MG' Option: Generate Makefile Dependencies - - This option can be used to generate makefile dependencies on stdout. - This differs from the `-M' option in that if a nonexisting file is - encountered, it is assumed to be a generated file and is added to - the dependency list without a prefix. - - 2.1.6 The `-MF' Option: Set Makefile Dependency File - - This option can be used with the `-M' or `-MG' options to send the - output to a file, rather than to stdout. For example: - - nasm -M -MF myfile.dep myfile.asm - - 2.1.7 The `-MD' Option: Assemble and Generate Dependencies - - The `-MD' option acts as the combination of the `-M' and `-MF' - options (i.e. a filename has to be specified.) However, unlike the - `-M' or `-MG' options, `-MD' does _not_ inhibit the normal operation - of the assembler. Use this to automatically generate updated - dependencies with every assembly session. For example: - - nasm -f elf -o myfile.o -MD myfile.dep myfile.asm - - 2.1.8 The `-MT' Option: Dependency Target Name - - The `-MT' option can be used to override the default name of the - dependency target. This is normally the same as the output filename, - specified by the `-o' option. - - 2.1.9 The `-MQ' Option: Dependency Target Name (Quoted) - - The `-MQ' option acts as the `-MT' option, except it tries to quote - characters that have special meaning in Makefile syntax. This is not - foolproof, as not all characters with special meaning are quotable - in Make. - -2.1.10 The `-MP' Option: Emit phony targets - - When used with any of the dependency generation options, the `-MP' - option causes NASM to emit a phony target without dependencies for - each header file. This prevents Make from complaining if a header - file has been removed. - -2.1.11 The `-F' Option: Selecting a Debug Information Format - - This option is used to select the format of the debug information - emitted into the output file, to be used by a debugger (or _will_ - be). Prior to version 2.03.01, the use of this switch did _not_ - enable output of the selected debug info format. Use `-g', see - section 2.1.12, to enable output. Versions 2.03.01 and later - automatically enable `-g' if `-F' is specified. - - A complete list of the available debug file formats for an output - format can be seen by issuing the command `nasm -f <format> -y'. Not - all output formats currently support debugging output. See section - 2.1.26. - - This should not be confused with the `-f dbg' output format option - which is not built into NASM by default. For information on how to - enable it when building from the sources, see section 7.14. - -2.1.12 The `-g' Option: Enabling Debug Information. - - This option can be used to generate debugging information in the - specified format. See section 2.1.11. Using `-g' without `-F' - results in emitting debug info in the default format, if any, for - the selected output format. If no debug information is currently - implemented in the selected output format, `-g' is _silently - ignored_. - -2.1.13 The `-X' Option: Selecting an Error Reporting Format - - This option can be used to select an error reporting format for any - error messages that might be produced by NASM. - - Currently, two error reporting formats may be selected. They are the - `-Xvc' option and the `-Xgnu' option. The GNU format is the default - and looks like this: - - filename.asm:65: error: specific error message - - where `filename.asm' is the name of the source file in which the - error was detected, `65' is the source file line number on which the - error was detected, `error' is the severity of the error (this could - be `warning'), and `specific error message' is a more detailed text - message which should help pinpoint the exact problem. - - The other format, specified by `-Xvc' is the style used by Microsoft - Visual C++ and some other programs. It looks like this: - - filename.asm(65) : error: specific error message - - where the only difference is that the line number is in parentheses - instead of being delimited by colons. - - See also the `Visual C++' output format, section 7.5. - -2.1.14 The `-Z' Option: Send Errors to a File - - Under `MS-DOS' it can be difficult (though there are ways) to - redirect the standard-error output of a program to a file. Since - NASM usually produces its warning and error messages on `stderr', - this can make it hard to capture the errors if (for example) you - want to load them into an editor. - - NASM therefore provides the `-Z' option, taking a filename argument - which causes errors to be sent to the specified files rather than - standard error. Therefore you can redirect the errors into a file by - typing - - nasm -Z myfile.err -f obj myfile.asm - - In earlier versions of NASM, this option was called `-E', but it was - changed since `-E' is an option conventionally used for - preprocessing only, with disastrous results. See section 2.1.20. - -2.1.15 The `-s' Option: Send Errors to `stdout' - - The `-s' option redirects error messages to `stdout' rather than - `stderr', so it can be redirected under `MS-DOS'. To assemble the - file `myfile.asm' and pipe its output to the `more' program, you can - type: - - nasm -s -f obj myfile.asm | more - - See also the `-Z' option, section 2.1.14. - -2.1.16 The `-i' Option: Include File Search Directories - - When NASM sees the `%include' or `%pathsearch' directive in a source - file (see section 4.6.1, section 4.6.2 or section 3.2.3), it will - search for the given file not only in the current directory, but - also in any directories specified on the command line by the use of - the `-i' option. Therefore you can include files from a macro - library, for example, by typing - - nasm -ic:\macrolib\ -f obj myfile.asm - - (As usual, a space between `-i' and the path name is allowed, and - optional). - - NASM, in the interests of complete source-code portability, does not - understand the file naming conventions of the OS it is running on; - the string you provide as an argument to the `-i' option will be - prepended exactly as written to the name of the include file. - Therefore the trailing backslash in the above example is necessary. - Under Unix, a trailing forward slash is similarly necessary. - - (You can use this to your advantage, if you're really perverse, by - noting that the option `-ifoo' will cause `%include "bar.i"' to - search for the file `foobar.i'...) - - If you want to define a _standard_ include search path, similar to - `/usr/include' on Unix systems, you should place one or more `-i' - directives in the `NASMENV' environment variable (see section - 2.1.28). - - For Makefile compatibility with many C compilers, this option can - also be specified as `-I'. - -2.1.17 The `-p' Option: Pre-Include a File - - NASM allows you to specify files to be _pre-included_ into your - source file, by the use of the `-p' option. So running - - nasm myfile.asm -p myinc.inc - - is equivalent to running `nasm myfile.asm' and placing the directive - `%include "myinc.inc"' at the start of the file. - - For consistency with the `-I', `-D' and `-U' options, this option - can also be specified as `-P'. - -2.1.18 The `-d' Option: Pre-Define a Macro - - Just as the `-p' option gives an alternative to placing `%include' - directives at the start of a source file, the `-d' option gives an - alternative to placing a `%define' directive. You could code - - nasm myfile.asm -dFOO=100 - - as an alternative to placing the directive - - %define FOO 100 - - at the start of the file. You can miss off the macro value, as well: - the option `-dFOO' is equivalent to coding `%define FOO'. This form - of the directive may be useful for selecting assembly-time options - which are then tested using `%ifdef', for example `-dDEBUG'. - - For Makefile compatibility with many C compilers, this option can - also be specified as `-D'. - -2.1.19 The `-u' Option: Undefine a Macro - - The `-u' option undefines a macro that would otherwise have been - pre-defined, either automatically or by a `-p' or `-d' option - specified earlier on the command lines. - - For example, the following command line: - - nasm myfile.asm -dFOO=100 -uFOO - - would result in `FOO' _not_ being a predefined macro in the program. - This is useful to override options specified at a different point in - a Makefile. - - For Makefile compatibility with many C compilers, this option can - also be specified as `-U'. - -2.1.20 The `-E' Option: Preprocess Only - - NASM allows the preprocessor to be run on its own, up to a point. - Using the `-E' option (which requires no arguments) will cause NASM - to preprocess its input file, expand all the macro references, - remove all the comments and preprocessor directives, and print the - resulting file on standard output (or save it to a file, if the `-o' - option is also used). - - This option cannot be applied to programs which require the - preprocessor to evaluate expressions which depend on the values of - symbols: so code such as - - %assign tablesize ($-tablestart) - - will cause an error in preprocess-only mode. - - For compatiblity with older version of NASM, this option can also be - written `-e'. `-E' in older versions of NASM was the equivalent of - the current `-Z' option, section 2.1.14. - -2.1.21 The `-a' Option: Don't Preprocess At All - - If NASM is being used as the back end to a compiler, it might be - desirable to suppress preprocessing completely and assume the - compiler has already done it, to save time and increase compilation - speeds. The `-a' option, requiring no argument, instructs NASM to - replace its powerful preprocessor with a stub preprocessor which - does nothing. - -2.1.22 The `-O' Option: Specifying Multipass Optimization - - NASM defaults to not optimizing operands which can fit into a signed - byte. This means that if you want the shortest possible object code, - you have to enable optimization. - - Using the `-O' option, you can tell NASM to carry out different - levels of optimization. The syntax is: - - (*) `-O0': No optimization. All operands take their long forms, if a - short form is not specified, except conditional jumps. This is - intended to match NASM 0.98 behavior. - - (*) `-O1': Minimal optimization. As above, but immediate operands - which will fit in a signed byte are optimized, unless the long - form is specified. Conditional jumps default to the long form - unless otherwise specified. - - (*) `-Ox' (where `x' is the actual letter `x'): Multipass - optimization. Minimize branch offsets and signed immediate - bytes, overriding size specification unless the `strict' keyword - has been used (see section 3.7). For compatability with earlier - releases, the letter `x' may also be any number greater than - one. This number has no effect on the actual number of passes. - - The `-Ox' mode is recommended for most uses. - - Note that this is a capital `O', and is different from a small `o', - which is used to specify the output file name. See section 2.1.1. - -2.1.23 The `-t' Option: Enable TASM Compatibility Mode - - NASM includes a limited form of compatibility with Borland's `TASM'. - When NASM's `-t' option is used, the following changes are made: - - (*) local labels may be prefixed with `@@' instead of `.' - - (*) size override is supported within brackets. In TASM compatible - mode, a size override inside square brackets changes the size of - the operand, and not the address type of the operand as it does - in NASM syntax. E.g. `mov eax,[DWORD val]' is valid syntax in - TASM compatibility mode. Note that you lose the ability to - override the default address type for the instruction. - - (*) unprefixed forms of some directives supported (`arg', `elif', - `else', `endif', `if', `ifdef', `ifdifi', `ifndef', `include', - `local') - -2.1.24 The `-w' and `-W' Options: Enable or Disable Assembly Warnings - - NASM can observe many conditions during the course of assembly which - are worth mentioning to the user, but not a sufficiently severe - error to justify NASM refusing to generate an output file. These - conditions are reported like errors, but come up with the word - `warning' before the message. Warnings do not prevent NASM from - generating an output file and returning a success status to the - operating system. - - Some conditions are even less severe than that: they are only - sometimes worth mentioning to the user. Therefore NASM supports the - `-w' command-line option, which enables or disables certain classes - of assembly warning. Such warning classes are described by a name, - for example `orphan-labels'; you can enable warnings of this class - by the command-line option `-w+orphan-labels' and disable it by - `-w-orphan-labels'. - - The suppressible warning classes are: - - (*) `macro-params' covers warnings about multi-line macros being - invoked with the wrong number of parameters. This warning class - is enabled by default; see section 4.3.2 for an example of why - you might want to disable it. - - (*) `macro-selfref' warns if a macro references itself. This warning - class is disabled by default. - - (*) `macro-defaults' warns when a macro has more default parameters - than optional parameters. This warning class is enabled by - default; see section 4.3.5 for why you might want to disable it. - - (*) `orphan-labels' covers warnings about source lines which contain - no instruction but define a label without a trailing colon. NASM - warns about this somewhat obscure condition by default; see - section 3.1 for more information. - - (*) `number-overflow' covers warnings about numeric constants which - don't fit in 64 bits. This warning class is enabled by default. - - (*) `gnu-elf-extensions' warns if 8-bit or 16-bit relocations are - used in `-f elf' format. The GNU extensions allow this. This - warning class is disabled by default. - - (*) `float-overflow' warns about floating point overflow. Enabled by - default. - - (*) `float-denorm' warns about floating point denormals. Disabled by - default. - - (*) `float-underflow' warns about floating point underflow. Disabled - by default. - - (*) `float-toolong' warns about too many digits in floating-point - numbers. Enabled by default. - - (*) `user' controls `%warning' directives (see section 4.9). Enabled - by default. - - (*) `error' causes warnings to be treated as errors. Disabled by - default. - - (*) `all' is an alias for _all_ suppressible warning classes (not - including `error'). Thus, `-w+all' enables all available - warnings. - - In addition, you can set warning classes across sections. Warning - classes may be enabled with `[warning +warning-name]', disabled with - `[warning -warning-name]' or reset to their original value with - `[warning *warning-name]'. No "user form" (without the brackets) - exists. - - Since version 2.00, NASM has also supported the gcc-like syntax - `-Wwarning' and `-Wno-warning' instead of `-w+warning' and - `-w-warning', respectively. - -2.1.25 The `-v' Option: Display Version Info - - Typing `NASM -v' will display the version of NASM which you are - using, and the date on which it was compiled. - - You will need the version number if you report a bug. - -2.1.26 The `-y' Option: Display Available Debug Info Formats - - Typing `nasm -f <option> -y' will display a list of the available - debug info formats for the given output format. The default format - is indicated by an asterisk. For example: - - nasm -f elf -y - - valid debug formats for 'elf32' output format are - ('*' denotes default): - * stabs ELF32 (i386) stabs debug format for Linux - dwarf elf32 (i386) dwarf debug format for Linux - -2.1.27 The `--prefix' and `--postfix' Options. - - The `--prefix' and `--postfix' options prepend or append - (respectively) the given argument to all `global' or `extern' - variables. E.g. `--prefix _' will prepend the underscore to all - global and external variables, as C sometimes (but not always) likes - it. - -2.1.28 The `NASMENV' Environment Variable - - If you define an environment variable called `NASMENV', the program - will interpret it as a list of extra command-line options, which are - processed before the real command line. You can use this to define - standard search directories for include files, by putting `-i' - options in the `NASMENV' variable. - - The value of the variable is split up at white space, so that the - value `-s -ic:\nasmlib\' will be treated as two separate options. - However, that means that the value `-dNAME="my name"' won't do what - you might want, because it will be split at the space and the NASM - command-line processing will get confused by the two nonsensical - words `-dNAME="my' and `name"'. - - To get round this, NASM provides a feature whereby, if you begin the - `NASMENV' environment variable with some character that isn't a - minus sign, then NASM will treat this character as the separator - character for options. So setting the `NASMENV' variable to the - value `!-s!-ic:\nasmlib\' is equivalent to setting it to - `-s -ic:\nasmlib\', but `!-dNAME="my name"' will work. - - This environment variable was previously called `NASM'. This was - changed with version 0.98.31. - - 2.2 Quick Start for MASM Users - - If you're used to writing programs with MASM, or with TASM in MASM- - compatible (non-Ideal) mode, or with `a86', this section attempts to - outline the major differences between MASM's syntax and NASM's. If - you're not already used to MASM, it's probably worth skipping this - section. - - 2.2.1 NASM Is Case-Sensitive - - One simple difference is that NASM is case-sensitive. It makes a - difference whether you call your label `foo', `Foo' or `FOO'. If - you're assembling to `DOS' or `OS/2' `.OBJ' files, you can invoke - the `UPPERCASE' directive (documented in section 7.4) to ensure that - all symbols exported to other code modules are forced to be upper - case; but even then, _within_ a single module, NASM will distinguish - between labels differing only in case. - - 2.2.2 NASM Requires Square Brackets For Memory References - - NASM was designed with simplicity of syntax in mind. One of the - design goals of NASM is that it should be possible, as far as is - practical, for the user to look at a single line of NASM code and - tell what opcode is generated by it. You can't do this in MASM: if - you declare, for example, - - foo equ 1 - bar dw 2 - - then the two lines of code - - mov ax,foo - mov ax,bar - - generate completely different opcodes, despite having identical- - looking syntaxes. - - NASM avoids this undesirable situation by having a much simpler - syntax for memory references. The rule is simply that any access to - the _contents_ of a memory location requires square brackets around - the address, and any access to the _address_ of a variable doesn't. - So an instruction of the form `mov ax,foo' will _always_ refer to a - compile-time constant, whether it's an `EQU' or the address of a - variable; and to access the _contents_ of the variable `bar', you - must code `mov ax,[bar]'. - - This also means that NASM has no need for MASM's `OFFSET' keyword, - since the MASM code `mov ax,offset bar' means exactly the same thing - as NASM's `mov ax,bar'. If you're trying to get large amounts of - MASM code to assemble sensibly under NASM, you can always code - `%idefine offset' to make the preprocessor treat the `OFFSET' - keyword as a no-op. - - This issue is even more confusing in `a86', where declaring a label - with a trailing colon defines it to be a `label' as opposed to a - `variable' and causes `a86' to adopt NASM-style semantics; so in - `a86', `mov ax,var' has different behaviour depending on whether - `var' was declared as `var: dw 0' (a label) or `var dw 0' (a word- - size variable). NASM is very simple by comparison: _everything_ is a - label. - - NASM, in the interests of simplicity, also does not support the - hybrid syntaxes supported by MASM and its clones, such as - `mov ax,table[bx]', where a memory reference is denoted by one - portion outside square brackets and another portion inside. The - correct syntax for the above is `mov ax,[table+bx]'. Likewise, - `mov ax,es:[di]' is wrong and `mov ax,[es:di]' is right. - - 2.2.3 NASM Doesn't Store Variable Types - - NASM, by design, chooses not to remember the types of variables you - declare. Whereas MASM will remember, on seeing `var dw 0', that you - declared `var' as a word-size variable, and will then be able to - fill in the ambiguity in the size of the instruction `mov var,2', - NASM will deliberately remember nothing about the symbol `var' - except where it begins, and so you must explicitly code - `mov word [var],2'. - - For this reason, NASM doesn't support the `LODS', `MOVS', `STOS', - `SCAS', `CMPS', `INS', or `OUTS' instructions, but only supports the - forms such as `LODSB', `MOVSW', and `SCASD', which explicitly - specify the size of the components of the strings being manipulated. - - 2.2.4 NASM Doesn't `ASSUME' - - As part of NASM's drive for simplicity, it also does not support the - `ASSUME' directive. NASM will not keep track of what values you - choose to put in your segment registers, and will never - _automatically_ generate a segment override prefix. - - 2.2.5 NASM Doesn't Support Memory Models - - NASM also does not have any directives to support different 16-bit - memory models. The programmer has to keep track of which functions - are supposed to be called with a far call and which with a near - call, and is responsible for putting the correct form of `RET' - instruction (`RETN' or `RETF'; NASM accepts `RET' itself as an - alternate form for `RETN'); in addition, the programmer is - responsible for coding CALL FAR instructions where necessary when - calling _external_ functions, and must also keep track of which - external variable definitions are far and which are near. - - 2.2.6 Floating-Point Differences - - NASM uses different names to refer to floating-point registers from - MASM: where MASM would call them `ST(0)', `ST(1)' and so on, and - `a86' would call them simply `0', `1' and so on, NASM chooses to - call them `st0', `st1' etc. - - As of version 0.96, NASM now treats the instructions with `nowait' - forms in the same way as MASM-compatible assemblers. The - idiosyncratic treatment employed by 0.95 and earlier was based on a - misunderstanding by the authors. - - 2.2.7 Other Differences - - For historical reasons, NASM uses the keyword `TWORD' where MASM and - compatible assemblers use `TBYTE'. - - NASM does not declare uninitialized storage in the same way as MASM: - where a MASM programmer might use `stack db 64 dup (?)', NASM - requires `stack resb 64', intended to be read as `reserve 64 bytes'. - For a limited amount of compatibility, since NASM treats `?' as a - valid character in symbol names, you can code `? equ 0' and then - writing `dw ?' will at least do something vaguely useful. `DUP' is - still not a supported syntax, however. - - In addition to all of this, macros and directives work completely - differently to MASM. See chapter 4 and chapter 6 for further - details. - -Chapter 3: The NASM Language ----------------------------- - - 3.1 Layout of a NASM Source Line - - Like most assemblers, each NASM source line contains (unless it is a - macro, a preprocessor directive or an assembler directive: see - chapter 4 and chapter 6) some combination of the four fields - - label: instruction operands ; comment - - As usual, most of these fields are optional; the presence or absence - of any combination of a label, an instruction and a comment is - allowed. Of course, the operand field is either required or - forbidden by the presence and nature of the instruction field. - - NASM uses backslash (\) as the line continuation character; if a - line ends with backslash, the next line is considered to be a part - of the backslash-ended line. - - NASM places no restrictions on white space within a line: labels may - have white space before them, or instructions may have no space - before them, or anything. The colon after a label is also optional. - (Note that this means that if you intend to code `lodsb' alone on a - line, and type `lodab' by accident, then that's still a valid source - line which does nothing but define a label. Running NASM with the - command-line option `-w+orphan-labels' will cause it to warn you if - you define a label alone on a line without a trailing colon.) - - Valid characters in labels are letters, numbers, `_', `$', `#', `@', - `~', `.', and `?'. The only characters which may be used as the - _first_ character of an identifier are letters, `.' (with special - meaning: see section 3.9), `_' and `?'. An identifier may also be - prefixed with a `$' to indicate that it is intended to be read as an - identifier and not a reserved word; thus, if some other module you - are linking with defines a symbol called `eax', you can refer to - `$eax' in NASM code to distinguish the symbol from the register. - Maximum length of an identifier is 4095 characters. - - The instruction field may contain any machine instruction: Pentium - and P6 instructions, FPU instructions, MMX instructions and even - undocumented instructions are all supported. The instruction may be - prefixed by `LOCK', `REP', `REPE'/`REPZ' or `REPNE'/`REPNZ', in the - usual way. Explicit address-size and operand-size prefixes `A16', - `A32', `A64', `O16' and `O32', `O64' are provided - one example of - their use is given in chapter 10. You can also use the name of a - segment register as an instruction prefix: coding `es mov [bx],ax' - is equivalent to coding `mov [es:bx],ax'. We recommend the latter - syntax, since it is consistent with other syntactic features of the - language, but for instructions such as `LODSB', which has no - operands and yet can require a segment override, there is no clean - syntactic way to proceed apart from `es lodsb'. - - An instruction is not required to use a prefix: prefixes such as - `CS', `A32', `LOCK' or `REPE' can appear on a line by themselves, - and NASM will just generate the prefix bytes. - - In addition to actual machine instructions, NASM also supports a - number of pseudo-instructions, described in section 3.2. - - Instruction operands may take a number of forms: they can be - registers, described simply by the register name (e.g. `ax', `bp', - `ebx', `cr0': NASM does not use the `gas'-style syntax in which - register names must be prefixed by a `%' sign), or they can be - effective addresses (see section 3.3), constants (section 3.4) or - expressions (section 3.5). - - For x87 floating-point instructions, NASM accepts a wide range of - syntaxes: you can use two-operand forms like MASM supports, or you - can use NASM's native single-operand forms in most cases. For - example, you can code: - - fadd st1 ; this sets st0 := st0 + st1 - fadd st0,st1 ; so does this - - fadd st1,st0 ; this sets st1 := st1 + st0 - fadd to st1 ; so does this - - Almost any x87 floating-point instruction that references memory - must use one of the prefixes `DWORD', `QWORD' or `TWORD' to indicate - what size of memory operand it refers to. - - 3.2 Pseudo-Instructions - - Pseudo-instructions are things which, though not real x86 machine - instructions, are used in the instruction field anyway because - that's the most convenient place to put them. The current pseudo- - instructions are `DB', `DW', `DD', `DQ', `DT', `DO' and `DY'; their - uninitialized counterparts `RESB', `RESW', `RESD', `RESQ', `REST', - `RESO' and `RESY'; the `INCBIN' command, the `EQU' command, and the - `TIMES' prefix. - - 3.2.1 `DB' and Friends: Declaring Initialized Data - - `DB', `DW', `DD', `DQ', `DT', `DO' and `DY' are used, much as in - MASM, to declare initialized data in the output file. They can be - invoked in a wide range of ways: - - db 0x55 ; just the byte 0x55 - db 0x55,0x56,0x57 ; three bytes in succession - db 'a',0x55 ; character constants are OK - db 'hello',13,10,'$' ; so are string constants - dw 0x1234 ; 0x34 0x12 - dw 'a' ; 0x61 0x00 (it's just a number) - dw 'ab' ; 0x61 0x62 (character constant) - dw 'abc' ; 0x61 0x62 0x63 0x00 (string) - dd 0x12345678 ; 0x78 0x56 0x34 0x12 - dd 1.234567e20 ; floating-point constant - dq 0x123456789abcdef0 ; eight byte constant - dq 1.234567e20 ; double-precision float - dt 1.234567e20 ; extended-precision float - - `DT', `DO' and `DY' do not accept numeric constants as operands. - - 3.2.2 `RESB' and Friends: Declaring Uninitialized Data - - `RESB', `RESW', `RESD', `RESQ', `REST', `RESO' and `RESY' are - designed to be used in the BSS section of a module: they declare - _uninitialized_ storage space. Each takes a single operand, which is - the number of bytes, words, doublewords or whatever to reserve. As - stated in section 2.2.7, NASM does not support the MASM/TASM syntax - of reserving uninitialized space by writing `DW ?' or similar - things: this is what it does instead. The operand to a `RESB'-type - pseudo-instruction is a _critical expression_: see section 3.8. - - For example: - - buffer: resb 64 ; reserve 64 bytes - wordvar: resw 1 ; reserve a word - realarray resq 10 ; array of ten reals - ymmval: resy 1 ; one YMM register - - 3.2.3 `INCBIN': Including External Binary Files - - `INCBIN' is borrowed from the old Amiga assembler DevPac: it - includes a binary file verbatim into the output file. This can be - handy for (for example) including graphics and sound data directly - into a game executable file. It can be called in one of these three - ways: - - incbin "file.dat" ; include the whole file - incbin "file.dat",1024 ; skip the first 1024 bytes - incbin "file.dat",1024,512 ; skip the first 1024, and - ; actually include at most 512 - - `INCBIN' is both a directive and a standard macro; the standard - macro version searches for the file in the include file search path - and adds the file to the dependency lists. This macro can be - overridden if desired. - - 3.2.4 `EQU': Defining Constants - - `EQU' defines a symbol to a given constant value: when `EQU' is - used, the source line must contain a label. The action of `EQU' is - to define the given label name to the value of its (only) operand. - This definition is absolute, and cannot change later. So, for - example, - - message db 'hello, world' - msglen equ $-message - - defines `msglen' to be the constant 12. `msglen' may not then be - redefined later. This is not a preprocessor definition either: the - value of `msglen' is evaluated _once_, using the value of `$' (see - section 3.5 for an explanation of `$') at the point of definition, - rather than being evaluated wherever it is referenced and using the - value of `$' at the point of reference. - - 3.2.5 `TIMES': Repeating Instructions or Data - - The `TIMES' prefix causes the instruction to be assembled multiple - times. This is partly present as NASM's equivalent of the `DUP' - syntax supported by MASM-compatible assemblers, in that you can code - - zerobuf: times 64 db 0 - - or similar things; but `TIMES' is more versatile than that. The - argument to `TIMES' is not just a numeric constant, but a numeric - _expression_, so you can do things like - - buffer: db 'hello, world' - times 64-$+buffer db ' ' - - which will store exactly enough spaces to make the total length of - `buffer' up to 64. Finally, `TIMES' can be applied to ordinary - instructions, so you can code trivial unrolled loops in it: - - times 100 movsb - - Note that there is no effective difference between - `times 100 resb 1' and `resb 100', except that the latter will be - assembled about 100 times faster due to the internal structure of - the assembler. - - The operand to `TIMES' is a critical expression (section 3.8). - - Note also that `TIMES' can't be applied to macros: the reason for - this is that `TIMES' is processed after the macro phase, which - allows the argument to `TIMES' to contain expressions such as - `64-$+buffer' as above. To repeat more than one line of code, or a - complex macro, use the preprocessor `%rep' directive. - - 3.3 Effective Addresses - - An effective address is any operand to an instruction which - references memory. Effective addresses, in NASM, have a very simple - syntax: they consist of an expression evaluating to the desired - address, enclosed in square brackets. For example: - - wordvar dw 123 - mov ax,[wordvar] - mov ax,[wordvar+1] - mov ax,[es:wordvar+bx] - - Anything not conforming to this simple system is not a valid memory - reference in NASM, for example `es:wordvar[bx]'. - - More complicated effective addresses, such as those involving more - than one register, work in exactly the same way: - - mov eax,[ebx*2+ecx+offset] - mov ax,[bp+di+8] - - NASM is capable of doing algebra on these effective addresses, so - that things which don't necessarily _look_ legal are perfectly all - right: - - mov eax,[ebx*5] ; assembles as [ebx*4+ebx] - mov eax,[label1*2-label2] ; ie [label1+(label1-label2)] - - Some forms of effective address have more than one assembled form; - in most such cases NASM will generate the smallest form it can. For - example, there are distinct assembled forms for the 32-bit effective - addresses `[eax*2+0]' and `[eax+eax]', and NASM will generally - generate the latter on the grounds that the former requires four - bytes to store a zero offset. - - NASM has a hinting mechanism which will cause `[eax+ebx]' and - `[ebx+eax]' to generate different opcodes; this is occasionally - useful because `[esi+ebp]' and `[ebp+esi]' have different default - segment registers. - - However, you can force NASM to generate an effective address in a - particular form by the use of the keywords `BYTE', `WORD', `DWORD' - and `NOSPLIT'. If you need `[eax+3]' to be assembled using a double- - word offset field instead of the one byte NASM will normally - generate, you can code `[dword eax+3]'. Similarly, you can force - NASM to use a byte offset for a small value which it hasn't seen on - the first pass (see section 3.8 for an example of such a code - fragment) by using `[byte eax+offset]'. As special cases, - `[byte eax]' will code `[eax+0]' with a byte offset of zero, and - `[dword eax]' will code it with a double-word offset of zero. The - normal form, `[eax]', will be coded with no offset field. - - The form described in the previous paragraph is also useful if you - are trying to access data in a 32-bit segment from within 16 bit - code. For more information on this see the section on mixed-size - addressing (section 10.2). In particular, if you need to access data - with a known offset that is larger than will fit in a 16-bit value, - if you don't specify that it is a dword offset, nasm will cause the - high word of the offset to be lost. - - Similarly, NASM will split `[eax*2]' into `[eax+eax]' because that - allows the offset field to be absent and space to be saved; in fact, - it will also split `[eax*2+offset]' into `[eax+eax+offset]'. You can - combat this behaviour by the use of the `NOSPLIT' keyword: - `[nosplit eax*2]' will force `[eax*2+0]' to be generated literally. - - In 64-bit mode, NASM will by default generate absolute addresses. - The `REL' keyword makes it produce `RIP'-relative addresses. Since - this is frequently the normally desired behaviour, see the `DEFAULT' - directive (section 6.2). The keyword `ABS' overrides `REL'. - - 3.4 Constants - - NASM understands four different types of constant: numeric, - character, string and floating-point. - - 3.4.1 Numeric Constants - - A numeric constant is simply a number. NASM allows you to specify - numbers in a variety of number bases, in a variety of ways: you can - suffix `H' or `X', `Q' or `O', and `B' for hexadecimal, octal and - binary respectively, or you can prefix `0x' for hexadecimal in the - style of C, or you can prefix `$' for hexadecimal in the style of - Borland Pascal. Note, though, that the `$' prefix does double duty - as a prefix on identifiers (see section 3.1), so a hex number - prefixed with a `$' sign must have a digit after the `$' rather than - a letter. In addition, current versions of NASM accept the prefix - `0h' for hexadecimal, `0o' or `0q' for octal, and `0b' for binary. - Please note that unlike C, a `0' prefix by itself does _not_ imply - an octal constant! - - Numeric constants can have underscores (`_') interspersed to break - up long strings. - - Some examples (all producing exactly the same code): - - mov ax,200 ; decimal - mov ax,0200 ; still decimal - mov ax,0200d ; explicitly decimal - mov ax,0d200 ; also decimal - mov ax,0c8h ; hex - mov ax,$0c8 ; hex again: the 0 is required - mov ax,0xc8 ; hex yet again - mov ax,0hc8 ; still hex - mov ax,310q ; octal - mov ax,310o ; octal again - mov ax,0o310 ; octal yet again - mov ax,0q310 ; hex yet again - mov ax,11001000b ; binary - mov ax,1100_1000b ; same binary constant - mov ax,0b1100_1000 ; same binary constant yet again - - 3.4.2 Character Strings - - A character string consists of up to eight characters enclosed in - either single quotes (`'...''), double quotes (`"..."') or - backquotes (``...`'). Single or double quotes are equivalent to NASM - (except of course that surrounding the constant with single quotes - allows double quotes to appear within it and vice versa); the - contents of those are represented verbatim. Strings enclosed in - backquotes support C-style `\'-escapes for special characters. - - The following escape sequences are recognized by backquoted strings: - - \' single quote (') - \" double quote (") - \` backquote (`) - \\ backslash (\) - \? question mark (?) - \a BEL (ASCII 7) - \b BS (ASCII 8) - \t TAB (ASCII 9) - \n LF (ASCII 10) - \v VT (ASCII 11) - \f FF (ASCII 12) - \r CR (ASCII 13) - \e ESC (ASCII 27) - \377 Up to 3 octal digits - literal byte - \xFF Up to 2 hexadecimal digits - literal byte - \u1234 4 hexadecimal digits - Unicode character - \U12345678 8 hexadecimal digits - Unicode character - - All other escape sequences are reserved. Note that `\0', meaning a - `NUL' character (ASCII 0), is a special case of the octal escape - sequence. - - Unicode characters specified with `\u' or `\U' are converted to - UTF-8. For example, the following lines are all equivalent: - - db `\u263a` ; UTF-8 smiley face - db `\xe2\x98\xba` ; UTF-8 smiley face - db 0E2h, 098h, 0BAh ; UTF-8 smiley face - - 3.4.3 Character Constants - - A character constant consists of a string up to eight bytes long, - used in an expression context. It is treated as if it was an - integer. - - A character constant with more than one byte will be arranged with - little-endian order in mind: if you code - - mov eax,'abcd' - - then the constant generated is not `0x61626364', but `0x64636261', - so that if you were then to store the value into memory, it would - read `abcd' rather than `dcba'. This is also the sense of character - constants understood by the Pentium's `CPUID' instruction. - - 3.4.4 String Constants - - String constants are character strings used in the context of some - pseudo-instructions, namely the `DB' family and `INCBIN' (where it - represents a filename.) They are also used in certain preprocessor - directives. - - A string constant looks like a character constant, only longer. It - is treated as a concatenation of maximum-size character constants - for the conditions. So the following are equivalent: - - db 'hello' ; string constant - db 'h','e','l','l','o' ; equivalent character constants - - And the following are also equivalent: - - dd 'ninechars' ; doubleword string constant - dd 'nine','char','s' ; becomes three doublewords - db 'ninechars',0,0,0 ; and really looks like this - - Note that when used in a string-supporting context, quoted strings - are treated as a string constants even if they are short enough to - be a character constant, because otherwise `db 'ab'' would have the - same effect as `db 'a'', which would be silly. Similarly, three- - character or four-character constants are treated as strings when - they are operands to `DW', and so forth. - - 3.4.5 Unicode Strings - - The special operators `__utf16__' and `__utf32__' allows definition - of Unicode strings. They take a string in UTF-8 format and converts - it to (littleendian) UTF-16 or UTF-32, respectively. - - For example: - - %define u(x) __utf16__(x) - %define w(x) __utf32__(x) - - dw u('C:\WINDOWS'), 0 ; Pathname in UTF-16 - dd w(`A + B = \u206a`), 0 ; String in UTF-32 - - `__utf16__' and `__utf32__' can be applied either to strings passed - to the `DB' family instructions, or to character constants in an - expression context. - - 3.4.6 Floating-Point Constants - - Floating-point constants are acceptable only as arguments to `DB', - `DW', `DD', `DQ', `DT', and `DO', or as arguments to the special - operators `__float8__', `__float16__', `__float32__', `__float64__', - `__float80m__', `__float80e__', `__float128l__', and - `__float128h__'. - - Floating-point constants are expressed in the traditional form: - digits, then a period, then optionally more digits, then optionally - an `E' followed by an exponent. The period is mandatory, so that - NASM can distinguish between `dd 1', which declares an integer - constant, and `dd 1.0' which declares a floating-point constant. - NASM also support C99-style hexadecimal floating-point: `0x', - hexadecimal digits, period, optionally more hexadeximal digits, then - optionally a `P' followed by a _binary_ (not hexadecimal) exponent - in decimal notation. - - Underscores to break up groups of digits are permitted in floating- - point constants as well. - - Some examples: - - db -0.2 ; "Quarter precision" - dw -0.5 ; IEEE 754r/SSE5 half precision - dd 1.2 ; an easy one - dd 1.222_222_222 ; underscores are permitted - dd 0x1p+2 ; 1.0x2^2 = 4.0 - dq 0x1p+32 ; 1.0x2^32 = 4 294 967 296.0 - dq 1.e10 ; 10 000 000 000.0 - dq 1.e+10 ; synonymous with 1.e10 - dq 1.e-10 ; 0.000 000 000 1 - dt 3.141592653589793238462 ; pi - do 1.e+4000 ; IEEE 754r quad precision - - The 8-bit "quarter-precision" floating-point format is - sign:exponent:mantissa = 1:4:3 with an exponent bias of 7. This - appears to be the most frequently used 8-bit floating-point format, - although it is not covered by any formal standard. This is sometimes - called a "minifloat." - - The special operators are used to produce floating-point numbers in - other contexts. They produce the binary representation of a specific - floating-point number as an integer, and can use anywhere integer - constants are used in an expression. `__float80m__' and - `__float80e__' produce the 64-bit mantissa and 16-bit exponent of an - 80-bit floating-point number, and `__float128l__' and - `__float128h__' produce the lower and upper 64-bit halves of a 128- - bit floating-point number, respectively. - - For example: - - mov rax,__float64__(3.141592653589793238462) - - ... would assign the binary representation of pi as a 64-bit - floating point number into `RAX'. This is exactly equivalent to: - - mov rax,0x400921fb54442d18 - - NASM cannot do compile-time arithmetic on floating-point constants. - This is because NASM is designed to be portable - although it always - generates code to run on x86 processors, the assembler itself can - run on any system with an ANSI C compiler. Therefore, the assembler - cannot guarantee the presence of a floating-point unit capable of - handling the Intel number formats, and so for NASM to be able to do - floating arithmetic it would have to include its own complete set of - floating-point routines, which would significantly increase the size - of the assembler for very little benefit. - - The special tokens `__Infinity__', `__QNaN__' (or `__NaN__') and - `__SNaN__' can be used to generate infinities, quiet NaNs, and - signalling NaNs, respectively. These are normally used as macros: - - %define Inf __Infinity__ - %define NaN __QNaN__ - - dq +1.5, -Inf, NaN ; Double-precision constants - - 3.4.7 Packed BCD Constants - - x87-style packed BCD constants can be used in the same contexts as - 80-bit floating-point numbers. They are suffixed with `p' or - prefixed with `0p', and can include up to 18 decimal digits. - - As with other numeric constants, underscores can be used to separate - digits. - - For example: - - dt 12_345_678_901_245_678p - dt -12_345_678_901_245_678p - dt +0p33 - dt 33p - - 3.5 Expressions - - Expressions in NASM are similar in syntax to those in C. Expressions - are evaluated as 64-bit integers which are then adjusted to the - appropriate size. - - NASM supports two special tokens in expressions, allowing - calculations to involve the current assembly position: the `$' and - `$$' tokens. `$' evaluates to the assembly position at the beginning - of the line containing the expression; so you can code an infinite - loop using `JMP $'. `$$' evaluates to the beginning of the current - section; so you can tell how far into the section you are by using - `($-$$)'. - - The arithmetic operators provided by NASM are listed here, in - increasing order of precedence. - - 3.5.1 `|': Bitwise OR Operator - - The `|' operator gives a bitwise OR, exactly as performed by the - `OR' machine instruction. Bitwise OR is the lowest-priority - arithmetic operator supported by NASM. - - 3.5.2 `^': Bitwise XOR Operator - - `^' provides the bitwise XOR operation. - - 3.5.3 `&': Bitwise AND Operator - - `&' provides the bitwise AND operation. - - 3.5.4 `<<' and `>>': Bit Shift Operators - - `<<' gives a bit-shift to the left, just as it does in C. So `5<<3' - evaluates to 5 times 8, or 40. `>>' gives a bit-shift to the right; - in NASM, such a shift is _always_ unsigned, so that the bits shifted - in from the left-hand end are filled with zero rather than a sign- - extension of the previous highest bit. - - 3.5.5 `+' and `-': Addition and Subtraction Operators - - The `+' and `-' operators do perfectly ordinary addition and - subtraction. - - 3.5.6 `*', `/', `//', `%' and `%%': Multiplication and Division - - `*' is the multiplication operator. `/' and `//' are both division - operators: `/' is unsigned division and `//' is signed division. - Similarly, `%' and `%%' provide unsigned and signed modulo operators - respectively. - - NASM, like ANSI C, provides no guarantees about the sensible - operation of the signed modulo operator. - - Since the `%' character is used extensively by the macro - preprocessor, you should ensure that both the signed and unsigned - modulo operators are followed by white space wherever they appear. - - 3.5.7 Unary Operators: `+', `-', `~', `!' and `SEG' - - The highest-priority operators in NASM's expression grammar are - those which only apply to one argument. `-' negates its operand, `+' - does nothing (it's provided for symmetry with `-'), `~' computes the - one's complement of its operand, `!' is the logical negation - operator, and `SEG' provides the segment address of its operand - (explained in more detail in section 3.6). - - 3.6 `SEG' and `WRT' - - When writing large 16-bit programs, which must be split into - multiple segments, it is often necessary to be able to refer to the - segment part of the address of a symbol. NASM supports the `SEG' - operator to perform this function. - - The `SEG' operator returns the _preferred_ segment base of a symbol, - defined as the segment base relative to which the offset of the - symbol makes sense. So the code - - mov ax,seg symbol - mov es,ax - mov bx,symbol - - will load `ES:BX' with a valid pointer to the symbol `symbol'. - - Things can be more complex than this: since 16-bit segments and - groups may overlap, you might occasionally want to refer to some - symbol using a different segment base from the preferred one. NASM - lets you do this, by the use of the `WRT' (With Reference To) - keyword. So you can do things like - - mov ax,weird_seg ; weird_seg is a segment base - mov es,ax - mov bx,symbol wrt weird_seg - - to load `ES:BX' with a different, but functionally equivalent, - pointer to the symbol `symbol'. - - NASM supports far (inter-segment) calls and jumps by means of the - syntax `call segment:offset', where `segment' and `offset' both - represent immediate values. So to call a far procedure, you could - code either of - - call (seg procedure):procedure - call weird_seg:(procedure wrt weird_seg) - - (The parentheses are included for clarity, to show the intended - parsing of the above instructions. They are not necessary in - practice.) - - NASM supports the syntax `call far procedure' as a synonym for the - first of the above usages. `JMP' works identically to `CALL' in - these examples. - - To declare a far pointer to a data item in a data segment, you must - code - - dw symbol, seg symbol - - NASM supports no convenient synonym for this, though you can always - invent one using the macro processor. - - 3.7 `STRICT': Inhibiting Optimization - - When assembling with the optimizer set to level 2 or higher (see - section 2.1.22), NASM will use size specifiers (`BYTE', `WORD', - `DWORD', `QWORD', `TWORD', `OWORD' or `YWORD'), but will give them - the smallest possible size. The keyword `STRICT' can be used to - inhibit optimization and force a particular operand to be emitted in - the specified size. For example, with the optimizer on, and in - `BITS 16' mode, - - push dword 33 - - is encoded in three bytes `66 6A 21', whereas - - push strict dword 33 - - is encoded in six bytes, with a full dword immediate operand - `66 68 21 00 00 00'. - - With the optimizer off, the same code (six bytes) is generated - whether the `STRICT' keyword was used or not. - - 3.8 Critical Expressions - - Although NASM has an optional multi-pass optimizer, there are some - expressions which must be resolvable on the first pass. These are - called _Critical Expressions_. - - The first pass is used to determine the size of all the assembled - code and data, so that the second pass, when generating all the - code, knows all the symbol addresses the code refers to. So one - thing NASM can't handle is code whose size depends on the value of a - symbol declared after the code in question. For example, - - times (label-$) db 0 - label: db 'Where am I?' - - The argument to `TIMES' in this case could equally legally evaluate - to anything at all; NASM will reject this example because it cannot - tell the size of the `TIMES' line when it first sees it. It will - just as firmly reject the slightly paradoxical code - - times (label-$+1) db 0 - label: db 'NOW where am I?' - - in which _any_ value for the `TIMES' argument is by definition - wrong! - - NASM rejects these examples by means of a concept called a _critical - expression_, which is defined to be an expression whose value is - required to be computable in the first pass, and which must - therefore depend only on symbols defined before it. The argument to - the `TIMES' prefix is a critical expression. - - 3.9 Local Labels - - NASM gives special treatment to symbols beginning with a period. A - label beginning with a single period is treated as a _local_ label, - which means that it is associated with the previous non-local label. - So, for example: - - label1 ; some code - - .loop - ; some more code - - jne .loop - ret - - label2 ; some code - - .loop - ; some more code - - jne .loop - ret - - In the above code fragment, each `JNE' instruction jumps to the line - immediately before it, because the two definitions of `.loop' are - kept separate by virtue of each being associated with the previous - non-local label. - - This form of local label handling is borrowed from the old Amiga - assembler DevPac; however, NASM goes one step further, in allowing - access to local labels from other parts of the code. This is - achieved by means of _defining_ a local label in terms of the - previous non-local label: the first definition of `.loop' above is - really defining a symbol called `label1.loop', and the second - defines a symbol called `label2.loop'. So, if you really needed to, - you could write - - label3 ; some more code - ; and some more - - jmp label1.loop - - Sometimes it is useful - in a macro, for instance - to be able to - define a label which can be referenced from anywhere but which - doesn't interfere with the normal local-label mechanism. Such a - label can't be non-local because it would interfere with subsequent - definitions of, and references to, local labels; and it can't be - local because the macro that defined it wouldn't know the label's - full name. NASM therefore introduces a third type of label, which is - probably only useful in macro definitions: if a label begins with - the special prefix `..@', then it does nothing to the local label - mechanism. So you could code - - label1: ; a non-local label - .local: ; this is really label1.local - ..@foo: ; this is a special symbol - label2: ; another non-local label - .local: ; this is really label2.local - - jmp ..@foo ; this will jump three lines up - - NASM has the capacity to define other special symbols beginning with - a double period: for example, `..start' is used to specify the entry - point in the `obj' output format (see section 7.4.6). - -Chapter 4: The NASM Preprocessor --------------------------------- - - NASM contains a powerful macro processor, which supports conditional - assembly, multi-level file inclusion, two forms of macro (single- - line and multi-line), and a `context stack' mechanism for extra - macro power. Preprocessor directives all begin with a `%' sign. - - The preprocessor collapses all lines which end with a backslash (\) - character into a single line. Thus: - - %define THIS_VERY_LONG_MACRO_NAME_IS_DEFINED_TO \ - THIS_VALUE - - will work like a single-line macro without the backslash-newline - sequence. - - 4.1 Single-Line Macros - - 4.1.1 The Normal Way: `%define' - - Single-line macros are defined using the `%define' preprocessor - directive. The definitions work in a similar way to C; so you can do - things like - - %define ctrl 0x1F & - %define param(a,b) ((a)+(a)*(b)) - - mov byte [param(2,ebx)], ctrl 'D' - - which will expand to - - mov byte [(2)+(2)*(ebx)], 0x1F & 'D' - - When the expansion of a single-line macro contains tokens which - invoke another macro, the expansion is performed at invocation time, - not at definition time. Thus the code - - %define a(x) 1+b(x) - %define b(x) 2*x - - mov ax,a(8) - - will evaluate in the expected way to `mov ax,1+2*8', even though the - macro `b' wasn't defined at the time of definition of `a'. - - Macros defined with `%define' are case sensitive: after - `%define foo bar', only `foo' will expand to `bar': `Foo' or `FOO' - will not. By using `%idefine' instead of `%define' (the `i' stands - for `insensitive') you can define all the case variants of a macro - at once, so that `%idefine foo bar' would cause `foo', `Foo', `FOO', - `fOO' and so on all to expand to `bar'. - - There is a mechanism which detects when a macro call has occurred as - a result of a previous expansion of the same macro, to guard against - circular references and infinite loops. If this happens, the - preprocessor will only expand the first occurrence of the macro. - Hence, if you code - - %define a(x) 1+a(x) - - mov ax,a(3) - - the macro `a(3)' will expand once, becoming `1+a(3)', and will then - expand no further. This behaviour can be useful: see section 9.1 for - an example of its use. - - You can overload single-line macros: if you write - - %define foo(x) 1+x - %define foo(x,y) 1+x*y - - the preprocessor will be able to handle both types of macro call, by - counting the parameters you pass; so `foo(3)' will become `1+3' - whereas `foo(ebx,2)' will become `1+ebx*2'. However, if you define - - %define foo bar - - then no other definition of `foo' will be accepted: a macro with no - parameters prohibits the definition of the same name as a macro - _with_ parameters, and vice versa. - - This doesn't prevent single-line macros being _redefined_: you can - perfectly well define a macro with - - %define foo bar - - and then re-define it later in the same source file with - - %define foo baz - - Then everywhere the macro `foo' is invoked, it will be expanded - according to the most recent definition. This is particularly useful - when defining single-line macros with `%assign' (see section 4.1.7). - - You can pre-define single-line macros using the `-d' option on the - NASM command line: see section 2.1.18. - - 4.1.2 Resolving `%define': `%xdefine' - - To have a reference to an embedded single-line macro resolved at the - time that the embedding macro is _defined_, as opposed to when the - embedding macro is _expanded_, you need a different mechanism to the - one offered by `%define'. The solution is to use `%xdefine', or it's - case-insensitive counterpart `%ixdefine'. - - Suppose you have the following code: - - %define isTrue 1 - %define isFalse isTrue - %define isTrue 0 - - val1: db isFalse - - %define isTrue 1 - - val2: db isFalse - - In this case, `val1' is equal to 0, and `val2' is equal to 1. This - is because, when a single-line macro is defined using `%define', it - is expanded only when it is called. As `isFalse' expands to - `isTrue', the expansion will be the current value of `isTrue'. The - first time it is called that is 0, and the second time it is 1. - - If you wanted `isFalse' to expand to the value assigned to the - embedded macro `isTrue' at the time that `isFalse' was defined, you - need to change the above code to use `%xdefine'. - - %xdefine isTrue 1 - %xdefine isFalse isTrue - %xdefine isTrue 0 - - val1: db isFalse - - %xdefine isTrue 1 - - val2: db isFalse - - Now, each time that `isFalse' is called, it expands to 1, as that is - what the embedded macro `isTrue' expanded to at the time that - `isFalse' was defined. - - 4.1.3 Macro Indirection: `%[...]' - - The `%[...]' construct can be used to expand macros in contexts - where macro expansion would otherwise not occur, including in the - names other macros. For example, if you have a set of macros named - `Foo16', `Foo32' and `Foo64', you could write: - - mov ax,Foo%[__BITS__] ; The Foo value - - to use the builtin macro `__BITS__' (see section 4.11.5) to - automatically select between them. Similarly, the two statements: - - %xdefine Bar Quux ; Expands due to %xdefine - %define Bar %[Quux] ; Expands due to %[...] - - have, in fact, exactly the same effect. - - `%[...]' concatenates to adjacent tokens in the same way that multi- - line macro parameters do, see section 4.3.8 for details. - - 4.1.4 Concatenating Single Line Macro Tokens: `%+' - - Individual tokens in single line macros can be concatenated, to - produce longer tokens for later processing. This can be useful if - there are several similar macros that perform similar functions. - - Please note that a space is required after `%+', in order to - disambiguate it from the syntax `%+1' used in multiline macros. - - As an example, consider the following: - - %define BDASTART 400h ; Start of BIOS data area - - struc tBIOSDA ; its structure - .COM1addr RESW 1 - .COM2addr RESW 1 - ; ..and so on - endstruc - - Now, if we need to access the elements of tBIOSDA in different - places, we can end up with: - - mov ax,BDASTART + tBIOSDA.COM1addr - mov bx,BDASTART + tBIOSDA.COM2addr - - This will become pretty ugly (and tedious) if used in many places, - and can be reduced in size significantly by using the following - macro: - - ; Macro to access BIOS variables by their names (from tBDA): - - %define BDA(x) BDASTART + tBIOSDA. %+ x - - Now the above code can be written as: - - mov ax,BDA(COM1addr) - mov bx,BDA(COM2addr) - - Using this feature, we can simplify references to a lot of macros - (and, in turn, reduce typing errors). - - 4.1.5 The Macro Name Itself: `%?' and `%??' - - The special symbols `%?' and `%??' can be used to reference the - macro name itself inside a macro expansion, this is supported for - both single-and multi-line macros. `%?' refers to the macro name as - _invoked_, whereas `%??' refers to the macro name as _declared_. The - two are always the same for case-sensitive macros, but for case- - insensitive macros, they can differ. - - For example: - - %idefine Foo mov %?,%?? - - foo - FOO - - will expand to: - - mov foo,Foo - mov FOO,Foo - - The sequence: - - %idefine keyword $%? - - can be used to make a keyword "disappear", for example in case a new - instruction has been used as a label in older code. For example: - - %idefine pause $%? ; Hide the PAUSE instruction - - 4.1.6 Undefining Single-Line Macros: `%undef' - - Single-line macros can be removed with the `%undef' directive. For - example, the following sequence: - - %define foo bar - %undef foo - - mov eax, foo - - will expand to the instruction `mov eax, foo', since after `%undef' - the macro `foo' is no longer defined. - - Macros that would otherwise be pre-defined can be undefined on the - command-line using the `-u' option on the NASM command line: see - section 2.1.19. - - 4.1.7 Preprocessor Variables: `%assign' - - An alternative way to define single-line macros is by means of the - `%assign' command (and its case-insensitive counterpart `%iassign', - which differs from `%assign' in exactly the same way that `%idefine' - differs from `%define'). - - `%assign' is used to define single-line macros which take no - parameters and have a numeric value. This value can be specified in - the form of an expression, and it will be evaluated once, when the - `%assign' directive is processed. - - Like `%define', macros defined using `%assign' can be re-defined - later, so you can do things like - - %assign i i+1 - - to increment the numeric value of a macro. - - `%assign' is useful for controlling the termination of `%rep' - preprocessor loops: see section 4.5 for an example of this. Another - use for `%assign' is given in section 8.4 and section 9.1. - - The expression passed to `%assign' is a critical expression (see - section 3.8), and must also evaluate to a pure number (rather than a - relocatable reference such as a code or data address, or anything - involving a register). - - 4.1.8 Defining Strings: `%defstr' - - `%defstr', and its case-insensitive counterpart `%idefstr', define - or redefine a single-line macro without parameters but converts the - entire right-hand side, after macro expansion, to a quoted string - before definition. - - For example: - - %defstr test TEST - - is equivalent to - - %define test 'TEST' - - This can be used, for example, with the `%!' construct (see section - 4.10.2): - - %defstr PATH %!PATH ; The operating system PATH variable - - 4.1.9 Defining Tokens: `%deftok' - - `%deftok', and its case-insensitive counterpart `%ideftok', define - or redefine a single-line macro without parameters but converts the - second parameter, after string conversion, to a sequence of tokens. - - For example: - - %deftok test 'TEST' - - is equivalent to - - %define test TEST - - 4.2 String Manipulation in Macros - - It's often useful to be able to handle strings in macros. NASM - supports a few simple string handling macro operators from which - more complex operations can be constructed. - - All the string operators define or redefine a value (either a string - or a numeric value) to a single-line macro. When producing a string - value, it may change the style of quoting of the input string or - strings, and possibly use `\'-escapes inside ``'-quoted strings. - - 4.2.1 Concatenating Strings: `%strcat' - - The `%strcat' operator concatenates quoted strings and assign them - to a single-line macro. - - For example: - - %strcat alpha "Alpha: ", '12" screen' - - ... would assign the value `'Alpha: 12" screen'' to `alpha'. - Similarly: - - %strcat beta '"foo"\', "'bar'" - - ... would assign the value ``"foo"\\'bar'`' to `beta'. - - The use of commas to separate strings is permitted but optional. - - 4.2.2 String Length: `%strlen' - - The `%strlen' operator assigns the length of a string to a macro. - For example: - - %strlen charcnt 'my string' - - In this example, `charcnt' would receive the value 9, just as if an - `%assign' had been used. In this example, `'my string'' was a - literal string but it could also have been a single-line macro that - expands to a string, as in the following example: - - %define sometext 'my string' - %strlen charcnt sometext - - As in the first case, this would result in `charcnt' being assigned - the value of 9. - - 4.2.3 Extracting Substrings: `%substr' - - Individual letters or substrings in strings can be extracted using - the `%substr' operator. An example of its use is probably more - useful than the description: - - %substr mychar 'xyzw' 1 ; equivalent to %define mychar 'x' - %substr mychar 'xyzw' 2 ; equivalent to %define mychar 'y' - %substr mychar 'xyzw' 3 ; equivalent to %define mychar 'z' - %substr mychar 'xyzw' 2,2 ; equivalent to %define mychar 'yz' - %substr mychar 'xyzw' 2,-1 ; equivalent to %define mychar 'yzw' - %substr mychar 'xyzw' 2,-2 ; equivalent to %define mychar 'yz' - - As with `%strlen' (see section 4.2.2), the first parameter is the - single-line macro to be created and the second is the string. The - third parameter specifies the first character to be selected, and - the optional fourth parameter preceeded by comma) is the length. - Note that the first index is 1, not 0 and the last index is equal to - the value that `%strlen' would assign given the same string. Index - values out of range result in an empty string. A negative length - means "until N-1 characters before the end of string", i.e. `-1' - means until end of string, `-2' until one character before, etc. - - 4.3 Multi-Line Macros: `%macro' - - Multi-line macros are much more like the type of macro seen in MASM - and TASM: a multi-line macro definition in NASM looks something like - this. - - %macro prologue 1 - - push ebp - mov ebp,esp - sub esp,%1 - - %endmacro - - This defines a C-like function prologue as a macro: so you would - invoke the macro with a call such as - - myfunc: prologue 12 - - which would expand to the three lines of code - - myfunc: push ebp - mov ebp,esp - sub esp,12 - - The number `1' after the macro name in the `%macro' line defines the - number of parameters the macro `prologue' expects to receive. The - use of `%1' inside the macro definition refers to the first - parameter to the macro call. With a macro taking more than one - parameter, subsequent parameters would be referred to as `%2', `%3' - and so on. - - Multi-line macros, like single-line macros, are case-sensitive, - unless you define them using the alternative directive `%imacro'. - - If you need to pass a comma as _part_ of a parameter to a multi-line - macro, you can do that by enclosing the entire parameter in braces. - So you could code things like - - %macro silly 2 - - %2: db %1 - - %endmacro - - silly 'a', letter_a ; letter_a: db 'a' - silly 'ab', string_ab ; string_ab: db 'ab' - silly {13,10}, crlf ; crlf: db 13,10 - - 4.3.1 Recursive Multi-Line Macros: `%rmacro' - - A multi-line macro cannot be referenced within itself, in order to - prevent accidental infinite recursion. - - Recursive multi-line macros allow for self-referencing, with the - caveat that the user is aware of the existence, use and purpose of - recursive multi-line macros. There is also a generous, but sane, - upper limit to the number of recursions, in order to prevent run- - away memory consumption in case of accidental infinite recursion. - - As with non-recursive multi-line macros, recursive multi-line macros - are case-sensitive, unless you define them using the alternative - directive `%irmacro'. - - 4.3.2 Overloading Multi-Line Macros - - As with single-line macros, multi-line macros can be overloaded by - defining the same macro name several times with different numbers of - parameters. This time, no exception is made for macros with no - parameters at all. So you could define - - %macro prologue 0 - - push ebp - mov ebp,esp - - %endmacro - - to define an alternative form of the function prologue which - allocates no local stack space. - - Sometimes, however, you might want to `overload' a machine - instruction; for example, you might want to define - - %macro push 2 - - push %1 - push %2 - - %endmacro - - so that you could code - - push ebx ; this line is not a macro call - push eax,ecx ; but this one is - - Ordinarily, NASM will give a warning for the first of the above two - lines, since `push' is now defined to be a macro, and is being - invoked with a number of parameters for which no definition has been - given. The correct code will still be generated, but the assembler - will give a warning. This warning can be disabled by the use of the - `-w-macro-params' command-line option (see section 2.1.24). - - 4.3.3 Macro-Local Labels - - NASM allows you to define labels within a multi-line macro - definition in such a way as to make them local to the macro call: so - calling the same macro multiple times will use a different label - each time. You do this by prefixing `%%' to the label name. So you - can invent an instruction which executes a `RET' if the `Z' flag is - set by doing this: - - %macro retz 0 - - jnz %%skip - ret - %%skip: - - %endmacro - - You can call this macro as many times as you want, and every time - you call it NASM will make up a different `real' name to substitute - for the label `%%skip'. The names NASM invents are of the form - `..@2345.skip', where the number 2345 changes with every macro call. - The `..@' prefix prevents macro-local labels from interfering with - the local label mechanism, as described in section 3.9. You should - avoid defining your own labels in this form (the `..@' prefix, then - a number, then another period) in case they interfere with macro- - local labels. - - 4.3.4 Greedy Macro Parameters - - Occasionally it is useful to define a macro which lumps its entire - command line into one parameter definition, possibly after - extracting one or two smaller parameters from the front. An example - might be a macro to write a text string to a file in MS-DOS, where - you might want to be able to write - - writefile [filehandle],"hello, world",13,10 - - NASM allows you to define the last parameter of a macro to be - _greedy_, meaning that if you invoke the macro with more parameters - than it expects, all the spare parameters get lumped into the last - defined one along with the separating commas. So if you code: - - %macro writefile 2+ - - jmp %%endstr - %%str: db %2 - %%endstr: - mov dx,%%str - mov cx,%%endstr-%%str - mov bx,%1 - mov ah,0x40 - int 0x21 - - %endmacro - - then the example call to `writefile' above will work as expected: - the text before the first comma, `[filehandle]', is used as the - first macro parameter and expanded when `%1' is referred to, and all - the subsequent text is lumped into `%2' and placed after the `db'. - - The greedy nature of the macro is indicated to NASM by the use of - the `+' sign after the parameter count on the `%macro' line. - - If you define a greedy macro, you are effectively telling NASM how - it should expand the macro given _any_ number of parameters from the - actual number specified up to infinity; in this case, for example, - NASM now knows what to do when it sees a call to `writefile' with 2, - 3, 4 or more parameters. NASM will take this into account when - overloading macros, and will not allow you to define another form of - `writefile' taking 4 parameters (for example). - - Of course, the above macro could have been implemented as a non- - greedy macro, in which case the call to it would have had to look - like - - writefile [filehandle], {"hello, world",13,10} - - NASM provides both mechanisms for putting commas in macro - parameters, and you choose which one you prefer for each macro - definition. - - See section 6.3.1 for a better way to write the above macro. - - 4.3.5 Default Macro Parameters - - NASM also allows you to define a multi-line macro with a _range_ of - allowable parameter counts. If you do this, you can specify defaults - for omitted parameters. So, for example: - - %macro die 0-1 "Painful program death has occurred." - - writefile 2,%1 - mov ax,0x4c01 - int 0x21 - - %endmacro - - This macro (which makes use of the `writefile' macro defined in - section 4.3.4) can be called with an explicit error message, which - it will display on the error output stream before exiting, or it can - be called with no parameters, in which case it will use the default - error message supplied in the macro definition. - - In general, you supply a minimum and maximum number of parameters - for a macro of this type; the minimum number of parameters are then - required in the macro call, and then you provide defaults for the - optional ones. So if a macro definition began with the line - - %macro foobar 1-3 eax,[ebx+2] - - then it could be called with between one and three parameters, and - `%1' would always be taken from the macro call. `%2', if not - specified by the macro call, would default to `eax', and `%3' if not - specified would default to `[ebx+2]'. - - You can provide extra information to a macro by providing too many - default parameters: - - %macro quux 1 something - - This will trigger a warning by default; see section 2.1.24 for more - information. When `quux' is invoked, it receives not one but two - parameters. `something' can be referred to as `%2'. The difference - between passing `something' this way and writing `something' in the - macro body is that with this way `something' is evaluated when the - macro is defined, not when it is expanded. - - You may omit parameter defaults from the macro definition, in which - case the parameter default is taken to be blank. This can be useful - for macros which can take a variable number of parameters, since the - `%0' token (see section 4.3.6) allows you to determine how many - parameters were really passed to the macro call. - - This defaulting mechanism can be combined with the greedy-parameter - mechanism; so the `die' macro above could be made more powerful, and - more useful, by changing the first line of the definition to - - %macro die 0-1+ "Painful program death has occurred.",13,10 - - The maximum parameter count can be infinite, denoted by `*'. In this - case, of course, it is impossible to provide a _full_ set of default - parameters. Examples of this usage are shown in section 4.3.7. - - 4.3.6 `%0': Macro Parameter Counter - - The parameter reference `%0' will return a numeric constant giving - the number of parameters received, that is, if `%0' is n then `%'n - is the last parameter. `%0' is mostly useful for macros that can - take a variable number of parameters. It can be used as an argument - to `%rep' (see section 4.5) in order to iterate through all the - parameters of a macro. Examples are given in section 4.3.7. - - 4.3.7 `%rotate': Rotating Macro Parameters - - Unix shell programmers will be familiar with the `shift' shell - command, which allows the arguments passed to a shell script - (referenced as `$1', `$2' and so on) to be moved left by one place, - so that the argument previously referenced as `$2' becomes available - as `$1', and the argument previously referenced as `$1' is no longer - available at all. - - NASM provides a similar mechanism, in the form of `%rotate'. As its - name suggests, it differs from the Unix `shift' in that no - parameters are lost: parameters rotated off the left end of the - argument list reappear on the right, and vice versa. - - `%rotate' is invoked with a single numeric argument (which may be an - expression). The macro parameters are rotated to the left by that - many places. If the argument to `%rotate' is negative, the macro - parameters are rotated to the right. - - So a pair of macros to save and restore a set of registers might - work as follows: - - %macro multipush 1-* - - %rep %0 - push %1 - %rotate 1 - %endrep - - %endmacro - - This macro invokes the `PUSH' instruction on each of its arguments - in turn, from left to right. It begins by pushing its first - argument, `%1', then invokes `%rotate' to move all the arguments one - place to the left, so that the original second argument is now - available as `%1'. Repeating this procedure as many times as there - were arguments (achieved by supplying `%0' as the argument to - `%rep') causes each argument in turn to be pushed. - - Note also the use of `*' as the maximum parameter count, indicating - that there is no upper limit on the number of parameters you may - supply to the `multipush' macro. - - It would be convenient, when using this macro, to have a `POP' - equivalent, which _didn't_ require the arguments to be given in - reverse order. Ideally, you would write the `multipush' macro call, - then cut-and-paste the line to where the pop needed to be done, and - change the name of the called macro to `multipop', and the macro - would take care of popping the registers in the opposite order from - the one in which they were pushed. - - This can be done by the following definition: - - %macro multipop 1-* - - %rep %0 - %rotate -1 - pop %1 - %endrep - - %endmacro - - This macro begins by rotating its arguments one place to the - _right_, so that the original _last_ argument appears as `%1'. This - is then popped, and the arguments are rotated right again, so the - second-to-last argument becomes `%1'. Thus the arguments are - iterated through in reverse order. - - 4.3.8 Concatenating Macro Parameters - - NASM can concatenate macro parameters and macro indirection - constructs on to other text surrounding them. This allows you to - declare a family of symbols, for example, in a macro definition. If, - for example, you wanted to generate a table of key codes along with - offsets into the table, you could code something like - - %macro keytab_entry 2 - - keypos%1 equ $-keytab - db %2 - - %endmacro - - keytab: - keytab_entry F1,128+1 - keytab_entry F2,128+2 - keytab_entry Return,13 - - which would expand to - - keytab: - keyposF1 equ $-keytab - db 128+1 - keyposF2 equ $-keytab - db 128+2 - keyposReturn equ $-keytab - db 13 - - You can just as easily concatenate text on to the other end of a - macro parameter, by writing `%1foo'. - - If you need to append a _digit_ to a macro parameter, for example - defining labels `foo1' and `foo2' when passed the parameter `foo', - you can't code `%11' because that would be taken as the eleventh - macro parameter. Instead, you must code `%{1}1', which will separate - the first `1' (giving the number of the macro parameter) from the - second (literal text to be concatenated to the parameter). - - This concatenation can also be applied to other preprocessor in-line - objects, such as macro-local labels (section 4.3.3) and context- - local labels (section 4.7.2). In all cases, ambiguities in syntax - can be resolved by enclosing everything after the `%' sign and - before the literal text in braces: so `%{%foo}bar' concatenates the - text `bar' to the end of the real name of the macro-local label - `%%foo'. (This is unnecessary, since the form NASM uses for the real - names of macro-local labels means that the two usages `%{%foo}bar' - and `%%foobar' would both expand to the same thing anyway; - nevertheless, the capability is there.) - - The single-line macro indirection construct, `%[...]' (section - 4.1.3), behaves the same way as macro parameters for the purpose of - concatenation. - - See also the `%+' operator, section 4.1.4. - - 4.3.9 Condition Codes as Macro Parameters - - NASM can give special treatment to a macro parameter which contains - a condition code. For a start, you can refer to the macro parameter - `%1' by means of the alternative syntax `%+1', which informs NASM - that this macro parameter is supposed to contain a condition code, - and will cause the preprocessor to report an error message if the - macro is called with a parameter which is _not_ a valid condition - code. - - Far more usefully, though, you can refer to the macro parameter by - means of `%-1', which NASM will expand as the _inverse_ condition - code. So the `retz' macro defined in section 4.3.3 can be replaced - by a general conditional-return macro like this: - - %macro retc 1 - - j%-1 %%skip - ret - %%skip: - - %endmacro - - This macro can now be invoked using calls like `retc ne', which will - cause the conditional-jump instruction in the macro expansion to - come out as `JE', or `retc po' which will make the jump a `JPE'. - - The `%+1' macro-parameter reference is quite happy to interpret the - arguments `CXZ' and `ECXZ' as valid condition codes; however, `%-1' - will report an error if passed either of these, because no inverse - condition code exists. - -4.3.10 Disabling Listing Expansion - - When NASM is generating a listing file from your program, it will - generally expand multi-line macros by means of writing the macro - call and then listing each line of the expansion. This allows you to - see which instructions in the macro expansion are generating what - code; however, for some macros this clutters the listing up - unnecessarily. - - NASM therefore provides the `.nolist' qualifier, which you can - include in a macro definition to inhibit the expansion of the macro - in the listing file. The `.nolist' qualifier comes directly after - the number of parameters, like this: - - %macro foo 1.nolist - - Or like this: - - %macro bar 1-5+.nolist a,b,c,d,e,f,g,h - -4.3.11 Undefining Multi-Line Macros: `%unmacro' - - Multi-line macros can be removed with the `%unmacro' directive. - Unlike the `%undef' directive, however, `%unmacro' takes an argument - specification, and will only remove exact matches with that argument - specification. - - For example: - - %macro foo 1-3 - ; Do something - %endmacro - %unmacro foo 1-3 - - removes the previously defined macro `foo', but - - %macro bar 1-3 - ; Do something - %endmacro - %unmacro bar 1 - - does _not_ remove the macro `bar', since the argument specification - does not match exactly. - -4.3.12 Exiting Multi-Line Macros: `%exitmacro' - - Multi-line macro expansions can be arbitrarily terminated with the - `%exitmacro' directive. - - For example: - - %macro foo 1-3 - ; Do something - %if<condition> - %exitmacro - %endif - ; Do something - %endmacro - - 4.4 Conditional Assembly - - Similarly to the C preprocessor, NASM allows sections of a source - file to be assembled only if certain conditions are met. The general - syntax of this feature looks like this: - - %if<condition> - ; some code which only appears if <condition> is met - %elif<condition2> - ; only appears if <condition> is not met but <condition2> is - %else - ; this appears if neither <condition> nor <condition2> was met - %endif - - The inverse forms `%ifn' and `%elifn' are also supported. - - The `%else' clause is optional, as is the `%elif' clause. You can - have more than one `%elif' clause as well. - - There are a number of variants of the `%if' directive. Each has its - corresponding `%elif', `%ifn', and `%elifn' directives; for example, - the equivalents to the `%ifdef' directive are `%elifdef', `%ifndef', - and `%elifndef'. - - 4.4.1 `%ifdef': Testing Single-Line Macro Existence - - Beginning a conditional-assembly block with the line `%ifdef MACRO' - will assemble the subsequent code if, and only if, a single-line - macro called `MACRO' is defined. If not, then the `%elif' and - `%else' blocks (if any) will be processed instead. - - For example, when debugging a program, you might want to write code - such as - - ; perform some function - %ifdef DEBUG - writefile 2,"Function performed successfully",13,10 - %endif - ; go and do something else - - Then you could use the command-line option `-dDEBUG' to create a - version of the program which produced debugging messages, and remove - the option to generate the final release version of the program. - - You can test for a macro _not_ being defined by using `%ifndef' - instead of `%ifdef'. You can also test for macro definitions in - `%elif' blocks by using `%elifdef' and `%elifndef'. - - 4.4.2 `%ifmacro': Testing Multi-Line Macro Existence - - The `%ifmacro' directive operates in the same way as the `%ifdef' - directive, except that it checks for the existence of a multi-line - macro. - - For example, you may be working with a large project and not have - control over the macros in a library. You may want to create a macro - with one name if it doesn't already exist, and another name if one - with that name does exist. - - The `%ifmacro' is considered true if defining a macro with the given - name and number of arguments would cause a definitions conflict. For - example: - - %ifmacro MyMacro 1-3 - - %error "MyMacro 1-3" causes a conflict with an existing macro. - - %else - - %macro MyMacro 1-3 - - ; insert code to define the macro - - %endmacro - - %endif - - This will create the macro "MyMacro 1-3" if no macro already exists - which would conflict with it, and emits a warning if there would be - a definition conflict. - - You can test for the macro not existing by using the `%ifnmacro' - instead of `%ifmacro'. Additional tests can be performed in `%elif' - blocks by using `%elifmacro' and `%elifnmacro'. - - 4.4.3 `%ifctx': Testing the Context Stack - - The conditional-assembly construct `%ifctx' will cause the - subsequent code to be assembled if and only if the top context on - the preprocessor's context stack has the same name as one of the - arguments. As with `%ifdef', the inverse and `%elif' forms - `%ifnctx', `%elifctx' and `%elifnctx' are also supported. - - For more details of the context stack, see section 4.7. For a sample - use of `%ifctx', see section 4.7.5. - - 4.4.4 `%if': Testing Arbitrary Numeric Expressions - - The conditional-assembly construct `%if expr' will cause the - subsequent code to be assembled if and only if the value of the - numeric expression `expr' is non-zero. An example of the use of this - feature is in deciding when to break out of a `%rep' preprocessor - loop: see section 4.5 for a detailed example. - - The expression given to `%if', and its counterpart `%elif', is a - critical expression (see section 3.8). - - `%if' extends the normal NASM expression syntax, by providing a set - of relational operators which are not normally available in - expressions. The operators `=', `<', `>', `<=', `>=' and `<>' test - equality, less-than, greater-than, less-or-equal, greater-or-equal - and not-equal respectively. The C-like forms `==' and `!=' are - supported as alternative forms of `=' and `<>'. In addition, low- - priority logical operators `&&', `^^' and `||' are provided, - supplying logical AND, logical XOR and logical OR. These work like - the C logical operators (although C has no logical XOR), in that - they always return either 0 or 1, and treat any non-zero input as 1 - (so that `^^', for example, returns 1 if exactly one of its inputs - is zero, and 0 otherwise). The relational operators also return 1 - for true and 0 for false. - - Like other `%if' constructs, `%if' has a counterpart `%elif', and - negative forms `%ifn' and `%elifn'. - - 4.4.5 `%ifidn' and `%ifidni': Testing Exact Text Identity - - The construct `%ifidn text1,text2' will cause the subsequent code to - be assembled if and only if `text1' and `text2', after expanding - single-line macros, are identical pieces of text. Differences in - white space are not counted. - - `%ifidni' is similar to `%ifidn', but is case-insensitive. - - For example, the following macro pushes a register or number on the - stack, and allows you to treat `IP' as a real register: - - %macro pushparam 1 - - %ifidni %1,ip - call %%label - %%label: - %else - push %1 - %endif - - %endmacro - - Like other `%if' constructs, `%ifidn' has a counterpart `%elifidn', - and negative forms `%ifnidn' and `%elifnidn'. Similarly, `%ifidni' - has counterparts `%elifidni', `%ifnidni' and `%elifnidni'. - - 4.4.6 `%ifid', `%ifnum', `%ifstr': Testing Token Types - - Some macros will want to perform different tasks depending on - whether they are passed a number, a string, or an identifier. For - example, a string output macro might want to be able to cope with - being passed either a string constant or a pointer to an existing - string. - - The conditional assembly construct `%ifid', taking one parameter - (which may be blank), assembles the subsequent code if and only if - the first token in the parameter exists and is an identifier. - `%ifnum' works similarly, but tests for the token being a numeric - constant; `%ifstr' tests for it being a string. - - For example, the `writefile' macro defined in section 4.3.4 can be - extended to take advantage of `%ifstr' in the following fashion: - - %macro writefile 2-3+ - - %ifstr %2 - jmp %%endstr - %if %0 = 3 - %%str: db %2,%3 - %else - %%str: db %2 - %endif - %%endstr: mov dx,%%str - mov cx,%%endstr-%%str - %else - mov dx,%2 - mov cx,%3 - %endif - mov bx,%1 - mov ah,0x40 - int 0x21 - - %endmacro - - Then the `writefile' macro can cope with being called in either of - the following two ways: - - writefile [file], strpointer, length - writefile [file], "hello", 13, 10 - - In the first, `strpointer' is used as the address of an already- - declared string, and `length' is used as its length; in the second, - a string is given to the macro, which therefore declares it itself - and works out the address and length for itself. - - Note the use of `%if' inside the `%ifstr': this is to detect whether - the macro was passed two arguments (so the string would be a single - string constant, and `db %2' would be adequate) or more (in which - case, all but the first two would be lumped together into `%3', and - `db %2,%3' would be required). - - The usual `%elif'..., `%ifn'..., and `%elifn'... versions exist for - each of `%ifid', `%ifnum' and `%ifstr'. - - 4.4.7 `%iftoken': Test for a Single Token - - Some macros will want to do different things depending on if it is - passed a single token (e.g. paste it to something else using `%+') - versus a multi-token sequence. - - The conditional assembly construct `%iftoken' assembles the - subsequent code if and only if the expanded parameters consist of - exactly one token, possibly surrounded by whitespace. - - For example: - - %iftoken 1 - - will assemble the subsequent code, but - - %iftoken -1 - - will not, since `-1' contains two tokens: the unary minus operator - `-', and the number `1'. - - The usual `%eliftoken', `%ifntoken', and `%elifntoken' variants are - also provided. - - 4.4.8 `%ifempty': Test for Empty Expansion - - The conditional assembly construct `%ifempty' assembles the - subsequent code if and only if the expanded parameters do not - contain any tokens at all, whitespace excepted. - - The usual `%elifempty', `%ifnempty', and `%elifnempty' variants are - also provided. - - 4.5 Preprocessor Loops: `%rep' - - NASM's `TIMES' prefix, though useful, cannot be used to invoke a - multi-line macro multiple times, because it is processed by NASM - after macros have already been expanded. Therefore NASM provides - another form of loop, this time at the preprocessor level: `%rep'. - - The directives `%rep' and `%endrep' (`%rep' takes a numeric - argument, which can be an expression; `%endrep' takes no arguments) - can be used to enclose a chunk of code, which is then replicated as - many times as specified by the preprocessor: - - %assign i 0 - %rep 64 - inc word [table+2*i] - %assign i i+1 - %endrep - - This will generate a sequence of 64 `INC' instructions, incrementing - every word of memory from `[table]' to `[table+126]'. - - For more complex termination conditions, or to break out of a repeat - loop part way along, you can use the `%exitrep' directive to - terminate the loop, like this: - - fibonacci: - %assign i 0 - %assign j 1 - %rep 100 - %if j > 65535 - %exitrep - %endif - dw j - %assign k j+i - %assign i j - %assign j k - %endrep - - fib_number equ ($-fibonacci)/2 - - This produces a list of all the Fibonacci numbers that will fit in - 16 bits. Note that a maximum repeat count must still be given to - `%rep'. This is to prevent the possibility of NASM getting into an - infinite loop in the preprocessor, which (on multitasking or multi- - user systems) would typically cause all the system memory to be - gradually used up and other applications to start crashing. - - 4.6 Source Files and Dependencies - - These commands allow you to split your sources into multiple files. - - 4.6.1 `%include': Including Other Files - - Using, once again, a very similar syntax to the C preprocessor, - NASM's preprocessor lets you include other source files into your - code. This is done by the use of the `%include' directive: - - %include "macros.mac" - - will include the contents of the file `macros.mac' into the source - file containing the `%include' directive. - - Include files are searched for in the current directory (the - directory you're in when you run NASM, as opposed to the location of - the NASM executable or the location of the source file), plus any - directories specified on the NASM command line using the `-i' - option. - - The standard C idiom for preventing a file being included more than - once is just as applicable in NASM: if the file `macros.mac' has the - form - - %ifndef MACROS_MAC - %define MACROS_MAC - ; now define some macros - %endif - - then including the file more than once will not cause errors, - because the second time the file is included nothing will happen - because the macro `MACROS_MAC' will already be defined. - - You can force a file to be included even if there is no `%include' - directive that explicitly includes it, by using the `-p' option on - the NASM command line (see section 2.1.17). - - 4.6.2 `%pathsearch': Search the Include Path - - The `%pathsearch' directive takes a single-line macro name and a - filename, and declare or redefines the specified single-line macro - to be the include-path-resolved version of the filename, if the file - exists (otherwise, it is passed unchanged.) - - For example, - - %pathsearch MyFoo "foo.bin" - - ... with `-Ibins/' in the include path may end up defining the macro - `MyFoo' to be `"bins/foo.bin"'. - - 4.6.3 `%depend': Add Dependent Files - - The `%depend' directive takes a filename and adds it to the list of - files to be emitted as dependency generation when the `-M' options - and its relatives (see section 2.1.4) are used. It produces no - output. - - This is generally used in conjunction with `%pathsearch'. For - example, a simplified version of the standard macro wrapper for the - `INCBIN' directive looks like: - - %imacro incbin 1-2+ 0 - %pathsearch dep %1 - %depend dep - incbin dep,%2 - %endmacro - - This first resolves the location of the file into the macro `dep', - then adds it to the dependency lists, and finally issues the - assembler-level `INCBIN' directive. - - 4.6.4 `%use': Include Standard Macro Package - - The `%use' directive is similar to `%include', but rather than - including the contents of a file, it includes a named standard macro - package. The standard macro packages are part of NASM, and are - described in chapter 5. - - Unlike the `%include' directive, package names for the `%use' - directive do not require quotes, but quotes are permitted. In NASM - 2.04 and 2.05 the unquoted form would be macro-expanded; this is no - longer true. Thus, the following lines are equivalent: - - %use altreg - %use 'altreg' - - Standard macro packages are protected from multiple inclusion. When - a standard macro package is used, a testable single-line macro of - the form `__USE_'_package_`__' is also defined, see section 4.11.8. - - 4.7 The Context Stack - - Having labels that are local to a macro definition is sometimes not - quite powerful enough: sometimes you want to be able to share labels - between several macro calls. An example might be a `REPEAT' ... - `UNTIL' loop, in which the expansion of the `REPEAT' macro would - need to be able to refer to a label which the `UNTIL' macro had - defined. However, for such a macro you would also want to be able to - nest these loops. - - NASM provides this level of power by means of a _context stack_. The - preprocessor maintains a stack of _contexts_, each of which is - characterized by a name. You add a new context to the stack using - the `%push' directive, and remove one using `%pop'. You can define - labels that are local to a particular context on the stack. - - 4.7.1 `%push' and `%pop': Creating and Removing Contexts - - The `%push' directive is used to create a new context and place it - on the top of the context stack. `%push' takes an optional argument, - which is the name of the context. For example: - - %push foobar - - This pushes a new context called `foobar' on the stack. You can have - several contexts on the stack with the same name: they can still be - distinguished. If no name is given, the context is unnamed (this is - normally used when both the `%push' and the `%pop' are inside a - single macro definition.) - - The directive `%pop', taking one optional argument, removes the top - context from the context stack and destroys it, along with any - labels associated with it. If an argument is given, it must match - the name of the current context, otherwise it will issue an error. - - 4.7.2 Context-Local Labels - - Just as the usage `%%foo' defines a label which is local to the - particular macro call in which it is used, the usage `%$foo' is used - to define a label which is local to the context on the top of the - context stack. So the `REPEAT' and `UNTIL' example given above could - be implemented by means of: - - %macro repeat 0 - - %push repeat - %$begin: - - %endmacro - - %macro until 1 - - j%-1 %$begin - %pop - - %endmacro - - and invoked by means of, for example, - - mov cx,string - repeat - add cx,3 - scasb - until e - - which would scan every fourth byte of a string in search of the byte - in `AL'. - - If you need to define, or access, labels local to the context - _below_ the top one on the stack, you can use `%$$foo', or `%$$$foo' - for the context below that, and so on. - - 4.7.3 Context-Local Single-Line Macros - - NASM also allows you to define single-line macros which are local to - a particular context, in just the same way: - - %define %$localmac 3 - - will define the single-line macro `%$localmac' to be local to the - top context on the stack. Of course, after a subsequent `%push', it - can then still be accessed by the name `%$$localmac'. - - 4.7.4 `%repl': Renaming a Context - - If you need to change the name of the top context on the stack (in - order, for example, to have it respond differently to `%ifctx'), you - can execute a `%pop' followed by a `%push'; but this will have the - side effect of destroying all context-local labels and macros - associated with the context that was just popped. - - NASM provides the directive `%repl', which _replaces_ a context with - a different name, without touching the associated macros and labels. - So you could replace the destructive code - - %pop - %push newname - - with the non-destructive version `%repl newname'. - - 4.7.5 Example Use of the Context Stack: Block IFs - - This example makes use of almost all the context-stack features, - including the conditional-assembly construct `%ifctx', to implement - a block IF statement as a set of macros. - - %macro if 1 - - %push if - j%-1 %$ifnot - - %endmacro - - %macro else 0 - - %ifctx if - %repl else - jmp %$ifend - %$ifnot: - %else - %error "expected `if' before `else'" - %endif - - %endmacro - - %macro endif 0 - - %ifctx if - %$ifnot: - %pop - %elifctx else - %$ifend: - %pop - %else - %error "expected `if' or `else' before `endif'" - %endif - - %endmacro - - This code is more robust than the `REPEAT' and `UNTIL' macros given - in section 4.7.2, because it uses conditional assembly to check that - the macros are issued in the right order (for example, not calling - `endif' before `if') and issues a `%error' if they're not. - - In addition, the `endif' macro has to be able to cope with the two - distinct cases of either directly following an `if', or following an - `else'. It achieves this, again, by using conditional assembly to do - different things depending on whether the context on top of the - stack is `if' or `else'. - - The `else' macro has to preserve the context on the stack, in order - to have the `%$ifnot' referred to by the `if' macro be the same as - the one defined by the `endif' macro, but has to change the - context's name so that `endif' will know there was an intervening - `else'. It does this by the use of `%repl'. - - A sample usage of these macros might look like: - - cmp ax,bx - - if ae - cmp bx,cx - - if ae - mov ax,cx - else - mov ax,bx - endif - - else - cmp ax,cx - - if ae - mov ax,cx - endif - - endif - - The block-`IF' macros handle nesting quite happily, by means of - pushing another context, describing the inner `if', on top of the - one describing the outer `if'; thus `else' and `endif' always refer - to the last unmatched `if' or `else'. - - 4.8 Stack Relative Preprocessor Directives - - The following preprocessor directives provide a way to use labels to - refer to local variables allocated on the stack. - - (*) `%arg' (see section 4.8.1) - - (*) `%stacksize' (see section 4.8.2) - - (*) `%local' (see section 4.8.3) - - 4.8.1 `%arg' Directive - - The `%arg' directive is used to simplify the handling of parameters - passed on the stack. Stack based parameter passing is used by many - high level languages, including C, C++ and Pascal. - - While NASM has macros which attempt to duplicate this functionality - (see section 8.4.5), the syntax is not particularly convenient to - use. and is not TASM compatible. Here is an example which shows the - use of `%arg' without any external macros: - - some_function: - - %push mycontext ; save the current context - %stacksize large ; tell NASM to use bp - %arg i:word, j_ptr:word - - mov ax,[i] - mov bx,[j_ptr] - add ax,[bx] - ret - - %pop ; restore original context - - This is similar to the procedure defined in section 8.4.5 and adds - the value in i to the value pointed to by j_ptr and returns the sum - in the ax register. See section 4.7.1 for an explanation of `push' - and `pop' and the use of context stacks. - - 4.8.2 `%stacksize' Directive - - The `%stacksize' directive is used in conjunction with the `%arg' - (see section 4.8.1) and the `%local' (see section 4.8.3) directives. - It tells NASM the default size to use for subsequent `%arg' and - `%local' directives. The `%stacksize' directive takes one required - argument which is one of `flat', `flat64', `large' or `small'. - - %stacksize flat - - This form causes NASM to use stack-based parameter addressing - relative to `ebp' and it assumes that a near form of call was used - to get to this label (i.e. that `eip' is on the stack). - - %stacksize flat64 - - This form causes NASM to use stack-based parameter addressing - relative to `rbp' and it assumes that a near form of call was used - to get to this label (i.e. that `rip' is on the stack). - - %stacksize large - - This form uses `bp' to do stack-based parameter addressing and - assumes that a far form of call was used to get to this address - (i.e. that `ip' and `cs' are on the stack). - - %stacksize small - - This form also uses `bp' to address stack parameters, but it is - different from `large' because it also assumes that the old value of - bp is pushed onto the stack (i.e. it expects an `ENTER' - instruction). In other words, it expects that `bp', `ip' and `cs' - are on the top of the stack, underneath any local space which may - have been allocated by `ENTER'. This form is probably most useful - when used in combination with the `%local' directive (see section - 4.8.3). - - 4.8.3 `%local' Directive - - The `%local' directive is used to simplify the use of local - temporary stack variables allocated in a stack frame. Automatic - local variables in C are an example of this kind of variable. The - `%local' directive is most useful when used with the `%stacksize' - (see section 4.8.2 and is also compatible with the `%arg' directive - (see section 4.8.1). It allows simplified reference to variables on - the stack which have been allocated typically by using the `ENTER' - instruction. An example of its use is the following: - - silly_swap: - - %push mycontext ; save the current context - %stacksize small ; tell NASM to use bp - %assign %$localsize 0 ; see text for explanation - %local old_ax:word, old_dx:word - - enter %$localsize,0 ; see text for explanation - mov [old_ax],ax ; swap ax & bx - mov [old_dx],dx ; and swap dx & cx - mov ax,bx - mov dx,cx - mov bx,[old_ax] - mov cx,[old_dx] - leave ; restore old bp - ret ; - - %pop ; restore original context - - The `%$localsize' variable is used internally by the `%local' - directive and _must_ be defined within the current context before - the `%local' directive may be used. Failure to do so will result in - one expression syntax error for each `%local' variable declared. It - then may be used in the construction of an appropriately sized ENTER - instruction as shown in the example. - - 4.9 Reporting User-Defined Errors: `%error', `%warning', `%fatal' - - The preprocessor directive `%error' will cause NASM to report an - error if it occurs in assembled code. So if other users are going to - try to assemble your source files, you can ensure that they define - the right macros by means of code like this: - - %ifdef F1 - ; do some setup - %elifdef F2 - ; do some different setup - %else - %error "Neither F1 nor F2 was defined." - %endif - - Then any user who fails to understand the way your code is supposed - to be assembled will be quickly warned of their mistake, rather than - having to wait until the program crashes on being run and then not - knowing what went wrong. - - Similarly, `%warning' issues a warning, but allows assembly to - continue: - - %ifdef F1 - ; do some setup - %elifdef F2 - ; do some different setup - %else - %warning "Neither F1 nor F2 was defined, assuming F1." - %define F1 - %endif - - `%error' and `%warning' are issued only on the final assembly pass. - This makes them safe to use in conjunction with tests that depend on - symbol values. - - `%fatal' terminates assembly immediately, regardless of pass. This - is useful when there is no point in continuing the assembly further, - and doing so is likely just going to cause a spew of confusing error - messages. - - It is optional for the message string after `%error', `%warning' or - `%fatal' to be quoted. If it is _not_, then single-line macros are - expanded in it, which can be used to display more information to the - user. For example: - - %if foo > 64 - %assign foo_over foo-64 - %error foo is foo_over bytes too large - %endif - - 4.10 Other Preprocessor Directives - - NASM also has preprocessor directives which allow access to - information from external sources. Currently they include: - - (*) `%line' enables NASM to correctly handle the output of another - preprocessor (see section 4.10.1). - - (*) `%!' enables NASM to read in the value of an environment - variable, which can then be used in your program (see section - 4.10.2). - -4.10.1 `%line' Directive - - The `%line' directive is used to notify NASM that the input line - corresponds to a specific line number in another file. Typically - this other file would be an original source file, with the current - NASM input being the output of a pre-processor. The `%line' - directive allows NASM to output messages which indicate the line - number of the original source file, instead of the file that is - being read by NASM. - - This preprocessor directive is not generally of use to programmers, - by may be of interest to preprocessor authors. The usage of the - `%line' preprocessor directive is as follows: - - %line nnn[+mmm] [filename] - - In this directive, `nnn' identifies the line of the original source - file which this line corresponds to. `mmm' is an optional parameter - which specifies a line increment value; each line of the input file - read in is considered to correspond to `mmm' lines of the original - source file. Finally, `filename' is an optional parameter which - specifies the file name of the original source file. - - After reading a `%line' preprocessor directive, NASM will report all - file name and line numbers relative to the values specified therein. - -4.10.2 `%!'`<env>': Read an environment variable. - - The `%!<env>' directive makes it possible to read the value of an - environment variable at assembly time. This could, for example, be - used to store the contents of an environment variable into a string, - which could be used at some other point in your code. - - For example, suppose that you have an environment variable `FOO', - and you want the contents of `FOO' to be embedded in your program. - You could do that as follows: - - %defstr FOO %!FOO - - See section 4.1.8 for notes on the `%defstr' directive. - - 4.11 Standard Macros - - NASM defines a set of standard macros, which are already defined - when it starts to process any source file. If you really need a - program to be assembled with no pre-defined macros, you can use the - `%clear' directive to empty the preprocessor of everything but - context-local preprocessor variables and single-line macros. - - Most user-level assembler directives (see chapter 6) are implemented - as macros which invoke primitive directives; these are described in - chapter 6. The rest of the standard macro set is described here. - -4.11.1 NASM Version Macros - - The single-line macros `__NASM_MAJOR__', `__NASM_MINOR__', - `__NASM_SUBMINOR__' and `___NASM_PATCHLEVEL__' expand to the major, - minor, subminor and patch level parts of the version number of NASM - being used. So, under NASM 0.98.32p1 for example, `__NASM_MAJOR__' - would be defined to be 0, `__NASM_MINOR__' would be defined as 98, - `__NASM_SUBMINOR__' would be defined to 32, and - `___NASM_PATCHLEVEL__' would be defined as 1. - - Additionally, the macro `__NASM_SNAPSHOT__' is defined for - automatically generated snapshot releases _only_. - -4.11.2 `__NASM_VERSION_ID__': NASM Version ID - - The single-line macro `__NASM_VERSION_ID__' expands to a dword - integer representing the full version number of the version of nasm - being used. The value is the equivalent to `__NASM_MAJOR__', - `__NASM_MINOR__', `__NASM_SUBMINOR__' and `___NASM_PATCHLEVEL__' - concatenated to produce a single doubleword. Hence, for 0.98.32p1, - the returned number would be equivalent to: - - dd 0x00622001 - - or - - db 1,32,98,0 - - Note that the above lines are generate exactly the same code, the - second line is used just to give an indication of the order that the - separate values will be present in memory. - -4.11.3 `__NASM_VER__': NASM Version string - - The single-line macro `__NASM_VER__' expands to a string which - defines the version number of nasm being used. So, under NASM - 0.98.32 for example, - - db __NASM_VER__ - - would expand to - - db "0.98.32" - -4.11.4 `__FILE__' and `__LINE__': File Name and Line Number - - Like the C preprocessor, NASM allows the user to find out the file - name and line number containing the current instruction. The macro - `__FILE__' expands to a string constant giving the name of the - current input file (which may change through the course of assembly - if `%include' directives are used), and `__LINE__' expands to a - numeric constant giving the current line number in the input file. - - These macros could be used, for example, to communicate debugging - information to a macro, since invoking `__LINE__' inside a macro - definition (either single-line or multi-line) will return the line - number of the macro _call_, rather than _definition_. So to - determine where in a piece of code a crash is occurring, for - example, one could write a routine `stillhere', which is passed a - line number in `EAX' and outputs something like `line 155: still - here'. You could then write a macro - - %macro notdeadyet 0 - - push eax - mov eax,__LINE__ - call stillhere - pop eax - - %endmacro - - and then pepper your code with calls to `notdeadyet' until you find - the crash point. - -4.11.5 `__BITS__': Current BITS Mode - - The `__BITS__' standard macro is updated every time that the BITS - mode is set using the `BITS XX' or `[BITS XX]' directive, where XX - is a valid mode number of 16, 32 or 64. `__BITS__' receives the - specified mode number and makes it globally available. This can be - very useful for those who utilize mode-dependent macros. - -4.11.6 `__OUTPUT_FORMAT__': Current Output Format - - The `__OUTPUT_FORMAT__' standard macro holds the current Output - Format, as given by the `-f' option or NASM's default. Type - `nasm -hf' for a list. - - %ifidn __OUTPUT_FORMAT__, win32 - %define NEWLINE 13, 10 - %elifidn __OUTPUT_FORMAT__, elf32 - %define NEWLINE 10 - %endif - -4.11.7 Assembly Date and Time Macros - - NASM provides a variety of macros that represent the timestamp of - the assembly session. - - (*) The `__DATE__' and `__TIME__' macros give the assembly date and - time as strings, in ISO 8601 format (`"YYYY-MM-DD"' and - `"HH:MM:SS"', respectively.) - - (*) The `__DATE_NUM__' and `__TIME_NUM__' macros give the assembly - date and time in numeric form; in the format `YYYYMMDD' and - `HHMMSS' respectively. - - (*) The `__UTC_DATE__' and `__UTC_TIME__' macros give the assembly - date and time in universal time (UTC) as strings, in ISO 8601 - format (`"YYYY-MM-DD"' and `"HH:MM:SS"', respectively.) If the - host platform doesn't provide UTC time, these macros are - undefined. - - (*) The `__UTC_DATE_NUM__' and `__UTC_TIME_NUM__' macros give the - assembly date and time universal time (UTC) in numeric form; in - the format `YYYYMMDD' and `HHMMSS' respectively. If the host - platform doesn't provide UTC time, these macros are undefined. - - (*) The `__POSIX_TIME__' macro is defined as a number containing the - number of seconds since the POSIX epoch, 1 January 1970 00:00:00 - UTC; excluding any leap seconds. This is computed using UTC time - if available on the host platform, otherwise it is computed - using the local time as if it was UTC. - - All instances of time and date macros in the same assembly session - produce consistent output. For example, in an assembly session - started at 42 seconds after midnight on January 1, 2010 in Moscow - (timezone UTC+3) these macros would have the following values, - assuming, of course, a properly configured environment with a - correct clock: - - __DATE__ "2010-01-01" - __TIME__ "00:00:42" - __DATE_NUM__ 20100101 - __TIME_NUM__ 000042 - __UTC_DATE__ "2009-12-31" - __UTC_TIME__ "21:00:42" - __UTC_DATE_NUM__ 20091231 - __UTC_TIME_NUM__ 210042 - __POSIX_TIME__ 1262293242 - -4.11.8 `__USE_'_package_`__': Package Include Test - - When a standard macro package (see chapter 5) is included with the - `%use' directive (see section 4.6.4), a single-line macro of the - form `__USE_'_package_`__' is automatically defined. This allows - testing if a particular package is invoked or not. - - For example, if the `altreg' package is included (see section 5.1), - then the macro `__USE_ALTREG__' is defined. - -4.11.9 `__PASS__': Assembly Pass - - The macro `__PASS__' is defined to be `1' on preparatory passes, and - `2' on the final pass. In preprocess-only mode, it is set to `3', - and when running only to generate dependencies (due to the `-M' or - `-MG' option, see section 2.1.4) it is set to `0'. - - _Avoid using this macro if at all possible. It is tremendously easy - to generate very strange errors by misusing it, and the semantics - may change in future versions of NASM._ - -4.11.10 `STRUC' and `ENDSTRUC': Declaring Structure Data Types - - The core of NASM contains no intrinsic means of defining data - structures; instead, the preprocessor is sufficiently powerful that - data structures can be implemented as a set of macros. The macros - `STRUC' and `ENDSTRUC' are used to define a structure data type. - - `STRUC' takes one or two parameters. The first parameter is the name - of the data type. The second, optional parameter is the base offset - of the structure. The name of the data type is defined as a symbol - with the value of the base offset, and the name of the data type - with the suffix `_size' appended to it is defined as an `EQU' giving - the size of the structure. Once `STRUC' has been issued, you are - defining the structure, and should define fields using the `RESB' - family of pseudo-instructions, and then invoke `ENDSTRUC' to finish - the definition. - - For example, to define a structure called `mytype' containing a - longword, a word, a byte and a string of bytes, you might code - - struc mytype - - mt_long: resd 1 - mt_word: resw 1 - mt_byte: resb 1 - mt_str: resb 32 - - endstruc - - The above code defines six symbols: `mt_long' as 0 (the offset from - the beginning of a `mytype' structure to the longword field), - `mt_word' as 4, `mt_byte' as 6, `mt_str' as 7, `mytype_size' as 39, - and `mytype' itself as zero. - - The reason why the structure type name is defined at zero by default - is a side effect of allowing structures to work with the local label - mechanism: if your structure members tend to have the same names in - more than one structure, you can define the above structure like - this: - - struc mytype - - .long: resd 1 - .word: resw 1 - .byte: resb 1 - .str: resb 32 - - endstruc - - This defines the offsets to the structure fields as `mytype.long', - `mytype.word', `mytype.byte' and `mytype.str'. - - NASM, since it has no _intrinsic_ structure support, does not - support any form of period notation to refer to the elements of a - structure once you have one (except the above local-label notation), - so code such as `mov ax,[mystruc.mt_word]' is not valid. `mt_word' - is a constant just like any other constant, so the correct syntax is - `mov ax,[mystruc+mt_word]' or `mov ax,[mystruc+mytype.word]'. - - Sometimes you only have the address of the structure displaced by an - offset. For example, consider this standard stack frame setup: - - push ebp - mov ebp, esp - sub esp, 40 - - In this case, you could access an element by subtracting the offset: - - mov [ebp - 40 + mytype.word], ax - - However, if you do not want to repeat this offset, you can use -40 - as a base offset: - - struc mytype, -40 - - And access an element this way: - - mov [ebp + mytype.word], ax - -4.11.11 `ISTRUC', `AT' and `IEND': Declaring Instances of Structures - - Having defined a structure type, the next thing you typically want - to do is to declare instances of that structure in your data - segment. NASM provides an easy way to do this in the `ISTRUC' - mechanism. To declare a structure of type `mytype' in a program, you - code something like this: - - mystruc: - istruc mytype - - at mt_long, dd 123456 - at mt_word, dw 1024 - at mt_byte, db 'x' - at mt_str, db 'hello, world', 13, 10, 0 - - iend - - The function of the `AT' macro is to make use of the `TIMES' prefix - to advance the assembly position to the correct point for the - specified structure field, and then to declare the specified data. - Therefore the structure fields must be declared in the same order as - they were specified in the structure definition. - - If the data to go in a structure field requires more than one source - line to specify, the remaining source lines can easily come after - the `AT' line. For example: - - at mt_str, db 123,134,145,156,167,178,189 - db 190,100,0 - - Depending on personal taste, you can also omit the code part of the - `AT' line completely, and start the structure field on the next - line: - - at mt_str - db 'hello, world' - db 13,10,0 - -4.11.12 `ALIGN' and `ALIGNB': Data Alignment - - The `ALIGN' and `ALIGNB' macros provides a convenient way to align - code or data on a word, longword, paragraph or other boundary. (Some - assemblers call this directive `EVEN'.) The syntax of the `ALIGN' - and `ALIGNB' macros is - - align 4 ; align on 4-byte boundary - align 16 ; align on 16-byte boundary - align 8,db 0 ; pad with 0s rather than NOPs - align 4,resb 1 ; align to 4 in the BSS - alignb 4 ; equivalent to previous line - - Both macros require their first argument to be a power of two; they - both compute the number of additional bytes required to bring the - length of the current section up to a multiple of that power of two, - and then apply the `TIMES' prefix to their second argument to - perform the alignment. - - If the second argument is not specified, the default for `ALIGN' is - `NOP', and the default for `ALIGNB' is `RESB 1'. So if the second - argument is specified, the two macros are equivalent. Normally, you - can just use `ALIGN' in code and data sections and `ALIGNB' in BSS - sections, and never need the second argument except for special - purposes. - - `ALIGN' and `ALIGNB', being simple macros, perform no error - checking: they cannot warn you if their first argument fails to be a - power of two, or if their second argument generates more than one - byte of code. In each of these cases they will silently do the wrong - thing. - - `ALIGNB' (or `ALIGN' with a second argument of `RESB 1') can be used - within structure definitions: - - struc mytype2 - - mt_byte: - resb 1 - alignb 2 - mt_word: - resw 1 - alignb 4 - mt_long: - resd 1 - mt_str: - resb 32 - - endstruc - - This will ensure that the structure members are sensibly aligned - relative to the base of the structure. - - A final caveat: `ALIGN' and `ALIGNB' work relative to the beginning - of the _section_, not the beginning of the address space in the - final executable. Aligning to a 16-byte boundary when the section - you're in is only guaranteed to be aligned to a 4-byte boundary, for - example, is a waste of effort. Again, NASM does not check that the - section's alignment characteristics are sensible for the use of - `ALIGN' or `ALIGNB'. - - See also the `smartalign' standard macro package, section 5.2. - -Chapter 5: Standard Macro Packages ----------------------------------- - - The `%use' directive (see section 4.6.4) includes one of the - standard macro packages included with the NASM distribution and - compiled into the NASM binary. It operates like the `%include' - directive (see section 4.6.1), but the included contents is provided - by NASM itself. - - The names of standard macro packages are case insensitive, and can - be quoted or not. - - 5.1 `altreg': Alternate Register Names - - The `altreg' standard macro package provides alternate register - names. It provides numeric register names for all registers (not - just `R8'-`R15'), the Intel-defined aliases `R8L'-`R15L' for the low - bytes of register (as opposed to the NASM/AMD standard names `R8B'- - `R15B'), and the names `R0H'-`R3H' (by analogy with `R0L'-`R3L') for - `AH', `CH', `DH', and `BH'. - - Example use: - - %use altreg - - proc: - mov r0l,r3h ; mov al,bh - ret - - See also section 11.1. - - 5.2 `smartalign': Smart `ALIGN' Macro - - The `smartalign' standard macro package provides for an `ALIGN' - macro which is more powerful than the default (and backwards- - compatible) one (see section 4.11.12). When the `smartalign' package - is enabled, when `ALIGN' is used without a second argument, NASM - will generate a sequence of instructions more efficient than a - series of `NOP'. Furthermore, if the padding exceeds a specific - threshold, then NASM will generate a jump over the entire padding - sequence. - - The specific instructions generated can be controlled with the new - `ALIGNMODE' macro. This macro takes two parameters: one mode, and an - optional jump threshold override. The modes are as follows: - - (*) `generic': Works on all x86 CPUs and should have reasonable - performance. The default jump threshold is 8. This is the - default. - - (*) `nop': Pad out with `NOP' instructions. The only difference - compared to the standard `ALIGN' macro is that NASM can still - jump over a large padding area. The default jump threshold is - 16. - - (*) `k7': Optimize for the AMD K7 (Athlon/Althon XP). These - instructions should still work on all x86 CPUs. The default jump - threshold is 16. - - (*) `k8': Optimize for the AMD K8 (Opteron/Althon 64). These - instructions should still work on all x86 CPUs. The default jump - threshold is 16. - - (*) `p6': Optimize for Intel CPUs. This uses the long `NOP' - instructions first introduced in Pentium Pro. This is - incompatible with all CPUs of family 5 or lower, as well as some - VIA CPUs and several virtualization solutions. The default jump - threshold is 16. - - The macro `__ALIGNMODE__' is defined to contain the current - alignment mode. A number of other macros beginning with `__ALIGN_' - are used internally by this macro package. - -Chapter 6: Assembler Directives -------------------------------- - - NASM, though it attempts to avoid the bureaucracy of assemblers like - MASM and TASM, is nevertheless forced to support a _few_ directives. - These are described in this chapter. - - NASM's directives come in two types: _user-level_ directives and - _primitive_ directives. Typically, each directive has a user-level - form and a primitive form. In almost all cases, we recommend that - users use the user-level forms of the directives, which are - implemented as macros which call the primitive forms. - - Primitive directives are enclosed in square brackets; user-level - directives are not. - - In addition to the universal directives described in this chapter, - each object file format can optionally supply extra directives in - order to control particular features of that file format. These - _format-specific_ directives are documented along with the formats - that implement them, in chapter 7. - - 6.1 `BITS': Specifying Target Processor Mode - - The `BITS' directive specifies whether NASM should generate code - designed to run on a processor operating in 16-bit mode, 32-bit mode - or 64-bit mode. The syntax is `BITS XX', where XX is 16, 32 or 64. - - In most cases, you should not need to use `BITS' explicitly. The - `aout', `coff', `elf', `macho', `win32' and `win64' object formats, - which are designed for use in 32-bit or 64-bit operating systems, - all cause NASM to select 32-bit or 64-bit mode, respectively, by - default. The `obj' object format allows you to specify each segment - you define as either `USE16' or `USE32', and NASM will set its - operating mode accordingly, so the use of the `BITS' directive is - once again unnecessary. - - The most likely reason for using the `BITS' directive is to write - 32-bit or 64-bit code in a flat binary file; this is because the - `bin' output format defaults to 16-bit mode in anticipation of it - being used most frequently to write DOS `.COM' programs, DOS `.SYS' - device drivers and boot loader software. - - You do _not_ need to specify `BITS 32' merely in order to use 32-bit - instructions in a 16-bit DOS program; if you do, the assembler will - generate incorrect code because it will be writing code targeted at - a 32-bit platform, to be run on a 16-bit one. - - When NASM is in `BITS 16' mode, instructions which use 32-bit data - are prefixed with an 0x66 byte, and those referring to 32-bit - addresses have an 0x67 prefix. In `BITS 32' mode, the reverse is - true: 32-bit instructions require no prefixes, whereas instructions - using 16-bit data need an 0x66 and those working on 16-bit addresses - need an 0x67. - - When NASM is in `BITS 64' mode, most instructions operate the same - as they do for `BITS 32' mode. However, there are 8 more general and - SSE registers, and 16-bit addressing is no longer supported. - - The default address size is 64 bits; 32-bit addressing can be - selected with the 0x67 prefix. The default operand size is still 32 - bits, however, and the 0x66 prefix selects 16-bit operand size. The - `REX' prefix is used both to select 64-bit operand size, and to - access the new registers. NASM automatically inserts REX prefixes - when necessary. - - When the `REX' prefix is used, the processor does not know how to - address the AH, BH, CH or DH (high 8-bit legacy) registers. Instead, - it is possible to access the the low 8-bits of the SP, BP SI and DI - registers as SPL, BPL, SIL and DIL, respectively; but only when the - REX prefix is used. - - The `BITS' directive has an exactly equivalent primitive form, - `[BITS 16]', `[BITS 32]' and `[BITS 64]'. The user-level form is a - macro which has no function other than to call the primitive form. - - Note that the space is neccessary, e.g. `BITS32' will _not_ work! - - 6.1.1 `USE16' & `USE32': Aliases for BITS - - The ``USE16'' and ``USE32'' directives can be used in place of - ``BITS 16'' and ``BITS 32'', for compatibility with other - assemblers. - - 6.2 `DEFAULT': Change the assembler defaults - - The `DEFAULT' directive changes the assembler defaults. Normally, - NASM defaults to a mode where the programmer is expected to - explicitly specify most features directly. However, this is - occationally obnoxious, as the explicit form is pretty much the only - one one wishes to use. - - Currently, the only `DEFAULT' that is settable is whether or not - registerless instructions in 64-bit mode are `RIP'-relative or not. - By default, they are absolute unless overridden with the `REL' - specifier (see section 3.3). However, if `DEFAULT REL' is specified, - `REL' is default, unless overridden with the `ABS' specifier, - _except when used with an FS or GS segment override_. - - The special handling of `FS' and `GS' overrides are due to the fact - that these registers are generally used as thread pointers or other - special functions in 64-bit mode, and generating `RIP'-relative - addresses would be extremely confusing. - - `DEFAULT REL' is disabled with `DEFAULT ABS'. - - 6.3 `SECTION' or `SEGMENT': Changing and Defining Sections - - The `SECTION' directive (`SEGMENT' is an exactly equivalent synonym) - changes which section of the output file the code you write will be - assembled into. In some object file formats, the number and names of - sections are fixed; in others, the user may make up as many as they - wish. Hence `SECTION' may sometimes give an error message, or may - define a new section, if you try to switch to a section that does - not (yet) exist. - - The Unix object formats, and the `bin' object format (but see - section 7.1.3, all support the standardized section names `.text', - `.data' and `.bss' for the code, data and uninitialized-data - sections. The `obj' format, by contrast, does not recognize these - section names as being special, and indeed will strip off the - leading period of any section name that has one. - - 6.3.1 The `__SECT__' Macro - - The `SECTION' directive is unusual in that its user-level form - functions differently from its primitive form. The primitive form, - `[SECTION xyz]', simply switches the current target section to the - one given. The user-level form, `SECTION xyz', however, first - defines the single-line macro `__SECT__' to be the primitive - `[SECTION]' directive which it is about to issue, and then issues - it. So the user-level directive - - SECTION .text - - expands to the two lines - - %define __SECT__ [SECTION .text] - [SECTION .text] - - Users may find it useful to make use of this in their own macros. - For example, the `writefile' macro defined in section 4.3.4 can be - usefully rewritten in the following more sophisticated form: - - %macro writefile 2+ - - [section .data] - - %%str: db %2 - %%endstr: - - __SECT__ - - mov dx,%%str - mov cx,%%endstr-%%str - mov bx,%1 - mov ah,0x40 - int 0x21 - - %endmacro - - This form of the macro, once passed a string to output, first - switches temporarily to the data section of the file, using the - primitive form of the `SECTION' directive so as not to modify - `__SECT__'. It then declares its string in the data section, and - then invokes `__SECT__' to switch back to _whichever_ section the - user was previously working in. It thus avoids the need, in the - previous version of the macro, to include a `JMP' instruction to - jump over the data, and also does not fail if, in a complicated - `OBJ' format module, the user could potentially be assembling the - code in any of several separate code sections. - - 6.4 `ABSOLUTE': Defining Absolute Labels - - The `ABSOLUTE' directive can be thought of as an alternative form of - `SECTION': it causes the subsequent code to be directed at no - physical section, but at the hypothetical section starting at the - given absolute address. The only instructions you can use in this - mode are the `RESB' family. - - `ABSOLUTE' is used as follows: - - absolute 0x1A - - kbuf_chr resw 1 - kbuf_free resw 1 - kbuf resw 16 - - This example describes a section of the PC BIOS data area, at - segment address 0x40: the above code defines `kbuf_chr' to be 0x1A, - `kbuf_free' to be 0x1C, and `kbuf' to be 0x1E. - - The user-level form of `ABSOLUTE', like that of `SECTION', redefines - the `__SECT__' macro when it is invoked. - - `STRUC' and `ENDSTRUC' are defined as macros which use `ABSOLUTE' - (and also `__SECT__'). - - `ABSOLUTE' doesn't have to take an absolute constant as an argument: - it can take an expression (actually, a critical expression: see - section 3.8) and it can be a value in a segment. For example, a TSR - can re-use its setup code as run-time BSS like this: - - org 100h ; it's a .COM program - - jmp setup ; setup code comes last - - ; the resident part of the TSR goes here - setup: - ; now write the code that installs the TSR here - - absolute setup - - runtimevar1 resw 1 - runtimevar2 resd 20 - - tsr_end: - - This defines some variables `on top of' the setup code, so that - after the setup has finished running, the space it took up can be - re-used as data storage for the running TSR. The symbol `tsr_end' - can be used to calculate the total size of the part of the TSR that - needs to be made resident. - - 6.5 `EXTERN': Importing Symbols from Other Modules - - `EXTERN' is similar to the MASM directive `EXTRN' and the C keyword - `extern': it is used to declare a symbol which is not defined - anywhere in the module being assembled, but is assumed to be defined - in some other module and needs to be referred to by this one. Not - every object-file format can support external variables: the `bin' - format cannot. - - The `EXTERN' directive takes as many arguments as you like. Each - argument is the name of a symbol: - - extern _printf - extern _sscanf,_fscanf - - Some object-file formats provide extra features to the `EXTERN' - directive. In all cases, the extra features are used by suffixing a - colon to the symbol name followed by object-format specific text. - For example, the `obj' format allows you to declare that the default - segment base of an external should be the group `dgroup' by means of - the directive - - extern _variable:wrt dgroup - - The primitive form of `EXTERN' differs from the user-level form only - in that it can take only one argument at a time: the support for - multiple arguments is implemented at the preprocessor level. - - You can declare the same variable as `EXTERN' more than once: NASM - will quietly ignore the second and later redeclarations. You can't - declare a variable as `EXTERN' as well as something else, though. - - 6.6 `GLOBAL': Exporting Symbols to Other Modules - - `GLOBAL' is the other end of `EXTERN': if one module declares a - symbol as `EXTERN' and refers to it, then in order to prevent linker - errors, some other module must actually _define_ the symbol and - declare it as `GLOBAL'. Some assemblers use the name `PUBLIC' for - this purpose. - - The `GLOBAL' directive applying to a symbol must appear _before_ the - definition of the symbol. - - `GLOBAL' uses the same syntax as `EXTERN', except that it must refer - to symbols which _are_ defined in the same module as the `GLOBAL' - directive. For example: - - global _main - _main: - ; some code - - `GLOBAL', like `EXTERN', allows object formats to define private - extensions by means of a colon. The `elf' object format, for - example, lets you specify whether global data items are functions or - data: - - global hashlookup:function, hashtable:data - - Like `EXTERN', the primitive form of `GLOBAL' differs from the user- - level form only in that it can take only one argument at a time. - - 6.7 `COMMON': Defining Common Data Areas - - The `COMMON' directive is used to declare _common variables_. A - common variable is much like a global variable declared in the - uninitialized data section, so that - - common intvar 4 - - is similar in function to - - global intvar - section .bss - - intvar resd 1 - - The difference is that if more than one module defines the same - common variable, then at link time those variables will be _merged_, - and references to `intvar' in all modules will point at the same - piece of memory. - - Like `GLOBAL' and `EXTERN', `COMMON' supports object-format specific - extensions. For example, the `obj' format allows common variables to - be NEAR or FAR, and the `elf' format allows you to specify the - alignment requirements of a common variable: - - common commvar 4:near ; works in OBJ - common intarray 100:4 ; works in ELF: 4 byte aligned - - Once again, like `EXTERN' and `GLOBAL', the primitive form of - `COMMON' differs from the user-level form only in that it can take - only one argument at a time. - - 6.8 `CPU': Defining CPU Dependencies - - The `CPU' directive restricts assembly to those instructions which - are available on the specified CPU. - - Options are: - - (*) `CPU 8086' Assemble only 8086 instruction set - - (*) `CPU 186' Assemble instructions up to the 80186 instruction set - - (*) `CPU 286' Assemble instructions up to the 286 instruction set - - (*) `CPU 386' Assemble instructions up to the 386 instruction set - - (*) `CPU 486' 486 instruction set - - (*) `CPU 586' Pentium instruction set - - (*) `CPU PENTIUM' Same as 586 - - (*) `CPU 686' P6 instruction set - - (*) `CPU PPRO' Same as 686 - - (*) `CPU P2' Same as 686 - - (*) `CPU P3' Pentium III (Katmai) instruction sets - - (*) `CPU KATMAI' Same as P3 - - (*) `CPU P4' Pentium 4 (Willamette) instruction set - - (*) `CPU WILLAMETTE' Same as P4 - - (*) `CPU PRESCOTT' Prescott instruction set - - (*) `CPU X64' x86-64 (x64/AMD64/Intel 64) instruction set - - (*) `CPU IA64' IA64 CPU (in x86 mode) instruction set - - All options are case insensitive. All instructions will be selected - only if they apply to the selected CPU or lower. By default, all - instructions are available. - - 6.9 `FLOAT': Handling of floating-point constants - - By default, floating-point constants are rounded to nearest, and - IEEE denormals are supported. The following options can be set to - alter this behaviour: - - (*) `FLOAT DAZ' Flush denormals to zero - - (*) `FLOAT NODAZ' Do not flush denormals to zero (default) - - (*) `FLOAT NEAR' Round to nearest (default) - - (*) `FLOAT UP' Round up (toward +Infinity) - - (*) `FLOAT DOWN' Round down (toward -Infinity) - - (*) `FLOAT ZERO' Round toward zero - - (*) `FLOAT DEFAULT' Restore default settings - - The standard macros `__FLOAT_DAZ__', `__FLOAT_ROUND__', and - `__FLOAT__' contain the current state, as long as the programmer has - avoided the use of the brackeded primitive form, (`[FLOAT]'). - - `__FLOAT__' contains the full set of floating-point settings; this - value can be saved away and invoked later to restore the setting. - -Chapter 7: Output Formats -------------------------- - - NASM is a portable assembler, designed to be able to compile on any - ANSI C-supporting platform and produce output to run on a variety of - Intel x86 operating systems. For this reason, it has a large number - of available output formats, selected using the `-f' option on the - NASM command line. Each of these formats, along with its extensions - to the base NASM syntax, is detailed in this chapter. - - As stated in section 2.1.1, NASM chooses a default name for your - output file based on the input file name and the chosen output - format. This will be generated by removing the extension (`.asm', - `.s', or whatever you like to use) from the input file name, and - substituting an extension defined by the output format. The - extensions are given with each format below. - - 7.1 `bin': Flat-Form Binary Output - - The `bin' format does not produce object files: it generates nothing - in the output file except the code you wrote. Such `pure binary' - files are used by MS-DOS: `.COM' executables and `.SYS' device - drivers are pure binary files. Pure binary output is also useful for - operating system and boot loader development. - - The `bin' format supports multiple section names. For details of how - NASM handles sections in the `bin' format, see section 7.1.3. - - Using the `bin' format puts NASM by default into 16-bit mode (see - section 6.1). In order to use `bin' to write 32-bit or 64-bit code, - such as an OS kernel, you need to explicitly issue the `BITS 32' or - `BITS 64' directive. - - `bin' has no default output file name extension: instead, it leaves - your file name as it is once the original extension has been - removed. Thus, the default is for NASM to assemble `binprog.asm' - into a binary file called `binprog'. - - 7.1.1 `ORG': Binary File Program Origin - - The `bin' format provides an additional directive to the list given - in chapter 6: `ORG'. The function of the `ORG' directive is to - specify the origin address which NASM will assume the program begins - at when it is loaded into memory. - - For example, the following code will generate the longword - `0x00000104': - - org 0x100 - dd label - label: - - Unlike the `ORG' directive provided by MASM-compatible assemblers, - which allows you to jump around in the object file and overwrite - code you have already generated, NASM's `ORG' does exactly what the - directive says: _origin_. Its sole function is to specify one offset - which is added to all internal address references within the - section; it does not permit any of the trickery that MASM's version - does. See section 12.1.3 for further comments. - - 7.1.2 `bin' Extensions to the `SECTION' Directive - - The `bin' output format extends the `SECTION' (or `SEGMENT') - directive to allow you to specify the alignment requirements of - segments. This is done by appending the `ALIGN' qualifier to the end - of the section-definition line. For example, - - section .data align=16 - - switches to the section `.data' and also specifies that it must be - aligned on a 16-byte boundary. - - The parameter to `ALIGN' specifies how many low bits of the section - start address must be forced to zero. The alignment value given may - be any power of two. - - 7.1.3 Multisection Support for the `bin' Format - - The `bin' format allows the use of multiple sections, of arbitrary - names, besides the "known" `.text', `.data', and `.bss' names. - - (*) Sections may be designated `progbits' or `nobits'. Default is - `progbits' (except `.bss', which defaults to `nobits', of - course). - - (*) Sections can be aligned at a specified boundary following the - previous section with `align=', or at an arbitrary byte-granular - position with `start='. - - (*) Sections can be given a virtual start address, which will be - used for the calculation of all memory references within that - section with `vstart='. - - (*) Sections can be ordered using `follows='`<section>' or - `vfollows='`<section>' as an alternative to specifying an - explicit start address. - - (*) Arguments to `org', `start', `vstart', and `align=' are critical - expressions. See section 3.8. E.g. `align=(1 << ALIGN_SHIFT)' - - `ALIGN_SHIFT' must be defined before it is used here. - - (*) Any code which comes before an explicit `SECTION' directive is - directed by default into the `.text' section. - - (*) If an `ORG' statement is not given, `ORG 0' is used by default. - - (*) The `.bss' section will be placed after the last `progbits' - section, unless `start=', `vstart=', `follows=', or `vfollows=' - has been specified. - - (*) All sections are aligned on dword boundaries, unless a different - alignment has been specified. - - (*) Sections may not overlap. - - (*) NASM creates the `section.<secname>.start' for each section, - which may be used in your code. - - 7.1.4 Map Files - - Map files can be generated in `-f bin' format by means of the - `[map]' option. Map types of `all' (default), `brief', `sections', - `segments', or `symbols' may be specified. Output may be directed to - `stdout' (default), `stderr', or a specified file. E.g. - `[map symbols myfile.map]'. No "user form" exists, the square - brackets must be used. - - 7.2 `ith': Intel Hex Output - - The `ith' file format produces Intel hex-format files. Just as the - `bin' format, this is a flat memory image format with no support for - relocation or linking. It is usually used with ROM programmers and - similar utilities. - - All extensions supported by the `bin' file format is also supported - by the `ith' file format. - - `ith' provides a default output file-name extension of `.ith'. - - 7.3 `srec': Motorola S-Records Output - - The `srec' file format produces Motorola S-records files. Just as - the `bin' format, this is a flat memory image format with no support - for relocation or linking. It is usually used with ROM programmers - and similar utilities. - - All extensions supported by the `bin' file format is also supported - by the `srec' file format. - - `srec' provides a default output file-name extension of `.srec'. - - 7.4 `obj': Microsoft OMF Object Files - - The `obj' file format (NASM calls it `obj' rather than `omf' for - historical reasons) is the one produced by MASM and TASM, which is - typically fed to 16-bit DOS linkers to produce `.EXE' files. It is - also the format used by OS/2. - - `obj' provides a default output file-name extension of `.obj'. - - `obj' is not exclusively a 16-bit format, though: NASM has full - support for the 32-bit extensions to the format. In particular, 32- - bit `obj' format files are used by Borland's Win32 compilers, - instead of using Microsoft's newer `win32' object file format. - - The `obj' format does not define any special segment names: you can - call your segments anything you like. Typical names for segments in - `obj' format files are `CODE', `DATA' and `BSS'. - - If your source file contains code before specifying an explicit - `SEGMENT' directive, then NASM will invent its own segment called - `__NASMDEFSEG' for you. - - When you define a segment in an `obj' file, NASM defines the segment - name as a symbol as well, so that you can access the segment address - of the segment. So, for example: - - segment data - - dvar: dw 1234 - - segment code - - function: - mov ax,data ; get segment address of data - mov ds,ax ; and move it into DS - inc word [dvar] ; now this reference will work - ret - - The `obj' format also enables the use of the `SEG' and `WRT' - operators, so that you can write code which does things like - - extern foo - - mov ax,seg foo ; get preferred segment of foo - mov ds,ax - mov ax,data ; a different segment - mov es,ax - mov ax,[ds:foo] ; this accesses `foo' - mov [es:foo wrt data],bx ; so does this - - 7.4.1 `obj' Extensions to the `SEGMENT' Directive - - The `obj' output format extends the `SEGMENT' (or `SECTION') - directive to allow you to specify various properties of the segment - you are defining. This is done by appending extra qualifiers to the - end of the segment-definition line. For example, - - segment code private align=16 - - defines the segment `code', but also declares it to be a private - segment, and requires that the portion of it described in this code - module must be aligned on a 16-byte boundary. - - The available qualifiers are: - - (*) `PRIVATE', `PUBLIC', `COMMON' and `STACK' specify the - combination characteristics of the segment. `PRIVATE' segments - do not get combined with any others by the linker; `PUBLIC' and - `STACK' segments get concatenated together at link time; and - `COMMON' segments all get overlaid on top of each other rather - than stuck end-to-end. - - (*) `ALIGN' is used, as shown above, to specify how many low bits of - the segment start address must be forced to zero. The alignment - value given may be any power of two from 1 to 4096; in reality, - the only values supported are 1, 2, 4, 16, 256 and 4096, so if 8 - is specified it will be rounded up to 16, and 32, 64 and 128 - will all be rounded up to 256, and so on. Note that alignment to - 4096-byte boundaries is a PharLap extension to the format and - may not be supported by all linkers. - - (*) `CLASS' can be used to specify the segment class; this feature - indicates to the linker that segments of the same class should - be placed near each other in the output file. The class name can - be any word, e.g. `CLASS=CODE'. - - (*) `OVERLAY', like `CLASS', is specified with an arbitrary word as - an argument, and provides overlay information to an overlay- - capable linker. - - (*) Segments can be declared as `USE16' or `USE32', which has the - effect of recording the choice in the object file and also - ensuring that NASM's default assembly mode when assembling in - that segment is 16-bit or 32-bit respectively. - - (*) When writing OS/2 object files, you should declare 32-bit - segments as `FLAT', which causes the default segment base for - anything in the segment to be the special group `FLAT', and also - defines the group if it is not already defined. - - (*) The `obj' file format also allows segments to be declared as - having a pre-defined absolute segment address, although no - linkers are currently known to make sensible use of this - feature; nevertheless, NASM allows you to declare a segment such - as `SEGMENT SCREEN ABSOLUTE=0xB800' if you need to. The - `ABSOLUTE' and `ALIGN' keywords are mutually exclusive. - - NASM's default segment attributes are `PUBLIC', `ALIGN=1', no class, - no overlay, and `USE16'. - - 7.4.2 `GROUP': Defining Groups of Segments - - The `obj' format also allows segments to be grouped, so that a - single segment register can be used to refer to all the segments in - a group. NASM therefore supplies the `GROUP' directive, whereby you - can code - - segment data - - ; some data - - segment bss - - ; some uninitialized data - - group dgroup data bss - - which will define a group called `dgroup' to contain the segments - `data' and `bss'. Like `SEGMENT', `GROUP' causes the group name to - be defined as a symbol, so that you can refer to a variable `var' in - the `data' segment as `var wrt data' or as `var wrt dgroup', - depending on which segment value is currently in your segment - register. - - If you just refer to `var', however, and `var' is declared in a - segment which is part of a group, then NASM will default to giving - you the offset of `var' from the beginning of the _group_, not the - _segment_. Therefore `SEG var', also, will return the group base - rather than the segment base. - - NASM will allow a segment to be part of more than one group, but - will generate a warning if you do this. Variables declared in a - segment which is part of more than one group will default to being - relative to the first group that was defined to contain the segment. - - A group does not have to contain any segments; you can still make - `WRT' references to a group which does not contain the variable you - are referring to. OS/2, for example, defines the special group - `FLAT' with no segments in it. - - 7.4.3 `UPPERCASE': Disabling Case Sensitivity in Output - - Although NASM itself is case sensitive, some OMF linkers are not; - therefore it can be useful for NASM to output single-case object - files. The `UPPERCASE' format-specific directive causes all segment, - group and symbol names that are written to the object file to be - forced to upper case just before being written. Within a source - file, NASM is still case-sensitive; but the object file can be - written entirely in upper case if desired. - - `UPPERCASE' is used alone on a line; it requires no parameters. - - 7.4.4 `IMPORT': Importing DLL Symbols - - The `IMPORT' format-specific directive defines a symbol to be - imported from a DLL, for use if you are writing a DLL's import - library in NASM. You still need to declare the symbol as `EXTERN' as - well as using the `IMPORT' directive. - - The `IMPORT' directive takes two required parameters, separated by - white space, which are (respectively) the name of the symbol you - wish to import and the name of the library you wish to import it - from. For example: - - import WSAStartup wsock32.dll - - A third optional parameter gives the name by which the symbol is - known in the library you are importing it from, in case this is not - the same as the name you wish the symbol to be known by to your code - once you have imported it. For example: - - import asyncsel wsock32.dll WSAAsyncSelect - - 7.4.5 `EXPORT': Exporting DLL Symbols - - The `EXPORT' format-specific directive defines a global symbol to be - exported as a DLL symbol, for use if you are writing a DLL in NASM. - You still need to declare the symbol as `GLOBAL' as well as using - the `EXPORT' directive. - - `EXPORT' takes one required parameter, which is the name of the - symbol you wish to export, as it was defined in your source file. An - optional second parameter (separated by white space from the first) - gives the _external_ name of the symbol: the name by which you wish - the symbol to be known to programs using the DLL. If this name is - the same as the internal name, you may leave the second parameter - off. - - Further parameters can be given to define attributes of the exported - symbol. These parameters, like the second, are separated by white - space. If further parameters are given, the external name must also - be specified, even if it is the same as the internal name. The - available attributes are: - - (*) `resident' indicates that the exported name is to be kept - resident by the system loader. This is an optimisation for - frequently used symbols imported by name. - - (*) `nodata' indicates that the exported symbol is a function which - does not make use of any initialized data. - - (*) `parm=NNN', where `NNN' is an integer, sets the number of - parameter words for the case in which the symbol is a call gate - between 32-bit and 16-bit segments. - - (*) An attribute which is just a number indicates that the symbol - should be exported with an identifying number (ordinal), and - gives the desired number. - - For example: - - export myfunc - export myfunc TheRealMoreFormalLookingFunctionName - export myfunc myfunc 1234 ; export by ordinal - export myfunc myfunc resident parm=23 nodata - - 7.4.6 `..start': Defining the Program Entry Point - - `OMF' linkers require exactly one of the object files being linked - to define the program entry point, where execution will begin when - the program is run. If the object file that defines the entry point - is assembled using NASM, you specify the entry point by declaring - the special symbol `..start' at the point where you wish execution - to begin. - - 7.4.7 `obj' Extensions to the `EXTERN' Directive - - If you declare an external symbol with the directive - - extern foo - - then references such as `mov ax,foo' will give you the offset of - `foo' from its preferred segment base (as specified in whichever - module `foo' is actually defined in). So to access the contents of - `foo' you will usually need to do something like - - mov ax,seg foo ; get preferred segment base - mov es,ax ; move it into ES - mov ax,[es:foo] ; and use offset `foo' from it - - This is a little unwieldy, particularly if you know that an external - is going to be accessible from a given segment or group, say - `dgroup'. So if `DS' already contained `dgroup', you could simply - code - - mov ax,[foo wrt dgroup] - - However, having to type this every time you want to access `foo' can - be a pain; so NASM allows you to declare `foo' in the alternative - form - - extern foo:wrt dgroup - - This form causes NASM to pretend that the preferred segment base of - `foo' is in fact `dgroup'; so the expression `seg foo' will now - return `dgroup', and the expression `foo' is equivalent to - `foo wrt dgroup'. - - This default-`WRT' mechanism can be used to make externals appear to - be relative to any group or segment in your program. It can also be - applied to common variables: see section 7.4.8. - - 7.4.8 `obj' Extensions to the `COMMON' Directive - - The `obj' format allows common variables to be either near or far; - NASM allows you to specify which your variables should be by the use - of the syntax - - common nearvar 2:near ; `nearvar' is a near common - common farvar 10:far ; and `farvar' is far - - Far common variables may be greater in size than 64Kb, and so the - OMF specification says that they are declared as a number of - _elements_ of a given size. So a 10-byte far common variable could - be declared as ten one-byte elements, five two-byte elements, two - five-byte elements or one ten-byte element. - - Some `OMF' linkers require the element size, as well as the variable - size, to match when resolving common variables declared in more than - one module. Therefore NASM must allow you to specify the element - size on your far common variables. This is done by the following - syntax: - - common c_5by2 10:far 5 ; two five-byte elements - common c_2by5 10:far 2 ; five two-byte elements - - If no element size is specified, the default is 1. Also, the `FAR' - keyword is not required when an element size is specified, since - only far commons may have element sizes at all. So the above - declarations could equivalently be - - common c_5by2 10:5 ; two five-byte elements - common c_2by5 10:2 ; five two-byte elements - - In addition to these extensions, the `COMMON' directive in `obj' - also supports default-`WRT' specification like `EXTERN' does - (explained in section 7.4.7). So you can also declare things like - - common foo 10:wrt dgroup - common bar 16:far 2:wrt data - common baz 24:wrt data:6 - - 7.5 `win32': Microsoft Win32 Object Files - - The `win32' output format generates Microsoft Win32 object files, - suitable for passing to Microsoft linkers such as Visual C++. Note - that Borland Win32 compilers do not use this format, but use `obj' - instead (see section 7.4). - - `win32' provides a default output file-name extension of `.obj'. - - Note that although Microsoft say that Win32 object files follow the - `COFF' (Common Object File Format) standard, the object files - produced by Microsoft Win32 compilers are not compatible with COFF - linkers such as DJGPP's, and vice versa. This is due to a difference - of opinion over the precise semantics of PC-relative relocations. To - produce COFF files suitable for DJGPP, use NASM's `coff' output - format; conversely, the `coff' format does not produce object files - that Win32 linkers can generate correct output from. - - 7.5.1 `win32' Extensions to the `SECTION' Directive - - Like the `obj' format, `win32' allows you to specify additional - information on the `SECTION' directive line, to control the type and - properties of sections you declare. Section types and properties are - generated automatically by NASM for the standard section names - `.text', `.data' and `.bss', but may still be overridden by these - qualifiers. - - The available qualifiers are: - - (*) `code', or equivalently `text', defines the section to be a code - section. This marks the section as readable and executable, but - not writable, and also indicates to the linker that the type of - the section is code. - - (*) `data' and `bss' define the section to be a data section, - analogously to `code'. Data sections are marked as readable and - writable, but not executable. `data' declares an initialized - data section, whereas `bss' declares an uninitialized data - section. - - (*) `rdata' declares an initialized data section that is readable - but not writable. Microsoft compilers use this section to place - constants in it. - - (*) `info' defines the section to be an informational section, which - is not included in the executable file by the linker, but may - (for example) pass information _to_ the linker. For example, - declaring an `info'-type section called `.drectve' causes the - linker to interpret the contents of the section as command-line - options. - - (*) `align=', used with a trailing number as in `obj', gives the - alignment requirements of the section. The maximum you may - specify is 64: the Win32 object file format contains no means to - request a greater section alignment than this. If alignment is - not explicitly specified, the defaults are 16-byte alignment for - code sections, 8-byte alignment for rdata sections and 4-byte - alignment for data (and BSS) sections. Informational sections - get a default alignment of 1 byte (no alignment), though the - value does not matter. - - The defaults assumed by NASM if you do not specify the above - qualifiers are: - - section .text code align=16 - section .data data align=4 - section .rdata rdata align=8 - section .bss bss align=4 - - Any other section name is treated by default like `.text'. - - 7.5.2 `win32': Safe Structured Exception Handling - - Among other improvements in Windows XP SP2 and Windows Server 2003 - Microsoft has introduced concept of "safe structured exception - handling." General idea is to collect handlers' entry points in - designated read-only table and have alleged entry point verified - against this table prior exception control is passed to the handler. - In order for an executable module to be equipped with such "safe - exception handler table," all object modules on linker command line - has to comply with certain criteria. If one single module among them - does not, then the table in question is omitted and above mentioned - run-time checks will not be performed for application in question. - Table omission is by default silent and therefore can be easily - overlooked. One can instruct linker to refuse to produce binary - without such table by passing `/safeseh' command line option. - - Without regard to this run-time check merits it's natural to expect - NASM to be capable of generating modules suitable for `/safeseh' - linking. From developer's viewpoint the problem is two-fold: - - (*) how to adapt modules not deploying exception handlers of their - own; - - (*) how to adapt/develop modules utilizing custom exception - handling; - - Former can be easily achieved with any NASM version by adding - following line to source code: - - $@feat.00 equ 1 - - As of version 2.03 NASM adds this absolute symbol automatically. If - it's not already present to be precise. I.e. if for whatever reason - developer would choose to assign another value in source file, it - would still be perfectly possible. - - Registering custom exception handler on the other hand requires - certain "magic." As of version 2.03 additional directive is - implemented, `safeseh', which instructs the assembler to produce - appropriately formatted input data for above mentioned "safe - exception handler table." Its typical use would be: - - section .text - extern _MessageBoxA@16 - %if __NASM_VERSION_ID__ >= 0x02030000 - safeseh handler ; register handler as "safe handler" - %endif - handler: - push DWORD 1 ; MB_OKCANCEL - push DWORD caption - push DWORD text - push DWORD 0 - call _MessageBoxA@16 - sub eax,1 ; incidentally suits as return value - ; for exception handler - ret - global _main - _main: - push DWORD handler - push DWORD [fs:0] - mov DWORD [fs:0],esp ; engage exception handler - xor eax,eax - mov eax,DWORD[eax] ; cause exception - pop DWORD [fs:0] ; disengage exception handler - add esp,4 - ret - text: db 'OK to rethrow, CANCEL to generate core dump',0 - caption:db 'SEGV',0 - - section .drectve info - db '/defaultlib:user32.lib /defaultlib:msvcrt.lib ' - - As you might imagine, it's perfectly possible to produce .exe binary - with "safe exception handler table" and yet engage unregistered - exception handler. Indeed, handler is engaged by simply manipulating - `[fs:0]' location at run-time, something linker has no power over, - run-time that is. It should be explicitly mentioned that such - failure to register handler's entry point with `safeseh' directive - has undesired side effect at run-time. If exception is raised and - unregistered handler is to be executed, the application is abruptly - terminated without any notification whatsoever. One can argue that - system could at least have logged some kind "non-safe exception - handler in x.exe at address n" message in event log, but no, - literally no notification is provided and user is left with no clue - on what caused application failure. - - Finally, all mentions of linker in this paragraph refer to Microsoft - linker version 7.x and later. Presence of `@feat.00' symbol and - input data for "safe exception handler table" causes no backward - incompatibilities and "safeseh" modules generated by NASM 2.03 and - later can still be linked by earlier versions or non-Microsoft - linkers. - - 7.6 `win64': Microsoft Win64 Object Files - - The `win64' output format generates Microsoft Win64 object files, - which is nearly 100% identical to the `win32' object format (section - 7.5) with the exception that it is meant to target 64-bit code and - the x86-64 platform altogether. This object file is used exactly the - same as the `win32' object format (section 7.5), in NASM, with - regard to this exception. - - 7.6.1 `win64': Writing Position-Independent Code - - While `REL' takes good care of RIP-relative addressing, there is one - aspect that is easy to overlook for a Win64 programmer: indirect - references. Consider a switch dispatch table: - - jmp QWORD[dsptch+rax*8] - ... - dsptch: dq case0 - dq case1 - ... - - Even novice Win64 assembler programmer will soon realize that the - code is not 64-bit savvy. Most notably linker will refuse to link it - with - "`'ADDR32' relocation to '.text' invalid without /LARGEADDRESSAWARE:NO'". - So [s]he will have to split jmp instruction as following: - - lea rbx,[rel dsptch] - jmp QWORD[rbx+rax*8] - - What happens behind the scene is that effective address in `lea' is - encoded relative to instruction pointer, or in perfectly position- - independent manner. But this is only part of the problem! Trouble is - that in .dll context `caseN' relocations will make their way to the - final module and might have to be adjusted at .dll load time. To be - specific when it can't be loaded at preferred address. And when this - occurs, pages with such relocations will be rendered private to - current process, which kind of undermines the idea of sharing .dll. - But no worry, it's trivial to fix: - - lea rbx,[rel dsptch] - add rbx,QWORD[rbx+rax*8] - jmp rbx - ... - dsptch: dq case0-dsptch - dq case1-dsptch - ... - - NASM version 2.03 and later provides another alternative, - `wrt ..imagebase' operator, which returns offset from base address - of the current image, be it .exe or .dll module, therefore the name. - For those acquainted with PE-COFF format base address denotes start - of `IMAGE_DOS_HEADER' structure. Here is how to implement switch - with these image-relative references: - - lea rbx,[rel dsptch] - mov eax,DWORD[rbx+rax*4] - sub rbx,dsptch wrt ..imagebase - add rbx,rax - jmp rbx - ... - dsptch: dd case0 wrt ..imagebase - dd case1 wrt ..imagebase - - One can argue that the operator is redundant. Indeed, snippet before - last works just fine with any NASM version and is not even Windows - specific... The real reason for implementing `wrt ..imagebase' will - become apparent in next paragraph. - - It should be noted that `wrt ..imagebase' is defined as 32-bit - operand only: - - dd label wrt ..imagebase ; ok - dq label wrt ..imagebase ; bad - mov eax,label wrt ..imagebase ; ok - mov rax,label wrt ..imagebase ; bad - - 7.6.2 `win64': Structured Exception Handling - - Structured exception handing in Win64 is completely different matter - from Win32. Upon exception program counter value is noted, and - linker-generated table comprising start and end addresses of all the - functions [in given executable module] is traversed and compared to - the saved program counter. Thus so called `UNWIND_INFO' structure is - identified. If it's not found, then offending subroutine is assumed - to be "leaf" and just mentioned lookup procedure is attempted for - its caller. In Win64 leaf function is such function that does not - call any other function _nor_ modifies any Win64 non-volatile - registers, including stack pointer. The latter ensures that it's - possible to identify leaf function's caller by simply pulling the - value from the top of the stack. - - While majority of subroutines written in assembler are not calling - any other function, requirement for non-volatile registers' - immutability leaves developer with not more than 7 registers and no - stack frame, which is not necessarily what [s]he counted with. - Customarily one would meet the requirement by saving non-volatile - registers on stack and restoring them upon return, so what can go - wrong? If [and only if] an exception is raised at run-time and no - `UNWIND_INFO' structure is associated with such "leaf" function, the - stack unwind procedure will expect to find caller's return address - on the top of stack immediately followed by its frame. Given that - developer pushed caller's non-volatile registers on stack, would the - value on top point at some code segment or even addressable space? - Well, developer can attempt copying caller's return address to the - top of stack and this would actually work in some very specific - circumstances. But unless developer can guarantee that these - circumstances are always met, it's more appropriate to assume worst - case scenario, i.e. stack unwind procedure going berserk. Relevant - question is what happens then? Application is abruptly terminated - without any notification whatsoever. Just like in Win32 case, one - can argue that system could at least have logged "unwind procedure - went berserk in x.exe at address n" in event log, but no, no trace - of failure is left. - - Now, when we understand significance of the `UNWIND_INFO' structure, - let's discuss what's in it and/or how it's processed. First of all - it is checked for presence of reference to custom language-specific - exception handler. If there is one, then it's invoked. Depending on - the return value, execution flow is resumed (exception is said to be - "handled"), _or_ rest of `UNWIND_INFO' structure is processed as - following. Beside optional reference to custom handler, it carries - information about current callee's stack frame and where non- - volatile registers are saved. Information is detailed enough to be - able to reconstruct contents of caller's non-volatile registers upon - call to current callee. And so caller's context is reconstructed, - and then unwind procedure is repeated, i.e. another `UNWIND_INFO' - structure is associated, this time, with caller's instruction - pointer, which is then checked for presence of reference to - language-specific handler, etc. The procedure is recursively - repeated till exception is handled. As last resort system "handles" - it by generating memory core dump and terminating the application. - - As for the moment of this writing NASM unfortunately does not - facilitate generation of above mentioned detailed information about - stack frame layout. But as of version 2.03 it implements building - blocks for generating structures involved in stack unwinding. As - simplest example, here is how to deploy custom exception handler for - leaf function: - - default rel - section .text - extern MessageBoxA - handler: - sub rsp,40 - mov rcx,0 - lea rdx,[text] - lea r8,[caption] - mov r9,1 ; MB_OKCANCEL - call MessageBoxA - sub eax,1 ; incidentally suits as return value - ; for exception handler - add rsp,40 - ret - global main - main: - xor rax,rax - mov rax,QWORD[rax] ; cause exception - ret - main_end: - text: db 'OK to rethrow, CANCEL to generate core dump',0 - caption:db 'SEGV',0 - - section .pdata rdata align=4 - dd main wrt ..imagebase - dd main_end wrt ..imagebase - dd xmain wrt ..imagebase - section .xdata rdata align=8 - xmain: db 9,0,0,0 - dd handler wrt ..imagebase - section .drectve info - db '/defaultlib:user32.lib /defaultlib:msvcrt.lib ' - - What you see in `.pdata' section is element of the "table comprising - start and end addresses of function" along with reference to - associated `UNWIND_INFO' structure. And what you see in `.xdata' - section is `UNWIND_INFO' structure describing function with no - frame, but with designated exception handler. References are - _required_ to be image-relative (which is the real reason for - implementing `wrt ..imagebase' operator). It should be noted that - `rdata align=n', as well as `wrt ..imagebase', are optional in these - two segments' contexts, i.e. can be omitted. Latter means that _all_ - 32-bit references, not only above listed required ones, placed into - these two segments turn out image-relative. Why is it important to - understand? Developer is allowed to append handler-specific data to - `UNWIND_INFO' structure, and if [s]he adds a 32-bit reference, then - [s]he will have to remember to adjust its value to obtain the real - pointer. - - As already mentioned, in Win64 terms leaf function is one that does - not call any other function _nor_ modifies any non-volatile - register, including stack pointer. But it's not uncommon that - assembler programmer plans to utilize every single register and - sometimes even have variable stack frame. Is there anything one can - do with bare building blocks? I.e. besides manually composing fully- - fledged `UNWIND_INFO' structure, which would surely be considered - error-prone? Yes, there is. Recall that exception handler is called - first, before stack layout is analyzed. As it turned out, it's - perfectly possible to manipulate current callee's context in custom - handler in manner that permits further stack unwinding. General idea - is that handler would not actually "handle" the exception, but - instead restore callee's context, as it was at its entry point and - thus mimic leaf function. In other words, handler would simply - undertake part of unwinding procedure. Consider following example: - - function: - mov rax,rsp ; copy rsp to volatile register - push r15 ; save non-volatile registers - push rbx - push rbp - mov r11,rsp ; prepare variable stack frame - sub r11,rcx - and r11,-64 - mov QWORD[r11],rax ; check for exceptions - mov rsp,r11 ; allocate stack frame - mov QWORD[rsp],rax ; save original rsp value - magic_point: - ... - mov r11,QWORD[rsp] ; pull original rsp value - mov rbp,QWORD[r11-24] - mov rbx,QWORD[r11-16] - mov r15,QWORD[r11-8] - mov rsp,r11 ; destroy frame - ret - - The keyword is that up to `magic_point' original `rsp' value remains - in chosen volatile register and no non-volatile register, except for - `rsp', is modified. While past `magic_point' `rsp' remains constant - till the very end of the `function'. In this case custom language- - specific exception handler would look like this: - - EXCEPTION_DISPOSITION handler (EXCEPTION_RECORD *rec,ULONG64 frame, - CONTEXT *context,DISPATCHER_CONTEXT *disp) - { ULONG64 *rsp; - if (context->Rip<(ULONG64)magic_point) - rsp = (ULONG64 *)context->Rax; - else - { rsp = ((ULONG64 **)context->Rsp)[0]; - context->Rbp = rsp[-3]; - context->Rbx = rsp[-2]; - context->R15 = rsp[-1]; - } - context->Rsp = (ULONG64)rsp; - - memcpy (disp->ContextRecord,context,sizeof(CONTEXT)); - RtlVirtualUnwind(UNW_FLAG_NHANDLER,disp->ImageBase, - dips->ControlPc,disp->FunctionEntry,disp->ContextRecord, - &disp->HandlerData,&disp->EstablisherFrame,NULL); - return ExceptionContinueSearch; - } - - As custom handler mimics leaf function, corresponding `UNWIND_INFO' - structure does not have to contain any information about stack frame - and its layout. - - 7.7 `coff': Common Object File Format - - The `coff' output type produces `COFF' object files suitable for - linking with the DJGPP linker. - - `coff' provides a default output file-name extension of `.o'. - - The `coff' format supports the same extensions to the `SECTION' - directive as `win32' does, except that the `align' qualifier and the - `info' section type are not supported. - - 7.8 `macho32' and `macho64': Mach Object File Format - - The `macho32' and `macho64' output formts produces `Mach-O' object - files suitable for linking with the MacOS X linker. `macho' is a - synonym for `macho32'. - - `macho' provides a default output file-name extension of `.o'. - - 7.9 `elf32' and `elf64': Executable and Linkable Format Object Files - - The `elf32' and `elf64' output formats generate `ELF32 and ELF64' - (Executable and Linkable Format) object files, as used by Linux as - well as Unix System V, including Solaris x86, UnixWare and SCO Unix. - `elf' provides a default output file-name extension of `.o'. `elf' - is a synonym for `elf32'. - - 7.9.1 ELF specific directive `osabi' - - The ELF header specifies the application binary interface for the - target operating system (OSABI). This field can be set by using the - `osabi' directive with the numeric value (0-255) of the target - system. If this directive is not used, the default value will be - "UNIX System V ABI" (0) which will work on most systems which - support ELF. - - 7.9.2 `elf' Extensions to the `SECTION' Directive - - Like the `obj' format, `elf' allows you to specify additional - information on the `SECTION' directive line, to control the type and - properties of sections you declare. Section types and properties are - generated automatically by NASM for the standard section names, but - may still be overridden by these qualifiers. - - The available qualifiers are: - - (*) `alloc' defines the section to be one which is loaded into - memory when the program is run. `noalloc' defines it to be one - which is not, such as an informational or comment section. - - (*) `exec' defines the section to be one which should have execute - permission when the program is run. `noexec' defines it as one - which should not. - - (*) `write' defines the section to be one which should be writable - when the program is run. `nowrite' defines it as one which - should not. - - (*) `progbits' defines the section to be one with explicit contents - stored in the object file: an ordinary code or data section, for - example, `nobits' defines the section to be one with no explicit - contents given, such as a BSS section. - - (*) `align=', used with a trailing number as in `obj', gives the - alignment requirements of the section. - - (*) `tls' defines the section to be one which contains thread local - variables. - - The defaults assumed by NASM if you do not specify the above - qualifiers are: - - - section .text progbits alloc exec nowrite align=16 - section .rodata progbits alloc noexec nowrite align=4 - section .lrodata progbits alloc noexec nowrite align=4 - section .data progbits alloc noexec write align=4 - section .ldata progbits alloc noexec write align=4 - section .bss nobits alloc noexec write align=4 - section .lbss nobits alloc noexec write align=4 - section .tdata progbits alloc noexec write align=4 tls - section .tbss nobits alloc noexec write align=4 tls - section .comment progbits noalloc noexec nowrite align=1 - section other progbits alloc noexec nowrite align=1 - - (Any section name other than those in the above table is treated by - default like `other' in the above table. Please note that section - names are case sensitive.) - - 7.9.3 Position-Independent Code: `elf' Special Symbols and `WRT' - - The `ELF' specification contains enough features to allow position- - independent code (PIC) to be written, which makes ELF shared - libraries very flexible. However, it also means NASM has to be able - to generate a variety of ELF specific relocation types in ELF object - files, if it is to be an assembler which can write PIC. - - Since `ELF' does not support segment-base references, the `WRT' - operator is not used for its normal purpose; therefore NASM's `elf' - output format makes use of `WRT' for a different purpose, namely the - PIC-specific relocation types. - - `elf' defines five special symbols which you can use as the right- - hand side of the `WRT' operator to obtain PIC relocation types. They - are `..gotpc', `..gotoff', `..got', `..plt' and `..sym'. Their - functions are summarized here: - - (*) Referring to the symbol marking the global offset table base - using `wrt ..gotpc' will end up giving the distance from the - beginning of the current section to the global offset table. - (`_GLOBAL_OFFSET_TABLE_' is the standard symbol name used to - refer to the GOT.) So you would then need to add `$$' to the - result to get the real address of the GOT. - - (*) Referring to a location in one of your own sections using - `wrt ..gotoff' will give the distance from the beginning of the - GOT to the specified location, so that adding on the address of - the GOT would give the real address of the location you wanted. - - (*) Referring to an external or global symbol using `wrt ..got' - causes the linker to build an entry _in_ the GOT containing the - address of the symbol, and the reference gives the distance from - the beginning of the GOT to the entry; so you can add on the - address of the GOT, load from the resulting address, and end up - with the address of the symbol. - - (*) Referring to a procedure name using `wrt ..plt' causes the - linker to build a procedure linkage table entry for the symbol, - and the reference gives the address of the PLT entry. You can - only use this in contexts which would generate a PC-relative - relocation normally (i.e. as the destination for `CALL' or - `JMP'), since ELF contains no relocation type to refer to PLT - entries absolutely. - - (*) Referring to a symbol name using `wrt ..sym' causes NASM to - write an ordinary relocation, but instead of making the - relocation relative to the start of the section and then adding - on the offset to the symbol, it will write a relocation record - aimed directly at the symbol in question. The distinction is a - necessary one due to a peculiarity of the dynamic linker. - - A fuller explanation of how to use these relocation types to write - shared libraries entirely in NASM is given in section 9.2. - - 7.9.4 Thread Local Storage: `elf' Special Symbols and `WRT' - - (*) In ELF32 mode, referring to an external or global symbol using - `wrt ..tlsie' causes the linker to build an entry _in_ the GOT - containing the offset of the symbol within the TLS block, so you - can access the value of the symbol with code such as: - - mov eax,[tid wrt ..tlsie] - mov [gs:eax],ebx - - (*) In ELF64 mode, referring to an external or global symbol using - `wrt ..gottpoff' causes the linker to build an entry _in_ the - GOT containing the offset of the symbol within the TLS block, so - you can access the value of the symbol with code such as: - - mov rax,[rel tid wrt ..gottpoff] - mov rcx,[fs:rax] - - 7.9.5 `elf' Extensions to the `GLOBAL' Directive - - `ELF' object files can contain more information about a global - symbol than just its address: they can contain the size of the - symbol and its type as well. These are not merely debugger - conveniences, but are actually necessary when the program being - written is a shared library. NASM therefore supports some extensions - to the `GLOBAL' directive, allowing you to specify these features. - - You can specify whether a global variable is a function or a data - object by suffixing the name with a colon and the word `function' or - `data'. (`object' is a synonym for `data'.) For example: - - global hashlookup:function, hashtable:data - - exports the global symbol `hashlookup' as a function and `hashtable' - as a data object. - - Optionally, you can control the ELF visibility of the symbol. Just - add one of the visibility keywords: `default', `internal', `hidden', - or `protected'. The default is `default' of course. For example, to - make `hashlookup' hidden: - - global hashlookup:function hidden - - You can also specify the size of the data associated with the - symbol, as a numeric expression (which may involve labels, and even - forward references) after the type specifier. Like this: - - global hashtable:data (hashtable.end - hashtable) - - hashtable: - db this,that,theother ; some data here - .end: - - This makes NASM automatically calculate the length of the table and - place that information into the `ELF' symbol table. - - Declaring the type and size of global symbols is necessary when - writing shared library code. For more information, see section - 9.2.4. - - 7.9.6 `elf' Extensions to the `COMMON' Directive - - `ELF' also allows you to specify alignment requirements on common - variables. This is done by putting a number (which must be a power - of two) after the name and size of the common variable, separated - (as usual) by a colon. For example, an array of doublewords would - benefit from 4-byte alignment: - - common dwordarray 128:4 - - This declares the total size of the array to be 128 bytes, and - requires that it be aligned on a 4-byte boundary. - - 7.9.7 16-bit code and ELF - - The `ELF32' specification doesn't provide relocations for 8- and 16- - bit values, but the GNU `ld' linker adds these as an extension. NASM - can generate GNU-compatible relocations, to allow 16-bit code to be - linked as ELF using GNU `ld'. If NASM is used with the - `-w+gnu-elf-extensions' option, a warning is issued when one of - these relocations is generated. - - 7.9.8 Debug formats and ELF - - `ELF32' and `ELF64' provide debug information in `STABS' and `DWARF' - formats. Line number information is generated for all executable - sections, but please note that only the ".text" section is - executable by default. - - 7.10 `aout': Linux `a.out' Object Files - - The `aout' format generates `a.out' object files, in the form used - by early Linux systems (current Linux systems use ELF, see section - 7.9.) These differ from other `a.out' object files in that the magic - number in the first four bytes of the file is different; also, some - implementations of `a.out', for example NetBSD's, support position- - independent code, which Linux's implementation does not. - - `a.out' provides a default output file-name extension of `.o'. - - `a.out' is a very simple object format. It supports no special - directives, no special symbols, no use of `SEG' or `WRT', and no - extensions to any standard directives. It supports only the three - standard section names `.text', `.data' and `.bss'. - - 7.11 `aoutb': NetBSD/FreeBSD/OpenBSD `a.out' Object Files - - The `aoutb' format generates `a.out' object files, in the form used - by the various free `BSD Unix' clones, `NetBSD', `FreeBSD' and - `OpenBSD'. For simple object files, this object format is exactly - the same as `aout' except for the magic number in the first four - bytes of the file. However, the `aoutb' format supports - position-independent code in the same way as the `elf' format, so - you can use it to write `BSD' shared libraries. - - `aoutb' provides a default output file-name extension of `.o'. - - `aoutb' supports no special directives, no special symbols, and only - the three standard section names `.text', `.data' and `.bss'. - However, it also supports the same use of `WRT' as `elf' does, to - provide position-independent code relocation types. See section - 7.9.3 for full documentation of this feature. - - `aoutb' also supports the same extensions to the `GLOBAL' directive - as `elf' does: see section 7.9.5 for documentation of this. - - 7.12 `as86': Minix/Linux `as86' Object Files - - The Minix/Linux 16-bit assembler `as86' has its own non-standard - object file format. Although its companion linker `ld86' produces - something close to ordinary `a.out' binaries as output, the object - file format used to communicate between `as86' and `ld86' is not - itself `a.out'. - - NASM supports this format, just in case it is useful, as `as86'. - `as86' provides a default output file-name extension of `.o'. - - `as86' is a very simple object format (from the NASM user's point of - view). It supports no special directives, no use of `SEG' or `WRT', - and no extensions to any standard directives. It supports only the - three standard section names `.text', `.data' and `.bss'. The only - special symbol supported is `..start'. - - 7.13 `rdf': Relocatable Dynamic Object File Format - - The `rdf' output format produces `RDOFF' object files. `RDOFF' - (Relocatable Dynamic Object File Format) is a home-grown object-file - format, designed alongside NASM itself and reflecting in its file - format the internal structure of the assembler. - - `RDOFF' is not used by any well-known operating systems. Those - writing their own systems, however, may well wish to use `RDOFF' as - their object format, on the grounds that it is designed primarily - for simplicity and contains very little file-header bureaucracy. - - The Unix NASM archive, and the DOS archive which includes sources, - both contain an `rdoff' subdirectory holding a set of RDOFF - utilities: an RDF linker, an `RDF' static-library manager, an RDF - file dump utility, and a program which will load and execute an RDF - executable under Linux. - - `rdf' supports only the standard section names `.text', `.data' and - `.bss'. - -7.13.1 Requiring a Library: The `LIBRARY' Directive - - `RDOFF' contains a mechanism for an object file to demand a given - library to be linked to the module, either at load time or run time. - This is done by the `LIBRARY' directive, which takes one argument - which is the name of the module: - - library mylib.rdl - -7.13.2 Specifying a Module Name: The `MODULE' Directive - - Special `RDOFF' header record is used to store the name of the - module. It can be used, for example, by run-time loader to perform - dynamic linking. `MODULE' directive takes one argument which is the - name of current module: - - module mymodname - - Note that when you statically link modules and tell linker to strip - the symbols from output file, all module names will be stripped too. - To avoid it, you should start module names with `$', like: - - module $kernel.core - -7.13.3 `rdf' Extensions to the `GLOBAL' Directive - - `RDOFF' global symbols can contain additional information needed by - the static linker. You can mark a global symbol as exported, thus - telling the linker do not strip it from target executable or library - file. Like in `ELF', you can also specify whether an exported symbol - is a procedure (function) or data object. - - Suffixing the name with a colon and the word `export' you make the - symbol exported: - - global sys_open:export - - To specify that exported symbol is a procedure (function), you add - the word `proc' or `function' after declaration: - - global sys_open:export proc - - Similarly, to specify exported data object, add the word `data' or - `object' to the directive: - - global kernel_ticks:export data - -7.13.4 `rdf' Extensions to the `EXTERN' Directive - - By default the `EXTERN' directive in `RDOFF' declares a "pure - external" symbol (i.e. the static linker will complain if such a - symbol is not resolved). To declare an "imported" symbol, which must - be resolved later during a dynamic linking phase, `RDOFF' offers an - additional `import' modifier. As in `GLOBAL', you can also specify - whether an imported symbol is a procedure (function) or data object. - For example: - - library $libc - extern _open:import - extern _printf:import proc - extern _errno:import data - - Here the directive `LIBRARY' is also included, which gives the - dynamic linker a hint as to where to find requested symbols. - - 7.14 `dbg': Debugging Format - - The `dbg' output format is not built into NASM in the default - configuration. If you are building your own NASM executable from the - sources, you can define `OF_DBG' in `output/outform.h' or on the - compiler command line, and obtain the `dbg' output format. - - The `dbg' format does not output an object file as such; instead, it - outputs a text file which contains a complete list of all the - transactions between the main body of NASM and the output-format - back end module. It is primarily intended to aid people who want to - write their own output drivers, so that they can get a clearer idea - of the various requests the main program makes of the output driver, - and in what order they happen. - - For simple files, one can easily use the `dbg' format like this: - - nasm -f dbg filename.asm - - which will generate a diagnostic file called `filename.dbg'. - However, this will not work well on files which were designed for a - different object format, because each object format defines its own - macros (usually user-level forms of directives), and those macros - will not be defined in the `dbg' format. Therefore it can be useful - to run NASM twice, in order to do the preprocessing with the native - object format selected: - - nasm -e -f rdf -o rdfprog.i rdfprog.asm - nasm -a -f dbg rdfprog.i - - This preprocesses `rdfprog.asm' into `rdfprog.i', keeping the `rdf' - object format selected in order to make sure RDF special directives - are converted into primitive form correctly. Then the preprocessed - source is fed through the `dbg' format to generate the final - diagnostic output. - - This workaround will still typically not work for programs intended - for `obj' format, because the `obj' `SEGMENT' and `GROUP' directives - have side effects of defining the segment and group names as - symbols; `dbg' will not do this, so the program will not assemble. - You will have to work around that by defining the symbols yourself - (using `EXTERN', for example) if you really need to get a `dbg' - trace of an `obj'-specific source file. - - `dbg' accepts any section name and any directives at all, and logs - them all to its output file. - -Chapter 8: Writing 16-bit Code (DOS, Windows 3/3.1) ---------------------------------------------------- - - This chapter attempts to cover some of the common issues encountered - when writing 16-bit code to run under `MS-DOS' or `Windows 3.x'. It - covers how to link programs to produce `.EXE' or `.COM' files, how - to write `.SYS' device drivers, and how to interface assembly - language code with 16-bit C compilers and with Borland Pascal. - - 8.1 Producing `.EXE' Files - - Any large program written under DOS needs to be built as a `.EXE' - file: only `.EXE' files have the necessary internal structure - required to span more than one 64K segment. Windows programs, also, - have to be built as `.EXE' files, since Windows does not support the - `.COM' format. - - In general, you generate `.EXE' files by using the `obj' output - format to produce one or more `.OBJ' files, and then linking them - together using a linker. However, NASM also supports the direct - generation of simple DOS `.EXE' files using the `bin' output format - (by using `DB' and `DW' to construct the `.EXE' file header), and a - macro package is supplied to do this. Thanks to Yann Guidon for - contributing the code for this. - - NASM may also support `.EXE' natively as another output format in - future releases. - - 8.1.1 Using the `obj' Format To Generate `.EXE' Files - - This section describes the usual method of generating `.EXE' files - by linking `.OBJ' files together. - - Most 16-bit programming language packages come with a suitable - linker; if you have none of these, there is a free linker called - VAL, available in `LZH' archive format from `x2ftp.oulu.fi'. An LZH - archiver can be found at `ftp.simtel.net'. There is another `free' - linker (though this one doesn't come with sources) called FREELINK, - available from `www.pcorner.com'. A third, `djlink', written by DJ - Delorie, is available at `www.delorie.com'. A fourth linker, - `ALINK', written by Anthony A.J. Williams, is available at - `alink.sourceforge.net'. - - When linking several `.OBJ' files into a `.EXE' file, you should - ensure that exactly one of them has a start point defined (using the - `..start' special symbol defined by the `obj' format: see section - 7.4.6). If no module defines a start point, the linker will not know - what value to give the entry-point field in the output file header; - if more than one defines a start point, the linker will not know - _which_ value to use. - - An example of a NASM source file which can be assembled to a `.OBJ' - file and linked on its own to a `.EXE' is given here. It - demonstrates the basic principles of defining a stack, initialising - the segment registers, and declaring a start point. This file is - also provided in the `test' subdirectory of the NASM archives, under - the name `objexe.asm'. - - segment code - - ..start: - mov ax,data - mov ds,ax - mov ax,stack - mov ss,ax - mov sp,stacktop - - This initial piece of code sets up `DS' to point to the data - segment, and initializes `SS' and `SP' to point to the top of the - provided stack. Notice that interrupts are implicitly disabled for - one instruction after a move into `SS', precisely for this - situation, so that there's no chance of an interrupt occurring - between the loads of `SS' and `SP' and not having a stack to execute - on. - - Note also that the special symbol `..start' is defined at the - beginning of this code, which means that will be the entry point - into the resulting executable file. - - mov dx,hello - mov ah,9 - int 0x21 - - The above is the main program: load `DS:DX' with a pointer to the - greeting message (`hello' is implicitly relative to the segment - `data', which was loaded into `DS' in the setup code, so the full - pointer is valid), and call the DOS print-string function. - - mov ax,0x4c00 - int 0x21 - - This terminates the program using another DOS system call. - - segment data - - hello: db 'hello, world', 13, 10, '$' - - The data segment contains the string we want to display. - - segment stack stack - resb 64 - stacktop: - - The above code declares a stack segment containing 64 bytes of - uninitialized stack space, and points `stacktop' at the top of it. - The directive `segment stack stack' defines a segment _called_ - `stack', and also of _type_ `STACK'. The latter is not necessary to - the correct running of the program, but linkers are likely to issue - warnings or errors if your program has no segment of type `STACK'. - - The above file, when assembled into a `.OBJ' file, will link on its - own to a valid `.EXE' file, which when run will print `hello, world' - and then exit. - - 8.1.2 Using the `bin' Format To Generate `.EXE' Files - - The `.EXE' file format is simple enough that it's possible to build - a `.EXE' file by writing a pure-binary program and sticking a 32- - byte header on the front. This header is simple enough that it can - be generated using `DB' and `DW' commands by NASM itself, so that - you can use the `bin' output format to directly generate `.EXE' - files. - - Included in the NASM archives, in the `misc' subdirectory, is a file - `exebin.mac' of macros. It defines three macros: `EXE_begin', - `EXE_stack' and `EXE_end'. - - To produce a `.EXE' file using this method, you should start by - using `%include' to load the `exebin.mac' macro package into your - source file. You should then issue the `EXE_begin' macro call (which - takes no arguments) to generate the file header data. Then write - code as normal for the `bin' format - you can use all three standard - sections `.text', `.data' and `.bss'. At the end of the file you - should call the `EXE_end' macro (again, no arguments), which defines - some symbols to mark section sizes, and these symbols are referred - to in the header code generated by `EXE_begin'. - - In this model, the code you end up writing starts at `0x100', just - like a `.COM' file - in fact, if you strip off the 32-byte header - from the resulting `.EXE' file, you will have a valid `.COM' - program. All the segment bases are the same, so you are limited to a - 64K program, again just like a `.COM' file. Note that an `ORG' - directive is issued by the `EXE_begin' macro, so you should not - explicitly issue one of your own. - - You can't directly refer to your segment base value, unfortunately, - since this would require a relocation in the header, and things - would get a lot more complicated. So you should get your segment - base by copying it out of `CS' instead. - - On entry to your `.EXE' file, `SS:SP' are already set up to point to - the top of a 2Kb stack. You can adjust the default stack size of 2Kb - by calling the `EXE_stack' macro. For example, to change the stack - size of your program to 64 bytes, you would call `EXE_stack 64'. - - A sample program which generates a `.EXE' file in this way is given - in the `test' subdirectory of the NASM archive, as `binexe.asm'. - - 8.2 Producing `.COM' Files - - While large DOS programs must be written as `.EXE' files, small ones - are often better written as `.COM' files. `.COM' files are pure - binary, and therefore most easily produced using the `bin' output - format. - - 8.2.1 Using the `bin' Format To Generate `.COM' Files - - `.COM' files expect to be loaded at offset `100h' into their segment - (though the segment may change). Execution then begins at `100h', - i.e. right at the start of the program. So to write a `.COM' - program, you would create a source file looking like - - org 100h - - section .text - - start: - ; put your code here - - section .data - - ; put data items here - - section .bss - - ; put uninitialized data here - - The `bin' format puts the `.text' section first in the file, so you - can declare data or BSS items before beginning to write code if you - want to and the code will still end up at the front of the file - where it belongs. - - The BSS (uninitialized data) section does not take up space in the - `.COM' file itself: instead, addresses of BSS items are resolved to - point at space beyond the end of the file, on the grounds that this - will be free memory when the program is run. Therefore you should - not rely on your BSS being initialized to all zeros when you run. - - To assemble the above program, you should use a command line like - - nasm myprog.asm -fbin -o myprog.com - - The `bin' format would produce a file called `myprog' if no explicit - output file name were specified, so you have to override it and give - the desired file name. - - 8.2.2 Using the `obj' Format To Generate `.COM' Files - - If you are writing a `.COM' program as more than one module, you may - wish to assemble several `.OBJ' files and link them together into a - `.COM' program. You can do this, provided you have a linker capable - of outputting `.COM' files directly (TLINK does this), or - alternatively a converter program such as `EXE2BIN' to transform the - `.EXE' file output from the linker into a `.COM' file. - - If you do this, you need to take care of several things: - - (*) The first object file containing code should start its code - segment with a line like `RESB 100h'. This is to ensure that the - code begins at offset `100h' relative to the beginning of the - code segment, so that the linker or converter program does not - have to adjust address references within the file when - generating the `.COM' file. Other assemblers use an `ORG' - directive for this purpose, but `ORG' in NASM is a format- - specific directive to the `bin' output format, and does not mean - the same thing as it does in MASM-compatible assemblers. - - (*) You don't need to define a stack segment. - - (*) All your segments should be in the same group, so that every - time your code or data references a symbol offset, all offsets - are relative to the same segment base. This is because, when a - `.COM' file is loaded, all the segment registers contain the - same value. - - 8.3 Producing `.SYS' Files - - MS-DOS device drivers - `.SYS' files - are pure binary files, - similar to `.COM' files, except that they start at origin zero - rather than `100h'. Therefore, if you are writing a device driver - using the `bin' format, you do not need the `ORG' directive, since - the default origin for `bin' is zero. Similarly, if you are using - `obj', you do not need the `RESB 100h' at the start of your code - segment. - - `.SYS' files start with a header structure, containing pointers to - the various routines inside the driver which do the work. This - structure should be defined at the start of the code segment, even - though it is not actually code. - - For more information on the format of `.SYS' files, and the data - which has to go in the header structure, a list of books is given in - the Frequently Asked Questions list for the newsgroup - `comp.os.msdos.programmer'. - - 8.4 Interfacing to 16-bit C Programs - - This section covers the basics of writing assembly routines that - call, or are called from, C programs. To do this, you would - typically write an assembly module as a `.OBJ' file, and link it - with your C modules to produce a mixed-language program. - - 8.4.1 External Symbol Names - - C compilers have the convention that the names of all global symbols - (functions or data) they define are formed by prefixing an - underscore to the name as it appears in the C program. So, for - example, the function a C programmer thinks of as `printf' appears - to an assembly language programmer as `_printf'. This means that in - your assembly programs, you can define symbols without a leading - underscore, and not have to worry about name clashes with C symbols. - - If you find the underscores inconvenient, you can define macros to - replace the `GLOBAL' and `EXTERN' directives as follows: - - %macro cglobal 1 - - global _%1 - %define %1 _%1 - - %endmacro - - %macro cextern 1 - - extern _%1 - %define %1 _%1 - - %endmacro - - (These forms of the macros only take one argument at a time; a - `%rep' construct could solve this.) - - If you then declare an external like this: - - cextern printf - - then the macro will expand it as - - extern _printf - %define printf _printf - - Thereafter, you can reference `printf' as if it was a symbol, and - the preprocessor will put the leading underscore on where necessary. - - The `cglobal' macro works similarly. You must use `cglobal' before - defining the symbol in question, but you would have had to do that - anyway if you used `GLOBAL'. - - Also see section 2.1.27. - - 8.4.2 Memory Models - - NASM contains no mechanism to support the various C memory models - directly; you have to keep track yourself of which one you are - writing for. This means you have to keep track of the following - things: - - (*) In models using a single code segment (tiny, small and compact), - functions are near. This means that function pointers, when - stored in data segments or pushed on the stack as function - arguments, are 16 bits long and contain only an offset field - (the `CS' register never changes its value, and always gives the - segment part of the full function address), and that functions - are called using ordinary near `CALL' instructions and return - using `RETN' (which, in NASM, is synonymous with `RET' anyway). - This means both that you should write your own routines to - return with `RETN', and that you should call external C routines - with near `CALL' instructions. - - (*) In models using more than one code segment (medium, large and - huge), functions are far. This means that function pointers are - 32 bits long (consisting of a 16-bit offset followed by a 16-bit - segment), and that functions are called using `CALL FAR' (or - `CALL seg:offset') and return using `RETF'. Again, you should - therefore write your own routines to return with `RETF' and use - `CALL FAR' to call external routines. - - (*) In models using a single data segment (tiny, small and medium), - data pointers are 16 bits long, containing only an offset field - (the `DS' register doesn't change its value, and always gives - the segment part of the full data item address). - - (*) In models using more than one data segment (compact, large and - huge), data pointers are 32 bits long, consisting of a 16-bit - offset followed by a 16-bit segment. You should still be careful - not to modify `DS' in your routines without restoring it - afterwards, but `ES' is free for you to use to access the - contents of 32-bit data pointers you are passed. - - (*) The huge memory model allows single data items to exceed 64K in - size. In all other memory models, you can access the whole of a - data item just by doing arithmetic on the offset field of the - pointer you are given, whether a segment field is present or - not; in huge model, you have to be more careful of your pointer - arithmetic. - - (*) In most memory models, there is a _default_ data segment, whose - segment address is kept in `DS' throughout the program. This - data segment is typically the same segment as the stack, kept in - `SS', so that functions' local variables (which are stored on - the stack) and global data items can both be accessed easily - without changing `DS'. Particularly large data items are - typically stored in other segments. However, some memory models - (though not the standard ones, usually) allow the assumption - that `SS' and `DS' hold the same value to be removed. Be careful - about functions' local variables in this latter case. - - In models with a single code segment, the segment is called `_TEXT', - so your code segment must also go by this name in order to be linked - into the same place as the main code segment. In models with a - single data segment, or with a default data segment, it is called - `_DATA'. - - 8.4.3 Function Definitions and Function Calls - - The C calling convention in 16-bit programs is as follows. In the - following description, the words _caller_ and _callee_ are used to - denote the function doing the calling and the function which gets - called. - - (*) The caller pushes the function's parameters on the stack, one - after another, in reverse order (right to left, so that the - first argument specified to the function is pushed last). - - (*) The caller then executes a `CALL' instruction to pass control to - the callee. This `CALL' is either near or far depending on the - memory model. - - (*) The callee receives control, and typically (although this is not - actually necessary, in functions which do not need to access - their parameters) starts by saving the value of `SP' in `BP' so - as to be able to use `BP' as a base pointer to find its - parameters on the stack. However, the caller was probably doing - this too, so part of the calling convention states that `BP' - must be preserved by any C function. Hence the callee, if it is - going to set up `BP' as a _frame pointer_, must push the - previous value first. - - (*) The callee may then access its parameters relative to `BP'. The - word at `[BP]' holds the previous value of `BP' as it was - pushed; the next word, at `[BP+2]', holds the offset part of the - return address, pushed implicitly by `CALL'. In a small-model - (near) function, the parameters start after that, at `[BP+4]'; - in a large-model (far) function, the segment part of the return - address lives at `[BP+4]', and the parameters begin at `[BP+6]'. - The leftmost parameter of the function, since it was pushed - last, is accessible at this offset from `BP'; the others follow, - at successively greater offsets. Thus, in a function such as - `printf' which takes a variable number of parameters, the - pushing of the parameters in reverse order means that the - function knows where to find its first parameter, which tells it - the number and type of the remaining ones. - - (*) The callee may also wish to decrease `SP' further, so as to - allocate space on the stack for local variables, which will then - be accessible at negative offsets from `BP'. - - (*) The callee, if it wishes to return a value to the caller, should - leave the value in `AL', `AX' or `DX:AX' depending on the size - of the value. Floating-point results are sometimes (depending on - the compiler) returned in `ST0'. - - (*) Once the callee has finished processing, it restores `SP' from - `BP' if it had allocated local stack space, then pops the - previous value of `BP', and returns via `RETN' or `RETF' - depending on memory model. - - (*) When the caller regains control from the callee, the function - parameters are still on the stack, so it typically adds an - immediate constant to `SP' to remove them (instead of executing - a number of slow `POP' instructions). Thus, if a function is - accidentally called with the wrong number of parameters due to a - prototype mismatch, the stack will still be returned to a - sensible state since the caller, which _knows_ how many - parameters it pushed, does the removing. - - It is instructive to compare this calling convention with that for - Pascal programs (described in section 8.5.1). Pascal has a simpler - convention, since no functions have variable numbers of parameters. - Therefore the callee knows how many parameters it should have been - passed, and is able to deallocate them from the stack itself by - passing an immediate argument to the `RET' or `RETF' instruction, so - the caller does not have to do it. Also, the parameters are pushed - in left-to-right order, not right-to-left, which means that a - compiler can give better guarantees about sequence points without - performance suffering. - - Thus, you would define a function in C style in the following way. - The following example is for small model: - - global _myfunc - - _myfunc: - push bp - mov bp,sp - sub sp,0x40 ; 64 bytes of local stack space - mov bx,[bp+4] ; first parameter to function - - ; some more code - - mov sp,bp ; undo "sub sp,0x40" above - pop bp - ret - - For a large-model function, you would replace `RET' by `RETF', and - look for the first parameter at `[BP+6]' instead of `[BP+4]'. Of - course, if one of the parameters is a pointer, then the offsets of - _subsequent_ parameters will change depending on the memory model as - well: far pointers take up four bytes on the stack when passed as a - parameter, whereas near pointers take up two. - - At the other end of the process, to call a C function from your - assembly code, you would do something like this: - - extern _printf - - ; and then, further down... - - push word [myint] ; one of my integer variables - push word mystring ; pointer into my data segment - call _printf - add sp,byte 4 ; `byte' saves space - - ; then those data items... - - segment _DATA - - myint dw 1234 - mystring db 'This number -> %d <- should be 1234',10,0 - - This piece of code is the small-model assembly equivalent of the C - code - - int myint = 1234; - printf("This number -> %d <- should be 1234\n", myint); - - In large model, the function-call code might look more like this. In - this example, it is assumed that `DS' already holds the segment base - of the segment `_DATA'. If not, you would have to initialize it - first. - - push word [myint] - push word seg mystring ; Now push the segment, and... - push word mystring ; ... offset of "mystring" - call far _printf - add sp,byte 6 - - The integer value still takes up one word on the stack, since large - model does not affect the size of the `int' data type. The first - argument (pushed last) to `printf', however, is a data pointer, and - therefore has to contain a segment and offset part. The segment - should be stored second in memory, and therefore must be pushed - first. (Of course, `PUSH DS' would have been a shorter instruction - than `PUSH WORD SEG mystring', if `DS' was set up as the above - example assumed.) Then the actual call becomes a far call, since - functions expect far calls in large model; and `SP' has to be - increased by 6 rather than 4 afterwards to make up for the extra - word of parameters. - - 8.4.4 Accessing Data Items - - To get at the contents of C variables, or to declare variables which - C can access, you need only declare the names as `GLOBAL' or - `EXTERN'. (Again, the names require leading underscores, as stated - in section 8.4.1.) Thus, a C variable declared as `int i' can be - accessed from assembler as - - extern _i - - mov ax,[_i] - - And to declare your own integer variable which C programs can access - as `extern int j', you do this (making sure you are assembling in - the `_DATA' segment, if necessary): - - global _j - - _j dw 0 - - To access a C array, you need to know the size of the components of - the array. For example, `int' variables are two bytes long, so if a - C program declares an array as `int a[10]', you can access `a[3]' by - coding `mov ax,[_a+6]'. (The byte offset 6 is obtained by - multiplying the desired array index, 3, by the size of the array - element, 2.) The sizes of the C base types in 16-bit compilers are: - 1 for `char', 2 for `short' and `int', 4 for `long' and `float', and - 8 for `double'. - - To access a C data structure, you need to know the offset from the - base of the structure to the field you are interested in. You can - either do this by converting the C structure definition into a NASM - structure definition (using `STRUC'), or by calculating the one - offset and using just that. - - To do either of these, you should read your C compiler's manual to - find out how it organizes data structures. NASM gives no special - alignment to structure members in its own `STRUC' macro, so you have - to specify alignment yourself if the C compiler generates it. - Typically, you might find that a structure like - - struct { - char c; - int i; - } foo; - - might be four bytes long rather than three, since the `int' field - would be aligned to a two-byte boundary. However, this sort of - feature tends to be a configurable option in the C compiler, either - using command-line options or `#pragma' lines, so you have to find - out how your own compiler does it. - - 8.4.5 `c16.mac': Helper Macros for the 16-bit C Interface - - Included in the NASM archives, in the `misc' directory, is a file - `c16.mac' of macros. It defines three macros: `proc', `arg' and - `endproc'. These are intended to be used for C-style procedure - definitions, and they automate a lot of the work involved in keeping - track of the calling convention. - - (An alternative, TASM compatible form of `arg' is also now built - into NASM's preprocessor. See section 4.8 for details.) - - An example of an assembly function using the macro set is given - here: - - proc _nearproc - - %$i arg - %$j arg - mov ax,[bp + %$i] - mov bx,[bp + %$j] - add ax,[bx] - - endproc - - This defines `_nearproc' to be a procedure taking two arguments, the - first (`i') an integer and the second (`j') a pointer to an integer. - It returns `i + *j'. - - Note that the `arg' macro has an `EQU' as the first line of its - expansion, and since the label before the macro call gets prepended - to the first line of the expanded macro, the `EQU' works, defining - `%$i' to be an offset from `BP'. A context-local variable is used, - local to the context pushed by the `proc' macro and popped by the - `endproc' macro, so that the same argument name can be used in later - procedures. Of course, you don't _have_ to do that. - - The macro set produces code for near functions (tiny, small and - compact-model code) by default. You can have it generate far - functions (medium, large and huge-model code) by means of coding - `%define FARCODE'. This changes the kind of return instruction - generated by `endproc', and also changes the starting point for the - argument offsets. The macro set contains no intrinsic dependency on - whether data pointers are far or not. - - `arg' can take an optional parameter, giving the size of the - argument. If no size is given, 2 is assumed, since it is likely that - many function parameters will be of type `int'. - - The large-model equivalent of the above function would look like - this: - - %define FARCODE - - proc _farproc - - %$i arg - %$j arg 4 - mov ax,[bp + %$i] - mov bx,[bp + %$j] - mov es,[bp + %$j + 2] - add ax,[bx] - - endproc - - This makes use of the argument to the `arg' macro to define a - parameter of size 4, because `j' is now a far pointer. When we load - from `j', we must load a segment and an offset. - - 8.5 Interfacing to Borland Pascal Programs - - Interfacing to Borland Pascal programs is similar in concept to - interfacing to 16-bit C programs. The differences are: - - (*) The leading underscore required for interfacing to C programs is - not required for Pascal. - - (*) The memory model is always large: functions are far, data - pointers are far, and no data item can be more than 64K long. - (Actually, some functions are near, but only those functions - that are local to a Pascal unit and never called from outside - it. All assembly functions that Pascal calls, and all Pascal - functions that assembly routines are able to call, are far.) - However, all static data declared in a Pascal program goes into - the default data segment, which is the one whose segment address - will be in `DS' when control is passed to your assembly code. - The only things that do not live in the default data segment are - local variables (they live in the stack segment) and dynamically - allocated variables. All data _pointers_, however, are far. - - (*) The function calling convention is different - described below. - - (*) Some data types, such as strings, are stored differently. - - (*) There are restrictions on the segment names you are allowed to - use - Borland Pascal will ignore code or data declared in a - segment it doesn't like the name of. The restrictions are - described below. - - 8.5.1 The Pascal Calling Convention - - The 16-bit Pascal calling convention is as follows. In the following - description, the words _caller_ and _callee_ are used to denote the - function doing the calling and the function which gets called. - - (*) The caller pushes the function's parameters on the stack, one - after another, in normal order (left to right, so that the first - argument specified to the function is pushed first). - - (*) The caller then executes a far `CALL' instruction to pass - control to the callee. - - (*) The callee receives control, and typically (although this is not - actually necessary, in functions which do not need to access - their parameters) starts by saving the value of `SP' in `BP' so - as to be able to use `BP' as a base pointer to find its - parameters on the stack. However, the caller was probably doing - this too, so part of the calling convention states that `BP' - must be preserved by any function. Hence the callee, if it is - going to set up `BP' as a frame pointer, must push the previous - value first. - - (*) The callee may then access its parameters relative to `BP'. The - word at `[BP]' holds the previous value of `BP' as it was - pushed. The next word, at `[BP+2]', holds the offset part of the - return address, and the next one at `[BP+4]' the segment part. - The parameters begin at `[BP+6]'. The rightmost parameter of the - function, since it was pushed last, is accessible at this offset - from `BP'; the others follow, at successively greater offsets. - - (*) The callee may also wish to decrease `SP' further, so as to - allocate space on the stack for local variables, which will then - be accessible at negative offsets from `BP'. - - (*) The callee, if it wishes to return a value to the caller, should - leave the value in `AL', `AX' or `DX:AX' depending on the size - of the value. Floating-point results are returned in `ST0'. - Results of type `Real' (Borland's own custom floating-point data - type, not handled directly by the FPU) are returned in - `DX:BX:AX'. To return a result of type `String', the caller - pushes a pointer to a temporary string before pushing the - parameters, and the callee places the returned string value at - that location. The pointer is not a parameter, and should not be - removed from the stack by the `RETF' instruction. - - (*) Once the callee has finished processing, it restores `SP' from - `BP' if it had allocated local stack space, then pops the - previous value of `BP', and returns via `RETF'. It uses the form - of `RETF' with an immediate parameter, giving the number of - bytes taken up by the parameters on the stack. This causes the - parameters to be removed from the stack as a side effect of the - return instruction. - - (*) When the caller regains control from the callee, the function - parameters have already been removed from the stack, so it needs - to do nothing further. - - Thus, you would define a function in Pascal style, taking two - `Integer'-type parameters, in the following way: - - global myfunc - - myfunc: push bp - mov bp,sp - sub sp,0x40 ; 64 bytes of local stack space - mov bx,[bp+8] ; first parameter to function - mov bx,[bp+6] ; second parameter to function - - ; some more code - - mov sp,bp ; undo "sub sp,0x40" above - pop bp - retf 4 ; total size of params is 4 - - At the other end of the process, to call a Pascal function from your - assembly code, you would do something like this: - - extern SomeFunc - - ; and then, further down... - - push word seg mystring ; Now push the segment, and... - push word mystring ; ... offset of "mystring" - push word [myint] ; one of my variables - call far SomeFunc - - This is equivalent to the Pascal code - - procedure SomeFunc(String: PChar; Int: Integer); - SomeFunc(@mystring, myint); - - 8.5.2 Borland Pascal Segment Name Restrictions - - Since Borland Pascal's internal unit file format is completely - different from `OBJ', it only makes a very sketchy job of actually - reading and understanding the various information contained in a - real `OBJ' file when it links that in. Therefore an object file - intended to be linked to a Pascal program must obey a number of - restrictions: - - (*) Procedures and functions must be in a segment whose name is - either `CODE', `CSEG', or something ending in `_TEXT'. - - (*) initialized data must be in a segment whose name is either - `CONST' or something ending in `_DATA'. - - (*) Uninitialized data must be in a segment whose name is either - `DATA', `DSEG', or something ending in `_BSS'. - - (*) Any other segments in the object file are completely ignored. - `GROUP' directives and segment attributes are also ignored. - - 8.5.3 Using `c16.mac' With Pascal Programs - - The `c16.mac' macro package, described in section 8.4.5, can also be - used to simplify writing functions to be called from Pascal - programs, if you code `%define PASCAL'. This definition ensures that - functions are far (it implies `FARCODE'), and also causes procedure - return instructions to be generated with an operand. - - Defining `PASCAL' does not change the code which calculates the - argument offsets; you must declare your function's arguments in - reverse order. For example: - - %define PASCAL - - proc _pascalproc - - %$j arg 4 - %$i arg - mov ax,[bp + %$i] - mov bx,[bp + %$j] - mov es,[bp + %$j + 2] - add ax,[bx] - - endproc - - This defines the same routine, conceptually, as the example in - section 8.4.5: it defines a function taking two arguments, an - integer and a pointer to an integer, which returns the sum of the - integer and the contents of the pointer. The only difference between - this code and the large-model C version is that `PASCAL' is defined - instead of `FARCODE', and that the arguments are declared in reverse - order. - -Chapter 9: Writing 32-bit Code (Unix, Win32, DJGPP) ---------------------------------------------------- - - This chapter attempts to cover some of the common issues involved - when writing 32-bit code, to run under Win32 or Unix, or to be - linked with C code generated by a Unix-style C compiler such as - DJGPP. It covers how to write assembly code to interface with 32-bit - C routines, and how to write position-independent code for shared - libraries. - - Almost all 32-bit code, and in particular all code running under - `Win32', `DJGPP' or any of the PC Unix variants, runs in _flat_ - memory model. This means that the segment registers and paging have - already been set up to give you the same 32-bit 4Gb address space no - matter what segment you work relative to, and that you should ignore - all segment registers completely. When writing flat-model - application code, you never need to use a segment override or modify - any segment register, and the code-section addresses you pass to - `CALL' and `JMP' live in the same address space as the data-section - addresses you access your variables by and the stack-section - addresses you access local variables and procedure parameters by. - Every address is 32 bits long and contains only an offset part. - - 9.1 Interfacing to 32-bit C Programs - - A lot of the discussion in section 8.4, about interfacing to 16-bit - C programs, still applies when working in 32 bits. The absence of - memory models or segmentation worries simplifies things a lot. - - 9.1.1 External Symbol Names - - Most 32-bit C compilers share the convention used by 16-bit - compilers, that the names of all global symbols (functions or data) - they define are formed by prefixing an underscore to the name as it - appears in the C program. However, not all of them do: the `ELF' - specification states that C symbols do _not_ have a leading - underscore on their assembly-language names. - - The older Linux `a.out' C compiler, all `Win32' compilers, `DJGPP', - and `NetBSD' and `FreeBSD', all use the leading underscore; for - these compilers, the macros `cextern' and `cglobal', as given in - section 8.4.1, will still work. For `ELF', though, the leading - underscore should not be used. - - See also section 2.1.27. - - 9.1.2 Function Definitions and Function Calls - - The C calling convention in 32-bit programs is as follows. In the - following description, the words _caller_ and _callee_ are used to - denote the function doing the calling and the function which gets - called. - - (*) The caller pushes the function's parameters on the stack, one - after another, in reverse order (right to left, so that the - first argument specified to the function is pushed last). - - (*) The caller then executes a near `CALL' instruction to pass - control to the callee. - - (*) The callee receives control, and typically (although this is not - actually necessary, in functions which do not need to access - their parameters) starts by saving the value of `ESP' in `EBP' - so as to be able to use `EBP' as a base pointer to find its - parameters on the stack. However, the caller was probably doing - this too, so part of the calling convention states that `EBP' - must be preserved by any C function. Hence the callee, if it is - going to set up `EBP' as a frame pointer, must push the previous - value first. - - (*) The callee may then access its parameters relative to `EBP'. The - doubleword at `[EBP]' holds the previous value of `EBP' as it - was pushed; the next doubleword, at `[EBP+4]', holds the return - address, pushed implicitly by `CALL'. The parameters start after - that, at `[EBP+8]'. The leftmost parameter of the function, - since it was pushed last, is accessible at this offset from - `EBP'; the others follow, at successively greater offsets. Thus, - in a function such as `printf' which takes a variable number of - parameters, the pushing of the parameters in reverse order means - that the function knows where to find its first parameter, which - tells it the number and type of the remaining ones. - - (*) The callee may also wish to decrease `ESP' further, so as to - allocate space on the stack for local variables, which will then - be accessible at negative offsets from `EBP'. - - (*) The callee, if it wishes to return a value to the caller, should - leave the value in `AL', `AX' or `EAX' depending on the size of - the value. Floating-point results are typically returned in - `ST0'. - - (*) Once the callee has finished processing, it restores `ESP' from - `EBP' if it had allocated local stack space, then pops the - previous value of `EBP', and returns via `RET' (equivalently, - `RETN'). - - (*) When the caller regains control from the callee, the function - parameters are still on the stack, so it typically adds an - immediate constant to `ESP' to remove them (instead of executing - a number of slow `POP' instructions). Thus, if a function is - accidentally called with the wrong number of parameters due to a - prototype mismatch, the stack will still be returned to a - sensible state since the caller, which _knows_ how many - parameters it pushed, does the removing. - - There is an alternative calling convention used by Win32 programs - for Windows API calls, and also for functions called _by_ the - Windows API such as window procedures: they follow what Microsoft - calls the `__stdcall' convention. This is slightly closer to the - Pascal convention, in that the callee clears the stack by passing a - parameter to the `RET' instruction. However, the parameters are - still pushed in right-to-left order. - - Thus, you would define a function in C style in the following way: - - global _myfunc - - _myfunc: - push ebp - mov ebp,esp - sub esp,0x40 ; 64 bytes of local stack space - mov ebx,[ebp+8] ; first parameter to function - - ; some more code - - leave ; mov esp,ebp / pop ebp - ret - - At the other end of the process, to call a C function from your - assembly code, you would do something like this: - - extern _printf - - ; and then, further down... - - push dword [myint] ; one of my integer variables - push dword mystring ; pointer into my data segment - call _printf - add esp,byte 8 ; `byte' saves space - - ; then those data items... - - segment _DATA - - myint dd 1234 - mystring db 'This number -> %d <- should be 1234',10,0 - - This piece of code is the assembly equivalent of the C code - - int myint = 1234; - printf("This number -> %d <- should be 1234\n", myint); - - 9.1.3 Accessing Data Items - - To get at the contents of C variables, or to declare variables which - C can access, you need only declare the names as `GLOBAL' or - `EXTERN'. (Again, the names require leading underscores, as stated - in section 9.1.1.) Thus, a C variable declared as `int i' can be - accessed from assembler as - - extern _i - mov eax,[_i] - - And to declare your own integer variable which C programs can access - as `extern int j', you do this (making sure you are assembling in - the `_DATA' segment, if necessary): - - global _j - _j dd 0 - - To access a C array, you need to know the size of the components of - the array. For example, `int' variables are four bytes long, so if a - C program declares an array as `int a[10]', you can access `a[3]' by - coding `mov ax,[_a+12]'. (The byte offset 12 is obtained by - multiplying the desired array index, 3, by the size of the array - element, 4.) The sizes of the C base types in 32-bit compilers are: - 1 for `char', 2 for `short', 4 for `int', `long' and `float', and 8 - for `double'. Pointers, being 32-bit addresses, are also 4 bytes - long. - - To access a C data structure, you need to know the offset from the - base of the structure to the field you are interested in. You can - either do this by converting the C structure definition into a NASM - structure definition (using `STRUC'), or by calculating the one - offset and using just that. - - To do either of these, you should read your C compiler's manual to - find out how it organizes data structures. NASM gives no special - alignment to structure members in its own `STRUC' macro, so you have - to specify alignment yourself if the C compiler generates it. - Typically, you might find that a structure like - - struct { - char c; - int i; - } foo; - - might be eight bytes long rather than five, since the `int' field - would be aligned to a four-byte boundary. However, this sort of - feature is sometimes a configurable option in the C compiler, either - using command-line options or `#pragma' lines, so you have to find - out how your own compiler does it. - - 9.1.4 `c32.mac': Helper Macros for the 32-bit C Interface - - Included in the NASM archives, in the `misc' directory, is a file - `c32.mac' of macros. It defines three macros: `proc', `arg' and - `endproc'. These are intended to be used for C-style procedure - definitions, and they automate a lot of the work involved in keeping - track of the calling convention. - - An example of an assembly function using the macro set is given - here: - - proc _proc32 - - %$i arg - %$j arg - mov eax,[ebp + %$i] - mov ebx,[ebp + %$j] - add eax,[ebx] - - endproc - - This defines `_proc32' to be a procedure taking two arguments, the - first (`i') an integer and the second (`j') a pointer to an integer. - It returns `i + *j'. - - Note that the `arg' macro has an `EQU' as the first line of its - expansion, and since the label before the macro call gets prepended - to the first line of the expanded macro, the `EQU' works, defining - `%$i' to be an offset from `BP'. A context-local variable is used, - local to the context pushed by the `proc' macro and popped by the - `endproc' macro, so that the same argument name can be used in later - procedures. Of course, you don't _have_ to do that. - - `arg' can take an optional parameter, giving the size of the - argument. If no size is given, 4 is assumed, since it is likely that - many function parameters will be of type `int' or pointers. - - 9.2 Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries - - `ELF' replaced the older `a.out' object file format under Linux - because it contains support for position-independent code (PIC), - which makes writing shared libraries much easier. NASM supports the - `ELF' position-independent code features, so you can write Linux - `ELF' shared libraries in NASM. - - NetBSD, and its close cousins FreeBSD and OpenBSD, take a different - approach by hacking PIC support into the `a.out' format. NASM - supports this as the `aoutb' output format, so you can write BSD - shared libraries in NASM too. - - The operating system loads a PIC shared library by memory-mapping - the library file at an arbitrarily chosen point in the address space - of the running process. The contents of the library's code section - must therefore not depend on where it is loaded in memory. - - Therefore, you cannot get at your variables by writing code like - this: - - mov eax,[myvar] ; WRONG - - Instead, the linker provides an area of memory called the _global - offset table_, or GOT; the GOT is situated at a constant distance - from your library's code, so if you can find out where your library - is loaded (which is typically done using a `CALL' and `POP' - combination), you can obtain the address of the GOT, and you can - then load the addresses of your variables out of linker-generated - entries in the GOT. - - The _data_ section of a PIC shared library does not have these - restrictions: since the data section is writable, it has to be - copied into memory anyway rather than just paged in from the library - file, so as long as it's being copied it can be relocated too. So - you can put ordinary types of relocation in the data section without - too much worry (but see section 9.2.4 for a caveat). - - 9.2.1 Obtaining the Address of the GOT - - Each code module in your shared library should define the GOT as an - external symbol: - - extern _GLOBAL_OFFSET_TABLE_ ; in ELF - extern __GLOBAL_OFFSET_TABLE_ ; in BSD a.out - - At the beginning of any function in your shared library which plans - to access your data or BSS sections, you must first calculate the - address of the GOT. This is typically done by writing the function - in this form: - - func: push ebp - mov ebp,esp - push ebx - call .get_GOT - .get_GOT: - pop ebx - add ebx,_GLOBAL_OFFSET_TABLE_+$$-.get_GOT wrt ..gotpc - - ; the function body comes here - - mov ebx,[ebp-4] - mov esp,ebp - pop ebp - ret - - (For BSD, again, the symbol `_GLOBAL_OFFSET_TABLE' requires a second - leading underscore.) - - The first two lines of this function are simply the standard C - prologue to set up a stack frame, and the last three lines are - standard C function epilogue. The third line, and the fourth to last - line, save and restore the `EBX' register, because PIC shared - libraries use this register to store the address of the GOT. - - The interesting bit is the `CALL' instruction and the following two - lines. The `CALL' and `POP' combination obtains the address of the - label `.get_GOT', without having to know in advance where the - program was loaded (since the `CALL' instruction is encoded relative - to the current position). The `ADD' instruction makes use of one of - the special PIC relocation types: GOTPC relocation. With the - `WRT ..gotpc' qualifier specified, the symbol referenced (here - `_GLOBAL_OFFSET_TABLE_', the special symbol assigned to the GOT) is - given as an offset from the beginning of the section. (Actually, - `ELF' encodes it as the offset from the operand field of the `ADD' - instruction, but NASM simplifies this deliberately, so you do things - the same way for both `ELF' and `BSD'.) So the instruction then - _adds_ the beginning of the section, to get the real address of the - GOT, and subtracts the value of `.get_GOT' which it knows is in - `EBX'. Therefore, by the time that instruction has finished, `EBX' - contains the address of the GOT. - - If you didn't follow that, don't worry: it's never necessary to - obtain the address of the GOT by any other means, so you can put - those three instructions into a macro and safely ignore them: - - %macro get_GOT 0 - - call %%getgot - %%getgot: - pop ebx - add ebx,_GLOBAL_OFFSET_TABLE_+$$-%%getgot wrt ..gotpc - - %endmacro - - 9.2.2 Finding Your Local Data Items - - Having got the GOT, you can then use it to obtain the addresses of - your data items. Most variables will reside in the sections you have - declared; they can be accessed using the `..gotoff' special `WRT' - type. The way this works is like this: - - lea eax,[ebx+myvar wrt ..gotoff] - - The expression `myvar wrt ..gotoff' is calculated, when the shared - library is linked, to be the offset to the local variable `myvar' - from the beginning of the GOT. Therefore, adding it to `EBX' as - above will place the real address of `myvar' in `EAX'. - - If you declare variables as `GLOBAL' without specifying a size for - them, they are shared between code modules in the library, but do - not get exported from the library to the program that loaded it. - They will still be in your ordinary data and BSS sections, so you - can access them in the same way as local variables, using the above - `..gotoff' mechanism. - - Note that due to a peculiarity of the way BSD `a.out' format handles - this relocation type, there must be at least one non-local symbol in - the same section as the address you're trying to access. - - 9.2.3 Finding External and Common Data Items - - If your library needs to get at an external variable (external to - the _library_, not just to one of the modules within it), you must - use the `..got' type to get at it. The `..got' type, instead of - giving you the offset from the GOT base to the variable, gives you - the offset from the GOT base to a GOT _entry_ containing the address - of the variable. The linker will set up this GOT entry when it - builds the library, and the dynamic linker will place the correct - address in it at load time. So to obtain the address of an external - variable `extvar' in `EAX', you would code - - mov eax,[ebx+extvar wrt ..got] - - This loads the address of `extvar' out of an entry in the GOT. The - linker, when it builds the shared library, collects together every - relocation of type `..got', and builds the GOT so as to ensure it - has every necessary entry present. - - Common variables must also be accessed in this way. - - 9.2.4 Exporting Symbols to the Library User - - If you want to export symbols to the user of the library, you have - to declare whether they are functions or data, and if they are data, - you have to give the size of the data item. This is because the - dynamic linker has to build procedure linkage table entries for any - exported functions, and also moves exported data items away from the - library's data section in which they were declared. - - So to export a function to users of the library, you must use - - global func:function ; declare it as a function - - func: push ebp - - ; etc. - - And to export a data item such as an array, you would have to code - - global array:data array.end-array ; give the size too - - array: resd 128 - .end: - - Be careful: If you export a variable to the library user, by - declaring it as `GLOBAL' and supplying a size, the variable will end - up living in the data section of the main program, rather than in - your library's data section, where you declared it. So you will have - to access your own global variable with the `..got' mechanism rather - than `..gotoff', as if it were external (which, effectively, it has - become). - - Equally, if you need to store the address of an exported global in - one of your data sections, you can't do it by means of the standard - sort of code: - - dataptr: dd global_data_item ; WRONG - - NASM will interpret this code as an ordinary relocation, in which - `global_data_item' is merely an offset from the beginning of the - `.data' section (or whatever); so this reference will end up - pointing at your data section instead of at the exported global - which resides elsewhere. - - Instead of the above code, then, you must write - - dataptr: dd global_data_item wrt ..sym - - which makes use of the special `WRT' type `..sym' to instruct NASM - to search the symbol table for a particular symbol at that address, - rather than just relocating by section base. - - Either method will work for functions: referring to one of your - functions by means of - - funcptr: dd my_function - - will give the user the address of the code you wrote, whereas - - funcptr: dd my_function wrt .sym - - will give the address of the procedure linkage table for the - function, which is where the calling program will _believe_ the - function lives. Either address is a valid way to call the function. - - 9.2.5 Calling Procedures Outside the Library - - Calling procedures outside your shared library has to be done by - means of a _procedure linkage table_, or PLT. The PLT is placed at a - known offset from where the library is loaded, so the library code - can make calls to the PLT in a position-independent way. Within the - PLT there is code to jump to offsets contained in the GOT, so - function calls to other shared libraries or to routines in the main - program can be transparently passed off to their real destinations. - - To call an external routine, you must use another special PIC - relocation type, `WRT ..plt'. This is much easier than the GOT-based - ones: you simply replace calls such as `CALL printf' with the PLT- - relative version `CALL printf WRT ..plt'. - - 9.2.6 Generating the Library File - - Having written some code modules and assembled them to `.o' files, - you then generate your shared library with a command such as - - ld -shared -o library.so module1.o module2.o # for ELF - ld -Bshareable -o library.so module1.o module2.o # for BSD - - For ELF, if your shared library is going to reside in system - directories such as `/usr/lib' or `/lib', it is usually worth using - the `-soname' flag to the linker, to store the final library file - name, with a version number, into the library: - - ld -shared -soname library.so.1 -o library.so.1.2 *.o - - You would then copy `library.so.1.2' into the library directory, and - create `library.so.1' as a symbolic link to it. - -Chapter 10: Mixing 16 and 32 Bit Code -------------------------------------- - - This chapter tries to cover some of the issues, largely related to - unusual forms of addressing and jump instructions, encountered when - writing operating system code such as protected-mode initialisation - routines, which require code that operates in mixed segment sizes, - such as code in a 16-bit segment trying to modify data in a 32-bit - one, or jumps between different-size segments. - - 10.1 Mixed-Size Jumps - - The most common form of mixed-size instruction is the one used when - writing a 32-bit OS: having done your setup in 16-bit mode, such as - loading the kernel, you then have to boot it by switching into - protected mode and jumping to the 32-bit kernel start address. In a - fully 32-bit OS, this tends to be the _only_ mixed-size instruction - you need, since everything before it can be done in pure 16-bit - code, and everything after it can be pure 32-bit. - - This jump must specify a 48-bit far address, since the target - segment is a 32-bit one. However, it must be assembled in a 16-bit - segment, so just coding, for example, - - jmp 0x1234:0x56789ABC ; wrong! - - will not work, since the offset part of the address will be - truncated to `0x9ABC' and the jump will be an ordinary 16-bit far - one. - - The Linux kernel setup code gets round the inability of `as86' to - generate the required instruction by coding it manually, using `DB' - instructions. NASM can go one better than that, by actually - generating the right instruction itself. Here's how to do it right: - - jmp dword 0x1234:0x56789ABC ; right - - The `DWORD' prefix (strictly speaking, it should come _after_ the - colon, since it is declaring the _offset_ field to be a doubleword; - but NASM will accept either form, since both are unambiguous) forces - the offset part to be treated as far, in the assumption that you are - deliberately writing a jump from a 16-bit segment to a 32-bit one. - - You can do the reverse operation, jumping from a 32-bit segment to a - 16-bit one, by means of the `WORD' prefix: - - jmp word 0x8765:0x4321 ; 32 to 16 bit - - If the `WORD' prefix is specified in 16-bit mode, or the `DWORD' - prefix in 32-bit mode, they will be ignored, since each is - explicitly forcing NASM into a mode it was in anyway. - - 10.2 Addressing Between Different-Size Segments - - If your OS is mixed 16 and 32-bit, or if you are writing a DOS - extender, you are likely to have to deal with some 16-bit segments - and some 32-bit ones. At some point, you will probably end up - writing code in a 16-bit segment which has to access data in a 32- - bit segment, or vice versa. - - If the data you are trying to access in a 32-bit segment lies within - the first 64K of the segment, you may be able to get away with using - an ordinary 16-bit addressing operation for the purpose; but sooner - or later, you will want to do 32-bit addressing from 16-bit mode. - - The easiest way to do this is to make sure you use a register for - the address, since any effective address containing a 32-bit - register is forced to be a 32-bit address. So you can do - - mov eax,offset_into_32_bit_segment_specified_by_fs - mov dword [fs:eax],0x11223344 - - This is fine, but slightly cumbersome (since it wastes an - instruction and a register) if you already know the precise offset - you are aiming at. The x86 architecture does allow 32-bit effective - addresses to specify nothing but a 4-byte offset, so why shouldn't - NASM be able to generate the best instruction for the purpose? - - It can. As in section 10.1, you need only prefix the address with - the `DWORD' keyword, and it will be forced to be a 32-bit address: - - mov dword [fs:dword my_offset],0x11223344 - - Also as in section 10.1, NASM is not fussy about whether the `DWORD' - prefix comes before or after the segment override, so arguably a - nicer-looking way to code the above instruction is - - mov dword [dword fs:my_offset],0x11223344 - - Don't confuse the `DWORD' prefix _outside_ the square brackets, - which controls the size of the data stored at the address, with the - one `inside' the square brackets which controls the length of the - address itself. The two can quite easily be different: - - mov word [dword 0x12345678],0x9ABC - - This moves 16 bits of data to an address specified by a 32-bit - offset. - - You can also specify `WORD' or `DWORD' prefixes along with the `FAR' - prefix to indirect far jumps or calls. For example: - - call dword far [fs:word 0x4321] - - This instruction contains an address specified by a 16-bit offset; - it loads a 48-bit far pointer from that (16-bit segment and 32-bit - offset), and calls that address. - - 10.3 Other Mixed-Size Instructions - - The other way you might want to access data might be using the - string instructions (`LODSx', `STOSx' and so on) or the `XLATB' - instruction. These instructions, since they take no parameters, - might seem to have no easy way to make them perform 32-bit - addressing when assembled in a 16-bit segment. - - This is the purpose of NASM's `a16', `a32' and `a64' prefixes. If - you are coding `LODSB' in a 16-bit segment but it is supposed to be - accessing a string in a 32-bit segment, you should load the desired - address into `ESI' and then code - - a32 lodsb - - The prefix forces the addressing size to 32 bits, meaning that - `LODSB' loads from `[DS:ESI]' instead of `[DS:SI]'. To access a - string in a 16-bit segment when coding in a 32-bit one, the - corresponding `a16' prefix can be used. - - The `a16', `a32' and `a64' prefixes can be applied to any - instruction in NASM's instruction table, but most of them can - generate all the useful forms without them. The prefixes are - necessary only for instructions with implicit addressing: `CMPSx', - `SCASx', `LODSx', `STOSx', `MOVSx', `INSx', `OUTSx', and `XLATB'. - Also, the various push and pop instructions (`PUSHA' and `POPF' as - well as the more usual `PUSH' and `POP') can accept `a16', `a32' or - `a64' prefixes to force a particular one of `SP', `ESP' or `RSP' to - be used as a stack pointer, in case the stack segment in use is a - different size from the code segment. - - `PUSH' and `POP', when applied to segment registers in 32-bit mode, - also have the slightly odd behaviour that they push and pop 4 bytes - at a time, of which the top two are ignored and the bottom two give - the value of the segment register being manipulated. To force the - 16-bit behaviour of segment-register push and pop instructions, you - can use the operand-size prefix `o16': - - o16 push ss - o16 push ds - - This code saves a doubleword of stack space by fitting two segment - registers into the space which would normally be consumed by pushing - one. - - (You can also use the `o32' prefix to force the 32-bit behaviour - when in 16-bit mode, but this seems less useful.) - -Chapter 11: Writing 64-bit Code (Unix, Win64) ---------------------------------------------- - - This chapter attempts to cover some of the common issues involved - when writing 64-bit code, to run under Win64 or Unix. It covers how - to write assembly code to interface with 64-bit C routines, and how - to write position-independent code for shared libraries. - - All 64-bit code uses a flat memory model, since segmentation is not - available in 64-bit mode. The one exception is the `FS' and `GS' - registers, which still add their bases. - - Position independence in 64-bit mode is significantly simpler, since - the processor supports `RIP'-relative addressing directly; see the - `REL' keyword (section 3.3). On most 64-bit platforms, it is - probably desirable to make that the default, using the directive - `DEFAULT REL' (section 6.2). - - 64-bit programming is relatively similar to 32-bit programming, but - of course pointers are 64 bits long; additionally, all existing - platforms pass arguments in registers rather than on the stack. - Furthermore, 64-bit platforms use SSE2 by default for floating - point. Please see the ABI documentation for your platform. - - 64-bit platforms differ in the sizes of the fundamental datatypes, - not just from 32-bit platforms but from each other. If a specific - size data type is desired, it is probably best to use the types - defined in the Standard C header `<inttypes.h>'. - - In 64-bit mode, the default instruction size is still 32 bits. When - loading a value into a 32-bit register (but not an 8- or 16-bit - register), the upper 32 bits of the corresponding 64-bit register - are set to zero. - - 11.1 Register Names in 64-bit Mode - - NASM uses the following names for general-purpose registers in 64- - bit mode, for 8-, 16-, 32- and 64-bit references, respecitively: - - AL/AH, CL/CH, DL/DH, BL/BH, SPL, BPL, SIL, DIL, R8B-R15B - AX, CX, DX, BX, SP, BP, SI, DI, R8W-R15W - EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI, R8D-R15D - RAX, RCX, RDX, RBX, RSP, RBP, RSI, RDI, R8-R15 - - This is consistent with the AMD documentation and most other - assemblers. The Intel documentation, however, uses the names - `R8L-R15L' for 8-bit references to the higher registers. It is - possible to use those names by definiting them as macros; similarly, - if one wants to use numeric names for the low 8 registers, define - them as macros. The standard macro package `altreg' (see section - 5.1) can be used for this purpose. - - 11.2 Immediates and Displacements in 64-bit Mode - - In 64-bit mode, immediates and displacements are generally only 32 - bits wide. NASM will therefore truncate most displacements and - immediates to 32 bits. - - The only instruction which takes a full 64-bit immediate is: - - MOV reg64,imm64 - - NASM will produce this instruction whenever the programmer uses - `MOV' with an immediate into a 64-bit register. If this is not - desirable, simply specify the equivalent 32-bit register, which will - be automatically zero-extended by the processor, or specify the - immediate as `DWORD': - - mov rax,foo ; 64-bit immediate - mov rax,qword foo ; (identical) - mov eax,foo ; 32-bit immediate, zero-extended - mov rax,dword foo ; 32-bit immediate, sign-extended - - The length of these instructions are 10, 5 and 7 bytes, - respectively. - - The only instructions which take a full 64-bit _displacement_ is - loading or storing, using `MOV', `AL', `AX', `EAX' or `RAX' (but no - other registers) to an absolute 64-bit address. Since this is a - relatively rarely used instruction (64-bit code generally uses - relative addressing), the programmer has to explicitly declare the - displacement size as `QWORD': - - default abs - - mov eax,[foo] ; 32-bit absolute disp, sign-extended - mov eax,[a32 foo] ; 32-bit absolute disp, zero-extended - mov eax,[qword foo] ; 64-bit absolute disp - - default rel - - mov eax,[foo] ; 32-bit relative disp - mov eax,[a32 foo] ; d:o, address truncated to 32 bits(!) - mov eax,[qword foo] ; error - mov eax,[abs qword foo] ; 64-bit absolute disp - - A sign-extended absolute displacement can access from -2 GB to +2 - GB; a zero-extended absolute displacement can access from 0 to 4 GB. - - 11.3 Interfacing to 64-bit C Programs (Unix) - - On Unix, the 64-bit ABI is defined by the document: - - `http://www.x86-64.org/documentation/abi.pdf' - - Although written for AT&T-syntax assembly, the concepts apply - equally well for NASM-style assembly. What follows is a simplified - summary. - - The first six integer arguments (from the left) are passed in `RDI', - `RSI', `RDX', `RCX', `R8', and `R9', in that order. Additional - integer arguments are passed on the stack. These registers, plus - `RAX', `R10' and `R11' are destroyed by function calls, and thus are - available for use by the function without saving. - - Integer return values are passed in `RAX' and `RDX', in that order. - - Floating point is done using SSE registers, except for - `long double'. Floating-point arguments are passed in `XMM0' to - `XMM7'; return is `XMM0' and `XMM1'. `long double' are passed on the - stack, and returned in `ST0' and `ST1'. - - All SSE and x87 registers are destroyed by function calls. - - On 64-bit Unix, `long' is 64 bits. - - Integer and SSE register arguments are counted separately, so for - the case of - - void foo(long a, double b, int c) - - `a' is passed in `RDI', `b' in `XMM0', and `c' in `ESI'. - - 11.4 Interfacing to 64-bit C Programs (Win64) - - The Win64 ABI is described at: - - `http://msdn2.microsoft.com/en-gb/library/ms794533.aspx' - - What follows is a simplified summary. - - The first four integer arguments are passed in `RCX', `RDX', `R8' - and `R9', in that order. Additional integer arguments are passed on - the stack. These registers, plus `RAX', `R10' and `R11' are - destroyed by function calls, and thus are available for use by the - function without saving. - - Integer return values are passed in `RAX' only. - - Floating point is done using SSE registers, except for - `long double'. Floating-point arguments are passed in `XMM0' to - `XMM3'; return is `XMM0' only. - - On Win64, `long' is 32 bits; `long long' or `_int64' is 64 bits. - - Integer and SSE register arguments are counted together, so for the - case of - - void foo(long long a, double b, int c) - - `a' is passed in `RCX', `b' in `XMM1', and `c' in `R8D'. - -Chapter 12: Troubleshooting ---------------------------- - - This chapter describes some of the common problems that users have - been known to encounter with NASM, and answers them. It also gives - instructions for reporting bugs in NASM if you find a difficulty - that isn't listed here. - - 12.1 Common Problems - -12.1.1 NASM Generates Inefficient Code - - We sometimes get `bug' reports about NASM generating inefficient, or - even `wrong', code on instructions such as `ADD ESP,8'. This is a - deliberate design feature, connected to predictability of output: - NASM, on seeing `ADD ESP,8', will generate the form of the - instruction which leaves room for a 32-bit offset. You need to code - `ADD ESP,BYTE 8' if you want the space-efficient form of the - instruction. This isn't a bug, it's user error: if you prefer to - have NASM produce the more efficient code automatically enable - optimization with the `-O' option (see section 2.1.22). - -12.1.2 My Jumps are Out of Range - - Similarly, people complain that when they issue conditional jumps - (which are `SHORT' by default) that try to jump too far, NASM - reports `short jump out of range' instead of making the jumps - longer. - - This, again, is partly a predictability issue, but in fact has a - more practical reason as well. NASM has no means of being told what - type of processor the code it is generating will be run on; so it - cannot decide for itself that it should generate `Jcc NEAR' type - instructions, because it doesn't know that it's working for a 386 or - above. Alternatively, it could replace the out-of-range short `JNE' - instruction with a very short `JE' instruction that jumps over a - `JMP NEAR'; this is a sensible solution for processors below a 386, - but hardly efficient on processors which have good branch prediction - _and_ could have used `JNE NEAR' instead. So, once again, it's up to - the user, not the assembler, to decide what instructions should be - generated. See section 2.1.22. - -12.1.3 `ORG' Doesn't Work - - People writing boot sector programs in the `bin' format often - complain that `ORG' doesn't work the way they'd like: in order to - place the `0xAA55' signature word at the end of a 512-byte boot - sector, people who are used to MASM tend to code - - ORG 0 - - ; some boot sector code - - ORG 510 - DW 0xAA55 - - This is not the intended use of the `ORG' directive in NASM, and - will not work. The correct way to solve this problem in NASM is to - use the `TIMES' directive, like this: - - ORG 0 - - ; some boot sector code - - TIMES 510-($-$$) DB 0 - DW 0xAA55 - - The `TIMES' directive will insert exactly enough zero bytes into the - output to move the assembly point up to 510. This method also has - the advantage that if you accidentally fill your boot sector too - full, NASM will catch the problem at assembly time and report it, so - you won't end up with a boot sector that you have to disassemble to - find out what's wrong with it. - -12.1.4 `TIMES' Doesn't Work - - The other common problem with the above code is people who write the - `TIMES' line as - - TIMES 510-$ DB 0 - - by reasoning that `$' should be a pure number, just like 510, so the - difference between them is also a pure number and can happily be fed - to `TIMES'. - - NASM is a _modular_ assembler: the various component parts are - designed to be easily separable for re-use, so they don't exchange - information unnecessarily. In consequence, the `bin' output format, - even though it has been told by the `ORG' directive that the `.text' - section should start at 0, does not pass that information back to - the expression evaluator. So from the evaluator's point of view, `$' - isn't a pure number: it's an offset from a section base. Therefore - the difference between `$' and 510 is also not a pure number, but - involves a section base. Values involving section bases cannot be - passed as arguments to `TIMES'. - - The solution, as in the previous section, is to code the `TIMES' - line in the form - - TIMES 510-($-$$) DB 0 - - in which `$' and `$$' are offsets from the same section base, and so - their difference is a pure number. This will solve the problem and - generate sensible code. - - 12.2 Bugs - - We have never yet released a version of NASM with any _known_ bugs. - That doesn't usually stop there being plenty we didn't know about, - though. Any that you find should be reported firstly via the - `bugtracker' at `https://sourceforge.net/projects/nasm/' (click on - "Bugs"), or if that fails then through one of the contacts in - section 1.2. - - Please read section 2.2 first, and don't report the bug if it's - listed in there as a deliberate feature. (If you think the feature - is badly thought out, feel free to send us reasons why you think it - should be changed, but don't just send us mail saying `This is a - bug' if the documentation says we did it on purpose.) Then read - section 12.1, and don't bother reporting the bug if it's listed - there. - - If you do report a bug, _please_ give us all of the following - information: - - (*) What operating system you're running NASM under. DOS, Linux, - NetBSD, Win16, Win32, VMS (I'd be impressed), whatever. - - (*) If you're running NASM under DOS or Win32, tell us whether - you've compiled your own executable from the DOS source archive, - or whether you were using the standard distribution binaries out - of the archive. If you were using a locally built executable, - try to reproduce the problem using one of the standard binaries, - as this will make it easier for us to reproduce your problem - prior to fixing it. - - (*) Which version of NASM you're using, and exactly how you invoked - it. Give us the precise command line, and the contents of the - `NASMENV' environment variable if any. - - (*) Which versions of any supplementary programs you're using, and - how you invoked them. If the problem only becomes visible at - link time, tell us what linker you're using, what version of it - you've got, and the exact linker command line. If the problem - involves linking against object files generated by a compiler, - tell us what compiler, what version, and what command line or - options you used. (If you're compiling in an IDE, please try to - reproduce the problem with the command-line version of the - compiler.) - - (*) If at all possible, send us a NASM source file which exhibits - the problem. If this causes copyright problems (e.g. you can - only reproduce the bug in restricted-distribution code) then - bear in mind the following two points: firstly, we guarantee - that any source code sent to us for the purposes of debugging - NASM will be used _only_ for the purposes of debugging NASM, and - that we will delete all our copies of it as soon as we have - found and fixed the bug or bugs in question; and secondly, we - would prefer _not_ to be mailed large chunks of code anyway. The - smaller the file, the better. A three-line sample file that does - nothing useful _except_ demonstrate the problem is much easier - to work with than a fully fledged ten-thousand-line program. (Of - course, some errors _do_ only crop up in large files, so this - may not be possible.) - - (*) A description of what the problem actually _is_. `It doesn't - work' is _not_ a helpful description! Please describe exactly - what is happening that shouldn't be, or what isn't happening - that should. Examples might be: `NASM generates an error message - saying Line 3 for an error that's actually on Line 5'; `NASM - generates an error message that I believe it shouldn't be - generating at all'; `NASM fails to generate an error message - that I believe it _should_ be generating'; `the object file - produced from this source code crashes my linker'; `the ninth - byte of the output file is 66 and I think it should be 77 - instead'. - - (*) If you believe the output file from NASM to be faulty, send it - to us. That allows us to determine whether our own copy of NASM - generates the same file, or whether the problem is related to - portability issues between our development platforms and yours. - We can handle binary files mailed to us as MIME attachments, - uuencoded, and even BinHex. Alternatively, we may be able to - provide an FTP site you can upload the suspect files to; but - mailing them is easier for us. - - (*) Any other information or data files that might be helpful. If, - for example, the problem involves NASM failing to generate an - object file while TASM can generate an equivalent file without - trouble, then send us _both_ object files, so we can see what - TASM is doing differently from us. - -Appendix A: Ndisasm -------------------- - - The Netwide Disassembler, NDISASM - - A.1 Introduction - - The Netwide Disassembler is a small companion program to the Netwide - Assembler, NASM. It seemed a shame to have an x86 assembler, - complete with a full instruction table, and not make as much use of - it as possible, so here's a disassembler which shares the - instruction table (and some other bits of code) with NASM. - - The Netwide Disassembler does nothing except to produce - disassemblies of _binary_ source files. NDISASM does not have any - understanding of object file formats, like `objdump', and it will - not understand `DOS .EXE' files like `debug' will. It just - disassembles. - - A.2 Getting Started: Installation - - See section 1.3 for installation instructions. NDISASM, like NASM, - has a `man page' which you may want to put somewhere useful, if you - are on a Unix system. - - A.3 Running NDISASM - - To disassemble a file, you will typically use a command of the form - - ndisasm -b {16|32|64} filename - - NDISASM can disassemble 16-, 32- or 64-bit code equally easily, - provided of course that you remember to specify which it is to work - with. If no `-b' switch is present, NDISASM works in 16-bit mode by - default. The `-u' switch (for USE32) also invokes 32-bit mode. - - Two more command line options are `-r' which reports the version - number of NDISASM you are running, and `-h' which gives a short - summary of command line options. - - A.3.1 COM Files: Specifying an Origin - - To disassemble a `DOS .COM' file correctly, a disassembler must - assume that the first instruction in the file is loaded at address - `0x100', rather than at zero. NDISASM, which assumes by default that - any file you give it is loaded at zero, will therefore need to be - informed of this. - - The `-o' option allows you to declare a different origin for the - file you are disassembling. Its argument may be expressed in any of - the NASM numeric formats: decimal by default, if it begins with - ``$'' or ``0x'' or ends in ``H'' it's `hex', if it ends in ``Q'' - it's `octal', and if it ends in ``B'' it's `binary'. - - Hence, to disassemble a `.COM' file: - - ndisasm -o100h filename.com - - will do the trick. - - A.3.2 Code Following Data: Synchronisation - - Suppose you are disassembling a file which contains some data which - isn't machine code, and _then_ contains some machine code. NDISASM - will faithfully plough through the data section, producing machine - instructions wherever it can (although most of them will look - bizarre, and some may have unusual prefixes, e.g. - ``FS OR AX,0x240A''), and generating `DB' instructions ever so often - if it's totally stumped. Then it will reach the code section. - - Supposing NDISASM has just finished generating a strange machine - instruction from part of the data section, and its file position is - now one byte _before_ the beginning of the code section. It's - entirely possible that another spurious instruction will get - generated, starting with the final byte of the data section, and - then the correct first instruction in the code section will not be - seen because the starting point skipped over it. This isn't really - ideal. - - To avoid this, you can specify a ``synchronisation'' point, or - indeed as many synchronisation points as you like (although NDISASM - can only handle 2147483647 sync points internally). The definition - of a sync point is this: NDISASM guarantees to hit sync points - exactly during disassembly. If it is thinking about generating an - instruction which would cause it to jump over a sync point, it will - discard that instruction and output a ``db'' instead. So it _will_ - start disassembly exactly from the sync point, and so you _will_ see - all the instructions in your code section. - - Sync points are specified using the `-s' option: they are measured - in terms of the program origin, not the file position. So if you - want to synchronize after 32 bytes of a `.COM' file, you would have - to do - - ndisasm -o100h -s120h file.com - - rather than - - ndisasm -o100h -s20h file.com - - As stated above, you can specify multiple sync markers if you need - to, just by repeating the `-s' option. - - A.3.3 Mixed Code and Data: Automatic (Intelligent) Synchronisation - - Suppose you are disassembling the boot sector of a `DOS' floppy - (maybe it has a virus, and you need to understand the virus so that - you know what kinds of damage it might have done you). Typically, - this will contain a `JMP' instruction, then some data, then the rest - of the code. So there is a very good chance of NDISASM being - _misaligned_ when the data ends and the code begins. Hence a sync - point is needed. - - On the other hand, why should you have to specify the sync point - manually? What you'd do in order to find where the sync point would - be, surely, would be to read the `JMP' instruction, and then to use - its target address as a sync point. So can NDISASM do that for you? - - The answer, of course, is yes: using either of the synonymous - switches `-a' (for automatic sync) or `-i' (for intelligent sync) - will enable `auto-sync' mode. Auto-sync mode automatically generates - a sync point for any forward-referring PC-relative jump or call - instruction that NDISASM encounters. (Since NDISASM is one-pass, if - it encounters a PC-relative jump whose target has already been - processed, there isn't much it can do about it...) - - Only PC-relative jumps are processed, since an absolute jump is - either through a register (in which case NDISASM doesn't know what - the register contains) or involves a segment address (in which case - the target code isn't in the same segment that NDISASM is working - in, and so the sync point can't be placed anywhere useful). - - For some kinds of file, this mechanism will automatically put sync - points in all the right places, and save you from having to place - any sync points manually. However, it should be stressed that auto- - sync mode is _not_ guaranteed to catch all the sync points, and you - may still have to place some manually. - - Auto-sync mode doesn't prevent you from declaring manual sync - points: it just adds automatically generated ones to the ones you - provide. It's perfectly feasible to specify `-i' _and_ some `-s' - options. - - Another caveat with auto-sync mode is that if, by some unpleasant - fluke, something in your data section should disassemble to a PC- - relative call or jump instruction, NDISASM may obediently place a - sync point in a totally random place, for example in the middle of - one of the instructions in your code section. So you may end up with - a wrong disassembly even if you use auto-sync. Again, there isn't - much I can do about this. If you have problems, you'll have to use - manual sync points, or use the `-k' option (documented below) to - suppress disassembly of the data area. - - A.3.4 Other Options - - The `-e' option skips a header on the file, by ignoring the first N - bytes. This means that the header is _not_ counted towards the - disassembly offset: if you give `-e10 -o10', disassembly will start - at byte 10 in the file, and this will be given offset 10, not 20. - - The `-k' option is provided with two comma-separated numeric - arguments, the first of which is an assembly offset and the second - is a number of bytes to skip. This _will_ count the skipped bytes - towards the assembly offset: its use is to suppress disassembly of a - data section which wouldn't contain anything you wanted to see - anyway. - - A.4 Bugs and Improvements - - There are no known bugs. However, any you find, with patches if - possible, should be sent to `nasm-bugs@lists.sourceforge.net', or to - the developer's site at `https://sourceforge.net/projects/nasm/' and - we'll try to fix them. Feel free to send contributions and new - features as well. - -Appendix B: Instruction List ----------------------------- - - B.1 Introduction - - The following sections show the instructions which NASM currently - supports. For each instruction, there is a separate entry for each - supported addressing mode. The third column shows the processor type - in which the instruction was introduced and, when appropriate, one - or more usage flags. - - B.1.1 Special instructions... - - DB - DW - DD - DQ - DT - DO - DY - RESB imm 8086 - RESW - RESD - RESQ - REST - RESO - RESY - - B.1.2 Conventional instructions - - AAA 8086,NOLONG - AAD 8086,NOLONG - AAD imm 8086,NOLONG - AAM 8086,NOLONG - AAM imm 8086,NOLONG - AAS 8086,NOLONG - ADC mem,reg8 8086 - ADC reg8,reg8 8086 - ADC mem,reg16 8086 - ADC reg16,reg16 8086 - ADC mem,reg32 386 - ADC reg32,reg32 386 - ADC mem,reg64 X64 - ADC reg64,reg64 X64 - ADC reg8,mem 8086 - ADC reg8,reg8 8086 - ADC reg16,mem 8086 - ADC reg16,reg16 8086 - ADC reg32,mem 386 - ADC reg32,reg32 386 - ADC reg64,mem X64 - ADC reg64,reg64 X64 - ADC rm16,imm8 8086 - ADC rm32,imm8 386 - ADC rm64,imm8 X64 - ADC reg_al,imm 8086 - ADC reg_ax,sbyte16 8086 - ADC reg_ax,imm 8086 - ADC reg_eax,sbyte32 386 - ADC reg_eax,imm 386 - ADC reg_rax,sbyte64 X64 - ADC reg_rax,imm X64 - ADC rm8,imm 8086 - ADC rm16,imm 8086 - ADC rm32,imm 386 - ADC rm64,imm X64 - ADC mem,imm8 8086 - ADC mem,imm16 8086 - ADC mem,imm32 386 - ADD mem,reg8 8086 - ADD reg8,reg8 8086 - ADD mem,reg16 8086 - ADD reg16,reg16 8086 - ADD mem,reg32 386 - ADD reg32,reg32 386 - ADD mem,reg64 X64 - ADD reg64,reg64 X64 - ADD reg8,mem 8086 - ADD reg8,reg8 8086 - ADD reg16,mem 8086 - ADD reg16,reg16 8086 - ADD reg32,mem 386 - ADD reg32,reg32 386 - ADD reg64,mem X64 - ADD reg64,reg64 X64 - ADD rm16,imm8 8086 - ADD rm32,imm8 386 - ADD rm64,imm8 X64 - ADD reg_al,imm 8086 - ADD reg_ax,sbyte16 8086 - ADD reg_ax,imm 8086 - ADD reg_eax,sbyte32 386 - ADD reg_eax,imm 386 - ADD reg_rax,sbyte64 X64 - ADD reg_rax,imm X64 - ADD rm8,imm 8086 - ADD rm16,imm 8086 - ADD rm32,imm 386 - ADD rm64,imm X64 - ADD mem,imm8 8086 - ADD mem,imm16 8086 - ADD mem,imm32 386 - AND mem,reg8 8086 - AND reg8,reg8 8086 - AND mem,reg16 8086 - AND reg16,reg16 8086 - AND mem,reg32 386 - AND reg32,reg32 386 - AND mem,reg64 X64 - AND reg64,reg64 X64 - AND reg8,mem 8086 - AND reg8,reg8 8086 - AND reg16,mem 8086 - AND reg16,reg16 8086 - AND reg32,mem 386 - AND reg32,reg32 386 - AND reg64,mem X64 - AND reg64,reg64 X64 - AND rm16,imm8 8086 - AND rm32,imm8 386 - AND rm64,imm8 X64 - AND reg_al,imm 8086 - AND reg_ax,sbyte16 8086 - AND reg_ax,imm 8086 - AND reg_eax,sbyte32 386 - AND reg_eax,imm 386 - AND reg_rax,sbyte64 X64 - AND reg_rax,imm X64 - AND rm8,imm 8086 - AND rm16,imm 8086 - AND rm32,imm 386 - AND rm64,imm X64 - AND mem,imm8 8086 - AND mem,imm16 8086 - AND mem,imm32 386 - ARPL mem,reg16 286,PROT,NOLONG - ARPL reg16,reg16 286,PROT,NOLONG - BB0_RESET PENT,CYRIX,ND - BB1_RESET PENT,CYRIX,ND - BOUND reg16,mem 186,NOLONG - BOUND reg32,mem 386,NOLONG - BSF reg16,mem 386 - BSF reg16,reg16 386 - BSF reg32,mem 386 - BSF reg32,reg32 386 - BSF reg64,mem X64 - BSF reg64,reg64 X64 - BSR reg16,mem 386 - BSR reg16,reg16 386 - BSR reg32,mem 386 - BSR reg32,reg32 386 - BSR reg64,mem X64 - BSR reg64,reg64 X64 - BSWAP reg32 486 - BSWAP reg64 X64 - BT mem,reg16 386 - BT reg16,reg16 386 - BT mem,reg32 386 - BT reg32,reg32 386 - BT mem,reg64 X64 - BT reg64,reg64 X64 - BT rm16,imm 386 - BT rm32,imm 386 - BT rm64,imm X64 - BTC mem,reg16 386 - BTC reg16,reg16 386 - BTC mem,reg32 386 - BTC reg32,reg32 386 - BTC mem,reg64 X64 - BTC reg64,reg64 X64 - BTC rm16,imm 386 - BTC rm32,imm 386 - BTC rm64,imm X64 - BTR mem,reg16 386 - BTR reg16,reg16 386 - BTR mem,reg32 386 - BTR reg32,reg32 386 - BTR mem,reg64 X64 - BTR reg64,reg64 X64 - BTR rm16,imm 386 - BTR rm32,imm 386 - BTR rm64,imm X64 - BTS mem,reg16 386 - BTS reg16,reg16 386 - BTS mem,reg32 386 - BTS reg32,reg32 386 - BTS mem,reg64 X64 - BTS reg64,reg64 X64 - BTS rm16,imm 386 - BTS rm32,imm 386 - BTS rm64,imm X64 - CALL imm 8086 - CALL imm|near 8086 - CALL imm|far 8086,ND,NOLONG - CALL imm16 8086 - CALL imm16|near 8086 - CALL imm16|far 8086,ND,NOLONG - CALL imm32 386 - CALL imm32|near 386 - CALL imm32|far 386,ND,NOLONG - CALL imm:imm 8086,NOLONG - CALL imm16:imm 8086,NOLONG - CALL imm:imm16 8086,NOLONG - CALL imm32:imm 386,NOLONG - CALL imm:imm32 386,NOLONG - CALL mem|far 8086,NOLONG - CALL mem|far X64 - CALL mem16|far 8086 - CALL mem32|far 386 - CALL mem64|far X64 - CALL mem|near 8086 - CALL mem16|near 8086 - CALL mem32|near 386,NOLONG - CALL mem64|near X64 - CALL reg16 8086 - CALL reg32 386,NOLONG - CALL reg64 X64 - CALL mem 8086 - CALL mem16 8086 - CALL mem32 386,NOLONG - CALL mem64 X64 - CBW 8086 - CDQ 386 - CDQE X64 - CLC 8086 - CLD 8086 - CLGI X64,AMD - CLI 8086 - CLTS 286,PRIV - CMC 8086 - CMP mem,reg8 8086 - CMP reg8,reg8 8086 - CMP mem,reg16 8086 - CMP reg16,reg16 8086 - CMP mem,reg32 386 - CMP reg32,reg32 386 - CMP mem,reg64 X64 - CMP reg64,reg64 X64 - CMP reg8,mem 8086 - CMP reg8,reg8 8086 - CMP reg16,mem 8086 - CMP reg16,reg16 8086 - CMP reg32,mem 386 - CMP reg32,reg32 386 - CMP reg64,mem X64 - CMP reg64,reg64 X64 - CMP rm16,imm8 8086 - CMP rm32,imm8 386 - CMP rm64,imm8 X64 - CMP reg_al,imm 8086 - CMP reg_ax,sbyte16 8086 - CMP reg_ax,imm 8086 - CMP reg_eax,sbyte32 386 - CMP reg_eax,imm 386 - CMP reg_rax,sbyte64 X64 - CMP reg_rax,imm X64 - CMP rm8,imm 8086 - CMP rm16,imm 8086 - CMP rm32,imm 386 - CMP rm64,imm X64 - CMP mem,imm8 8086 - CMP mem,imm16 8086 - CMP mem,imm32 386 - CMPSB 8086 - CMPSD 386 - CMPSQ X64 - CMPSW 8086 - CMPXCHG mem,reg8 PENT - CMPXCHG reg8,reg8 PENT - CMPXCHG mem,reg16 PENT - CMPXCHG reg16,reg16 PENT - CMPXCHG mem,reg32 PENT - CMPXCHG reg32,reg32 PENT - CMPXCHG mem,reg64 X64 - CMPXCHG reg64,reg64 X64 - CMPXCHG486 mem,reg8 486,UNDOC,ND - CMPXCHG486 reg8,reg8 486,UNDOC,ND - CMPXCHG486 mem,reg16 486,UNDOC,ND - CMPXCHG486 reg16,reg16 486,UNDOC,ND - CMPXCHG486 mem,reg32 486,UNDOC,ND - CMPXCHG486 reg32,reg32 486,UNDOC,ND - CMPXCHG8B mem PENT - CMPXCHG16B mem X64 - CPUID PENT - CPU_READ PENT,CYRIX - CPU_WRITE PENT,CYRIX - CQO X64 - CWD 8086 - CWDE 386 - DAA 8086,NOLONG - DAS 8086,NOLONG - DEC reg16 8086,NOLONG - DEC reg32 386,NOLONG - DEC rm8 8086 - DEC rm16 8086 - DEC rm32 386 - DEC rm64 X64 - DIV rm8 8086 - DIV rm16 8086 - DIV rm32 386 - DIV rm64 X64 - DMINT P6,CYRIX - EMMS PENT,MMX - ENTER imm,imm 186 - EQU imm 8086 - EQU imm:imm 8086 - F2XM1 8086,FPU - FABS 8086,FPU - FADD mem32 8086,FPU - FADD mem64 8086,FPU - FADD fpureg|to 8086,FPU - FADD fpureg 8086,FPU - FADD fpureg,fpu0 8086,FPU - FADD fpu0,fpureg 8086,FPU - FADD 8086,FPU,ND - FADDP fpureg 8086,FPU - FADDP fpureg,fpu0 8086,FPU - FADDP 8086,FPU,ND - FBLD mem80 8086,FPU - FBLD mem 8086,FPU - FBSTP mem80 8086,FPU - FBSTP mem 8086,FPU - FCHS 8086,FPU - FCLEX 8086,FPU - FCMOVB fpureg P6,FPU - FCMOVB fpu0,fpureg P6,FPU - FCMOVB P6,FPU,ND - FCMOVBE fpureg P6,FPU - FCMOVBE fpu0,fpureg P6,FPU - FCMOVBE P6,FPU,ND - FCMOVE fpureg P6,FPU - FCMOVE fpu0,fpureg P6,FPU - FCMOVE P6,FPU,ND - FCMOVNB fpureg P6,FPU - FCMOVNB fpu0,fpureg P6,FPU - FCMOVNB P6,FPU,ND - FCMOVNBE fpureg P6,FPU - FCMOVNBE fpu0,fpureg P6,FPU - FCMOVNBE P6,FPU,ND - FCMOVNE fpureg P6,FPU - FCMOVNE fpu0,fpureg P6,FPU - FCMOVNE P6,FPU,ND - FCMOVNU fpureg P6,FPU - FCMOVNU fpu0,fpureg P6,FPU - FCMOVNU P6,FPU,ND - FCMOVU fpureg P6,FPU - FCMOVU fpu0,fpureg P6,FPU - FCMOVU P6,FPU,ND - FCOM mem32 8086,FPU - FCOM mem64 8086,FPU - FCOM fpureg 8086,FPU - FCOM fpu0,fpureg 8086,FPU - FCOM 8086,FPU,ND - FCOMI fpureg P6,FPU - FCOMI fpu0,fpureg P6,FPU - FCOMI P6,FPU,ND - FCOMIP fpureg P6,FPU - FCOMIP fpu0,fpureg P6,FPU - FCOMIP P6,FPU,ND - FCOMP mem32 8086,FPU - FCOMP mem64 8086,FPU - FCOMP fpureg 8086,FPU - FCOMP fpu0,fpureg 8086,FPU - FCOMP 8086,FPU,ND - FCOMPP 8086,FPU - FCOS 386,FPU - FDECSTP 8086,FPU - FDISI 8086,FPU - FDIV mem32 8086,FPU - FDIV mem64 8086,FPU - FDIV fpureg|to 8086,FPU - FDIV fpureg 8086,FPU - FDIV fpureg,fpu0 8086,FPU - FDIV fpu0,fpureg 8086,FPU - FDIV 8086,FPU,ND - FDIVP fpureg 8086,FPU - FDIVP fpureg,fpu0 8086,FPU - FDIVP 8086,FPU,ND - FDIVR mem32 8086,FPU - FDIVR mem64 8086,FPU - FDIVR fpureg|to 8086,FPU - FDIVR fpureg,fpu0 8086,FPU - FDIVR fpureg 8086,FPU - FDIVR fpu0,fpureg 8086,FPU - FDIVR 8086,FPU,ND - FDIVRP fpureg 8086,FPU - FDIVRP fpureg,fpu0 8086,FPU - FDIVRP 8086,FPU,ND - FEMMS PENT,3DNOW - FENI 8086,FPU - FFREE fpureg 8086,FPU - FFREE 8086,FPU - FFREEP fpureg 286,FPU,UNDOC - FFREEP 286,FPU,UNDOC - FIADD mem32 8086,FPU - FIADD mem16 8086,FPU - FICOM mem32 8086,FPU - FICOM mem16 8086,FPU - FICOMP mem32 8086,FPU - FICOMP mem16 8086,FPU - FIDIV mem32 8086,FPU - FIDIV mem16 8086,FPU - FIDIVR mem32 8086,FPU - FIDIVR mem16 8086,FPU - FILD mem32 8086,FPU - FILD mem16 8086,FPU - FILD mem64 8086,FPU - FIMUL mem32 8086,FPU - FIMUL mem16 8086,FPU - FINCSTP 8086,FPU - FINIT 8086,FPU - FIST mem32 8086,FPU - FIST mem16 8086,FPU - FISTP mem32 8086,FPU - FISTP mem16 8086,FPU - FISTP mem64 8086,FPU - FISTTP mem16 PRESCOTT,FPU - FISTTP mem32 PRESCOTT,FPU - FISTTP mem64 PRESCOTT,FPU - FISUB mem32 8086,FPU - FISUB mem16 8086,FPU - FISUBR mem32 8086,FPU - FISUBR mem16 8086,FPU - FLD mem32 8086,FPU - FLD mem64 8086,FPU - FLD mem80 8086,FPU - FLD fpureg 8086,FPU - FLD 8086,FPU,ND - FLD1 8086,FPU - FLDCW mem 8086,FPU,SW - FLDENV mem 8086,FPU - FLDL2E 8086,FPU - FLDL2T 8086,FPU - FLDLG2 8086,FPU - FLDLN2 8086,FPU - FLDPI 8086,FPU - FLDZ 8086,FPU - FMUL mem32 8086,FPU - FMUL mem64 8086,FPU - FMUL fpureg|to 8086,FPU - FMUL fpureg,fpu0 8086,FPU - FMUL fpureg 8086,FPU - FMUL fpu0,fpureg 8086,FPU - FMUL 8086,FPU,ND - FMULP fpureg 8086,FPU - FMULP fpureg,fpu0 8086,FPU - FMULP 8086,FPU,ND - FNCLEX 8086,FPU - FNDISI 8086,FPU - FNENI 8086,FPU - FNINIT 8086,FPU - FNOP 8086,FPU - FNSAVE mem 8086,FPU - FNSTCW mem 8086,FPU,SW - FNSTENV mem 8086,FPU - FNSTSW mem 8086,FPU,SW - FNSTSW reg_ax 286,FPU - FPATAN 8086,FPU - FPREM 8086,FPU - FPREM1 386,FPU - FPTAN 8086,FPU - FRNDINT 8086,FPU - FRSTOR mem 8086,FPU - FSAVE mem 8086,FPU - FSCALE 8086,FPU - FSETPM 286,FPU - FSIN 386,FPU - FSINCOS 386,FPU - FSQRT 8086,FPU - FST mem32 8086,FPU - FST mem64 8086,FPU - FST fpureg 8086,FPU - FST 8086,FPU,ND - FSTCW mem 8086,FPU,SW - FSTENV mem 8086,FPU - FSTP mem32 8086,FPU - FSTP mem64 8086,FPU - FSTP mem80 8086,FPU - FSTP fpureg 8086,FPU - FSTP 8086,FPU,ND - FSTSW mem 8086,FPU,SW - FSTSW reg_ax 286,FPU - FSUB mem32 8086,FPU - FSUB mem64 8086,FPU - FSUB fpureg|to 8086,FPU - FSUB fpureg,fpu0 8086,FPU - FSUB fpureg 8086,FPU - FSUB fpu0,fpureg 8086,FPU - FSUB 8086,FPU,ND - FSUBP fpureg 8086,FPU - FSUBP fpureg,fpu0 8086,FPU - FSUBP 8086,FPU,ND - FSUBR mem32 8086,FPU - FSUBR mem64 8086,FPU - FSUBR fpureg|to 8086,FPU - FSUBR fpureg,fpu0 8086,FPU - FSUBR fpureg 8086,FPU - FSUBR fpu0,fpureg 8086,FPU - FSUBR 8086,FPU,ND - FSUBRP fpureg 8086,FPU - FSUBRP fpureg,fpu0 8086,FPU - FSUBRP 8086,FPU,ND - FTST 8086,FPU - FUCOM fpureg 386,FPU - FUCOM fpu0,fpureg 386,FPU - FUCOM 386,FPU,ND - FUCOMI fpureg P6,FPU - FUCOMI fpu0,fpureg P6,FPU - FUCOMI P6,FPU,ND - FUCOMIP fpureg P6,FPU - FUCOMIP fpu0,fpureg P6,FPU - FUCOMIP P6,FPU,ND - FUCOMP fpureg 386,FPU - FUCOMP fpu0,fpureg 386,FPU - FUCOMP 386,FPU,ND - FUCOMPP 386,FPU - FXAM 8086,FPU - FXCH fpureg 8086,FPU - FXCH fpureg,fpu0 8086,FPU - FXCH fpu0,fpureg 8086,FPU - FXCH 8086,FPU,ND - FXTRACT 8086,FPU - FYL2X 8086,FPU - FYL2XP1 8086,FPU - HLT 8086,PRIV - IBTS mem,reg16 386,SW,UNDOC,ND - IBTS reg16,reg16 386,UNDOC,ND - IBTS mem,reg32 386,SD,UNDOC,ND - IBTS reg32,reg32 386,UNDOC,ND - ICEBP 386,ND - IDIV rm8 8086 - IDIV rm16 8086 - IDIV rm32 386 - IDIV rm64 X64 - IMUL rm8 8086 - IMUL rm16 8086 - IMUL rm32 386 - IMUL rm64 X64 - IMUL reg16,mem 386 - IMUL reg16,reg16 386 - IMUL reg32,mem 386 - IMUL reg32,reg32 386 - IMUL reg64,mem X64 - IMUL reg64,reg64 X64 - IMUL reg16,mem,imm8 186 - IMUL reg16,mem,sbyte16 186,ND - IMUL reg16,mem,imm16 186 - IMUL reg16,mem,imm 186,ND - IMUL reg16,reg16,imm8 186 - IMUL reg16,reg16,sbyte16 186,ND - IMUL reg16,reg16,imm16 186 - IMUL reg16,reg16,imm 186,ND - IMUL reg32,mem,imm8 386 - IMUL reg32,mem,sbyte32 386,ND - IMUL reg32,mem,imm32 386 - IMUL reg32,mem,imm 386,ND - IMUL reg32,reg32,imm8 386 - IMUL reg32,reg32,sbyte32 386,ND - IMUL reg32,reg32,imm32 386 - IMUL reg32,reg32,imm 386,ND - IMUL reg64,mem,imm8 X64 - IMUL reg64,mem,sbyte64 X64,ND - IMUL reg64,mem,imm32 X64 - IMUL reg64,mem,imm X64,ND - IMUL reg64,reg64,imm8 X64 - IMUL reg64,reg64,sbyte64 X64,ND - IMUL reg64,reg64,imm32 X64 - IMUL reg64,reg64,imm X64,ND - IMUL reg16,imm8 186 - IMUL reg16,sbyte16 186,ND - IMUL reg16,imm16 186 - IMUL reg16,imm 186,ND - IMUL reg32,imm8 386 - IMUL reg32,sbyte32 386,ND - IMUL reg32,imm32 386 - IMUL reg32,imm 386,ND - IMUL reg64,imm8 X64 - IMUL reg64,sbyte64 X64,ND - IMUL reg64,imm32 X64 - IMUL reg64,imm X64,ND - IN reg_al,imm 8086 - IN reg_ax,imm 8086 - IN reg_eax,imm 386 - IN reg_al,reg_dx 8086 - IN reg_ax,reg_dx 8086 - IN reg_eax,reg_dx 386 - INC reg16 8086,NOLONG - INC reg32 386,NOLONG - INC rm8 8086 - INC rm16 8086 - INC rm32 386 - INC rm64 X64 - INCBIN - INSB 186 - INSD 386 - INSW 186 - INT imm 8086 - INT01 386,ND - INT1 386 - INT03 8086,ND - INT3 8086 - INTO 8086,NOLONG - INVD 486,PRIV - INVLPG mem 486,PRIV - INVLPGA reg_ax,reg_ecx X86_64,AMD,NOLONG - INVLPGA reg_eax,reg_ecx X86_64,AMD - INVLPGA reg_rax,reg_ecx X64,AMD - INVLPGA X86_64,AMD - IRET 8086 - IRETD 386 - IRETQ X64 - IRETW 8086 - JCXZ imm 8086,NOLONG - JECXZ imm 386 - JRCXZ imm X64 - JMP imm|short 8086 - JMP imm 8086,ND - JMP imm 8086 - JMP imm|near 8086,ND - JMP imm|far 8086,ND,NOLONG - JMP imm16 8086 - JMP imm16|near 8086,ND - JMP imm16|far 8086,ND,NOLONG - JMP imm32 386 - JMP imm32|near 386,ND - JMP imm32|far 386,ND,NOLONG - JMP imm:imm 8086,NOLONG - JMP imm16:imm 8086,NOLONG - JMP imm:imm16 8086,NOLONG - JMP imm32:imm 386,NOLONG - JMP imm:imm32 386,NOLONG - JMP mem|far 8086,NOLONG - JMP mem|far X64 - JMP mem16|far 8086 - JMP mem32|far 386 - JMP mem64|far X64 - JMP mem|near 8086 - JMP mem16|near 8086 - JMP mem32|near 386,NOLONG - JMP mem64|near X64 - JMP reg16 8086 - JMP reg32 386,NOLONG - JMP reg64 X64 - JMP mem 8086 - JMP mem16 8086 - JMP mem32 386,NOLONG - JMP mem64 X64 - JMPE imm IA64 - JMPE imm16 IA64 - JMPE imm32 IA64 - JMPE rm16 IA64 - JMPE rm32 IA64 - LAHF 8086 - LAR reg16,mem 286,PROT,SW - LAR reg16,reg16 286,PROT - LAR reg16,reg32 386,PROT - LAR reg16,reg64 X64,PROT,ND - LAR reg32,mem 386,PROT,SW - LAR reg32,reg16 386,PROT - LAR reg32,reg32 386,PROT - LAR reg32,reg64 X64,PROT,ND - LAR reg64,mem X64,PROT,SW - LAR reg64,reg16 X64,PROT - LAR reg64,reg32 X64,PROT - LAR reg64,reg64 X64,PROT - LDS reg16,mem 8086,NOLONG - LDS reg32,mem 386,NOLONG - LEA reg16,mem 8086 - LEA reg32,mem 386 - LEA reg64,mem X64 - LEAVE 186 - LES reg16,mem 8086,NOLONG - LES reg32,mem 386,NOLONG - LFENCE X64,AMD - LFS reg16,mem 386 - LFS reg32,mem 386 - LGDT mem 286,PRIV - LGS reg16,mem 386 - LGS reg32,mem 386 - LIDT mem 286,PRIV - LLDT mem 286,PROT,PRIV - LLDT mem16 286,PROT,PRIV - LLDT reg16 286,PROT,PRIV - LMSW mem 286,PRIV - LMSW mem16 286,PRIV - LMSW reg16 286,PRIV - LOADALL 386,UNDOC - LOADALL286 286,UNDOC - LODSB 8086 - LODSD 386 - LODSQ X64 - LODSW 8086 - LOOP imm 8086 - LOOP imm,reg_cx 8086,NOLONG - LOOP imm,reg_ecx 386 - LOOP imm,reg_rcx X64 - LOOPE imm 8086 - LOOPE imm,reg_cx 8086,NOLONG - LOOPE imm,reg_ecx 386 - LOOPE imm,reg_rcx X64 - LOOPNE imm 8086 - LOOPNE imm,reg_cx 8086,NOLONG - LOOPNE imm,reg_ecx 386 - LOOPNE imm,reg_rcx X64 - LOOPNZ imm 8086 - LOOPNZ imm,reg_cx 8086,NOLONG - LOOPNZ imm,reg_ecx 386 - LOOPNZ imm,reg_rcx X64 - LOOPZ imm 8086 - LOOPZ imm,reg_cx 8086,NOLONG - LOOPZ imm,reg_ecx 386 - LOOPZ imm,reg_rcx X64 - LSL reg16,mem 286,PROT,SW - LSL reg16,reg16 286,PROT - LSL reg16,reg32 386,PROT - LSL reg16,reg64 X64,PROT,ND - LSL reg32,mem 386,PROT,SW - LSL reg32,reg16 386,PROT - LSL reg32,reg32 386,PROT - LSL reg32,reg64 X64,PROT,ND - LSL reg64,mem X64,PROT,SW - LSL reg64,reg16 X64,PROT - LSL reg64,reg32 X64,PROT - LSL reg64,reg64 X64,PROT - LSS reg16,mem 386 - LSS reg32,mem 386 - LTR mem 286,PROT,PRIV - LTR mem16 286,PROT,PRIV - LTR reg16 286,PROT,PRIV - MFENCE X64,AMD - MONITOR PRESCOTT - MONITOR reg_eax,reg_ecx,reg_edx PRESCOTT,ND - MONITOR reg_rax,reg_ecx,reg_edx X64,ND - MOV mem,reg_sreg 8086 - MOV reg16,reg_sreg 8086 - MOV reg32,reg_sreg 386 - MOV reg_sreg,mem 8086 - MOV reg_sreg,reg16 8086 - MOV reg_sreg,reg32 386 - MOV reg_al,mem_offs 8086 - MOV reg_ax,mem_offs 8086 - MOV reg_eax,mem_offs 386 - MOV reg_rax,mem_offs X64 - MOV mem_offs,reg_al 8086 - MOV mem_offs,reg_ax 8086 - MOV mem_offs,reg_eax 386 - MOV mem_offs,reg_rax X64 - MOV reg32,reg_creg 386,PRIV,NOLONG - MOV reg64,reg_creg X64,PRIV - MOV reg_creg,reg32 386,PRIV,NOLONG - MOV reg_creg,reg64 X64,PRIV - MOV reg32,reg_dreg 386,PRIV,NOLONG - MOV reg64,reg_dreg X64,PRIV - MOV reg_dreg,reg32 386,PRIV,NOLONG - MOV reg_dreg,reg64 X64,PRIV - MOV reg32,reg_treg 386,NOLONG,ND - MOV reg_treg,reg32 386,NOLONG,ND - MOV mem,reg8 8086 - MOV reg8,reg8 8086 - MOV mem,reg16 8086 - MOV reg16,reg16 8086 - MOV mem,reg32 386 - MOV reg32,reg32 386 - MOV mem,reg64 X64 - MOV reg64,reg64 X64 - MOV reg8,mem 8086 - MOV reg8,reg8 8086 - MOV reg16,mem 8086 - MOV reg16,reg16 8086 - MOV reg32,mem 386 - MOV reg32,reg32 386 - MOV reg64,mem X64 - MOV reg64,reg64 X64 - MOV reg8,imm 8086 - MOV reg16,imm 8086 - MOV reg32,imm 386 - MOV reg64,imm X64 - MOV reg64,imm32 X64 - MOV rm8,imm 8086 - MOV rm16,imm 8086 - MOV rm32,imm 386 - MOV rm64,imm X64 - MOV mem,imm8 8086 - MOV mem,imm16 8086 - MOV mem,imm32 386 - MOVD mmxreg,mem PENT,MMX,SD - MOVD mmxreg,reg32 PENT,MMX - MOVD mem,mmxreg PENT,MMX,SD - MOVD reg32,mmxreg PENT,MMX - MOVD xmmreg,mem X64,SD - MOVD xmmreg,reg32 X64 - MOVD mem,xmmreg X64,SD - MOVD reg32,xmmreg X64,SSE - MOVQ mmxreg,mmxrm PENT,MMX - MOVQ mmxrm,mmxreg PENT,MMX - MOVQ mmxreg,rm64 X64,MMX - MOVQ rm64,mmxreg X64,MMX - MOVSB 8086 - MOVSD 386 - MOVSQ X64 - MOVSW 8086 - MOVSX reg16,mem 386 - MOVSX reg16,reg8 386 - MOVSX reg32,rm8 386 - MOVSX reg32,rm16 386 - MOVSX reg64,rm8 X64 - MOVSX reg64,rm16 X64 - MOVSXD reg64,rm32 X64 - MOVSX reg64,rm32 X64,ND - MOVZX reg16,mem 386 - MOVZX reg16,reg8 386 - MOVZX reg32,rm8 386 - MOVZX reg32,rm16 386 - MOVZX reg64,rm8 X64 - MOVZX reg64,rm16 X64 - MUL rm8 8086 - MUL rm16 8086 - MUL rm32 386 - MUL rm64 X64 - MWAIT PRESCOTT - MWAIT reg_eax,reg_ecx PRESCOTT,ND - NEG rm8 8086 - NEG rm16 8086 - NEG rm32 386 - NEG rm64 X64 - NOP 8086 - NOP rm16 P6 - NOP rm32 P6 - NOP rm64 X64 - NOT rm8 8086 - NOT rm16 8086 - NOT rm32 386 - NOT rm64 X64 - OR mem,reg8 8086 - OR reg8,reg8 8086 - OR mem,reg16 8086 - OR reg16,reg16 8086 - OR mem,reg32 386 - OR reg32,reg32 386 - OR mem,reg64 X64 - OR reg64,reg64 X64 - OR reg8,mem 8086 - OR reg8,reg8 8086 - OR reg16,mem 8086 - OR reg16,reg16 8086 - OR reg32,mem 386 - OR reg32,reg32 386 - OR reg64,mem X64 - OR reg64,reg64 X64 - OR rm16,imm8 8086 - OR rm32,imm8 386 - OR rm64,imm8 X64 - OR reg_al,imm 8086 - OR reg_ax,sbyte16 8086 - OR reg_ax,imm 8086 - OR reg_eax,sbyte32 386 - OR reg_eax,imm 386 - OR reg_rax,sbyte64 X64 - OR reg_rax,imm X64 - OR rm8,imm 8086 - OR rm16,imm 8086 - OR rm32,imm 386 - OR rm64,imm X64 - OR mem,imm8 8086 - OR mem,imm16 8086 - OR mem,imm32 386 - OUT imm,reg_al 8086 - OUT imm,reg_ax 8086 - OUT imm,reg_eax 386 - OUT reg_dx,reg_al 8086 - OUT reg_dx,reg_ax 8086 - OUT reg_dx,reg_eax 386 - OUTSB 186 - OUTSD 386 - OUTSW 186 - PACKSSDW mmxreg,mmxrm PENT,MMX - PACKSSWB mmxreg,mmxrm PENT,MMX - PACKUSWB mmxreg,mmxrm PENT,MMX - PADDB mmxreg,mmxrm PENT,MMX - PADDD mmxreg,mmxrm PENT,MMX - PADDSB mmxreg,mmxrm PENT,MMX - PADDSIW mmxreg,mmxrm PENT,MMX,CYRIX - PADDSW mmxreg,mmxrm PENT,MMX - PADDUSB mmxreg,mmxrm PENT,MMX - PADDUSW mmxreg,mmxrm PENT,MMX - PADDW mmxreg,mmxrm PENT,MMX - PAND mmxreg,mmxrm PENT,MMX - PANDN mmxreg,mmxrm PENT,MMX - PAUSE 8086 - PAVEB mmxreg,mmxrm PENT,MMX,CYRIX - PAVGUSB mmxreg,mmxrm PENT,3DNOW - PCMPEQB mmxreg,mmxrm PENT,MMX - PCMPEQD mmxreg,mmxrm PENT,MMX - PCMPEQW mmxreg,mmxrm PENT,MMX - PCMPGTB mmxreg,mmxrm PENT,MMX - PCMPGTD mmxreg,mmxrm PENT,MMX - PCMPGTW mmxreg,mmxrm PENT,MMX - PDISTIB mmxreg,mem PENT,MMX,CYRIX - PF2ID mmxreg,mmxrm PENT,3DNOW - PFACC mmxreg,mmxrm PENT,3DNOW - PFADD mmxreg,mmxrm PENT,3DNOW - PFCMPEQ mmxreg,mmxrm PENT,3DNOW - PFCMPGE mmxreg,mmxrm PENT,3DNOW - PFCMPGT mmxreg,mmxrm PENT,3DNOW - PFMAX mmxreg,mmxrm PENT,3DNOW - PFMIN mmxreg,mmxrm PENT,3DNOW - PFMUL mmxreg,mmxrm PENT,3DNOW - PFRCP mmxreg,mmxrm PENT,3DNOW - PFRCPIT1 mmxreg,mmxrm PENT,3DNOW - PFRCPIT2 mmxreg,mmxrm PENT,3DNOW - PFRSQIT1 mmxreg,mmxrm PENT,3DNOW - PFRSQRT mmxreg,mmxrm PENT,3DNOW - PFSUB mmxreg,mmxrm PENT,3DNOW - PFSUBR mmxreg,mmxrm PENT,3DNOW - PI2FD mmxreg,mmxrm PENT,3DNOW - PMACHRIW mmxreg,mem PENT,MMX,CYRIX - PMADDWD mmxreg,mmxrm PENT,MMX - PMAGW mmxreg,mmxrm PENT,MMX,CYRIX - PMULHRIW mmxreg,mmxrm PENT,MMX,CYRIX - PMULHRWA mmxreg,mmxrm PENT,3DNOW - PMULHRWC mmxreg,mmxrm PENT,MMX,CYRIX - PMULHW mmxreg,mmxrm PENT,MMX - PMULLW mmxreg,mmxrm PENT,MMX - PMVGEZB mmxreg,mem PENT,MMX,CYRIX - PMVLZB mmxreg,mem PENT,MMX,CYRIX - PMVNZB mmxreg,mem PENT,MMX,CYRIX - PMVZB mmxreg,mem PENT,MMX,CYRIX - POP reg16 8086 - POP reg32 386,NOLONG - POP reg64 X64 - POP rm16 8086 - POP rm32 386,NOLONG - POP rm64 X64 - POP reg_cs 8086,UNDOC,ND - POP reg_dess 8086,NOLONG - POP reg_fsgs 386 - POPA 186,NOLONG - POPAD 386,NOLONG - POPAW 186,NOLONG - POPF 8086 - POPFD 386,NOLONG - POPFQ X64 - POPFW 8086 - POR mmxreg,mmxrm PENT,MMX - PREFETCH mem PENT,3DNOW - PREFETCHW mem PENT,3DNOW - PSLLD mmxreg,mmxrm PENT,MMX - PSLLD mmxreg,imm PENT,MMX - PSLLQ mmxreg,mmxrm PENT,MMX - PSLLQ mmxreg,imm PENT,MMX - PSLLW mmxreg,mmxrm PENT,MMX - PSLLW mmxreg,imm PENT,MMX - PSRAD mmxreg,mmxrm PENT,MMX - PSRAD mmxreg,imm PENT,MMX - PSRAW mmxreg,mmxrm PENT,MMX - PSRAW mmxreg,imm PENT,MMX - PSRLD mmxreg,mmxrm PENT,MMX - PSRLD mmxreg,imm PENT,MMX - PSRLQ mmxreg,mmxrm PENT,MMX - PSRLQ mmxreg,imm PENT,MMX - PSRLW mmxreg,mmxrm PENT,MMX - PSRLW mmxreg,imm PENT,MMX - PSUBB mmxreg,mmxrm PENT,MMX - PSUBD mmxreg,mmxrm PENT,MMX - PSUBSB mmxreg,mmxrm PENT,MMX - PSUBSIW mmxreg,mmxrm PENT,MMX,CYRIX - PSUBSW mmxreg,mmxrm PENT,MMX - PSUBUSB mmxreg,mmxrm PENT,MMX - PSUBUSW mmxreg,mmxrm PENT,MMX - PSUBW mmxreg,mmxrm PENT,MMX - PUNPCKHBW mmxreg,mmxrm PENT,MMX - PUNPCKHDQ mmxreg,mmxrm PENT,MMX - PUNPCKHWD mmxreg,mmxrm PENT,MMX - PUNPCKLBW mmxreg,mmxrm PENT,MMX - PUNPCKLDQ mmxreg,mmxrm PENT,MMX - PUNPCKLWD mmxreg,mmxrm PENT,MMX - PUSH reg16 8086 - PUSH reg32 386,NOLONG - PUSH reg64 X64 - PUSH rm16 8086 - PUSH rm32 386,NOLONG - PUSH rm64 X64 - PUSH reg_cs 8086,NOLONG - PUSH reg_dess 8086,NOLONG - PUSH reg_fsgs 386 - PUSH imm8 186 - PUSH imm16 186,AR0,SZ - PUSH imm32 386,NOLONG,AR0,SZ - PUSH imm32 386,NOLONG,SD - PUSH imm64 X64,AR0,SZ - PUSHA 186,NOLONG - PUSHAD 386,NOLONG - PUSHAW 186,NOLONG - PUSHF 8086 - PUSHFD 386,NOLONG - PUSHFQ X64 - PUSHFW 8086 - PXOR mmxreg,mmxrm PENT,MMX - RCL rm8,unity 8086 - RCL rm8,reg_cl 8086 - RCL rm8,imm 186 - RCL rm16,unity 8086 - RCL rm16,reg_cl 8086 - RCL rm16,imm 186 - RCL rm32,unity 386 - RCL rm32,reg_cl 386 - RCL rm32,imm 386 - RCL rm64,unity X64 - RCL rm64,reg_cl X64 - RCL rm64,imm X64 - RCR rm8,unity 8086 - RCR rm8,reg_cl 8086 - RCR rm8,imm 186 - RCR rm16,unity 8086 - RCR rm16,reg_cl 8086 - RCR rm16,imm 186 - RCR rm32,unity 386 - RCR rm32,reg_cl 386 - RCR rm32,imm 386 - RCR rm64,unity X64 - RCR rm64,reg_cl X64 - RCR rm64,imm X64 - RDSHR rm32 P6,CYRIXM - RDMSR PENT,PRIV - RDPMC P6 - RDTSC PENT - RDTSCP X86_64 - RET 8086 - RET imm 8086,SW - RETF 8086 - RETF imm 8086,SW - RETN 8086 - RETN imm 8086,SW - ROL rm8,unity 8086 - ROL rm8,reg_cl 8086 - ROL rm8,imm 186 - ROL rm16,unity 8086 - ROL rm16,reg_cl 8086 - ROL rm16,imm 186 - ROL rm32,unity 386 - ROL rm32,reg_cl 386 - ROL rm32,imm 386 - ROL rm64,unity X64 - ROL rm64,reg_cl X64 - ROL rm64,imm X64 - ROR rm8,unity 8086 - ROR rm8,reg_cl 8086 - ROR rm8,imm 186 - ROR rm16,unity 8086 - ROR rm16,reg_cl 8086 - ROR rm16,imm 186 - ROR rm32,unity 386 - ROR rm32,reg_cl 386 - ROR rm32,imm 386 - ROR rm64,unity X64 - ROR rm64,reg_cl X64 - ROR rm64,imm X64 - RDM P6,CYRIX,ND - RSDC reg_sreg,mem80 486,CYRIXM - RSLDT mem80 486,CYRIXM - RSM PENTM - RSTS mem80 486,CYRIXM - SAHF 8086 - SAL rm8,unity 8086,ND - SAL rm8,reg_cl 8086,ND - SAL rm8,imm 186,ND - SAL rm16,unity 8086,ND - SAL rm16,reg_cl 8086,ND - SAL rm16,imm 186,ND - SAL rm32,unity 386,ND - SAL rm32,reg_cl 386,ND - SAL rm32,imm 386,ND - SAL rm64,unity X64,ND - SAL rm64,reg_cl X64,ND - SAL rm64,imm X64,ND - SALC 8086,UNDOC - SAR rm8,unity 8086 - SAR rm8,reg_cl 8086 - SAR rm8,imm 186 - SAR rm16,unity 8086 - SAR rm16,reg_cl 8086 - SAR rm16,imm 186 - SAR rm32,unity 386 - SAR rm32,reg_cl 386 - SAR rm32,imm 386 - SAR rm64,unity X64 - SAR rm64,reg_cl X64 - SAR rm64,imm X64 - SBB mem,reg8 8086 - SBB reg8,reg8 8086 - SBB mem,reg16 8086 - SBB reg16,reg16 8086 - SBB mem,reg32 386 - SBB reg32,reg32 386 - SBB mem,reg64 X64 - SBB reg64,reg64 X64 - SBB reg8,mem 8086 - SBB reg8,reg8 8086 - SBB reg16,mem 8086 - SBB reg16,reg16 8086 - SBB reg32,mem 386 - SBB reg32,reg32 386 - SBB reg64,mem X64 - SBB reg64,reg64 X64 - SBB rm16,imm8 8086 - SBB rm32,imm8 386 - SBB rm64,imm8 X64 - SBB reg_al,imm 8086 - SBB reg_ax,sbyte16 8086 - SBB reg_ax,imm 8086 - SBB reg_eax,sbyte32 386 - SBB reg_eax,imm 386 - SBB reg_rax,sbyte64 X64 - SBB reg_rax,imm X64 - SBB rm8,imm 8086 - SBB rm16,imm 8086 - SBB rm32,imm 386 - SBB rm64,imm X64 - SBB mem,imm8 8086 - SBB mem,imm16 8086 - SBB mem,imm32 386 - SCASB 8086 - SCASD 386 - SCASQ X64 - SCASW 8086 - SFENCE X64,AMD - SGDT mem 286 - SHL rm8,unity 8086 - SHL rm8,reg_cl 8086 - SHL rm8,imm 186 - SHL rm16,unity 8086 - SHL rm16,reg_cl 8086 - SHL rm16,imm 186 - SHL rm32,unity 386 - SHL rm32,reg_cl 386 - SHL rm32,imm 386 - SHL rm64,unity X64 - SHL rm64,reg_cl X64 - SHL rm64,imm X64 - SHLD mem,reg16,imm 3862 - SHLD reg16,reg16,imm 3862 - SHLD mem,reg32,imm 3862 - SHLD reg32,reg32,imm 3862 - SHLD mem,reg64,imm X642 - SHLD reg64,reg64,imm X642 - SHLD mem,reg16,reg_cl 386 - SHLD reg16,reg16,reg_cl 386 - SHLD mem,reg32,reg_cl 386 - SHLD reg32,reg32,reg_cl 386 - SHLD mem,reg64,reg_cl X64 - SHLD reg64,reg64,reg_cl X64 - SHR rm8,unity 8086 - SHR rm8,reg_cl 8086 - SHR rm8,imm 186 - SHR rm16,unity 8086 - SHR rm16,reg_cl 8086 - SHR rm16,imm 186 - SHR rm32,unity 386 - SHR rm32,reg_cl 386 - SHR rm32,imm 386 - SHR rm64,unity X64 - SHR rm64,reg_cl X64 - SHR rm64,imm X64 - SHRD mem,reg16,imm 3862 - SHRD reg16,reg16,imm 3862 - SHRD mem,reg32,imm 3862 - SHRD reg32,reg32,imm 3862 - SHRD mem,reg64,imm X642 - SHRD reg64,reg64,imm X642 - SHRD mem,reg16,reg_cl 386 - SHRD reg16,reg16,reg_cl 386 - SHRD mem,reg32,reg_cl 386 - SHRD reg32,reg32,reg_cl 386 - SHRD mem,reg64,reg_cl X64 - SHRD reg64,reg64,reg_cl X64 - SIDT mem 286 - SLDT mem 286 - SLDT mem16 286 - SLDT reg16 286 - SLDT reg32 386 - SLDT reg64 X64,ND - SLDT reg64 X64 - SKINIT X64 - SMI 386,UNDOC - SMINT P6,CYRIX,ND - SMINTOLD 486,CYRIX,ND - SMSW mem 286 - SMSW mem16 286 - SMSW reg16 286 - SMSW reg32 386 - STC 8086 - STD 8086 - STGI X64 - STI 8086 - STOSB 8086 - STOSD 386 - STOSQ X64 - STOSW 8086 - STR mem 286,PROT - STR mem16 286,PROT - STR reg16 286,PROT - STR reg32 386,PROT - STR reg64 X64 - SUB mem,reg8 8086 - SUB reg8,reg8 8086 - SUB mem,reg16 8086 - SUB reg16,reg16 8086 - SUB mem,reg32 386 - SUB reg32,reg32 386 - SUB mem,reg64 X64 - SUB reg64,reg64 X64 - SUB reg8,mem 8086 - SUB reg8,reg8 8086 - SUB reg16,mem 8086 - SUB reg16,reg16 8086 - SUB reg32,mem 386 - SUB reg32,reg32 386 - SUB reg64,mem X64 - SUB reg64,reg64 X64 - SUB rm16,imm8 8086 - SUB rm32,imm8 386 - SUB rm64,imm8 X64 - SUB reg_al,imm 8086 - SUB reg_ax,sbyte16 8086 - SUB reg_ax,imm 8086 - SUB reg_eax,sbyte32 386 - SUB reg_eax,imm 386 - SUB reg_rax,sbyte64 X64 - SUB reg_rax,imm X64 - SUB rm8,imm 8086 - SUB rm16,imm 8086 - SUB rm32,imm 386 - SUB rm64,imm X64 - SUB mem,imm8 8086 - SUB mem,imm16 8086 - SUB mem,imm32 386 - SVDC mem80,reg_sreg 486,CYRIXM - SVLDT mem80 486,CYRIXM,ND - SVTS mem80 486,CYRIXM - SWAPGS X64 - SYSCALL P6,AMD - SYSENTER P6 - SYSEXIT P6,PRIV - SYSRET P6,PRIV,AMD - TEST mem,reg8 8086 - TEST reg8,reg8 8086 - TEST mem,reg16 8086 - TEST reg16,reg16 8086 - TEST mem,reg32 386 - TEST reg32,reg32 386 - TEST mem,reg64 X64 - TEST reg64,reg64 X64 - TEST reg8,mem 8086 - TEST reg16,mem 8086 - TEST reg32,mem 386 - TEST reg64,mem X64 - TEST reg_al,imm 8086 - TEST reg_ax,imm 8086 - TEST reg_eax,imm 386 - TEST reg_rax,imm X64 - TEST rm8,imm 8086 - TEST rm16,imm 8086 - TEST rm32,imm 386 - TEST rm64,imm X64 - TEST mem,imm8 8086 - TEST mem,imm16 8086 - TEST mem,imm32 386 - UD0 186,UNDOC - UD1 186,UNDOC - UD2B 186,UNDOC,ND - UD2 186 - UD2A 186,ND - UMOV mem,reg8 386,UNDOC,ND - UMOV reg8,reg8 386,UNDOC,ND - UMOV mem,reg16 386,UNDOC,ND - UMOV reg16,reg16 386,UNDOC,ND - UMOV mem,reg32 386,UNDOC,ND - UMOV reg32,reg32 386,UNDOC,ND - UMOV reg8,mem 386,UNDOC,ND - UMOV reg8,reg8 386,UNDOC,ND - UMOV reg16,mem 386,UNDOC,ND - UMOV reg16,reg16 386,UNDOC,ND - UMOV reg32,mem 386,UNDOC,ND - UMOV reg32,reg32 386,UNDOC,ND - VERR mem 286,PROT - VERR mem16 286,PROT - VERR reg16 286,PROT - VERW mem 286,PROT - VERW mem16 286,PROT - VERW reg16 286,PROT - FWAIT 8086 - WBINVD 486,PRIV - WRSHR rm32 P6,CYRIXM - WRMSR PENT,PRIV - XADD mem,reg8 486 - XADD reg8,reg8 486 - XADD mem,reg16 486 - XADD reg16,reg16 486 - XADD mem,reg32 486 - XADD reg32,reg32 486 - XADD mem,reg64 X64 - XADD reg64,reg64 X64 - XBTS reg16,mem 386,SW,UNDOC,ND - XBTS reg16,reg16 386,UNDOC,ND - XBTS reg32,mem 386,SD,UNDOC,ND - XBTS reg32,reg32 386,UNDOC,ND - XCHG reg_ax,reg16 8086 - XCHG reg_eax,reg32na 386 - XCHG reg_rax,reg64 X64 - XCHG reg16,reg_ax 8086 - XCHG reg32na,reg_eax 386 - XCHG reg64,reg_rax X64 - XCHG reg_eax,reg_eax 386,NOLONG - XCHG reg8,mem 8086 - XCHG reg8,reg8 8086 - XCHG reg16,mem 8086 - XCHG reg16,reg16 8086 - XCHG reg32,mem 386 - XCHG reg32,reg32 386 - XCHG reg64,mem X64 - XCHG reg64,reg64 X64 - XCHG mem,reg8 8086 - XCHG reg8,reg8 8086 - XCHG mem,reg16 8086 - XCHG reg16,reg16 8086 - XCHG mem,reg32 386 - XCHG reg32,reg32 386 - XCHG mem,reg64 X64 - XCHG reg64,reg64 X64 - XLATB 8086 - XLAT 8086 - XOR mem,reg8 8086 - XOR reg8,reg8 8086 - XOR mem,reg16 8086 - XOR reg16,reg16 8086 - XOR mem,reg32 386 - XOR reg32,reg32 386 - XOR mem,reg64 X64 - XOR reg64,reg64 X64 - XOR reg8,mem 8086 - XOR reg8,reg8 8086 - XOR reg16,mem 8086 - XOR reg16,reg16 8086 - XOR reg32,mem 386 - XOR reg32,reg32 386 - XOR reg64,mem X64 - XOR reg64,reg64 X64 - XOR rm16,imm8 8086 - XOR rm32,imm8 386 - XOR rm64,imm8 X64 - XOR reg_al,imm 8086 - XOR reg_ax,sbyte16 8086 - XOR reg_ax,imm 8086 - XOR reg_eax,sbyte32 386 - XOR reg_eax,imm 386 - XOR reg_rax,sbyte64 X64 - XOR reg_rax,imm X64 - XOR rm8,imm 8086 - XOR rm16,imm 8086 - XOR rm32,imm 386 - XOR rm64,imm X64 - XOR mem,imm8 8086 - XOR mem,imm16 8086 - XOR mem,imm32 386 - CMOVcc reg16,mem P6 - CMOVcc reg16,reg16 P6 - CMOVcc reg32,mem P6 - CMOVcc reg32,reg32 P6 - CMOVcc reg64,mem X64 - CMOVcc reg64,reg64 X64 - Jcc imm|near 386 - Jcc imm16|near 386 - Jcc imm32|near 386 - Jcc imm|short 8086,ND - Jcc imm 8086,ND - Jcc imm 386,ND - Jcc imm 8086,ND - Jcc imm 8086 - SETcc mem 386 - SETcc reg8 386 - - B.1.3 Katmai Streaming SIMD instructions (SSE -- a.k.a. KNI, XMM, MMX2) - - ADDPS xmmreg,xmmrm KATMAI,SSE - ADDSS xmmreg,xmmrm KATMAI,SSE,SD - ANDNPS xmmreg,xmmrm KATMAI,SSE - ANDPS xmmreg,xmmrm KATMAI,SSE - CMPEQPS xmmreg,xmmrm KATMAI,SSE - CMPEQSS xmmreg,xmmrm KATMAI,SSE - CMPLEPS xmmreg,xmmrm KATMAI,SSE - CMPLESS xmmreg,xmmrm KATMAI,SSE - CMPLTPS xmmreg,xmmrm KATMAI,SSE - CMPLTSS xmmreg,xmmrm KATMAI,SSE - CMPNEQPS xmmreg,xmmrm KATMAI,SSE - CMPNEQSS xmmreg,xmmrm KATMAI,SSE - CMPNLEPS xmmreg,xmmrm KATMAI,SSE - CMPNLESS xmmreg,xmmrm KATMAI,SSE - CMPNLTPS xmmreg,xmmrm KATMAI,SSE - CMPNLTSS xmmreg,xmmrm KATMAI,SSE - CMPORDPS xmmreg,xmmrm KATMAI,SSE - CMPORDSS xmmreg,xmmrm KATMAI,SSE - CMPUNORDPS xmmreg,xmmrm KATMAI,SSE - CMPUNORDSS xmmreg,xmmrm KATMAI,SSE - CMPPS xmmreg,mem,imm KATMAI,SSE - CMPPS xmmreg,xmmreg,imm KATMAI,SSE - CMPSS xmmreg,mem,imm KATMAI,SSE - CMPSS xmmreg,xmmreg,imm KATMAI,SSE - COMISS xmmreg,xmmrm KATMAI,SSE - CVTPI2PS xmmreg,mmxrm KATMAI,SSE,MMX - CVTPS2PI mmxreg,xmmrm KATMAI,SSE,MMX - CVTSI2SS xmmreg,mem KATMAI,SSE,SD,AR1,ND - CVTSI2SS xmmreg,rm32 KATMAI,SSE,SD,AR1 - CVTSI2SS xmmreg,rm64 X64,SSE,AR1 - CVTSS2SI reg32,xmmreg KATMAI,SSE,SD,AR1 - CVTSS2SI reg32,mem KATMAI,SSE,SD,AR1 - CVTSS2SI reg64,xmmreg X64,SSE,SD,AR1 - CVTSS2SI reg64,mem X64,SSE,SD,AR1 - CVTTPS2PI mmxreg,xmmrm KATMAI,SSE,MMX - CVTTSS2SI reg32,xmmrm KATMAI,SSE,SD,AR1 - CVTTSS2SI reg64,xmmrm X64,SSE,SD,AR1 - DIVPS xmmreg,xmmrm KATMAI,SSE - DIVSS xmmreg,xmmrm KATMAI,SSE - LDMXCSR mem KATMAI,SSE,SD - MAXPS xmmreg,xmmrm KATMAI,SSE - MAXSS xmmreg,xmmrm KATMAI,SSE - MINPS xmmreg,xmmrm KATMAI,SSE - MINSS xmmreg,xmmrm KATMAI,SSE - MOVAPS xmmreg,mem KATMAI,SSE - MOVAPS mem,xmmreg KATMAI,SSE - MOVAPS xmmreg,xmmreg KATMAI,SSE - MOVAPS xmmreg,xmmreg KATMAI,SSE - MOVHPS xmmreg,mem KATMAI,SSE - MOVHPS mem,xmmreg KATMAI,SSE - MOVLHPS xmmreg,xmmreg KATMAI,SSE - MOVLPS xmmreg,mem KATMAI,SSE - MOVLPS mem,xmmreg KATMAI,SSE - MOVHLPS xmmreg,xmmreg KATMAI,SSE - MOVMSKPS reg32,xmmreg KATMAI,SSE - MOVMSKPS reg64,xmmreg X64,SSE - MOVNTPS mem,xmmreg KATMAI,SSE - MOVSS xmmreg,mem KATMAI,SSE - MOVSS mem,xmmreg KATMAI,SSE - MOVSS xmmreg,xmmreg KATMAI,SSE - MOVSS xmmreg,xmmreg KATMAI,SSE - MOVUPS xmmreg,mem KATMAI,SSE - MOVUPS mem,xmmreg KATMAI,SSE - MOVUPS xmmreg,xmmreg KATMAI,SSE - MOVUPS xmmreg,xmmreg KATMAI,SSE - MULPS xmmreg,xmmrm KATMAI,SSE - MULSS xmmreg,xmmrm KATMAI,SSE - ORPS xmmreg,xmmrm KATMAI,SSE - RCPPS xmmreg,xmmrm KATMAI,SSE - RCPSS xmmreg,xmmrm KATMAI,SSE - RSQRTPS xmmreg,xmmrm KATMAI,SSE - RSQRTSS xmmreg,xmmrm KATMAI,SSE - SHUFPS xmmreg,mem,imm KATMAI,SSE - SHUFPS xmmreg,xmmreg,imm KATMAI,SSE - SQRTPS xmmreg,xmmrm KATMAI,SSE - SQRTSS xmmreg,xmmrm KATMAI,SSE - STMXCSR mem KATMAI,SSE,SD - SUBPS xmmreg,xmmrm KATMAI,SSE - SUBSS xmmreg,xmmrm KATMAI,SSE - UCOMISS xmmreg,xmmrm KATMAI,SSE - UNPCKHPS xmmreg,xmmrm KATMAI,SSE - UNPCKLPS xmmreg,xmmrm KATMAI,SSE - XORPS xmmreg,xmmrm KATMAI,SSE - - B.1.4 Introduced in Deschutes but necessary for SSE support - - FXRSTOR mem P6,SSE,FPU - FXSAVE mem P6,SSE,FPU - - B.1.5 XSAVE group (AVX and extended state) - - XGETBV NEHALEM - XSETBV NEHALEM,PRIV - XSAVE mem NEHALEM - XRSTOR mem NEHALEM - - B.1.6 Generic memory operations - - PREFETCHNTA mem KATMAI - PREFETCHT0 mem KATMAI - PREFETCHT1 mem KATMAI - PREFETCHT2 mem KATMAI - SFENCE KATMAI - - B.1.7 New MMX instructions introduced in Katmai - - MASKMOVQ mmxreg,mmxreg KATMAI,MMX - MOVNTQ mem,mmxreg KATMAI,MMX - PAVGB mmxreg,mmxrm KATMAI,MMX - PAVGW mmxreg,mmxrm KATMAI,MMX - PEXTRW reg32,mmxreg,imm KATMAI,MMX - PINSRW mmxreg,mem,imm KATMAI,MMX - PINSRW mmxreg,rm16,imm KATMAI,MMX - PINSRW mmxreg,reg32,imm KATMAI,MMX - PMAXSW mmxreg,mmxrm KATMAI,MMX - PMAXUB mmxreg,mmxrm KATMAI,MMX - PMINSW mmxreg,mmxrm KATMAI,MMX - PMINUB mmxreg,mmxrm KATMAI,MMX - PMOVMSKB reg32,mmxreg KATMAI,MMX - PMULHUW mmxreg,mmxrm KATMAI,MMX - PSADBW mmxreg,mmxrm KATMAI,MMX - PSHUFW mmxreg,mmxrm,imm KATMAI,MMX2 - - B.1.8 AMD Enhanced 3DNow! (Athlon) instructions - - PF2IW mmxreg,mmxrm PENT,3DNOW - PFNACC mmxreg,mmxrm PENT,3DNOW - PFPNACC mmxreg,mmxrm PENT,3DNOW - PI2FW mmxreg,mmxrm PENT,3DNOW - PSWAPD mmxreg,mmxrm PENT,3DNOW - - B.1.9 Willamette SSE2 Cacheability Instructions - - MASKMOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 - CLFLUSH mem WILLAMETTE,SSE2 - MOVNTDQ mem,xmmreg WILLAMETTE,SSE2,SO - MOVNTI mem,reg32 WILLAMETTE,SD - MOVNTI mem,reg64 X64 - MOVNTPD mem,xmmreg WILLAMETTE,SSE2,SO - LFENCE WILLAMETTE,SSE2 - MFENCE WILLAMETTE,SSE2 - -B.1.10 Willamette MMX instructions (SSE2 SIMD Integer Instructions) - - MOVD mem,xmmreg WILLAMETTE,SSE2,SD - MOVD xmmreg,mem WILLAMETTE,SSE2,SD - MOVD xmmreg,rm32 WILLAMETTE,SSE2 - MOVD rm32,xmmreg WILLAMETTE,SSE2 - MOVDQA xmmreg,xmmreg WILLAMETTE,SSE2 - MOVDQA mem,xmmreg WILLAMETTE,SSE2,SO - MOVDQA xmmreg,mem WILLAMETTE,SSE2,SO - MOVDQA xmmreg,xmmreg WILLAMETTE,SSE2 - MOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 - MOVDQU mem,xmmreg WILLAMETTE,SSE2,SO - MOVDQU xmmreg,mem WILLAMETTE,SSE2,SO - MOVDQU xmmreg,xmmreg WILLAMETTE,SSE2 - MOVDQ2Q mmxreg,xmmreg WILLAMETTE,SSE2 - MOVQ xmmreg,xmmreg WILLAMETTE,SSE2 - MOVQ xmmreg,xmmreg WILLAMETTE,SSE2 - MOVQ mem,xmmreg WILLAMETTE,SSE2 - MOVQ xmmreg,mem WILLAMETTE,SSE2 - MOVQ xmmreg,rm64 X64,SSE2 - MOVQ rm64,xmmreg X64,SSE2 - MOVQ2DQ xmmreg,mmxreg WILLAMETTE,SSE2 - PACKSSWB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PACKSSDW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PACKUSWB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDQ mmxreg,mmxrm WILLAMETTE,MMX - PADDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDSB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDUSB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PADDUSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PAND xmmreg,xmmrm WILLAMETTE,SSE2,SO - PANDN xmmreg,xmmrm WILLAMETTE,SSE2,SO - PAVGB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PAVGW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPEQB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPEQW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPEQD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPGTB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPGTW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PCMPGTD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PEXTRW reg32,xmmreg,imm WILLAMETTE,SSE2 - PINSRW xmmreg,reg16,imm WILLAMETTE,SSE2 - PINSRW xmmreg,reg32,imm WILLAMETTE,SSE2,ND - PINSRW xmmreg,mem,imm WILLAMETTE,SSE2 - PINSRW xmmreg,mem16,imm WILLAMETTE,SSE2 - PMADDWD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMAXSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMAXUB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMINSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMINUB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMOVMSKB reg32,xmmreg WILLAMETTE,SSE2 - PMULHUW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMULHW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMULLW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PMULUDQ mmxreg,mmxrm WILLAMETTE,SSE2,SO - PMULUDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - POR xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSADBW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSHUFD xmmreg,xmmreg,imm WILLAMETTE,SSE2 - PSHUFD xmmreg,mem,imm WILLAMETTE,SSE22 - PSHUFHW xmmreg,xmmreg,imm WILLAMETTE,SSE2 - PSHUFHW xmmreg,mem,imm WILLAMETTE,SSE22 - PSHUFLW xmmreg,xmmreg,imm WILLAMETTE,SSE2 - PSHUFLW xmmreg,mem,imm WILLAMETTE,SSE22 - PSLLDQ xmmreg,imm WILLAMETTE,SSE2,AR1 - PSLLW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSLLW xmmreg,imm WILLAMETTE,SSE2,AR1 - PSLLD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSLLD xmmreg,imm WILLAMETTE,SSE2,AR1 - PSLLQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSLLQ xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRAW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSRAW xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRAD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSRAD xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRLDQ xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRLW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSRLW xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRLD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSRLD xmmreg,imm WILLAMETTE,SSE2,AR1 - PSRLQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSRLQ xmmreg,imm WILLAMETTE,SSE2,AR1 - PSUBB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBQ mmxreg,mmxrm WILLAMETTE,SSE2,SO - PSUBQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBSB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBUSB xmmreg,xmmrm WILLAMETTE,SSE2,SO - PSUBUSW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKHBW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKHWD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKHDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKHQDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKLBW xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKLWD xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKLDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PUNPCKLQDQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - PXOR xmmreg,xmmrm WILLAMETTE,SSE2,SO - -B.1.11 Willamette Streaming SIMD instructions (SSE2) - - ADDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - ADDSD xmmreg,xmmrm WILLAMETTE,SSE2 - ANDNPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - ANDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPEQPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPEQSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPLEPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPLESD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPLTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPLTSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPNEQPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPNEQSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPNLEPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPNLESD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPNLTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPNLTSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPORDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPORDSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPUNORDPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - CMPUNORDSD xmmreg,xmmrm WILLAMETTE,SSE2 - CMPPD xmmreg,xmmrm,imm WILLAMETTE,SSE22 - CMPSD xmmreg,xmmrm,imm WILLAMETTE,SSE2 - COMISD xmmreg,xmmrm WILLAMETTE,SSE2 - CVTDQ2PD xmmreg,xmmrm WILLAMETTE,SSE2 - CVTDQ2PS xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTPD2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTPD2PI mmxreg,xmmrm WILLAMETTE,SSE2,SO - CVTPD2PS xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTPI2PD xmmreg,mmxrm WILLAMETTE,SSE2 - CVTPS2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTPS2PD xmmreg,xmmrm WILLAMETTE,SSE2 - CVTSD2SI reg32,xmmreg WILLAMETTE,SSE2,AR1 - CVTSD2SI reg32,mem WILLAMETTE,SSE2,AR1 - CVTSD2SI reg64,xmmreg X64,SSE2,AR1 - CVTSD2SI reg64,mem X64,SSE2,AR1 - CVTSD2SS xmmreg,xmmrm WILLAMETTE,SSE2 - CVTSI2SD xmmreg,mem WILLAMETTE,SSE2,SD,AR1,ND - CVTSI2SD xmmreg,rm32 WILLAMETTE,SSE2,SD,AR1 - CVTSI2SD xmmreg,rm64 X64,SSE2,AR1 - CVTSS2SD xmmreg,xmmrm WILLAMETTE,SSE2,SD - CVTTPD2PI mmxreg,xmmrm WILLAMETTE,SSE2,SO - CVTTPD2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTTPS2DQ xmmreg,xmmrm WILLAMETTE,SSE2,SO - CVTTSD2SI reg32,xmmreg WILLAMETTE,SSE2,AR1 - CVTTSD2SI reg32,mem WILLAMETTE,SSE2,AR1 - CVTTSD2SI reg64,xmmreg X64,SSE2,AR1 - CVTTSD2SI reg64,mem X64,SSE2,AR1 - DIVPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - DIVSD xmmreg,xmmrm WILLAMETTE,SSE2 - MAXPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - MAXSD xmmreg,xmmrm WILLAMETTE,SSE2 - MINPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - MINSD xmmreg,xmmrm WILLAMETTE,SSE2 - MOVAPD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVAPD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVAPD mem,xmmreg WILLAMETTE,SSE2,SO - MOVAPD xmmreg,mem WILLAMETTE,SSE2,SO - MOVHPD mem,xmmreg WILLAMETTE,SSE2 - MOVHPD xmmreg,mem WILLAMETTE,SSE2 - MOVLPD mem,xmmreg WILLAMETTE,SSE2 - MOVLPD xmmreg,mem WILLAMETTE,SSE2 - MOVMSKPD reg32,xmmreg WILLAMETTE,SSE2 - MOVMSKPD reg64,xmmreg X64,SSE2 - MOVSD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVSD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVSD mem,xmmreg WILLAMETTE,SSE2 - MOVSD xmmreg,mem WILLAMETTE,SSE2 - MOVUPD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVUPD xmmreg,xmmreg WILLAMETTE,SSE2 - MOVUPD mem,xmmreg WILLAMETTE,SSE2,SO - MOVUPD xmmreg,mem WILLAMETTE,SSE2,SO - MULPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - MULSD xmmreg,xmmrm WILLAMETTE,SSE2 - ORPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - SHUFPD xmmreg,xmmreg,imm WILLAMETTE,SSE2 - SHUFPD xmmreg,mem,imm WILLAMETTE,SSE2 - SQRTPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - SQRTSD xmmreg,xmmrm WILLAMETTE,SSE2 - SUBPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - SUBSD xmmreg,xmmrm WILLAMETTE,SSE2 - UCOMISD xmmreg,xmmrm WILLAMETTE,SSE2 - UNPCKHPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - UNPCKLPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - XORPD xmmreg,xmmrm WILLAMETTE,SSE2,SO - -B.1.12 Prescott New Instructions (SSE3) - - ADDSUBPD xmmreg,xmmrm PRESCOTT,SSE3,SO - ADDSUBPS xmmreg,xmmrm PRESCOTT,SSE3,SO - HADDPD xmmreg,xmmrm PRESCOTT,SSE3,SO - HADDPS xmmreg,xmmrm PRESCOTT,SSE3,SO - HSUBPD xmmreg,xmmrm PRESCOTT,SSE3,SO - HSUBPS xmmreg,xmmrm PRESCOTT,SSE3,SO - LDDQU xmmreg,mem PRESCOTT,SSE3,SO - MOVDDUP xmmreg,xmmrm PRESCOTT,SSE3 - MOVSHDUP xmmreg,xmmrm PRESCOTT,SSE3 - MOVSLDUP xmmreg,xmmrm PRESCOTT,SSE3 - -B.1.13 VMX Instructions - - VMCALL VMX - VMCLEAR mem VMX - VMLAUNCH VMX - VMLOAD X64,VMX - VMMCALL X64,VMX - VMPTRLD mem VMX - VMPTRST mem VMX - VMREAD rm32,reg32 VMX,NOLONG,SD - VMREAD rm64,reg64 X64,VMX - VMRESUME VMX - VMRUN X64,VMX - VMSAVE X64,VMX - VMWRITE reg32,rm32 VMX,NOLONG,SD - VMWRITE reg64,rm64 X64,VMX - VMXOFF VMX - VMXON mem VMX - -B.1.14 Extended Page Tables VMX instructions - - INVEPT reg32,mem VMX,SO,NOLONG - INVEPT reg64,mem VMX,SO,LONG - INVVPID reg32,mem VMX,SO,NOLONG - INVVPID reg64,mem VMX,SO,LONG - -B.1.15 Tejas New Instructions (SSSE3) - - PABSB mmxreg,mmxrm SSSE3,MMX - PABSB xmmreg,xmmrm SSSE3 - PABSW mmxreg,mmxrm SSSE3,MMX - PABSW xmmreg,xmmrm SSSE3 - PABSD mmxreg,mmxrm SSSE3,MMX - PABSD xmmreg,xmmrm SSSE3 - PALIGNR mmxreg,mmxrm,imm SSSE3,MMX - PALIGNR xmmreg,xmmrm,imm SSSE3 - PHADDW mmxreg,mmxrm SSSE3,MMX - PHADDW xmmreg,xmmrm SSSE3 - PHADDD mmxreg,mmxrm SSSE3,MMX - PHADDD xmmreg,xmmrm SSSE3 - PHADDSW mmxreg,mmxrm SSSE3,MMX - PHADDSW xmmreg,xmmrm SSSE3 - PHSUBW mmxreg,mmxrm SSSE3,MMX - PHSUBW xmmreg,xmmrm SSSE3 - PHSUBD mmxreg,mmxrm SSSE3,MMX - PHSUBD xmmreg,xmmrm SSSE3 - PHSUBSW mmxreg,mmxrm SSSE3,MMX - PHSUBSW xmmreg,xmmrm SSSE3 - PMADDUBSW mmxreg,mmxrm SSSE3,MMX - PMADDUBSW xmmreg,xmmrm SSSE3 - PMULHRSW mmxreg,mmxrm SSSE3,MMX - PMULHRSW xmmreg,xmmrm SSSE3 - PSHUFB mmxreg,mmxrm SSSE3,MMX - PSHUFB xmmreg,xmmrm SSSE3 - PSIGNB mmxreg,mmxrm SSSE3,MMX - PSIGNB xmmreg,xmmrm SSSE3 - PSIGNW mmxreg,mmxrm SSSE3,MMX - PSIGNW xmmreg,xmmrm SSSE3 - PSIGND mmxreg,mmxrm SSSE3,MMX - PSIGND xmmreg,xmmrm SSSE3 - -B.1.16 AMD SSE4A - - EXTRQ xmmreg,imm,imm SSE4A,AMD - EXTRQ xmmreg,xmmreg SSE4A,AMD - INSERTQ xmmreg,xmmreg,imm,imm SSE4A,AMD - INSERTQ xmmreg,xmmreg SSE4A,AMD - MOVNTSD mem,xmmreg SSE4A,AMD - MOVNTSS mem,xmmreg SSE4A,AMD,SD - -B.1.17 New instructions in Barcelona - - LZCNT reg16,rm16 P6,AMD - LZCNT reg32,rm32 P6,AMD - LZCNT reg64,rm64 X64,AMD - -B.1.18 Penryn New Instructions (SSE4.1) - - BLENDPD xmmreg,xmmrm,imm SSE41 - BLENDPS xmmreg,xmmrm,imm SSE41 - BLENDVPD xmmreg,xmmrm,xmm0 SSE41 - BLENDVPS xmmreg,xmmrm,xmm0 SSE41 - DPPD xmmreg,xmmrm,imm SSE41 - DPPS xmmreg,xmmrm,imm SSE41 - EXTRACTPS rm32,xmmreg,imm SSE41 - EXTRACTPS reg64,xmmreg,imm SSE41,X64 - INSERTPS xmmreg,xmmrm,imm SSE41,SD - MOVNTDQA xmmreg,mem SSE41 - MPSADBW xmmreg,xmmrm,imm SSE41 - PACKUSDW xmmreg,xmmrm SSE41 - PBLENDVB xmmreg,xmmrm,xmm0 SSE41 - PBLENDW xmmreg,xmmrm,imm SSE41 - PCMPEQQ xmmreg,xmmrm SSE41 - PEXTRB reg32,xmmreg,imm SSE41 - PEXTRB mem8,xmmreg,imm SSE41 - PEXTRB reg64,xmmreg,imm SSE41,X64 - PEXTRD rm32,xmmreg,imm SSE41 - PEXTRQ rm64,xmmreg,imm SSE41,X64 - PEXTRW reg32,xmmreg,imm SSE41 - PEXTRW mem16,xmmreg,imm SSE41 - PEXTRW reg64,xmmreg,imm SSE41,X64 - PHMINPOSUW xmmreg,xmmrm SSE41 - PINSRB xmmreg,mem,imm SSE41 - PINSRB xmmreg,rm8,imm SSE41 - PINSRB xmmreg,reg32,imm SSE41 - PINSRD xmmreg,mem,imm SSE41 - PINSRD xmmreg,rm32,imm SSE41 - PINSRQ xmmreg,mem,imm SSE41,X64 - PINSRQ xmmreg,rm64,imm SSE41,X64 - PMAXSB xmmreg,xmmrm SSE41 - PMAXSD xmmreg,xmmrm SSE41 - PMAXUD xmmreg,xmmrm SSE41 - PMAXUW xmmreg,xmmrm SSE41 - PMINSB xmmreg,xmmrm SSE41 - PMINSD xmmreg,xmmrm SSE41 - PMINUD xmmreg,xmmrm SSE41 - PMINUW xmmreg,xmmrm SSE41 - PMOVSXBW xmmreg,xmmrm SSE41 - PMOVSXBD xmmreg,xmmrm SSE41,SD - PMOVSXBQ xmmreg,xmmrm SSE41,SW - PMOVSXWD xmmreg,xmmrm SSE41 - PMOVSXWQ xmmreg,xmmrm SSE41,SD - PMOVSXDQ xmmreg,xmmrm SSE41 - PMOVZXBW xmmreg,xmmrm SSE41 - PMOVZXBD xmmreg,xmmrm SSE41,SD - PMOVZXBQ xmmreg,xmmrm SSE41,SW - PMOVZXWD xmmreg,xmmrm SSE41 - PMOVZXWQ xmmreg,xmmrm SSE41,SD - PMOVZXDQ xmmreg,xmmrm SSE41 - PMULDQ xmmreg,xmmrm SSE41 - PMULLD xmmreg,xmmrm SSE41 - PTEST xmmreg,xmmrm SSE41 - ROUNDPD xmmreg,xmmrm,imm SSE41 - ROUNDPS xmmreg,xmmrm,imm SSE41 - ROUNDSD xmmreg,xmmrm,imm SSE41 - ROUNDSS xmmreg,xmmrm,imm SSE41 - -B.1.19 Nehalem New Instructions (SSE4.2) - - CRC32 reg32,rm8 SSE42 - CRC32 reg32,rm16 SSE42 - CRC32 reg32,rm32 SSE42 - CRC32 reg64,rm8 SSE42,X64 - CRC32 reg64,rm64 SSE42,X64 - PCMPESTRI xmmreg,xmmrm,imm SSE42 - PCMPESTRM xmmreg,xmmrm,imm SSE42 - PCMPISTRI xmmreg,xmmrm,imm SSE42 - PCMPISTRM xmmreg,xmmrm,imm SSE42 - PCMPGTQ xmmreg,xmmrm SSE42 - POPCNT reg16,rm16 NEHALEM,SW - POPCNT reg32,rm32 NEHALEM,SD - POPCNT reg64,rm64 NEHALEM,X64 - -B.1.20 Intel SMX - - GETSEC KATMAI - -B.1.21 Geode (Cyrix) 3DNow! additions - - PFRCPV mmxreg,mmxrm PENT,3DNOW,CYRIX - PFRSQRTV mmxreg,mmxrm PENT,3DNOW,CYRIX - -B.1.22 Intel new instructions in ??? - - MOVBE reg16,mem16 NEHALEM - MOVBE reg32,mem32 NEHALEM - MOVBE reg64,mem64 NEHALEM - MOVBE mem16,reg16 NEHALEM - MOVBE mem32,reg32 NEHALEM - MOVBE mem64,reg64 NEHALEM - -B.1.23 Intel AES instructions - - AESENC xmmreg,xmmrm128 SSE,WESTMERE - AESENCLAST xmmreg,xmmrm128 SSE,WESTMERE - AESDEC xmmreg,xmmrm128 SSE,WESTMERE - AESDECLAST xmmreg,xmmrm128 SSE,WESTMERE - AESIMC xmmreg,xmmrm128 SSE,WESTMERE - AESKEYGENASSIST xmmreg,xmmrm128,imm8 SSE,WESTMERE - -B.1.24 Intel AVX AES instructions - - VAESENC xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VAESENCLAST xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VAESDEC xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VAESDECLAST xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VAESIMC xmmreg,xmmrm128 AVX,SANDYBRIDGE - VAESKEYGENASSIST xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - -B.1.25 Intel AVX instructions - - VADDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VADDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VADDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VADDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VADDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VADDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VADDSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VADDSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VADDSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VADDSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VANDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VANDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VANDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VANDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VANDNPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VANDNPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VANDNPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VANDNPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VBLENDPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VBLENDPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VBLENDPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VBLENDPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VBLENDVPD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VBLENDVPD xmmreg,xmmrm128,xmm0 AVX,SANDYBRIDGE - VBLENDVPD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VBLENDVPD ymmreg,ymmrm256,ymm0 AVX,SANDYBRIDGE - VBLENDVPS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VBLENDVPS xmmreg,xmmrm128,xmm0 AVX,SANDYBRIDGE - VBLENDVPS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VBLENDVPD ymmreg,ymmrm256,ymm0 AVX,SANDYBRIDGE - VBROADCASTSS xmmreg,mem32 AVX,SANDYBRIDGE - VBROADCASTSS ymmreg,mem32 AVX,SANDYBRIDGE - VBROADCASTSD ymmreg,mem64 AVX,SANDYBRIDGE - VBROADCASTF128 ymmreg,mem128 AVX,SANDYBRIDGE - VCMPEQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPUNORDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPUNORDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPORDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPORDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPFALSEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPFALSEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGTPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGTPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPTRUEPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPTRUEPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLT_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLT_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLE_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLE_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPUNORD_SPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPUNORD_SPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLT_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLT_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLE_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLE_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPORD_SPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPORD_SPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGE_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGE_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGT_UQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGT_UQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPFALSE_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPFALSE_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_OSPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_OSPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGE_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGE_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGT_OQPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGT_OQPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPTRUE_USPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPTRUE_USPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VCMPPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VCMPEQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPUNORDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPUNORDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPORDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPORDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPFALSEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPFALSEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGTPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGTPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPTRUEPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPTRUEPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLT_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLT_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPLE_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPLE_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPUNORD_SPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPUNORD_SPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLT_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLT_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNLE_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNLE_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPORD_SPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPORD_SPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPEQ_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPEQ_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGE_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGE_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNGT_UQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNGT_UQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPFALSE_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPFALSE_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPNEQ_OSPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPNEQ_OSPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGE_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGE_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPGT_OQPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPGT_OQPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPTRUE_USPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VCMPTRUE_USPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VCMPPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VCMPPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VCMPEQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPLTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPLESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPUNORDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNEQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNLTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNLESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPORDSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPEQ_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNGESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNGTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPFALSESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNEQ_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPGESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPGTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPTRUESD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPEQ_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPLT_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPLE_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPUNORD_SSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNEQ_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNLT_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNLE_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPORD_SSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPEQ_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNGE_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNGT_UQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPFALSE_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPNEQ_OSSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPGE_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPGT_OQSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPTRUE_USSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCMPSD xmmreg,xmmreg*,xmmrm64,imm8 AVX,SANDYBRIDGE - VCMPEQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPLTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPLESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPUNORDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNEQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNLTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNLESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPORDSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPEQ_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNGESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNGTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPFALSESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNEQ_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPGESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPGTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPTRUESS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPEQ_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPLT_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPLE_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPUNORD_SSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNEQ_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNLT_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNLE_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPORD_SSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPEQ_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNGE_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNGT_UQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPFALSE_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPNEQ_OSSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPGE_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPGT_OQSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPTRUE_USSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCMPSS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE - VCOMISD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VCOMISS xmmreg,xmmrm32 AVX,SANDYBRIDGE - VCVTDQ2PD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VCVTDQ2PD ymmreg,xmmrm128 AVX,SANDYBRIDGE - VCVTDQ2PS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VCVTDQ2PS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VCVTPD2DQ xmmreg,xmmreg AVX,SANDYBRIDGE - VCVTPD2DQ xmmreg,mem128 AVX,SANDYBRIDGE,SO - VCVTPD2DQ xmmreg,ymmreg AVX,SANDYBRIDGE - VCVTPD2DQ xmmreg,mem256 AVX,SANDYBRIDGE,SY - VCVTPD2PS xmmreg,xmmreg AVX,SANDYBRIDGE - VCVTPD2PS xmmreg,mem128 AVX,SANDYBRIDGE,SO - VCVTPD2PS xmmreg,ymmreg AVX,SANDYBRIDGE - VCVTPD2PS xmmreg,mem256 AVX,SANDYBRIDGE,SY - VCVTPS2DQ xmmreg,xmmrm128 AVX,SANDYBRIDGE - VCVTPS2DQ ymmreg,ymmrm256 AVX,SANDYBRIDGE - VCVTPS2PD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VCVTPS2PD ymmreg,xmmrm128 AVX,SANDYBRIDGE - VCVTSD2SI reg32,xmmrm64 AVX,SANDYBRIDGE - VCVTSD2SI reg64,xmmrm64 AVX,SANDYBRIDGE,LONG - VCVTSD2SS xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VCVTSI2SD xmmreg,xmmreg*,rm32 AVX,SANDYBRIDGE,SD - VCVTSI2SD xmmreg,xmmreg*,mem32 AVX,SANDYBRIDGE,ND,SD - VCVTSI2SD xmmreg,xmmreg*,rm64 AVX,SANDYBRIDGE,LONG - VCVTSI2SS xmmreg,xmmreg*,rm32 AVX,SANDYBRIDGE,SD - VCVTSI2SS xmmreg,xmmreg*,mem32 AVX,SANDYBRIDGE,ND,SD - VCVTSI2SS xmmreg,xmmreg*,rm64 AVX,SANDYBRIDGE,LONG - VCVTSS2SD xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VCVTSS2SI reg32,xmmrm32 AVX,SANDYBRIDGE - VCVTSS2SI reg64,xmmrm32 AVX,SANDYBRIDGE,LONG - VCVTTPD2DQ xmmreg,xmmreg AVX,SANDYBRIDGE - VCVTTPD2DQ xmmreg,mem128 AVX,SANDYBRIDGE,SO - VCVTTPD2DQ xmmreg,ymmreg AVX,SANDYBRIDGE - VCVTTPD2DQ xmmreg,mem256 AVX,SANDYBRIDGE,SY - VCVTTPS2DQ xmmreg,xmmrm128 AVX,SANDYBRIDGE - VCVTTPS2DQ ymmreg,ymmrm256 AVX,SANDYBRIDGE - VCVTTSD2SI reg32,xmmrm64 AVX,SANDYBRIDGE - VCVTTSD2SI reg64,xmmrm64 AVX,SANDYBRIDGE,LONG - VCVTTSS2SI reg32,xmmrm32 AVX,SANDYBRIDGE - VCVTTSS2SI reg64,xmmrm32 AVX,SANDYBRIDGE,LONG - VDIVPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VDIVPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VDIVPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VDIVPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VDIVSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VDIVSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VDPPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VDPPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VDPPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VEXTRACTF128 xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE - VEXTRACTPS rm32,xmmreg,imm8 AVX,SANDYBRIDGE - VHADDPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VHADDPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VHADDPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VHADDPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VHSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VHSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VHSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VHSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VINSERTF128 ymmreg,ymmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VINSERTPS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE - VLDDQU xmmreg,mem128 AVX,SANDYBRIDGE - VLDQQU ymmreg,mem256 AVX,SANDYBRIDGE - VLDDQU ymmreg,mem256 AVX,SANDYBRIDGE - VLDMXCSR mem32 AVX,SANDYBRIDGE - VMASKMOVDQU xmmreg,xmmreg AVX,SANDYBRIDGE - VMASKMOVPS xmmreg,xmmreg,mem128 AVX,SANDYBRIDGE - VMASKMOVPS ymmreg,ymmreg,mem256 AVX,SANDYBRIDGE - VMASKMOVPS mem128,xmmreg,xmmreg AVX,SANDYBRIDGE,SO - VMASKMOVPS mem256,xmmreg,xmmreg AVX,SANDYBRIDGE,SY - VMASKMOVPD xmmreg,xmmreg,mem128 AVX,SANDYBRIDGE - VMASKMOVPD ymmreg,ymmreg,mem256 AVX,SANDYBRIDGE - VMASKMOVPD mem128,xmmreg,xmmreg AVX,SANDYBRIDGE - VMASKMOVPD mem256,ymmreg,ymmreg AVX,SANDYBRIDGE - VMAXPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMAXPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMAXPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMAXPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMAXSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VMAXSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VMINPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMINPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMINPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMINPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMINSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VMINSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VMOVAPD xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVAPD xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVAPD ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVAPD ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVAPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVAPS xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVAPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVAPS ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVQ xmmreg,xmmrm64 AVX,SANDYBRIDGE - VMOVQ xmmrm64,xmmreg AVX,SANDYBRIDGE - VMOVQ xmmreg,rm64 AVX,SANDYBRIDGE,LONG - VMOVQ rm64,xmmreg AVX,SANDYBRIDGE,LONG - VMOVD xmmreg,rm32 AVX,SANDYBRIDGE - VMOVD rm32,xmmreg AVX,SANDYBRIDGE - VMOVDDUP xmmreg,xmmrm64 AVX,SANDYBRIDGE - VMOVDDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVDQA xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVDQA xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVQQA ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVQQA ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVDQA ymmreg,ymmrm AVX,SANDYBRIDGE - VMOVDQA ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVDQU xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVDQU xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVQQU ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVQQU ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVDQU ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVDQU ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVHLPS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVHPD xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE - VMOVHPD mem64,xmmreg AVX,SANDYBRIDGE - VMOVHPS xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE - VMOVHPS mem64,xmmreg AVX,SANDYBRIDGE - VMOVLHPS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVLPD xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE - VMOVLPD mem64,xmmreg AVX,SANDYBRIDGE - VMOVLPS xmmreg,xmmreg*,mem64 AVX,SANDYBRIDGE - VMOVLPS mem64,xmmreg AVX,SANDYBRIDGE - VMOVMSKPD reg64,xmmreg AVX,SANDYBRIDGE,LONG - VMOVMSKPD reg32,xmmreg AVX,SANDYBRIDGE - VMOVMSKPD reg64,ymmreg AVX,SANDYBRIDGE,LONG - VMOVMSKPD reg32,ymmreg AVX,SANDYBRIDGE - VMOVMSKPS reg64,xmmreg AVX,SANDYBRIDGE,LONG - VMOVMSKPS reg32,xmmreg AVX,SANDYBRIDGE - VMOVMSKPS reg64,ymmreg AVX,SANDYBRIDGE,LONG - VMOVMSKPS reg32,ymmreg AVX,SANDYBRIDGE - VMOVNTDQ mem128,xmmreg AVX,SANDYBRIDGE - VMOVNTQQ mem256,ymmreg AVX,SANDYBRIDGE - VMOVNTDQ mem256,ymmreg AVX,SANDYBRIDGE - VMOVNTDQA xmmreg,mem128 AVX,SANDYBRIDGE - VMOVNTPD mem128,xmmreg AVX,SANDYBRIDGE - VMOVNTPD mem256,ymmreg AVX,SANDYBRIDGE - VMOVNTPS mem128,xmmreg AVX,SANDYBRIDGE - VMOVNTPS mem128,ymmreg AVX,SANDYBRIDGE - VMOVSD xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVSD xmmreg,mem64 AVX,SANDYBRIDGE - VMOVSD xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVSD mem64,xmmreg AVX,SANDYBRIDGE - VMOVSHDUP xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVSHDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVSLDUP xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVSLDUP ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVSS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVSS xmmreg,mem64 AVX,SANDYBRIDGE - VMOVSS xmmreg,xmmreg*,xmmreg AVX,SANDYBRIDGE - VMOVSS mem64,xmmreg AVX,SANDYBRIDGE - VMOVUPD xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVUPD xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVUPD ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVUPD ymmrm256,ymmreg AVX,SANDYBRIDGE - VMOVUPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VMOVUPS xmmrm128,xmmreg AVX,SANDYBRIDGE - VMOVUPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VMOVUPS ymmrm256,ymmreg AVX,SANDYBRIDGE - VMPSADBW xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VMULPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMULPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMULPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VMULPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VMULSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VMULSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VORPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VORPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VORPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VORPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VPABSB xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPABSW xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPABSD xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPACKSSWB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPACKSSDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPACKUSWB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPACKUSDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDUSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPADDUSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPALIGNR xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VPAND xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPANDN xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPAVGB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPAVGW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPBLENDVB xmmreg,xmmreg*,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPBLENDW xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VPCMPESTRI xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPCMPESTRM xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPCMPISTRI xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPCMPISTRM xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPCMPEQB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPEQW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPEQD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPEQQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPGTB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPGTW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPGTD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCMPGTQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPERMILPD xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILPD ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILPD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPERMILPD ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VPERMILTD2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILTD2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILTD2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILTD2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILMO2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILMO2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILMO2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILMO2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILMZ2PD xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILMZ2PD xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILMZ2PD ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILMZ2PD ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMIL2PD xmmreg,xmmreg,xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE - VPERMIL2PD xmmreg,xmmreg,xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPERMIL2PD ymmreg,ymmreg,ymmrm256,ymmreg,imm8 AVX,SANDYBRIDGE - VPERMIL2PD ymmreg,ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VPERMILPS xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILPS ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILPS xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPERMILPS ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VPERMILTD2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILTD2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILTD2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILTD2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILMO2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILMO2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILMO2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILMO2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMILMZ2PS xmmreg,xmmreg,xmmrm128,xmmreg AVX,SANDYBRIDGE - VPERMILMZ2PS xmmreg,xmmreg,xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPERMILMZ2PS ymmreg,ymmreg,ymmrm256,ymmreg AVX,SANDYBRIDGE - VPERMILMZ2PS ymmreg,ymmreg,ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPERMIL2PS xmmreg,xmmreg,xmmrm128,xmmreg,imm8 AVX,SANDYBRIDGE - VPERMIL2PS xmmreg,xmmreg,xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPERMIL2PS ymmreg,ymmreg,ymmrm256,ymmreg,imm8 AVX,SANDYBRIDGE - VPERMIL2PS ymmreg,ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VPERM2F128 ymmreg,ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VPEXTRB reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG - VPEXTRB reg32,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRB mem8,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRW reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG - VPEXTRW reg32,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRW mem16,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRW reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG - VPEXTRW reg32,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRW mem16,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRD reg64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG - VPEXTRD rm32,xmmreg,imm8 AVX,SANDYBRIDGE - VPEXTRQ rm64,xmmreg,imm8 AVX,SANDYBRIDGE,LONG - VPHADDW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPHADDD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPHADDSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPHMINPOSUW xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPHSUBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPHSUBD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPHSUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPINSRB xmmreg,xmmreg*,mem8,imm8 AVX,SANDYBRIDGE - VPINSRB xmmreg,xmmreg*,rm8,imm8 AVX,SANDYBRIDGE - VPINSRB xmmreg,xmmreg*,reg32,imm8 AVX,SANDYBRIDGE - VPINSRW xmmreg,xmmreg*,mem16,imm8 AVX,SANDYBRIDGE - VPINSRW xmmreg,xmmreg*,rm16,imm8 AVX,SANDYBRIDGE - VPINSRW xmmreg,xmmreg*,reg32,imm8 AVX,SANDYBRIDGE - VPINSRD xmmreg,xmmreg*,mem32,imm8 AVX,SANDYBRIDGE - VPINSRD xmmreg,xmmreg*,rm32,imm8 AVX,SANDYBRIDGE - VPINSRQ xmmreg,xmmreg*,mem64,imm8 AVX,SANDYBRIDGE,LONG - VPINSRQ xmmreg,xmmreg*,rm64,imm8 AVX,SANDYBRIDGE,LONG - VPMADDWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMADDUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXSD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXUB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMAXUD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINSD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINUB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMINUD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMOVMSKB reg64,xmmreg AVX,SANDYBRIDGE,LONG - VPMOVMSKB reg32,xmmreg AVX,SANDYBRIDGE - VPMOVSXBW xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMOVSXBD xmmreg,xmmrm32 AVX,SANDYBRIDGE - VPMOVSXBQ xmmreg,xmmrm16 AVX,SANDYBRIDGE - VPMOVSXWD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMOVSXWQ xmmreg,xmmrm32 AVX,SANDYBRIDGE - VPMOVSXDQ xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMOVZXBW xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMOVZXBD xmmreg,xmmrm32 AVX,SANDYBRIDGE - VPMOVZXBQ xmmreg,xmmrm16 AVX,SANDYBRIDGE - VPMOVZXWD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMOVZXWQ xmmreg,xmmrm32 AVX,SANDYBRIDGE - VPMOVZXDQ xmmreg,xmmrm64 AVX,SANDYBRIDGE - VPMULHUW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULHRSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULHW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULUDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPMULDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPOR xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSADBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSHUFB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSHUFD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPSHUFHW xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPSHUFLW xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VPSIGNB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSIGNW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSIGND xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSLLDQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRLDQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSLLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSLLW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSLLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSLLD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSLLQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSLLQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRAW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSRAW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRAD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSRAD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRLW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSRLW xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRLD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSRLD xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPSRLQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSRLQ xmmreg,xmmreg*,imm8 AVX,SANDYBRIDGE - VPTEST xmmreg,xmmrm128 AVX,SANDYBRIDGE - VPTEST ymmreg,ymmrm256 AVX,SANDYBRIDGE - VPSUBB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBUSB xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPSUBUSW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKHBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKHWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKHDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKLBW xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKLWD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKLDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPUNPCKLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPXOR xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VRCPPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VRCPPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VRCPSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VRSQRTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VRSQRTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VRSQRTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VROUNDPD xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VROUNDPD ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VROUNDPS xmmreg,xmmrm128,imm8 AVX,SANDYBRIDGE - VROUNDPS ymmreg,ymmrm256,imm8 AVX,SANDYBRIDGE - VROUNDSD xmmreg,xmmreg*,xmmrm64,imm8 AVX,SANDYBRIDGE - VROUNDSS xmmreg,xmmreg*,xmmrm32,imm8 AVX,SANDYBRIDGE - VSHUFPD xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VSHUFPD ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VSHUFPS xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - VSHUFPS ymmreg,ymmreg*,ymmrm256,imm8 AVX,SANDYBRIDGE - VSQRTPD xmmreg,xmmrm128 AVX,SANDYBRIDGE - VSQRTPD ymmreg,ymmrm256 AVX,SANDYBRIDGE - VSQRTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VSQRTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VSQRTSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VSQRTSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VSTMXCSR mem32 AVX,SANDYBRIDGE - VSUBPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VSUBPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VSUBPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VSUBPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VSUBSD xmmreg,xmmreg*,xmmrm64 AVX,SANDYBRIDGE - VSUBSS xmmreg,xmmreg*,xmmrm32 AVX,SANDYBRIDGE - VTESTPS xmmreg,xmmrm128 AVX,SANDYBRIDGE - VTESTPS ymmreg,ymmrm256 AVX,SANDYBRIDGE - VTESTPD xmmreg,xmmrm128 AVX,SANDYBRIDGE - VTESTPD ymmreg,ymmrm256 AVX,SANDYBRIDGE - VUCOMISD xmmreg,xmmrm64 AVX,SANDYBRIDGE - VUCOMISS xmmreg,xmmrm32 AVX,SANDYBRIDGE - VUNPCKHPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VUNPCKHPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VUNPCKHPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VUNPCKHPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VUNPCKLPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VUNPCKLPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VUNPCKLPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VUNPCKLPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VXORPD xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VXORPD ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VXORPS xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VXORPS ymmreg,ymmreg*,ymmrm256 AVX,SANDYBRIDGE - VZEROALL AVX,SANDYBRIDGE - VZEROUPPER AVX,SANDYBRIDGE - -B.1.26 Intel Carry-Less Multiplication instructions (CLMUL) - - PCLMULLQLQDQ xmmreg,xmmrm128 SSE,WESTMERE - PCLMULHQLQDQ xmmreg,xmmrm128 SSE,WESTMERE - PCLMULLQHQDQ xmmreg,xmmrm128 SSE,WESTMERE - PCLMULHQHQDQ xmmreg,xmmrm128 SSE,WESTMERE - PCLMULQDQ xmmreg,xmmrm128,imm8 SSE,WESTMERE - -B.1.27 Intel AVX Carry-Less Multiplication instructions (CLMUL) - - VPCLMULLQLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCLMULHQLQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCLMULLQHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCLMULHQHQDQ xmmreg,xmmreg*,xmmrm128 AVX,SANDYBRIDGE - VPCLMULQDQ xmmreg,xmmreg*,xmmrm128,imm8 AVX,SANDYBRIDGE - -B.1.28 Intel Fused Multiply-Add instructions (FMA) - - VFMADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADDSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMADDSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMSUBADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFMSUBADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMADD321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMADD321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB132PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB132PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB132PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB132PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB312PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB312PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB312PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB312PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB213PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB213PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB213PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB213PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB123PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB123PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB123PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB123PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB231PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB231PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB231PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB231PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB321PS xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB321PS ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFNMSUB321PD xmmreg,xmmreg,xmmrm128 FMA,FUTURE - VFNMSUB321PD ymmreg,ymmreg,ymmrm256 FMA,FUTURE - VFMADD132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMADD312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMADD213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMADD123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMADD231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMADD321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMADD321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFMSUB321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFMSUB321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMADD321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMADD321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB132SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB132SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB312SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB312SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB213SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB213SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB123SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB123SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB231SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB231SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - VFNMSUB321SS xmmreg,xmmreg,xmmrm32 FMA,FUTURE - VFNMSUB321SD xmmreg,xmmreg,xmmrm64 FMA,FUTURE - -B.1.29 VIA (Centaur) security instructions - - XSTORE PENT,CYRIX - XCRYPTECB PENT,CYRIX - XCRYPTCBC PENT,CYRIX - XCRYPTCTR PENT,CYRIX - XCRYPTCFB PENT,CYRIX - XCRYPTOFB PENT,CYRIX - MONTMUL PENT,CYRIX - XSHA1 PENT,CYRIX - XSHA256 PENT,CYRIX - -B.1.30 AMD Lightweight Profiling (LWP) instructions - - LLWPCB reg16 AMD - LLWPCB reg32 AMD,386 - LLWPCB reg64 AMD,X64 - SLWPCB reg16 AMD - SLWPCB reg32 AMD,386 - SLWPCB reg64 AMD,X64 - LWPVAL reg16,rm32,imm16 AMD,386 - LWPVAL reg32,rm32,imm32 AMD,386 - LWPVAL reg64,rm32,imm32 AMD,X64 - LWPINS reg16,rm32,imm16 AMD,386 - LWPINS reg32,rm32,imm32 AMD,386 - LWPINS reg64,rm32,imm32 AMD,X64 - -B.1.31 AMD XOP, FMA4 and CVT16 instructions (SSE5) - - VCVTPH2PS xmmreg,xmmrm64*,imm8 AMD,SSE5 - VCVTPH2PS ymmreg,xmmrm128,imm8 AMD,SSE5 - VCVTPH2PS ymmreg,ymmrm128*,imm8 AMD,SSE5 - VCVTPS2PH xmmrm64,xmmreg*,imm8 AMD,SSE5 - VCVTPS2PH xmmrm128,ymmreg,imm8 AMD,SSE5 - VCVTPS2PH ymmrm128,ymmreg*,imm8 AMD,SSE5 - VFMADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMADDSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 - VFMADDSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 - VFMADDSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 - VFMADDSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 - VFMADDSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMADDSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMADDSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMADDSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMADDSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMADDSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMADDSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMADDSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMSUBADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMSUBADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMSUBADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMSUBADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMSUBADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMSUBADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMSUBADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMSUBADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFMSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFMSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFMSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFMSUBSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 - VFMSUBSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 - VFMSUBSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 - VFMSUBSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 - VFNMADDPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFNMADDPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFNMADDPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFNMADDPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFNMADDPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFNMADDPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFNMADDPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFNMADDPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFNMADDSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 - VFNMADDSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 - VFNMADDSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 - VFNMADDSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 - VFNMSUBPD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFNMSUBPD ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFNMSUBPD xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFNMSUBPD ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFNMSUBPS xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VFNMSUBPS ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VFNMSUBPS xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VFNMSUBPS ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VFNMSUBSD xmmreg,xmmreg*,xmmrm64,xmmreg AMD,SSE5 - VFNMSUBSD xmmreg,xmmreg*,xmmreg,xmmrm64 AMD,SSE5 - VFNMSUBSS xmmreg,xmmreg*,xmmrm32,xmmreg AMD,SSE5 - VFNMSUBSS xmmreg,xmmreg*,xmmreg,xmmrm32 AMD,SSE5 - VFRCZPD xmmreg,xmmrm128* AMD,SSE5 - VFRCZPD ymmreg,ymmrm256* AMD,SSE5 - VFRCZPS xmmreg,xmmrm128* AMD,SSE5 - VFRCZPS ymmreg,ymmrm256* AMD,SSE5 - VFRCZSD xmmreg,xmmrm64* AMD,SSE5 - VFRCZSS xmmreg,xmmrm32* AMD,SSE5 - VPCMOV xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPCMOV ymmreg,ymmreg*,ymmrm256,ymmreg AMD,SSE5 - VPCMOV xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VPCMOV ymmreg,ymmreg*,ymmreg,ymmrm256 AMD,SSE5 - VPCOMB xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMD xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMQ xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMUB xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMUD xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMUQ xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMUW xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPCOMW xmmreg,xmmreg*,xmmrm128,imm8 AMD,SSE5 - VPHADDBD xmmreg,xmmrm128* AMD,SSE5 - VPHADDBQ xmmreg,xmmrm128* AMD,SSE5 - VPHADDBW xmmreg,xmmrm128* AMD,SSE5 - VPHADDDQ xmmreg,xmmrm128* AMD,SSE5 - VPHADDUBD xmmreg,xmmrm128* AMD,SSE5 - VPHADDUBQ xmmreg,xmmrm128* AMD,SSE5 - VPHADDUBW xmmreg,xmmrm128* AMD,SSE5 - VPHADDUDQ xmmreg,xmmrm128* AMD,SSE5 - VPHADDUWD xmmreg,xmmrm128* AMD,SSE5 - VPHADDUWQ xmmreg,xmmrm128* AMD,SSE5 - VPHADDWD xmmreg,xmmrm128* AMD,SSE5 - VPHADDWQ xmmreg,xmmrm128* AMD,SSE5 - VPHSUBBW xmmreg,xmmrm128* AMD,SSE5 - VPHSUBDQ xmmreg,xmmrm128* AMD,SSE5 - VPHSUBWD xmmreg,xmmrm128* AMD,SSE5 - VPMACSDD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSDQH xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSDQL xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSSDD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSSDQH xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSSDQL xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSSWW xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMACSWW xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMADCSSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPMADCSWD xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPPERM xmmreg,xmmreg*,xmmreg,xmmrm128 AMD,SSE5 - VPPERM xmmreg,xmmreg*,xmmrm128,xmmreg AMD,SSE5 - VPROTB xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPROTB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPROTB xmmreg,xmmrm128*,imm8 AMD,SSE5 - VPROTD xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPROTD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPROTD xmmreg,xmmrm128*,imm8 AMD,SSE5 - VPROTQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPROTQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPROTQ xmmreg,xmmrm128*,imm8 AMD,SSE5 - VPROTW xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPROTW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPROTW xmmreg,xmmrm128*,imm8 AMD,SSE5 - VPSHAB xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHAB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHAD xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHAD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHAQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHAQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHAW xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHAW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHLB xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHLB xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHLD xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHLD xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHLQ xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHLQ xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - VPSHLW xmmreg,xmmrm128*,xmmreg AMD,SSE5 - VPSHLW xmmreg,xmmreg*,xmmrm128 AMD,SSE5 - -B.1.32 Systematic names for the hinting nop instructions - - HINT_NOP0 rm16 P6,UNDOC - HINT_NOP0 rm32 P6,UNDOC - HINT_NOP0 rm64 X64,UNDOC - HINT_NOP1 rm16 P6,UNDOC - HINT_NOP1 rm32 P6,UNDOC - HINT_NOP1 rm64 X64,UNDOC - HINT_NOP2 rm16 P6,UNDOC - HINT_NOP2 rm32 P6,UNDOC - HINT_NOP2 rm64 X64,UNDOC - HINT_NOP3 rm16 P6,UNDOC - HINT_NOP3 rm32 P6,UNDOC - HINT_NOP3 rm64 X64,UNDOC - HINT_NOP4 rm16 P6,UNDOC - HINT_NOP4 rm32 P6,UNDOC - HINT_NOP4 rm64 X64,UNDOC - HINT_NOP5 rm16 P6,UNDOC - HINT_NOP5 rm32 P6,UNDOC - HINT_NOP5 rm64 X64,UNDOC - HINT_NOP6 rm16 P6,UNDOC - HINT_NOP6 rm32 P6,UNDOC - HINT_NOP6 rm64 X64,UNDOC - HINT_NOP7 rm16 P6,UNDOC - HINT_NOP7 rm32 P6,UNDOC - HINT_NOP7 rm64 X64,UNDOC - HINT_NOP8 rm16 P6,UNDOC - HINT_NOP8 rm32 P6,UNDOC - HINT_NOP8 rm64 X64,UNDOC - HINT_NOP9 rm16 P6,UNDOC - HINT_NOP9 rm32 P6,UNDOC - HINT_NOP9 rm64 X64,UNDOC - HINT_NOP10 rm16 P6,UNDOC - HINT_NOP10 rm32 P6,UNDOC - HINT_NOP10 rm64 X64,UNDOC - HINT_NOP11 rm16 P6,UNDOC - HINT_NOP11 rm32 P6,UNDOC - HINT_NOP11 rm64 X64,UNDOC - HINT_NOP12 rm16 P6,UNDOC - HINT_NOP12 rm32 P6,UNDOC - HINT_NOP12 rm64 X64,UNDOC - HINT_NOP13 rm16 P6,UNDOC - HINT_NOP13 rm32 P6,UNDOC - HINT_NOP13 rm64 X64,UNDOC - HINT_NOP14 rm16 P6,UNDOC - HINT_NOP14 rm32 P6,UNDOC - HINT_NOP14 rm64 X64,UNDOC - HINT_NOP15 rm16 P6,UNDOC - HINT_NOP15 rm32 P6,UNDOC - HINT_NOP15 rm64 X64,UNDOC - HINT_NOP16 rm16 P6,UNDOC - HINT_NOP16 rm32 P6,UNDOC - HINT_NOP16 rm64 X64,UNDOC - HINT_NOP17 rm16 P6,UNDOC - HINT_NOP17 rm32 P6,UNDOC - HINT_NOP17 rm64 X64,UNDOC - HINT_NOP18 rm16 P6,UNDOC - HINT_NOP18 rm32 P6,UNDOC - HINT_NOP18 rm64 X64,UNDOC - HINT_NOP19 rm16 P6,UNDOC - HINT_NOP19 rm32 P6,UNDOC - HINT_NOP19 rm64 X64,UNDOC - HINT_NOP20 rm16 P6,UNDOC - HINT_NOP20 rm32 P6,UNDOC - HINT_NOP20 rm64 X64,UNDOC - HINT_NOP21 rm16 P6,UNDOC - HINT_NOP21 rm32 P6,UNDOC - HINT_NOP21 rm64 X64,UNDOC - HINT_NOP22 rm16 P6,UNDOC - HINT_NOP22 rm32 P6,UNDOC - HINT_NOP22 rm64 X64,UNDOC - HINT_NOP23 rm16 P6,UNDOC - HINT_NOP23 rm32 P6,UNDOC - HINT_NOP23 rm64 X64,UNDOC - HINT_NOP24 rm16 P6,UNDOC - HINT_NOP24 rm32 P6,UNDOC - HINT_NOP24 rm64 X64,UNDOC - HINT_NOP25 rm16 P6,UNDOC - HINT_NOP25 rm32 P6,UNDOC - HINT_NOP25 rm64 X64,UNDOC - HINT_NOP26 rm16 P6,UNDOC - HINT_NOP26 rm32 P6,UNDOC - HINT_NOP26 rm64 X64,UNDOC - HINT_NOP27 rm16 P6,UNDOC - HINT_NOP27 rm32 P6,UNDOC - HINT_NOP27 rm64 X64,UNDOC - HINT_NOP28 rm16 P6,UNDOC - HINT_NOP28 rm32 P6,UNDOC - HINT_NOP28 rm64 X64,UNDOC - HINT_NOP29 rm16 P6,UNDOC - HINT_NOP29 rm32 P6,UNDOC - HINT_NOP29 rm64 X64,UNDOC - HINT_NOP30 rm16 P6,UNDOC - HINT_NOP30 rm32 P6,UNDOC - HINT_NOP30 rm64 X64,UNDOC - HINT_NOP31 rm16 P6,UNDOC - HINT_NOP31 rm32 P6,UNDOC - HINT_NOP31 rm64 X64,UNDOC - HINT_NOP32 rm16 P6,UNDOC - HINT_NOP32 rm32 P6,UNDOC - HINT_NOP32 rm64 X64,UNDOC - HINT_NOP33 rm16 P6,UNDOC - HINT_NOP33 rm32 P6,UNDOC - HINT_NOP33 rm64 X64,UNDOC - HINT_NOP34 rm16 P6,UNDOC - HINT_NOP34 rm32 P6,UNDOC - HINT_NOP34 rm64 X64,UNDOC - HINT_NOP35 rm16 P6,UNDOC - HINT_NOP35 rm32 P6,UNDOC - HINT_NOP35 rm64 X64,UNDOC - HINT_NOP36 rm16 P6,UNDOC - HINT_NOP36 rm32 P6,UNDOC - HINT_NOP36 rm64 X64,UNDOC - HINT_NOP37 rm16 P6,UNDOC - HINT_NOP37 rm32 P6,UNDOC - HINT_NOP37 rm64 X64,UNDOC - HINT_NOP38 rm16 P6,UNDOC - HINT_NOP38 rm32 P6,UNDOC - HINT_NOP38 rm64 X64,UNDOC - HINT_NOP39 rm16 P6,UNDOC - HINT_NOP39 rm32 P6,UNDOC - HINT_NOP39 rm64 X64,UNDOC - HINT_NOP40 rm16 P6,UNDOC - HINT_NOP40 rm32 P6,UNDOC - HINT_NOP40 rm64 X64,UNDOC - HINT_NOP41 rm16 P6,UNDOC - HINT_NOP41 rm32 P6,UNDOC - HINT_NOP41 rm64 X64,UNDOC - HINT_NOP42 rm16 P6,UNDOC - HINT_NOP42 rm32 P6,UNDOC - HINT_NOP42 rm64 X64,UNDOC - HINT_NOP43 rm16 P6,UNDOC - HINT_NOP43 rm32 P6,UNDOC - HINT_NOP43 rm64 X64,UNDOC - HINT_NOP44 rm16 P6,UNDOC - HINT_NOP44 rm32 P6,UNDOC - HINT_NOP44 rm64 X64,UNDOC - HINT_NOP45 rm16 P6,UNDOC - HINT_NOP45 rm32 P6,UNDOC - HINT_NOP45 rm64 X64,UNDOC - HINT_NOP46 rm16 P6,UNDOC - HINT_NOP46 rm32 P6,UNDOC - HINT_NOP46 rm64 X64,UNDOC - HINT_NOP47 rm16 P6,UNDOC - HINT_NOP47 rm32 P6,UNDOC - HINT_NOP47 rm64 X64,UNDOC - HINT_NOP48 rm16 P6,UNDOC - HINT_NOP48 rm32 P6,UNDOC - HINT_NOP48 rm64 X64,UNDOC - HINT_NOP49 rm16 P6,UNDOC - HINT_NOP49 rm32 P6,UNDOC - HINT_NOP49 rm64 X64,UNDOC - HINT_NOP50 rm16 P6,UNDOC - HINT_NOP50 rm32 P6,UNDOC - HINT_NOP50 rm64 X64,UNDOC - HINT_NOP51 rm16 P6,UNDOC - HINT_NOP51 rm32 P6,UNDOC - HINT_NOP51 rm64 X64,UNDOC - HINT_NOP52 rm16 P6,UNDOC - HINT_NOP52 rm32 P6,UNDOC - HINT_NOP52 rm64 X64,UNDOC - HINT_NOP53 rm16 P6,UNDOC - HINT_NOP53 rm32 P6,UNDOC - HINT_NOP53 rm64 X64,UNDOC - HINT_NOP54 rm16 P6,UNDOC - HINT_NOP54 rm32 P6,UNDOC - HINT_NOP54 rm64 X64,UNDOC - HINT_NOP55 rm16 P6,UNDOC - HINT_NOP55 rm32 P6,UNDOC - HINT_NOP55 rm64 X64,UNDOC - HINT_NOP56 rm16 P6,UNDOC - HINT_NOP56 rm32 P6,UNDOC - HINT_NOP56 rm64 X64,UNDOC - HINT_NOP57 rm16 P6,UNDOC - HINT_NOP57 rm32 P6,UNDOC - HINT_NOP57 rm64 X64,UNDOC - HINT_NOP58 rm16 P6,UNDOC - HINT_NOP58 rm32 P6,UNDOC - HINT_NOP58 rm64 X64,UNDOC - HINT_NOP59 rm16 P6,UNDOC - HINT_NOP59 rm32 P6,UNDOC - HINT_NOP59 rm64 X64,UNDOC - HINT_NOP60 rm16 P6,UNDOC - HINT_NOP60 rm32 P6,UNDOC - HINT_NOP60 rm64 X64,UNDOC - HINT_NOP61 rm16 P6,UNDOC - HINT_NOP61 rm32 P6,UNDOC - HINT_NOP61 rm64 X64,UNDOC - HINT_NOP62 rm16 P6,UNDOC - HINT_NOP62 rm32 P6,UNDOC - HINT_NOP62 rm64 X64,UNDOC - HINT_NOP63 rm16 P6,UNDOC - HINT_NOP63 rm32 P6,UNDOC - HINT_NOP63 rm64 X64,UNDOC - -Appendix C: NASM Version History --------------------------------- - - C.1 NASM 2 Series - - The NASM 2 series support x86-64, and is the production version of - NASM since 2007. - - C.1.1 Version 2.08 - - (*) A number of enhancements/fixes in macros area. - - (*) Support for arbitrarily terminating macro expansions - `%exitmacro'. See section 4.3.12. - - (*) Support for recursive macro expansion `%rmacro/irmacro'. See - section 4.3.1. - - (*) Support for converting strings to tokens. See section 4.1.9. - - (*) Fuzzy operand size logic introduced. - - (*) Fix COFF stack overrun on too long export identifiers. - - (*) Fix Macho-O alignment bug. - - (*) Fix crashes with -fwin32 on file with many exports. - - (*) Fix stack overrun for too long [DEBUG id]. - - (*) Fix incorrect sbyte usage in IMUL (hit only if optimization flag - passed). - - (*) Append ending token for `.stabs' records in the ELF output - format. - - (*) New NSIS script which uses ModernUI and MultiUser approach. - - (*) Visual Studio 2008 NASM integration (rules file). - - (*) Warn a user if a constant is too long (and as result will be - stripped). - - (*) The obsoleted pre-XOP AMD SSE5 instruction set which was never - actualized was removed. - - (*) Fix stack overrun on too long error file name passed from the - command line. - - (*) Bind symbols to the .text section by default (ie in case if - SECTION directive was omitted) in the ELF output format. - - (*) Fix sync points array index wrapping. - - (*) A few fixes for FMA4 and XOP instruction templates. - - (*) Add AMD Lightweight Profiling (LWP) instructions. - - C.1.2 Version 2.07 - - (*) NASM is now under the 2-clause BSD license. See section 1.1.2. - - (*) Fix the section type for the `.strtab' section in the `elf64' - output format. - - (*) Fix the handling of `COMMON' directives in the `obj' output - format. - - (*) New `ith' and `srec' output formats; these are variants of the - `bin' output format which output Intel hex and Motorola S- - records, respectively. See section 7.2 and section 7.3. - - (*) `rdf2ihx' replaced with an enhanced `rdf2bin', which can output - binary, COM, Intel hex or Motorola S-records. - - (*) The Windows installer now puts the NASM directory first in the - `PATH' of the "NASM Shell". - - (*) Revert the early expansion behavior of `%+' to pre-2.06 - behavior: `%+' is only expanded late. - - (*) Yet another Mach-O alignment fix. - - (*) Don't delete the list file on errors. Also, include error and - warning information in the list file. - - (*) Support for 64-bit Mach-O output, see section 7.8. - - (*) Fix assert failure on certain operations that involve strings - with high-bit bytes. - - C.1.3 Version 2.06 - - (*) This release is dedicated to the memory of Charles A. Crayne, - long time NASM developer as well as moderator of - `comp.lang.asm.x86' and author of the book _Serious Assembler_. - We miss you, Chuck. - - (*) Support for indirect macro expansion (`%[...]'). See section - 4.1.3. - - (*) `%pop' can now take an argument, see section 4.7.1. - - (*) The argument to `%use' is no longer macro-expanded. Use `%[...]' - if macro expansion is desired. - - (*) Support for thread-local storage in ELF32 and ELF64. See section - 7.9.4. - - (*) Fix crash on `%ifmacro' without an argument. - - (*) Correct the arguments to the `POPCNT' instruction. - - (*) Fix section alignment in the Mach-O format. - - (*) Update AVX support to version 5 of the Intel specification. - - (*) Fix the handling of accesses to context-local macros from higher - levels in the context stack. - - (*) Treat `WAIT' as a prefix rather than as an instruction, thereby - allowing constructs like `O16 FSAVE' to work correctly. - - (*) Support for structures with a non-zero base offset. See section - 4.11.10. - - (*) Correctly handle preprocessor token concatenation (see section - 4.3.8) involving floating-point numbers. - - (*) The `PINSR' series of instructions have been corrected and - rationalized. - - (*) Removed AMD SSE5, replaced with the new XOP/FMA4/CVT16 (rev - 3.03) spec. - - (*) The ELF backends no longer automatically generate a `.comment' - section. - - (*) Add additional "well-known" ELF sections with default - attributes. See section 7.9.2. - - C.1.4 Version 2.05.01 - - (*) Fix the `-w'/`-W' option parsing, which was broken in NASM 2.05. - - C.1.5 Version 2.05 - - (*) Fix redundant REX.W prefix on `JMP reg64'. - - (*) Make the behaviour of `-O0' match NASM 0.98 legacy behavior. See - section 2.1.22. - - (*) `-w-user' can be used to suppress the output of `%warning' - directives. See section 2.1.24. - - (*) Fix bug where `ALIGN' would issue a full alignment datum instead - of zero bytes. - - (*) Fix offsets in list files. - - (*) Fix `%include' inside multi-line macros or loops. - - (*) Fix error where NASM would generate a spurious warning on valid - optimizations of immediate values. - - (*) Fix arguments to a number of the `CVT' SSE instructions. - - (*) Fix RIP-relative offsets when the instruction carries an - immediate. - - (*) Massive overhaul of the ELF64 backend for spec compliance. - - (*) Fix the Geode `PFRCPV' and `PFRSQRTV' instruction. - - (*) Fix the SSE 4.2 `CRC32' instruction. - - C.1.6 Version 2.04 - - (*) Sanitize macro handing in the `%error' directive. - - (*) New `%warning' directive to issue user-controlled warnings. - - (*) `%error' directives are now deferred to the final assembly - phase. - - (*) New `%fatal' directive to immediately terminate assembly. - - (*) New `%strcat' directive to join quoted strings together. - - (*) New `%use' macro directive to support standard macro directives. - See section 4.6.4. - - (*) Excess default parameters to `%macro' now issues a warning by - default. See section 4.3. - - (*) Fix `%ifn' and `%elifn'. - - (*) Fix nested `%else' clauses. - - (*) Correct the handling of nested `%rep's. - - (*) New `%unmacro' directive to undeclare a multi-line macro. See - section 4.3.11. - - (*) Builtin macro `__PASS__' which expands to the current assembly - pass. See section 4.11.9. - - (*) `__utf16__' and `__utf32__' operators to generate UTF-16 and - UTF-32 strings. See section 3.4.5. - - (*) Fix bug in case-insensitive matching when compiled on platforms - that don't use the `configure' script. Of the official release - binaries, that only affected the OS/2 binary. - - (*) Support for x87 packed BCD constants. See section 3.4.7. - - (*) Correct the `LTR' and `SLDT' instructions in 64-bit mode. - - (*) Fix unnecessary REX.W prefix on indirect jumps in 64-bit mode. - - (*) Add AVX versions of the AES instructions (`VAES'...). - - (*) Fix the 256-bit FMA instructions. - - (*) Add 256-bit AVX stores per the latest AVX spec. - - (*) VIA XCRYPT instructions can now be written either with or - without `REP', apparently different versions of the VIA spec - wrote them differently. - - (*) Add missing 64-bit `MOVNTI' instruction. - - (*) Fix the operand size of `VMREAD' and `VMWRITE'. - - (*) Numerous bug fixes, especially to the AES, AVX and VTX - instructions. - - (*) The optimizer now always runs until it converges. It also runs - even when disabled, but doesn't optimize. This allows most - forward references to be resolved properly. - - (*) `%push' no longer needs a context identifier; omitting the - context identifier results in an anonymous context. - - C.1.7 Version 2.03.01 - - (*) Fix buffer overflow in the listing module. - - (*) Fix the handling of hexadecimal escape codes in `...` strings. - - (*) The Postscript/PDF documentation has been reformatted. - - (*) The `-F' option now implies `-g'. - - C.1.8 Version 2.03 - - (*) Add support for Intel AVX, CLMUL and FMA instructions, including - YMM registers. - - (*) `dy', `resy' and `yword' for 32-byte operands. - - (*) Fix some SSE5 instructions. - - (*) Intel `INVEPT', `INVVPID' and `MOVBE' instructions. - - (*) Fix checking for critical expressions when the optimizer is - enabled. - - (*) Support the DWARF debugging format for ELF targets. - - (*) Fix optimizations of signed bytes. - - (*) Fix operation on bigendian machines. - - (*) Fix buffer overflow in the preprocessor. - - (*) `SAFESEH' support for Win32, `IMAGEREL' for Win64 (SEH). - - (*) `%?' and `%??' to refer to the name of a macro itself. In - particular, `%idefine keyword $%?' can be used to make a keyword - "disappear". - - (*) New options for dependency generation: `-MD', `-MF', `-MP', - `-MT', `-MQ'. - - (*) New preprocessor directives `%pathsearch' and `%depend'; INCBIN - reimplemented as a macro. - - (*) `%include' now resolves macros in a sane manner. - - (*) `%substr' can now be used to get other than one-character - substrings. - - (*) New type of character/string constants, using backquotes - (``...`'), which support C-style escape sequences. - - (*) `%defstr' and `%idefstr' to stringize macro definitions before - creation. - - (*) Fix forward references used in `EQU' statements. - - C.1.9 Version 2.02 - - (*) Additional fixes for MMX operands with explicit `qword', as well - as (hopefully) SSE operands with `oword'. - - (*) Fix handling of truncated strings with `DO'. - - (*) Fix segfaults due to memory overwrites when floating-point - constants were used. - - (*) Fix segfaults due to missing include files. - - (*) Fix OpenWatcom Makefiles for DOS and OS/2. - - (*) Add autogenerated instruction list back into the documentation. - - (*) ELF: Fix segfault when generating stabs, and no symbols have - been defined. - - (*) ELF: Experimental support for DWARF debugging information. - - (*) New compile date and time standard macros. - - (*) `%ifnum' now returns true for negative numbers. - - (*) New `%iftoken' test for a single token. - - (*) New `%ifempty' test for empty expansion. - - (*) Add support for the `XSAVE' instruction group. - - (*) Makefile for Netware/gcc. - - (*) Fix issue with some warnings getting emitted way too many times. - - (*) Autogenerated instruction list added to the documentation. - -C.1.10 Version 2.01 - - (*) Fix the handling of MMX registers with explicit `qword' tags on - memory (broken in 2.00 due to 64-bit changes.) - - (*) Fix the PREFETCH instructions. - - (*) Fix the documentation. - - (*) Fix debugging info when using `-f elf' (backwards compatibility - alias for `-f elf32'). - - (*) Man pages for rdoff tools (from the Debian project.) - - (*) ELF: handle large numbers of sections. - - (*) Fix corrupt output when the optimizer runs out of passes. - -C.1.11 Version 2.00 - - (*) Added c99 data-type compliance. - - (*) Added general x86-64 support. - - (*) Added win64 (x86-64 COFF) output format. - - (*) Added `__BITS__' standard macro. - - (*) Renamed the `elf' output format to `elf32' for clarity. - - (*) Added `elf64' and `macho' (MacOS X) output formats. - - (*) Added Numeric constants in `dq' directive. - - (*) Added `oword', `do' and `reso' pseudo operands. - - (*) Allow underscores in numbers. - - (*) Added 8-, 16- and 128-bit floating-point formats. - - (*) Added binary, octal and hexadecimal floating-point. - - (*) Correct the generation of floating-point constants. - - (*) Added floating-point option control. - - (*) Added Infinity and NaN floating point support. - - (*) Added ELF Symbol Visibility support. - - (*) Added setting OSABI value in ELF header directive. - - (*) Added Generate Makefile Dependencies option. - - (*) Added Unlimited Optimization Passes option. - - (*) Added `%IFN' and `%ELIFN' support. - - (*) Added Logical Negation Operator. - - (*) Enhanced Stack Relative Preprocessor Directives. - - (*) Enhanced ELF Debug Formats. - - (*) Enhanced Send Errors to a File option. - - (*) Added SSSE3, SSE4.1, SSE4.2, SSE5 support. - - (*) Added a large number of additional instructions. - - (*) Significant performance improvements. - - (*) `-w+warning' and `-w-warning' can now be written as -Wwarning - and -Wno-warning, respectively. See section 2.1.24. - - (*) Add `-w+error' to treat warnings as errors. See section 2.1.24. - - (*) Add `-w+all' and `-w-all' to enable or disable all suppressible - warnings. See section 2.1.24. - - C.2 NASM 0.98 Series - - The 0.98 series was the production versions of NASM from 1999 to - 2007. - - C.2.1 Version 0.98.39 - - (*) fix buffer overflow - - (*) fix outas86's `.bss' handling - - (*) "make spotless" no longer deletes config.h.in. - - (*) `%(el)if(n)idn' insensitivity to string quotes difference - (#809300). - - (*) (nasm.c)`__OUTPUT_FORMAT__' changed to string value instead of - symbol. - - C.2.2 Version 0.98.38 - - (*) Add Makefile for 16-bit DOS binaries under OpenWatcom, and - modify `mkdep.pl' to be able to generate completely pathless - dependencies, as required by OpenWatcom wmake (it supports path - searches, but not explicit paths.) - - (*) Fix the `STR' instruction. - - (*) Fix the ELF output format, which was broken under certain - circumstances due to the addition of stabs support. - - (*) Quick-fix Borland format debug-info for `-f obj' - - (*) Fix for `%rep' with no arguments (#560568) - - (*) Fix concatenation of preprocessor function call (#794686) - - (*) Fix long label causes coredump (#677841) - - (*) Use autoheader as well as autoconf to keep configure from - generating ridiculously long command lines. - - (*) Make sure that all of the formats which support debugging output - actually will suppress debugging output when `-g' not specified. - - C.2.3 Version 0.98.37 - - (*) Paths given in `-I' switch searched for `incbin'-ed as well as - `%include'-ed files. - - (*) Added stabs debugging for the ELF output format, patch from - Martin Wawro. - - (*) Fix `output/outbin.c' to allow origin > 80000000h. - - (*) Make `-U' switch work. - - (*) Fix the use of relative offsets with explicit prefixes, e.g. - `a32 loop foo'. - - (*) Remove `backslash()'. - - (*) Fix the `SMSW' and `SLDT' instructions. - - (*) `-O2' and `-O3' are no longer aliases for `-O10' and `-O15'. If - you mean the latter, please say so! :) - - C.2.4 Version 0.98.36 - - (*) Update rdoff - librarian/archiver - common rec - docs! - - (*) Fix signed/unsigned problems. - - (*) Fix `JMP FAR label' and `CALL FAR label'. - - (*) Add new multisection support - map files - fix align bug - - (*) Fix sysexit, movhps/movlps reg,reg bugs in insns.dat - - (*) `Q' or `O' suffixes indicate octal - - (*) Support Prescott new instructions (PNI). - - (*) Cyrix `XSTORE' instruction. - - C.2.5 Version 0.98.35 - - (*) Fix build failure on 16-bit DOS (Makefile.bc3 workaround for - compiler bug.) - - (*) Fix dependencies and compiler warnings. - - (*) Add "const" in a number of places. - - (*) Add -X option to specify error reporting format (use -Xvc to - integrate with Microsoft Visual Studio.) - - (*) Minor changes for code legibility. - - (*) Drop use of tmpnam() in rdoff (security fix.) - - C.2.6 Version 0.98.34 - - (*) Correct additional address-size vs. operand-size confusions. - - (*) Generate dependencies for all Makefiles automatically. - - (*) Add support for unimplemented (but theoretically available) - registers such as tr0 and cr5. Segment registers 6 and 7 are - called segr6 and segr7 for the operations which they can be - represented. - - (*) Correct some disassembler bugs related to redundant address-size - prefixes. Some work still remains in this area. - - (*) Correctly generate an error for things like "SEG eax". - - (*) Add the JMPE instruction, enabled by "CPU IA64". - - (*) Correct compilation on newer gcc/glibc platforms. - - (*) Issue an error on things like "jmp far eax". - - C.2.7 Version 0.98.33 - - (*) New __NASM_PATCHLEVEL__ and __NASM_VERSION_ID__ standard macros - to round out the version-query macros. version.pl now - understands X.YYplWW or X.YY.ZZplWW as a version number, - equivalent to X.YY.ZZ.WW (or X.YY.0.WW, as appropriate). - - (*) New keyword "strict" to disable the optimization of specific - operands. - - (*) Fix the handing of size overrides with JMP instructions - (instructions such as "jmp dword foo".) - - (*) Fix the handling of "ABSOLUTE label", where "label" points into - a relocatable segment. - - (*) Fix OBJ output format with lots of externs. - - (*) More documentation updates. - - (*) Add -Ov option to get verbose information about optimizations. - - (*) Undo a braindead change which broke `%elif' directives. - - (*) Makefile updates. - - C.2.8 Version 0.98.32 - - (*) Fix NASM crashing when `%macro' directives were left - unterminated. - - (*) Lots of documentation updates. - - (*) Complete rewrite of the PostScript/PDF documentation generator. - - (*) The MS Visual C++ Makefile was updated and corrected. - - (*) Recognize .rodata as a standard section name in ELF. - - (*) Fix some obsolete Perl4-isms in Perl scripts. - - (*) Fix configure.in to work with autoconf 2.5x. - - (*) Fix a couple of "make cleaner" misses. - - (*) Make the normal "./configure && make" work with Cygwin. - - C.2.9 Version 0.98.31 - - (*) Correctly build in a separate object directory again. - - (*) Derive all references to the version number from the version - file. - - (*) New standard macros __NASM_SUBMINOR__ and __NASM_VER__ macros. - - (*) Lots of Makefile updates and bug fixes. - - (*) New `%ifmacro' directive to test for multiline macros. - - (*) Documentation updates. - - (*) Fixes for 16-bit OBJ format output. - - (*) Changed the NASM environment variable to NASMENV. - -C.2.10 Version 0.98.30 - - (*) Changed doc files a lot: completely removed old READMExx and - Wishlist files, incorporating all information in CHANGES and - TODO. - - (*) I waited a long time to rename zoutieee.c to (original) - outieee.c - - (*) moved all output modules to output/ subdirectory. - - (*) Added 'make strip' target to strip debug info from nasm & - ndisasm. - - (*) Added INSTALL file with installation instructions. - - (*) Added -v option description to nasm man. - - (*) Added dist makefile target to produce source distributions. - - (*) 16-bit support for ELF output format (GNU extension, but - useful.) - -C.2.11 Version 0.98.28 - - (*) Fastcooked this for Debian's Woody release: Frank applied the - INCBIN bug patch to 0.98.25alt and called it 0.98.28 to not - confuse poor little apt-get. - -C.2.12 Version 0.98.26 - - (*) Reorganised files even better from 0.98.25alt - -C.2.13 Version 0.98.25alt - - (*) Prettified the source tree. Moved files to more reasonable - places. - - (*) Added findleak.pl script to misc/ directory. - - (*) Attempted to fix doc. - -C.2.14 Version 0.98.25 - - (*) Line continuation character `\'. - - (*) Docs inadvertantly reverted - "dos packaging". - -C.2.15 Version 0.98.24p1 - - (*) FIXME: Someone, document this please. - -C.2.16 Version 0.98.24 - - (*) Documentation - Ndisasm doc added to Nasm.doc. - -C.2.17 Version 0.98.23 - - (*) Attempted to remove rdoff version1 - - (*) Lino Mastrodomenico's patches to preproc.c (%$$ bug?). - -C.2.18 Version 0.98.22 - - (*) Update rdoff2 - attempt to remove v1. - -C.2.19 Version 0.98.21 - - (*) Optimization fixes. - -C.2.20 Version 0.98.20 - - (*) Optimization fixes. - -C.2.21 Version 0.98.19 - - (*) H. J. Lu's patch back out. - -C.2.22 Version 0.98.18 - - (*) Added ".rdata" to "-f win32". - -C.2.23 Version 0.98.17 - - (*) H. J. Lu's "bogus elf" patch. (Red Hat problem?) - -C.2.24 Version 0.98.16 - - (*) Fix whitespace before "[section ..." bug. - -C.2.25 Version 0.98.15 - - (*) Rdoff changes (?). - - (*) Fix fixes to memory leaks. - -C.2.26 Version 0.98.14 - - (*) Fix memory leaks. - -C.2.27 Version 0.98.13 - - (*) There was no 0.98.13 - -C.2.28 Version 0.98.12 - - (*) Update optimization (new function of "-O1") - - (*) Changes to test/bintest.asm (?). - -C.2.29 Version 0.98.11 - - (*) Optimization changes. - - (*) Ndisasm fixed. - -C.2.30 Version 0.98.10 - - (*) There was no 0.98.10 - -C.2.31 Version 0.98.09 - - (*) Add multiple sections support to "-f bin". - - (*) Changed GLOBAL_TEMP_BASE in outelf.c from 6 to 15. - - (*) Add "-v" as an alias to the "-r" switch. - - (*) Remove "#ifdef" from Tasm compatibility options. - - (*) Remove redundant size-overrides on "mov ds, ex", etc. - - (*) Fixes to SSE2, other insns.dat (?). - - (*) Enable uppercase "I" and "P" switches. - - (*) Case insinsitive "seg" and "wrt". - - (*) Update install.sh (?). - - (*) Allocate tokens in blocks. - - (*) Improve "invalid effective address" messages. - -C.2.32 Version 0.98.08 - - (*) Add "`%strlen'" and "`%substr'" macro operators - - (*) Fixed broken c16.mac. - - (*) Unterminated string error reported. - - (*) Fixed bugs as per 0.98bf - -C.2.33 Version 0.98.09b with John Coffman patches released 28-Oct-2001 - - Changes from 0.98.07 release to 98.09b as of 28-Oct-2001 - - (*) More closely compatible with 0.98 when -O0 is implied or - specified. Not strictly identical, since backward branches in - range of short offsets are recognized, and signed byte values - with no explicit size specification will be assembled as a - single byte. - - (*) More forgiving with the PUSH instruction. 0.98 requires a size - to be specified always. 0.98.09b will imply the size from the - current BITS setting (16 or 32). - - (*) Changed definition of the optimization flag: - - -O0 strict two-pass assembly, JMP and Jcc are handled more like - 0.98, except that back- ward JMPs are short, if possible. - - -O1 strict two-pass assembly, but forward branches are assembled - with code guaranteed to reach; may produce larger code than -O0, but - will produce successful assembly more often if branch offset sizes - are not specified. - - -O2 multi-pass optimization, minimize branch offsets; also will - minimize signed immed- iate bytes, overriding size specification. - - -O3 like -O2, but more passes taken, if needed - -C.2.34 Version 0.98.07 released 01/28/01 - - (*) Added Stepane Denis' SSE2 instructions to a *working* version of - the code - some earlier versions were based on broken code - - sorry 'bout that. version "0.98.07" - - 01/28/01 - - (*) Cosmetic modifications to nasm.c, nasm.h, AUTHORS, MODIFIED - -C.2.35 Version 0.98.06f released 01/18/01 - - (*) - Add "metalbrain"s jecxz bug fix in insns.dat - alter - nasmdoc.src to match - version "0.98.06f" - -C.2.36 Version 0.98.06e released 01/09/01 - - (*) Removed the "outforms.h" file - it appears to be someone's old - backup of "outform.h". version "0.98.06e" - - 01/09/01 - - (*) fbk - finally added the fix for the "multiple %includes bug", - known since 7/27/99 - reported originally (?) and sent to us by - Austin Lunnen - he reports that John Fine had a fix within the - day. Here it is... - - (*) Nelson Rush resigns from the group. Big thanks to Nelson for his - leadership and enthusiasm in getting these changes incorporated - into Nasm! - - (*) fbk - [list +], [list -] directives - ineptly implemented, - should be re-written or removed, perhaps. - - (*) Brian Raiter / fbk - "elfso bug" fix - applied to aoutb format - as well - testing might be desirable... - - 08/07/00 - - (*) James Seter - -postfix, -prefix command line switches. - - (*) Yuri Zaporogets - rdoff utility changes. - -C.2.37 Version 0.98p1 - - (*) GAS-like palign (Panos Minos) - - (*) FIXME: Someone, fill this in with details - -C.2.38 Version 0.98bf (bug-fixed) - - (*) Fixed - elf and aoutb bug - shared libraries - multiple - "%include" bug in "-f obj" - jcxz, jecxz bug - unrecognized - option bug in ndisasm - -C.2.39 Version 0.98.03 with John Coffman's changes released 27-Jul-2000 - - (*) Added signed byte optimizations for the 0x81/0x83 class of - instructions: ADC, ADD, AND, CMP, OR, SBB, SUB, XOR: when used - as 'ADD reg16,imm' or 'ADD reg32,imm.' Also optimization of - signed byte form of 'PUSH imm' and 'IMUL reg,imm'/'IMUL - reg,reg,imm.' No size specification is needed. - - (*) Added multi-pass JMP and Jcc offset optimization. Offsets on - forward references will preferentially use the short form, - without the need to code a specific size (short or near) for the - branch. Added instructions for 'Jcc label' to use the form - 'Jnotcc $+3/JMP label', in cases where a short offset is out of - bounds. If compiling for a 386 or higher CPU, then the 386 form - of Jcc will be used instead. - - This feature is controlled by a new command-line switch: "O", (upper - case letter O). "-O0" reverts the assembler to no extra optimization - passes, "-O1" allows up to 5 extra passes, and "-O2"(default), - allows up to 10 extra optimization passes. - - (*) Added a new directive: 'cpu XXX', where XXX is any of: 8086, - 186, 286, 386, 486, 586, pentium, 686, PPro, P2, P3 or Katmai. - All are case insensitive. All instructions will be selected only - if they apply to the selected cpu or lower. Corrected a couple - of bugs in cpu-dependence in 'insns.dat'. - - (*) Added to 'standard.mac', the "use16" and "use32" forms of the - "bits 16/32" directive. This is nothing new, just conforms to a - lot of other assemblers. (minor) - - (*) Changed label allocation from 320/32 (10000 labels @ 200K+) to - 32/37 (1000 labels); makes running under DOS much easier. Since - additional label space is allocated dynamically, this should - have no effect on large programs with lots of labels. The 37 is - a prime, believed to be better for hashing. (minor) - -C.2.40 Version 0.98.03 - - "Integrated patchfile 0.98-0.98.01. I call this version 0.98.03 for - historical reasons: 0.98.02 was trashed." --John Coffman - <johninsd@san.rr.com>, 27-Jul-2000 - - (*) Kendall Bennett's SciTech MGL changes - - (*) Note that you must define "TASM_COMPAT" at compile-time to get - the Tasm Ideal Mode compatibility. - - (*) All changes can be compiled in and out using the TASM_COMPAT - macros, and when compiled without TASM_COMPAT defined we get the - exact same binary as the unmodified 0.98 sources. - - (*) standard.mac, macros.c: Added macros to ignore TASM directives - before first include - - (*) nasm.h: Added extern declaration for tasm_compatible_mode - - (*) nasm.c: Added global variable tasm_compatible_mode - - (*) Added command line switch for TASM compatible mode (-t) - - (*) Changed version command line to reflect when compiled with TASM - additions - - (*) Added response file processing to allow all arguments on a - single line (response file is @resp rather than -@resp for NASM - format). - - (*) labels.c: Changes islocal() macro to support TASM style @@local - labels. - - (*) Added islocalchar() macro to support TASM style @@local labels. - - (*) parser.c: Added support for TASM style memory references (ie: - mov [DWORD eax],10 rather than the NASM style mov DWORD - [eax],10). - - (*) preproc.c: Added new directives, `%arg', `%local', `%stacksize' - to directives table - - (*) Added support for TASM style directives without a leading % - symbol. - - (*) Integrated a block of changes from Andrew Zabolotny - <bit@eltech.ru>: - - (*) A new keyword `%xdefine' and its case-insensitive counterpart - `%ixdefine'. They work almost the same way as `%define' and - `%idefine' but expand the definition immediately, not on the - invocation. Something like a cross between `%define' and - `%assign'. The "x" suffix stands for "eXpand", so "xdefine" can - be deciphered as "expand-and-define". Thus you can do things - like this: - - %assign ofs 0 - - %macro arg 1 - %xdefine %1 dword [esp+ofs] - %assign ofs ofs+4 - %endmacro - - (*) Changed the place where the expansion of %$name macros are - expanded. Now they are converted into ..@ctxnum.name form when - detokenizing, so there are no quirks as before when using %$name - arguments to macros, in macros etc. For example: - - %macro abc 1 - %define %1 hello - %endm - - abc %$here - %$here - - Now last line will be expanded into "hello" as expected. This also - allows for lots of goodies, a good example are extended "proc" - macros included in this archive. - - (*) Added a check for "cstk" in smacro_defined() before calling - get_ctx() - this allows for things like: - - %ifdef %$abc - %endif - - to work without warnings even in no context. - - (*) Added a check for "cstk" in %if*ctx and %elif*ctx directives - - this allows to use `%ifctx' without excessive warnings. If there - is no active context, `%ifctx' goes through "false" branch. - - (*) Removed "user error: " prefix with `%error' directive: it just - clobbers the output and has absolutely no functionality. - Besides, this allows to write macros that does not differ from - built-in functions in any way. - - (*) Added expansion of string that is output by `%error' directive. - Now you can do things like: - - %define hello(x) Hello, x! - - %define %$name andy - %error "hello(%$name)" - - Same happened with `%include' directive. - - (*) Now all directives that expect an identifier will try to expand - and concatenate everything without whitespaces in between before - usage. For example, with "unfixed" nasm the commands - - %define %$abc hello - %define __%$abc goodbye - __%$abc - - would produce "incorrect" output: last line will expand to - - hello goodbyehello - - Not quite what you expected, eh? :-) The answer is that preprocessor - treats the `%define' construct as if it would be - - %define __ %$abc goodbye - - (note the white space between __ and %$abc). After my "fix" it will - "correctly" expand into - - goodbye - - as expected. Note that I use quotes around words "correct", - "incorrect" etc because this is rather a feature not a bug; however - current behaviour is more logical (and allows more advanced macro - usage :-). - - Same change was applied to: - `%push',`%macro',`%imacro',`%define',`%idefine',`%xdefine',`%ixdefine', - `%assign',`%iassign',`%undef' - - (*) A new directive [WARNING {+|-}warning-id] have been added. It - works only if the assembly phase is enabled (i.e. it doesn't - work with nasm -e). - - (*) A new warning type: macro-selfref. By default this warning is - disabled; when enabled NASM warns when a macro self-references - itself; for example the following source: - - [WARNING macro-selfref] - - %macro push 1-* - %rep %0 - push %1 - %rotate 1 - %endrep - %endmacro - - push eax,ebx,ecx - - will produce a warning, but if we remove the first line we won't see - it anymore (which is The Right Thing To Do {tm} IMHO since C - preprocessor eats such constructs without warnings at all). - - (*) Added a "error" routine to preprocessor which always will set - ERR_PASS1 bit in severity_code. This removes annoying repeated - errors on first and second passes from preprocessor. - - (*) Added the %+ operator in single-line macros for concatenating - two identifiers. Usage example: - - %define _myfunc _otherfunc - %define cextern(x) _ %+ x - cextern (myfunc) - - After first expansion, third line will become "_myfunc". After this - expansion is performed again so it becomes "_otherunc". - - (*) Now if preprocessor is in a non-emitting state, no warning or - error will be emitted. Example: - - %if 1 - mov eax,ebx - %else - put anything you want between these two brackets, - even macro-parameter references %1 or local - labels %$zz or macro-local labels %%zz - no - warning will be emitted. - %endif - - (*) Context-local variables on expansion as a last resort are looked - up in outer contexts. For example, the following piece: - - %push outer - %define %$a [esp] - - %push inner - %$a - %pop - %pop - - will expand correctly the fourth line to [esp]; if we'll define - another %$a inside the "inner" context, it will take precedence over - outer definition. However, this modification has been applied only - to expand_smacro and not to smacro_define: as a consequence - expansion looks in outer contexts, but `%ifdef' won't look in outer - contexts. - - This behaviour is needed because we don't want nested contexts to - act on already defined local macros. Example: - - %define %$arg1 [esp+4] - test eax,eax - if nz - mov eax,%$arg1 - endif - - In this example the "if" mmacro enters into the "if" context, so - %$arg1 is not valid anymore inside "if". Of course it could be - worked around by using explicitely %$$arg1 but this is ugly IMHO. - - (*) Fixed memory leak in `%undef'. The origline wasn't freed before - exiting on success. - - (*) Fixed trap in preprocessor when line expanded to empty set of - tokens. This happens, for example, in the following case: - - #define SOMETHING - SOMETHING - -C.2.41 Version 0.98 - - All changes since NASM 0.98p3 have been produced by H. Peter Anvin - <hpa@zytor.com>. - - (*) The documentation comment delimiter is - - (*) Allow EQU definitions to refer to external labels; reported by - Pedro Gimeno. - - (*) Re-enable support for RDOFF v1; reported by Pedro Gimeno. - - (*) Updated License file per OK from Simon and Julian. - -C.2.42 Version 0.98p9 - - (*) Update documentation (although the instruction set reference - will have to wait; I don't want to hold up the 0.98 release for - it.) - - (*) Verified that the NASM implementation of the PEXTRW and PMOVMSKB - instructions is correct. The encoding differs from what the - Intel manuals document, but the Pentium III behaviour matches - NASM, not the Intel manuals. - - (*) Fix handling of implicit sizes in PSHUFW and PINSRW, reported by - Stefan Hoffmeister. - - (*) Resurrect the -s option, which was removed when changing the - diagnostic output to stdout. - -C.2.43 Version 0.98p8 - - (*) Fix for "DB" when NASM is running on a bigendian machine. - - (*) Invoke insns.pl once for each output script, making Makefile.in - legal for "make -j". - - (*) Improve the Unix configure-based makefiles to make package - creation easier. - - (*) Included an RPM .spec file for building RPM (RedHat Package - Manager) packages on Linux or Unix systems. - - (*) Fix Makefile dependency problems. - - (*) Change src/rdsrc.pl to include sectioning information in info - output; required for install-info to work. - - (*) Updated the RDOFF distribution to version 2 from Jules; minor - massaging to make it compile in my environment. - - (*) Split doc files that can be built by anyone with a Perl - interpreter off into a separate archive. - - (*) "Dress rehearsal" release! - -C.2.44 Version 0.98p7 - - (*) Fixed opcodes with a third byte-sized immediate argument to not - complain if given "byte" on the immediate. - - (*) Allow `%undef' to remove single-line macros with arguments. This - matches the behaviour of #undef in the C preprocessor. - - (*) Allow -d, -u, -i and -p to be specified as -D, -U, -I and -P for - compatibility with most C compilers and preprocessors. This - allows Makefile options to be shared between cc and nasm, for - example. - - (*) Minor cleanups. - - (*) Went through the list of Katmai instructions and hopefully fixed - the (rather few) mistakes in it. - - (*) (Hopefully) fixed a number of disassembler bugs related to - ambiguous instructions (disambiguated by -p) and SSE - instructions with REP. - - (*) Fix for bug reported by Mark Junger: "call dword 0x12345678" - should work and may add an OSP (affected CALL, JMP, Jcc). - - (*) Fix for environments when "stderr" isn't a compile-time - constant. - -C.2.45 Version 0.98p6 - - (*) Took officially over coordination of the 0.98 release; so drop - the p3.x notation. Skipped p4 and p5 to avoid confusion with - John Fine's J4 and J5 releases. - - (*) Update the documentation; however, it still doesn't include - documentation for the various new instructions. I somehow wonder - if it makes sense to have an instruction set reference in the - assembler manual when Intel et al have PDF versions of their - manuals online. - - (*) Recognize "idt" or "centaur" for the -p option to ndisasm. - - (*) Changed error messages back to stderr where they belong, but add - an -E option to redirect them elsewhere (the DOS shell cannot - redirect stderr.) - - (*) -M option to generate Makefile dependencies (based on code from - Alex Verstak.) - - (*) `%undef' preprocessor directive, and -u option, that undefines a - single-line macro. - - (*) OS/2 Makefile (Mkfiles/Makefile.os2) for Borland under OS/2; - from Chuck Crayne. - - (*) Various minor bugfixes (reported by): - Dangling `%s' in - preproc.c (Martin Junker) - - (*) THERE ARE KNOWN BUGS IN SSE AND THE OTHER KATMAI INSTRUCTIONS. I - am on a trip and didn't bring the Katmai instruction reference, - so I can't work on them right now. - - (*) Updated the License file per agreement with Simon and Jules to - include a GPL distribution clause. - -C.2.46 Version 0.98p3.7 - - (*) (Hopefully) fixed the canned Makefiles to include the outrdf2 - and zoutieee modules. - - (*) Renamed changes.asm to changed.asm. - -C.2.47 Version 0.98p3.6 - - (*) Fixed a bunch of instructions that were added in 0.98p3.5 which - had memory operands, and the address-size prefix was missing - from the instruction pattern. - -C.2.48 Version 0.98p3.5 - - (*) Merged in changes from John S. Fine's 0.98-J5 release. John's - based 0.98-J5 on my 0.98p3.3 release; this merges the changes. - - (*) Expanded the instructions flag field to a long so we can fit - more flags; mark SSE (KNI) and AMD or Katmai-specific - instructions as such. - - (*) Fix the "PRIV" flag on a bunch of instructions, and create new - "PROT" flag for protected-mode-only instructions (orthogonal to - if the instruction is privileged!) and new "SMM" flag for SMM- - only instructions. - - (*) Added AMD-only SYSCALL and SYSRET instructions. - - (*) Make SSE actually work, and add new Katmai MMX instructions. - - (*) Added a -p (preferred vendor) option to ndisasm so that it can - distinguish e.g. Cyrix opcodes also used in SSE. For example: - - ndisasm -p cyrix aliased.bin - 00000000 670F514310 paddsiw mm0,[ebx+0x10] - 00000005 670F514320 paddsiw mm0,[ebx+0x20] - ndisasm -p intel aliased.bin - 00000000 670F514310 sqrtps xmm0,[ebx+0x10] - 00000005 670F514320 sqrtps xmm0,[ebx+0x20] - - (*) Added a bunch of Cyrix-specific instructions. - -C.2.49 Version 0.98p3.4 - - (*) Made at least an attempt to modify all the additional Makefiles - (in the Mkfiles directory). I can't test it, but this was the - best I could do. - - (*) DOS DJGPP+"Opus Make" Makefile from John S. Fine. - - (*) changes.asm changes from John S. Fine. - -C.2.50 Version 0.98p3.3 - - (*) Patch from Conan Brink to allow nesting of `%rep' directives. - - (*) If we're going to allow INT01 as an alias for INT1/ICEBP (one of - Jules 0.98p3 changes), then we should allow INT03 as an alias - for INT3 as well. - - (*) Updated changes.asm to include the latest changes. - - (*) Tried to clean up the <CR>s that had snuck in from a DOS/Windows - environment into my Unix environment, and try to make sure than - DOS/Windows users get them back. - - (*) We would silently generate broken tools if insns.dat wasn't - sorted properly. Change insns.pl so that the order doesn't - matter. - - (*) Fix bug in insns.pl (introduced by me) which would cause - conditional instructions to have an extra "cc" in disassembly, - e.g. "jnz" disassembled as "jccnz". - -C.2.51 Version 0.98p3.2 - - (*) Merged in John S. Fine's changes from his 0.98-J4 prerelease; - see http://www.csoft.net/cz/johnfine/ - - (*) Changed previous "spotless" Makefile target (appropriate for - distribution) to "distclean", and added "cleaner" target which - is same as "clean" except deletes files generated by Perl - scripts; "spotless" is union. - - (*) Removed BASIC programs from distribution. Get a Perl interpreter - instead (see below.) - - (*) Calling this "pre-release 3.2" rather than "p3-hpa2" because of - John's contributions. - - (*) Actually link in the IEEE output format (zoutieee.c); fix a - bunch of compiler warnings in that file. Note I don't know what - IEEE output is supposed to look like, so these changes were made - "blind". - -C.2.52 Version 0.98p3-hpa - - (*) Merged nasm098p3.zip with nasm-0.97.tar.gz to create a fully - buildable version for Unix systems (Makefile.in updates, etc.) - - (*) Changed insns.pl to create the instruction tables in nasm.h and - names.c, so that a new instruction can be added by adding it - *only* to insns.dat. - - (*) Added the following new instructions: SYSENTER, SYSEXIT, FXSAVE, - FXRSTOR, UD1, UD2 (the latter two are two opcodes that Intel - guarantee will never be used; one of them is documented as UD2 - in Intel documentation, the other one just as "Undefined Opcode" - -- calling it UD1 seemed to make sense.) - - (*) MAX_SYMBOL was defined to be 9, but LOADALL286 and LOADALL386 - are 10 characters long. Now MAX_SYMBOL is derived from - insns.dat. - - (*) A note on the BASIC programs included: forget them. insns.bas is - already out of date. Get yourself a Perl interpreter for your - platform of choice at http://www.cpan.org/ports/index.html. - -C.2.53 Version 0.98 pre-release 3 - - (*) added response file support, improved command line handling, new - layout help screen - - (*) fixed limit checking bug, 'OUT byte nn, reg' bug, and a couple - of rdoff related bugs, updated Wishlist; 0.98 Prerelease 3. - -C.2.54 Version 0.98 pre-release 2 - - (*) fixed bug in outcoff.c to do with truncating section names - longer than 8 characters, referencing beyond end of string; 0.98 - pre-release 2 - -C.2.55 Version 0.98 pre-release 1 - - (*) Fixed a bug whereby STRUC didn't work at all in RDF. - - (*) Fixed a problem with group specification in PUBDEFs in OBJ. - - (*) Improved ease of adding new output formats. Contribution due to - Fox Cutter. - - (*) Fixed a bug in relocations in the `bin' format: was showing up - when a relocatable reference crossed an 8192-byte boundary in - any output section. - - (*) Fixed a bug in local labels: local-label lookups were - inconsistent between passes one and two if an EQU occurred - between the definition of a global label and the subsequent use - of a local label local to that global. - - (*) Fixed a seg-fault in the preprocessor (again) which happened - when you use a blank line as the first line of a multi-line - macro definition and then defined a label on the same line as a - call to that macro. - - (*) Fixed a stale-pointer bug in the handling of the NASM - environment variable. Thanks to Thomas McWilliams. - - (*) ELF had a hard limit on the number of sections which caused - segfaults when transgressed. Fixed. - - (*) Added ability for ndisasm to read from stdin by using `-' as the - filename. - - (*) ndisasm wasn't outputting the TO keyword. Fixed. - - (*) Fixed error cascade on bogus expression in `%if' - an error in - evaluation was causing the entire `%if' to be discarded, thus - creating trouble later when the `%else' or `%endif' was - encountered. - - (*) Forward reference tracking was instruction-granular not operand- - granular, which was causing 286-specific code to be generated - needlessly on code of the form `shr word [forwardref],1'. Thanks - to Jim Hague for sending a patch. - - (*) All messages now appear on stdout, as sending them to stderr - serves no useful purpose other than to make redirection - difficult. - - (*) Fixed the problem with EQUs pointing to an external symbol - - this now generates an error message. - - (*) Allowed multiple size prefixes to an operand, of which only the - first is taken into account. - - (*) Incorporated John Fine's changes, including fixes of a large - number of preprocessor bugs, some small problems in OBJ, and a - reworking of label handling to define labels before their line - is assembled, rather than after. - - (*) Reformatted a lot of the source code to be more readable. - Included 'coding.txt' as a guideline for how to format code for - contributors. - - (*) Stopped nested `%reps' causing a panic - they now cause a - slightly more friendly error message instead. - - (*) Fixed floating point constant problems (patch by Pedro Gimeno) - - (*) Fixed the return value of insn_size() not being checked for -1, - indicating an error. - - (*) Incorporated 3Dnow! instructions. - - (*) Fixed the 'mov eax, eax + ebx' bug. - - (*) Fixed the GLOBAL EQU bug in ELF. Released developers release 3. - - (*) Incorporated John Fine's command line parsing changes - - (*) Incorporated David Lindauer's OMF debug support - - (*) Made changes for LCC 4.0 support (`__NASM_CDecl__', removed - register size specification warning when sizes agree). - - C.3 NASM 0.9 Series - - Revisions before 0.98. - - C.3.1 Version 0.97 released December 1997 - - (*) This was entirely a bug-fix release to 0.96, which seems to have - got cursed. Silly me. - - (*) Fixed stupid mistake in OBJ which caused `MOV EAX,<constant>' to - fail. Caused by an error in the `MOV EAX,<segment>' support. - - (*) ndisasm hung at EOF when compiled with lcc on Linux because lcc - on Linux somehow breaks feof(). ndisasm now does not rely on - feof(). - - (*) A heading in the documentation was missing due to a markup error - in the indexing. Fixed. - - (*) Fixed failure to update all pointers on realloc() within - extended- operand code in parser.c. Was causing wrong behaviour - and seg faults on lines such as `dd 0.0,0.0,0.0,0.0,...' - - (*) Fixed a subtle preprocessor bug whereby invoking one multi-line - macro on the first line of the expansion of another, when the - second had been invoked with a label defined before it, didn't - expand the inner macro. - - (*) Added internal.doc back in to the distribution archives - it was - missing in 0.96 *blush* - - (*) Fixed bug causing 0.96 to be unable to assemble its own test - files, specifically objtest.asm. *blush again* - - (*) Fixed seg-faults and bogus error messages caused by mismatching - `%rep' and `%endrep' within multi-line macro definitions. - - (*) Fixed a problem with buffer overrun in OBJ, which was causing - corruption at ends of long PUBDEF records. - - (*) Separated DOS archives into main-program and documentation to - reduce download size. - - C.3.2 Version 0.96 released November 1997 - - (*) Fixed a bug whereby, if `nasm sourcefile' would cause a filename - collision warning and put output into `nasm.out', then `nasm - sourcefile -o outputfile' still gave the warning even though the - `-o' was honoured. Fixed name pollution under Digital UNIX: one - of its header files defined R_SP, which broke the enum in - nasm.h. - - (*) Fixed minor instruction table problems: FUCOM and FUCOMP didn't - have two-operand forms; NDISASM didn't recognise the longer - register forms of PUSH and POP (eg FF F3 for PUSH BX); TEST - mem,imm32 was flagged as undocumented; the 32-bit forms of CMOV - had 16-bit operand size prefixes; `AAD imm' and `AAM imm' are no - longer flagged as undocumented because the Intel Architecture - reference documents them. - - (*) Fixed a problem with the local-label mechanism, whereby strange - types of symbol (EQUs, auto-defined OBJ segment base symbols) - interfered with the `previous global label' value and screwed up - local labels. - - (*) Fixed a bug whereby the stub preprocessor didn't communicate - with the listing file generator, so that the -a and -l options - in conjunction would produce a useless listing file. - - (*) Merged `os2' object file format back into `obj', after - discovering that `obj' _also_ shouldn't have a link pass - separator in a module containing a non-trivial MODEND. Flat - segments are now declared using the FLAT attribute. `os2' is no - longer a valid object format name: use `obj'. - - (*) Removed the fixed-size temporary storage in the evaluator. Very - very long expressions (like `mov ax,1+1+1+1+...' for two hundred - 1s or so) should now no longer crash NASM. - - (*) Fixed a bug involving segfaults on disassembly of MMX - instructions, by changing the meaning of one of the operand-type - flags in nasm.h. This may cause other apparently unrelated MMX - problems; it needs to be tested thoroughly. - - (*) Fixed some buffer overrun problems with large OBJ output files. - Thanks to DJ Delorie for the bug report and fix. - - (*) Made preprocess-only mode actually listen to the `%line' markers - as it prints them, so that it can report errors more sanely. - - (*) Re-designed the evaluator to keep more sensible track of - expressions involving forward references: can now cope with - previously-nightmare situations such as: - - mov ax,foo | bar - foo equ 1 - bar equ 2 - - (*) Added the ALIGN and ALIGNB standard macros. - - (*) Added PIC support in ELF: use of WRT to obtain the four extra - relocation types needed. - - (*) Added the ability for output file formats to define their own - extensions to the GLOBAL, COMMON and EXTERN directives. - - (*) Implemented common-variable alignment, and global-symbol type - and size declarations, in ELF. - - (*) Implemented NEAR and FAR keywords for common variables, plus - far-common element size specification, in OBJ. - - (*) Added a feature whereby EXTERNs and COMMONs in OBJ can be given - a default WRT specification (either a segment or a group). - - (*) Transformed the Unix NASM archive into an auto-configuring - package. - - (*) Added a sanity-check for people applying SEG to things which are - already segment bases: this previously went unnoticed by the SEG - processing and caused OBJ-driver panics later. - - (*) Added the ability, in OBJ format, to deal with `MOV - EAX,<segment>' type references: OBJ doesn't directly support - dword-size segment base fixups, but as long as the low two bytes - of the constant term are zero, a word-size fixup can be - generated instead and it will work. - - (*) Added the ability to specify sections' alignment requirements in - Win32 object files and pure binary files. - - (*) Added preprocess-time expression evaluation: the `%assign' (and - `%iassign') directive and the bare `%if' (and `%elif') - conditional. Added relational operators to the evaluator, for - use only in `%if' constructs: the standard relationals = < > <= - >= <> (and C-like synonyms == and !=) plus low-precedence - logical operators &&, ^^ and ||. - - (*) Added a preprocessor repeat construct: `%rep' / `%exitrep' / - `%endrep'. - - (*) Added the __FILE__ and __LINE__ standard macros. - - (*) Added a sanity check for number constants being greater than - 0xFFFFFFFF. The warning can be disabled. - - (*) Added the %0 token whereby a variadic multi-line macro can tell - how many parameters it's been given in a specific invocation. - - (*) Added `%rotate', allowing multi-line macro parameters to be - cycled. - - (*) Added the `*' option for the maximum parameter count on multi- - line macros, allowing them to take arbitrarily many parameters. - - (*) Added the ability for the user-level forms of EXTERN, GLOBAL and - COMMON to take more than one argument. - - (*) Added the IMPORT and EXPORT directives in OBJ format, to deal - with Windows DLLs. - - (*) Added some more preprocessor `%if' constructs: `%ifidn' / - `%ifidni' (exact textual identity), and `%ifid' / `%ifnum' / - `%ifstr' (token type testing). - - (*) Added the ability to distinguish SHL AX,1 (the 8086 version) - from SHL AX,BYTE 1 (the 286-and-upwards version whose constant - happens to be 1). - - (*) Added NetBSD/FreeBSD/OpenBSD's variant of a.out format, complete - with PIC shared library features. - - (*) Changed NASM's idiosyncratic handling of FCLEX, FDISI, FENI, - FINIT, FSAVE, FSTCW, FSTENV, and FSTSW to bring it into line - with the otherwise accepted standard. The previous behaviour, - though it was a deliberate feature, was a deliberate feature - based on a misunderstanding. Apologies for the inconvenience. - - (*) Improved the flexibility of ABSOLUTE: you can now give it an - expression rather than being restricted to a constant, and it - can take relocatable arguments as well. - - (*) Added the ability for a variable to be declared as EXTERN - multiple times, and the subsequent definitions are just ignored. - - (*) We now allow instruction prefixes (CS, DS, LOCK, REPZ etc) to be - alone on a line (without a following instruction). - - (*) Improved sanity checks on whether the arguments to EXTERN, - GLOBAL and COMMON are valid identifiers. - - (*) Added misc/exebin.mac to allow direct generation of .EXE files - by hacking up an EXE header using DB and DW; also added - test/binexe.asm to demonstrate the use of this. Thanks to Yann - Guidon for contributing the EXE header code. - - (*) ndisasm forgot to check whether the input file had been - successfully opened. Now it does. Doh! - - (*) Added the Cyrix extensions to the MMX instruction set. - - (*) Added a hinting mechanism to allow [EAX+EBX] and [EBX+EAX] to be - assembled differently. This is important since [ESI+EBP] and - [EBP+ESI] have different default base segment registers. - - (*) Added support for the PharLap OMF extension for 4096-byte - segment alignment. - - C.3.3 Version 0.95 released July 1997 - - (*) Fixed yet another ELF bug. This one manifested if the user - relied on the default segment, and attempted to define global - symbols without first explicitly declaring the target segment. - - (*) Added makefiles (for NASM and the RDF tools) to build Win32 - console apps under Symantec C++. Donated by Mark Junker. - - (*) Added `macros.bas' and `insns.bas', QBasic versions of the Perl - scripts that convert `standard.mac' to `macros.c' and convert - `insns.dat' to `insnsa.c' and `insnsd.c'. Also thanks to Mark - Junker. - - (*) Changed the diassembled forms of the conditional instructions so - that JB is now emitted as JC, and other similar changes. - Suggested list by Ulrich Doewich. - - (*) Added `@' to the list of valid characters to begin an identifier - with. - - (*) Documentary changes, notably the addition of the `Common - Problems' section in nasm.doc. - - (*) Fixed a bug relating to 32-bit PC-relative fixups in OBJ. - - (*) Fixed a bug in perm_copy() in labels.c which was causing - exceptions in cleanup_labels() on some systems. - - (*) Positivity sanity check in TIMES argument changed from a warning - to an error following a further complaint. - - (*) Changed the acceptable limits on byte and word operands to allow - things like `~10111001b' to work. - - (*) Fixed a major problem in the preprocessor which caused seg- - faults if macro definitions contained blank lines or comment- - only lines. - - (*) Fixed inadequate error checking on the commas separating the - arguments to `db', `dw' etc. - - (*) Fixed a crippling bug in the handling of macros with operand - counts defined with a `+' modifier. - - (*) Fixed a bug whereby object file formats which stored the input - file name in the output file (such as OBJ and COFF) weren't - doing so correctly when the output file name was specified on - the command line. - - (*) Removed [INC] and [INCLUDE] support for good, since they were - obsolete anyway. - - (*) Fixed a bug in OBJ which caused all fixups to be output in 16- - bit (old-format) FIXUPP records, rather than putting the 32-bit - ones in FIXUPP32 (new-format) records. - - (*) Added, tentatively, OS/2 object file support (as a minor variant - on OBJ). - - (*) Updates to Fox Cutter's Borland C makefile, Makefile.bc2. - - (*) Removed a spurious second fclose() on the output file. - - (*) Added the `-s' command line option to redirect all messages - which would go to stderr (errors, help text) to stdout instead. - - (*) Added the `-w' command line option to selectively suppress some - classes of assembly warning messages. - - (*) Added the `-p' pre-include and `-d' pre-define command-line - options. - - (*) Added an include file search path: the `-i' command line option. - - (*) Fixed a silly little preprocessor bug whereby starting a line - with a `%!' environment-variable reference caused an `unknown - directive' error. - - (*) Added the long-awaited listing file support: the `-l' command - line option. - - (*) Fixed a problem with OBJ format whereby, in the absence of any - explicit segment definition, non-global symbols declared in the - implicit default segment generated spurious EXTDEF records in - the output. - - (*) Added the NASM environment variable. - - (*) From this version forward, Win32 console-mode binaries will be - included in the DOS distribution in addition to the 16-bit - binaries. Added Makefile.vc for this purpose. - - (*) Added `return 0;' to test/objlink.c to prevent compiler - warnings. - - (*) Added the __NASM_MAJOR__ and __NASM_MINOR__ standard defines. - - (*) Added an alternative memory-reference syntax in which prefixing - an operand with `&' is equivalent to enclosing it in square - brackets, at the request of Fox Cutter. - - (*) Errors in pass two now cause the program to return a non-zero - error code, which they didn't before. - - (*) Fixed the single-line macro cycle detection, which didn't work - at all on macros with no parameters (caused an infinite loop). - Also changed the behaviour of single-line macro cycle detection - to work like cpp, so that macros like `extrn' as given in the - documentation can be implemented. - - (*) Fixed the implementation of WRT, which was too restrictive in - that you couldn't do `mov ax,[di+abc wrt dgroup]' because - (di+abc) wasn't a relocatable reference. - - C.3.4 Version 0.94 released April 1997 - - (*) Major item: added the macro processor. - - (*) Added undocumented instructions SMI, IBTS, XBTS and LOADALL286. - Also reorganised CMPXCHG instruction into early-486 and Pentium - forms. Thanks to Thobias Jones for the information. - - (*) Fixed two more stupid bugs in ELF, which were causing `ld' to - continue to seg-fault in a lot of non-trivial cases. - - (*) Fixed a seg-fault in the label manager. - - (*) Stopped FBLD and FBSTP from _requiring_ the TWORD keyword, which - is the only option for BCD loads/stores in any case. - - (*) Ensured FLDCW, FSTCW and FSTSW can cope with the WORD keyword, - if anyone bothers to provide it. Previously they complained - unless no keyword at all was present. - - (*) Some forms of FDIV/FDIVR and FSUB/FSUBR were still inverted: a - vestige of a bug that I thought had been fixed in 0.92. This was - fixed, hopefully for good this time... - - (*) Another minor phase error (insofar as a phase error can _ever_ - be minor) fixed, this one occurring in code of the form - - rol ax,forward_reference - forward_reference equ 1 - - (*) The number supplied to TIMES is now sanity-checked for - positivity, and also may be greater than 64K (which previously - didn't work on 16-bit systems). - - (*) Added Watcom C makefiles, and misc/pmw.bat, donated by Dominik - Behr. - - (*) Added the INCBIN pseudo-opcode. - - (*) Due to the advent of the preprocessor, the [INCLUDE] and [INC] - directives have become obsolete. They are still supported in - this version, with a warning, but won't be in the next. - - (*) Fixed a bug in OBJ format, which caused incorrect object records - to be output when absolute labels were made global. - - (*) Updates to RDOFF subdirectory, and changes to outrdf.c. - - C.3.5 Version 0.93 released January 1997 - - This release went out in a great hurry after semi-crippling bugs - were found in 0.92. - - (*) Really _did_ fix the stack overflows this time. *blush* - - (*) Had problems with EA instruction sizes changing between passes, - when an offset contained a forward reference and so 4 bytes were - allocated for the offset in pass one; by pass two the symbol had - been defined and happened to be a small absolute value, so only - 1 byte got allocated, causing instruction size mismatch between - passes and hence incorrect address calculations. Fixed. - - (*) Stupid bug in the revised ELF section generation fixed - (associated string-table section for .symtab was hard-coded as - 7, even when this didn't fit with the real section table). Was - causing `ld' to seg-fault under Linux. - - (*) Included a new Borland C makefile, Makefile.bc2, donated by Fox - Cutter <lmb@comtch.iea.com>. - - C.3.6 Version 0.92 released January 1997 - - (*) The FDIVP/FDIVRP and FSUBP/FSUBRP pairs had been inverted: this - was fixed. This also affected the LCC driver. - - (*) Fixed a bug regarding 32-bit effective addresses of the form - `[other_register+ESP]'. - - (*) Documentary changes, notably documentation of the fact that - Borland Win32 compilers use `obj' rather than `win32' object - format. - - (*) Fixed the COMENT record in OBJ files, which was formatted - incorrectly. - - (*) Fixed a bug causing segfaults in large RDF files. - - (*) OBJ format now strips initial periods from segment and group - definitions, in order to avoid complications with the local - label syntax. - - (*) Fixed a bug in disassembling far calls and jumps in NDISASM. - - (*) Added support for user-defined sections in COFF and ELF files. - - (*) Compiled the DOS binaries with a sensible amount of stack, to - prevent stack overflows on any arithmetic expression containing - parentheses. - - (*) Fixed a bug in handling of files that do not terminate in a - newline. - - C.3.7 Version 0.91 released November 1996 - - (*) Loads of bug fixes. - - (*) Support for RDF added. - - (*) Support for DBG debugging format added. - - (*) Support for 32-bit extensions to Microsoft OBJ format added. - - (*) Revised for Borland C: some variable names changed, makefile - added. - - (*) LCC support revised to actually work. - - (*) JMP/CALL NEAR/FAR notation added. - - (*) `a16', `o16', `a32' and `o32' prefixes added. - - (*) Range checking on short jumps implemented. - - (*) MMX instruction support added. - - (*) Negative floating point constant support added. - - (*) Memory handling improved to bypass 64K barrier under DOS. - - (*) `$' prefix to force treatment of reserved words as identifiers - added. - - (*) Default-size mechanism for object formats added. - - (*) Compile-time configurability added. - - (*) `#', `@', `~' and c{?} are now valid characters in labels. - - (*) `-e' and `-k' options in NDISASM added. - - C.3.8 Version 0.90 released October 1996 - - First release version. First support for object file output. Other - changes from previous version (0.3x) too numerous to document. |