RE: PATCH: use hashtab for pseudo op table

["Dave Korn" <dave.korn@artimi.com>]

----Original Message----
>From: Zack Weinberg
>Sent: 05 May 2005 18:13

> The auto-resizing certainly would be nice to have.  I'm not just
> bringing up the indirect function call penalty as a hypothetical,
> though; over in GCC we got measurable speedups by switching back to a
> custom hash table (libcpp/symtab.c) for identifier lookups.

  You mentioned this before in the context of iterators, but surely passing
a function pointer into an iterator routine and getting that function called
once per hashtable item is no worse than having an iterator, calling a
function (not through a pointer admittedly) to advance it once per hashtable
item, and then processing the thing inline?  There's still one function call
per entry and one block of code that loops over all entries calling that
function.....

>  I don't
> know whether the assembler's parse pass bottlenecks in the same places
> that GCC's parsers do, but it wouldn't surprise me -- parsers is
> parsers.

  LOL, that is _soooooo_ not a valid conclusion!  The complexity, structure,
architecture, implementation and behaviour of a backtracking parser that can
make sense of C++ in no way compares to the simple minded "Every line begins
with an optional label, then has an opcode, then some operands, and might
end with a comment" style parsing of gas!  Parsers most definitely is not
just parsers: some of them is parsers, and some is just crude tokenizers and
string matchers, and some is absolute monsters!

> I'm also concerned with hashtab.c's interface being significantly
> messier. 

> That's both less lucid and less efficient.  And it's not practical to
> hide the mess in wrapper functions, because you have to get the type
> of 'key' right ... gas/config/tc-arm.c has about a dozen little
> structures stored in hash tables.

  So, perhaps a slight bit of work on the libiberty hashtab api, to offer a
few interfaces that take a) NUL-terminated strings b) fixed-size structs and
maybe even c) variable sized structs with parameters specifying an offset
and size within the struct where the sizeof the struct can be found, would
make you reconsider?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....