From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16108 invoked by alias); 7 Oct 2003 04:57:18 -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 16101 invoked from network); 7 Oct 2003 04:57:17 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 7 Oct 2003 04:57:17 -0000 Received: by zenia.home (Postfix, from userid 5433) id C928920766; Mon, 6 Oct 2003 23:56:04 -0500 (EST) To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: RFA: hardware can have ISA attributes, too References: <16242.64736.793146.497702@casey.transmeta.com> <16257.56504.68603.667102@casey.transmeta.com> From: Jim Blandy Date: Tue, 07 Oct 2003 04:57:00 -0000 In-Reply-To: <16257.56504.68603.667102@casey.transmeta.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q4/txt/msg00003.txt.bz2 Doug Evans writes: > 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. Okay, thanks. (Delay in committing patches due to personal entropy, nothing else.)