Commit Graph

5 Commits

Author SHA1 Message Date
H. Peter Anvin
166c247f36 hash user allocates struct hash_table
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.
2008-05-28 12:28:58 -07:00
H. Peter Anvin
072771e4a5 Use hash tables even for context-sensitive macros
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.
2008-05-22 13:17:51 -07:00
H. Peter Anvin
a59795c986 Use the crc64 we already use as the perfect hash function prehash
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.
2007-10-02 17:40:00 -07:00
H. Peter Anvin
97a234782d Switch the preprocessor over to using the hash table library
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.
2007-09-16 18:04:57 -07:00
H. Peter Anvin
cde08292d6 Define a proper hash table library
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.
2007-09-14 09:24:38 -07:00