Add copyright headers to the *.c/*.h files in the main directory. For
files where I'm sure enough that we have all the approvals, I have
given them the 2-BSD license, the others have been given the "LGPL for
now" license header. Most of them can probably be changed after
auditing.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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.
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.
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.
