SAA's were never intended to allow random access, but several backends
do random or semirandom access via saa_fread() and saa_fwrite()
anyway. Rewrite the SAA system to allow for efficient random access.
On "label.pl 10000000" this improves performance by a factor of 12.
Change cloc_t to struct location, and reorder the members so that it
should fit in 16 bytes instead of needing 8 bytes of extra padding on
64-bit machines.
Change loc_t to cloc_t to avoid AIX conflict.
We really shouldn't use _t names at all; they are usually considered
platform types, but worry about that later.
Concentrate compiler dependencies to compiler.h; make sure compiler.h
is included first in every .c file (since some prototypes may depend
on the presence of feature request macros.)
Actually use the conditional inclusion of various functions (totally
broken in previous releases.)
Use the same crc64 that we already use for the symbol table hash as
the perfect hash function prehash. We appear to get radically faster
convergence this way, and the crc64 is probably *faster*, since the
table likely to be resident in memory.
0F 18-1F are reserved for hinting NOPs; they all take a single memory
operand which may be sized. Allow the use of systematic names; this
also makes sure they get sensibly disassembled.
Remove bogus "treat labels different from immediates" code, which
would result in generating of a relative mod/rm but without adjusting
the address accordingly.
Update addressing mode test.
To deal with fools^Wpeople trying to keep really old systems alive,
create a proper framework for substitution functions, and make it
possible to deal with the lack of snprintf/vsnprintf in particular.
Add support for daily snapshot releases of the form
<ordinary version number>-<datecode>. These are exported to programs
as the new macro __NASM_SNAPSHOT__ (only present in snapshot releases.)
Add a Makefile for OpenWatcom using WMAKE. This is a horrible version
of Make, but since it's bundled with OpenWatcom it is probably better
to stick to it. It has the nice property that it can produce DOS,
Win32 or OS/2 binaries.
This Makefile currently assumes that it is hosted on a system where
pathname separators are backslashes. For cross-compiling using
OpenWatcom on a Linux system it is probably better to write a separate
Makefile using GNU make to invoke Watcom.
Corrections the section on 64-bit immediates and displacements. In
particular, immediates are sign-extended the same way displacements
are (and the same way 8-bit immediates are), so there is some use for
the 7-byte mov eax,dword imm form :(
Add nasm_zalloc(), a wrapper around calloc(), to allocate
zero-initialized memory. For large allocations, this is often far
more efficient than allocating and zeroing, since the operating system
tends to keep a pool of zero pages around.
The parent-pointer-based freeing loop in %undef should not advance the
parent pointer when a node is freed, since that will result accessing
freed memory.
Per SF bug report 1351586:
The COFF spec suggests that the "Virtual Size" field (which
immediately follows the name field inside a section header) be set to
0 for an object file.
By contrast (as documented in comment #4 at the beginning of its
outcoff.c file) NASM sets it to a particular non-0 value.
MASM 6.15 matches NASM for both 16- and 32-bit object files,
i.e. emits non-0 values.
MASM 8 (from VS 2005 Beta) matches the COFF spec for 64-bit object
files, i.e. emits 0.
GAS matches the COFF spec for 32-bit object files (MinGW or Cygwin),
i.e. also emits 0.
Older versions of GNU ld seem to honor said "Virtual Size" field
whereas newer versions do not. As a result those older versions
generate "bloated" image files.
Since the COFF spec and the real world seem to disagree for this case,
it might make sense to add a method for selecting between the two to
NASM.
Date: 2005-11-28 15:39
Sender: nasm64developer
Logged In: YES
user_id=804543
MASM 8 (from VS 2005 Beta) also matches the COFF spec for 16- and
32-bit object files, i.e. emits 0.
That said, NASM should always emit 0 too. Therefore I am turning this
from a support request into a bug.
