struct hash_table, a fixed-sized structure, is now allocated by the
caller. This lets us integrate it into the Context structure, thus
avoiding an additional dynamically allocated object for no good
reason.
Add some minor code collapsing: make it more obvious that all that
differs is a pointer value, rather than relying on the compiler to do
tail merging.
Normally, contexts aren't used with a large number of macros, but in
case someone does, do use hash tables for those as well. This
simplifies the code somewhat, since *all* handling of macros is now
done via hash tables.
Future note: consider if it wouldn't be better to allow struct
hash_table to be allocated by the caller, instead of being allocated
by the hash table routine.
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.
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.
Switch the preprocessor over to using the hash table library. On my
system, this improves the runtime of the output of test/pref/macro.pl
from over 600 seconds to 7 seconds.
Macros have an odd mix of case-sensitive and case-insensitive
behaviour, plus there are matching parameters for arguments, etc. As
a result, we use case-insensitive hash tables and use a linked list to
store all the possible isomorphs.
Define a proper hash table library, instead of the current ad hoc stuff
used for both labels and macros. This only implements the actual
library; it is not yet used.
We use a CRC64 as a prehash. This is almost certainly overkill,
although it is rather efficient (except, arguably, the table lookup)
on 64-bit platforms, and not all that bad on 32-bit platforms. All we
really need is a function which produces two independent 32-bit
results which are used as the primary and secondary hash
respectively. Either way, the prehash function is easily replacable
if/when we have a quicker alternative.
