include/dis-asm.h patch for cgen disassemblers

[Andrew Cagney]

> 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