Re: include/dis-asm.h patch for cgen disassemblers

["Frank Ch. Eigler" <fche@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]

Hi -


cagney wrote:
> [...]
> What has a fabrication decision got to do with this?  The PS2 is a 
> 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 
> BFD_ARCH's.  If it isn't then the documentation, at least, for BFD is wrong.
> 
> You appear to contend that it is correctly modeled as a single bfd_arch 
> 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 your
criterion.


> > I don't really care -- it has no bearing on the current issue.
> 
> It has direct bearing on the current issue.  Your response to the above 
> illustrates this.  

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 
* 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.  


> [...]
> Who knows what you're doing.  You haven't posted any thing updating the 
> 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 
> 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 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]