From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13638 invoked by alias); 25 Sep 2003 14:34:32 -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 13604 invoked from network); 25 Sep 2003 14:34:30 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 25 Sep 2003 14:34:30 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id HAA05057; Thu, 25 Sep 2003 07:34:27 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma005051; Thu, 25 Sep 03 07:34:06 -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 h8PEY9g19410; Thu, 25 Sep 2003 07:34:09 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id HAA05494; Thu, 25 Sep 2003 07:34:08 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16242.64736.793146.497702@casey.transmeta.com> Date: Sat, 27 Sep 2003 04:11:00 -0000 To: Jim Blandy Cc: cgen@sources.redhat.com Subject: RFA: hardware can have ISA attributes, too In-Reply-To: References: X-SW-Source: 2003-q3/txt/msg00070.txt.bz2 Jim Blandy writes: > I don't really feel like I understand CGEN's data model well enough to > know whether this is really appropriate, or just a kludge. > > Here's the motivation. We have a toolchain that supports several > different machines within a family; some register sets are present on > some machines, but not on others. Given an ISA, we want to be able to > traverse the hardware list and see which register sets are available > on that ISA. > > So along with this will come another patch that produces an extern > declaration for @arch@_cgen_hw_table, so we can traverse it. > > What's the best way to do this? The patch to mach.scm is fine. 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. struct cgen_cpu_desc is filled by the call to @arch@_cgen_cpu_open, and the hw_table member is filled in based on the requested machs, not isas. That's why, I think, I didn't initially add the extern declaration. OTOH, if that were the case I would have made it static ... And if it's not static, where's its entry in some header? I don't know enough about the application at hand to know whether all the hw entries you want to look at are in cgen_cpu_desc . hw_table, but given that I didn't make the hw_table static, it should have an extern declaration anyway. Thus go for it. [There are other tables in the same boat, but we can to them on an as-needed basis.]