This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: use hashtab for pseudo op table
- From: Richard Henderson <rth at redhat dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Dave Korn <dave dot korn at artimi dot com>, "'Nick Clifton'" <nickc at redhat dot com>, "'Alan Modra'" <amodra at bigpond dot net dot au>, "'Ben Elliston'" <bje at au1 dot ibm dot com>, binutils at sources dot redhat dot com
- Date: Thu, 5 May 2005 13:09:09 -0700
- Subject: Re: PATCH: use hashtab for pseudo op table
- References: <SERRANOIA3EEmYDKFJ200000245@SERRANO.CAM.ARTIMI.COM> <87fyx1cxfl.fsf@codesourcery.com>
On Thu, May 05, 2005 at 11:58:06AM -0700, Zack Weinberg wrote:
> > 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?
>
> I'd feel better about the interface, but I'd still be concerned about
> the constant factors. And I want support for not-NUL-terminated
> strings with length passed in separately, too.
The libiberty hash table doesn't need any changes to support this.
The comparison function is asymmetric. It's therefore possible to
compare two completely different items.
For instance:
struct opcode
{
const char *name;
// other stuff
};
struct opcode_key
{
const char *start;
size_t len;
};
static int
eq_opcode_name (const void *xelt, const void *xkey)
{
const struct opcode *elt = (const struct opcode *) xelt;
const struct opcode_key *key = (const struct opcode_key *) xkey;
if (strncmp (elt->name, key->start, key->len) == 0)
return elt->name[key->len] == '\0';
else
return 0;
}
const struct opcode *
find_opcode (const char *start, size_t len)
{
struct opcode_key key;
hashval_t hash;
key.start = name;
key.len = len;
hash = // something like htab_hash_string, but with length
return htab_find_with_hash (htab, &key, hash);
}
That said, I agree that the overhead of the indirection in the libiberty
version will probably be noticable.
r~