From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14985 invoked by alias); 6 Oct 2003 21:21:19 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 14975 invoked from network); 6 Oct 2003 21:21:18 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 6 Oct 2003 21:21:18 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA07879; Mon, 6 Oct 2003 14:21:13 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma007866; Mon, 6 Oct 03 14:20:53 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h96LKvL20490; Mon, 6 Oct 2003 14:20:57 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id OAA22719; Mon, 6 Oct 2003 14:20:56 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.56504.68603.667102@casey.transmeta.com> Date: Mon, 06 Oct 2003 21:21:00 -0000 To: Jim Blandy Cc: cgen@sources.redhat.com Subject: Re: RFA: hardware can have ISA attributes, too In-Reply-To: References: <16242.64736.793146.497702@casey.transmeta.com> X-SW-Source: 2003-q4/txt/msg00002.txt.bz2 Jim Blandy writes: > > I'm not sure about the patch to provide extern @arch@_cgen_hw_table though. > > If it's ultimately needed, great. > > The way it's intended to normally work is that you access the CGEN_HW_ENTRY > > elements via struct cgen_cpu_desc . hw_table. > > I had considered instantiating a desc, the way the disassembler does. > That would work, too. But I wasn't sure how expensive they were, and > I knew the information I needed was right there in the table, no > allocation necessary. > > The toolchain at hand could be handling up to a dozen processor > variants. There'd be a separate desc instantiated for each variant > the user refers to in a single GDB session. Does that seem > reasonable? Sorry for the delay! The message got lost in my queue. Whether it's reasonable or not I'll leave to you. I'm guessing not but I'm not sure what the usage pattern would be. In the end, adding the extern decl is probably a useful thing to do anyway, so just go ahead.