From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24917 invoked by alias); 5 May 2005 17:55:09 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 24556 invoked from network); 5 May 2005 17:54:43 -0000 Received: from unknown (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org with SMTP; 5 May 2005 17:54:43 -0000 Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 18:54:33 +0100 From: "Dave Korn" To: "'Zack Weinberg'" , "'Nick Clifton'" Cc: "'Alan Modra'" , "'Ben Elliston'" , Subject: RE: PATCH: use hashtab for pseudo op table Date: Thu, 05 May 2005 17:58:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <87k6mdd2a3.fsf@codesourcery.com> Message-ID: X-OriginalArrivalTime: 05 May 2005 17:54:33.0066 (UTC) FILETIME=[7E4CA4A0:01C5519B] X-SW-Source: 2005-05/txt/msg00190.txt.bz2 ----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....