This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: include/dis-asm.h patch for cgen disassemblers
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Andrew Cagney <cagney at redhat dot com>, binutils at sources dot redhat dot com
- Date: Fri, 01 Feb 2002 14:36:01 -0500
- Subject: Re: include/dis-asm.h patch for cgen disassemblers
- References: <20020131124350.C19966@redhat.com> <15449.42904.232177.265525@casey.transmeta.com> <20020131162132.I19966@redhat.com> <3C59BD4A.9060900@cygnus.com> <20020131184230.A6166@redhat.com> <3C59DB61.3000106@cygnus.com> <20020131195734.D6166@redhat.com> <3C5A3694.7020502@cygnus.com> <20020201092827.H6166@redhat.com>
[doh, I got binutils@wrong]
[Frank sent this privately, quoted with permission]
> Hi -
>
> On Fri, Feb 01, 2002 at 01:32:52AM -0500, Andrew Cagney wrote:
>
>> [...]
>> Yes, and both bfd_arch_ia64 and bfd_arch_i386 are defined as separate
>> bfd_architectures.
>
>
> That's something else, explained by other factors, such as the
> ~12-year delay between their development, and a reluctance to
> build any given program with both pieces.
>
It is also explained by someone making the rational decision that these two ISA's really are different and hence deserve separate bfd_architecture designations.
Consider the PS2. It contains a number of compute engines (for want of a better term), each with their own ISA. Do they each get their own bfd_architecture or does something else happen?
Remembering the history of BFD, I'd think they would get different bfd_architecture designations. GDB has certainly been working on this assumption.
>
>
>> Sorry, can you try that again.
>
>
> Think about it. If the processor has modes, each of which has a
> different set of instructions available to it, then for many
> purposes, those sets need to be formally identified as distinct
> groups. That's what an instruction set is, in the deeper sense.
>
>
>
To me this appears to be subverting what I understand to be the original intent of BFD's architecture / machine model. The subverting might be a good thing, however, it needs to be carefully considered and in a context that doesn't preassume definitions that CGEN or SID have adopted.
I think for this change to go through BFD needs to first clearly define (and document - hint!) what bfd_architecture, machine and this new thing are and where they apply.
My guess is ``environment'' (stolen from the PPC ISA manual). For instance:
bfd_powerpc - the ISA or ISA family
ppc620 - the specific implementation - supports two modes (or as you like to call them ISA)
environment - 32/64, operating/user, altivec, ...
Andrew