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 15:25:53 -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> <3C5AE910.4090009@cygnus.com> <20020201145627.A4226@redhat.com>
> To me thi 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 assume CGEN or SID.
>
>
> Referring to BFD misses the point! The BFD library barely cares about
> individual instructions or instruction sets. (The only example I can
> come up with off the top of my head is linker relaxation -- about as
> inspiring a module as gdb prologue decoding. :-) Instruction sets as
> such show up in the gas, opcodes, gcc, simulators, and so on. Look
> there for enlightenment.
BFD sets the scene for its clients - LD, GDB, ... It defines an
architecture / machine relationship (abet slighly broken in parts) and
applications use that.
My understanding of CGEN/SID is that they turned their back on BFD and
defined a new set of architecture / machine relationships.
GDB certainly doesn't want to go down that path.
>> [...]
>> 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, ...
>
>
> I need a way of identifying the list of sets of instructions ("instruction
> sets", get it?) valid in some current context (processor state, mode,
> environment, whatever). I think the term "isas" is better than "mode",
> which is in turn better than "environment", to refer to this. Are we
> down to a mere choice-of-terminology issue?
Where is the fire?
See above, there is, I think a more fundamental problem here. The
definition of bfd-architecture and machine are being quietly changed.
Andrew