From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25393 invoked by alias); 27 Sep 2003 04:11:22 -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 25385 invoked from network); 27 Sep 2003 04:11:22 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 27 Sep 2003 04:11:22 -0000 Received: by zenia.home (Postfix, from userid 5433) id AC06720766; Fri, 26 Sep 2003 23:07:34 -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> From: Jim Blandy Date: Sat, 27 Sep 2003 14:13:00 -0000 In-Reply-To: <16242.64736.793146.497702@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-q3/txt/msg00071.txt.bz2 Doug Evans writes: > The patch to mach.scm is fine. Okay, great! > 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?