This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi -

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.

It is a sensible modelling decision, given that executables are
unlikely to mix ia64 and ia32 code.  The point of the example was
to show that the same piece of hardware can implement distinct
instruction sets, contrary to your possible desire to lump them
all into one mega-isa and calling them insubstantial "modes".

(BTW, I wonder whether ia64 OS kernels need to have some of each,
and if so, whether linker tricks are required to make that work.)


> 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? [...]

We did whatever must have seemed most useful at the time for their
treatment ... one bfd_arch, a bunch of bfd_mach's.  Note that all
those coprocessors have a static set of instructions.


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


> [...]
> 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?


- FChE

Attachment: msg00041/pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]