From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28687 invoked by alias); 4 Feb 2002 16:32:07 -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 28534 invoked from network); 4 Feb 2002 16:32:03 -0000 Received: from unknown (HELO toenail.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 4 Feb 2002 16:32:03 -0000 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id g14GW1V26047; Mon, 4 Feb 2002 11:32:01 -0500 Date: Mon, 04 Feb 2002 08:32:00 -0000 From: "Frank Ch. Eigler" To: Andrew Cagney Cc: binutils@sources.redhat.com, cgen@sources.redhat.com Subject: Re: include/dis-asm.h patch for cgen disassemblers Message-ID: <20020204113200.A10856@redhat.com> References: <3C5A3694.7020502@cygnus.com> <20020201092827.H6166@redhat.com> <3C5AE910.4090009@cygnus.com> <20020201145627.A4226@redhat.com> <3C5AF43E.8030407@cygnus.com> <20020201151026.B4226@redhat.com> <3C5AFE3C.6050405@cygnus.com> <3C5B00CF.6090001@cygnus.com> <20020201162327.E4226@redhat.com> <3C5B1E19.8030405@cygnus.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C5B1E19.8030405@cygnus.com>; from ac131313@cygnus.com on Fri, Feb 01, 2002 at 06:00:41PM -0500 X-SW-Source: 2002-q1/txt/msg00049.txt.bz2 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3390 Hi - cagney wrote: > [...] > What has a fabrication decision got to do with this? The PS2 is a=20 > number of different ISAs that happen to be on a single chip. Good, we agree. > I'm contending that this is correctly modeled within BFD as separate=20 > BFD_ARCH's. If it isn't then the documentation, at least, for BFD is wro= ng. >=20 > You appear to contend that it is correctly modeled as a single bfd_arch=20 > and a number of different bfd_machs. [...] It is correct in the sense that it works (and has been working for, oh, three years now?), it's reasonably compact in code, and it doesn't obviously contradict any important rules. If you prefer a new "correctness" criterion that it fails, the it's not "correct", but the onus is on you to justify yo= ur criterion. > > I don't really care -- it has no bearing on the current issue. >=20 > It has direct bearing on the current issue. Your response to the above=20 > illustrates this.=20=20 I wish you simply read what I wrote. There is no connection between this PS2 modelling issue and the new one. I'll put it in a table so you can't miss it: PS2 MULTIPLE-ISA CHIP * multiple processors * single processor * one instruction set per * multiple instruction sets processor=20 * one bfd_arch, multiple * one bfd_arch, one bfd_mach bfd_machs For the benefit of mystified binutils/cgen readers, I think the reason cagney is so interested in the first column, is a long-standing quixotic battle against gdb-ically incorrect bfd modelling. Apparently, roughly speaking, gdb's multiarch system likes to map from bfd_arch numbers (and not bfd_arch/bfd_mach pairs) to a vector of target-specific functions. Using multiple bfd_mach codes for dissimilar family members throws a monkey-wrench into this scheme, for the simpleminded "each bfd_mach is a strict subtype of the bfd_arch" view of the world. Whether such a simple/rigid subtyping relationship is in fact reasonable to insist on is a legitimate question, and I invite Andrew to nudge the great ship bfd toward whatever heading he prefers. In the mean time, I expect that people recognize the second column as a distinct situation, with a distinct problem (run-time selection among several instruction sets a la arm/thumb), for which my patch is a reasonable solution.=20=20 > [...] > Who knows what you're doing. You haven't posted any thing updating the=20 > documentation and clarifying this. AFAIK (and I at least have looked), the disassemble_info struct is not separately documented. I will expand on the inline comments though. > [...] Try, instruction_subsets then? I have strong reservations over=20 > isa as it and bfd_architecture are badly overloaded. So -- it is the "a" in "isa" that concerns you. I will for now dodge the issue whether it makes sense to talk about the architecture of an instruction set per se, as opposed to the larger architecture of a processor. I propose to adopt the shortened "insn_sets" as the new disassemble_info field name in question. > Can I assume, for instance, that INSTRUCTION_SUBSETS, wouldn't be used=20 > to select orthogonal ISAs that run on different compute engines? I have no such intent -- as I've had to say too many times now, I need the field to further refine the set of instructions identified by some given bfd_arch/bfd_mach pair. - FChE --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8XreAVZbdDOm/ZT0RAltJAJ49yv/uA4cHrRhTiLLR2NdnaqUnbwCfWftR UET/VS/aNZv+flawucfaN8U= =r0lL -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--