RFC: Program Properties

Jose E. Marchesi jose.marchesi@oracle.com
Fri Jan 1 00:00:00 GMT 2016



    >     > 1. Minimum ISAs.  Executables and shared objects, which are optimized
    >     > specifically to run on a particular processor, will not run on processors
    >     > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
    >     > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
    >     > information to tell if an executable or a shared object is compatible
    >     > with available ISAs.
    >
    >     Why cant the following be defined as processor specific e_flags (like
    >     other processors do) in elf.h itself?
    >
    > It is easy to exhaust the space of EF_* flags.  In sparc this happened
    > many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
    > and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.
    
    Hmm. Looks reasonable. But I still have some points to ponder:
    
    e_flags is processor specific and I thought each processor has its own
    space. And e_flags is also 4 byte size (purpose is unsigned integer).
    
    The proposed numbering scheme is already at 17 and 14 more left-shifts
    left. It would be same as e_flags capacity.

In SPARC we have more than 32 hardware capabilities, that can be
combined in any way, so 4 bytes are not enough.

Also, the only practical way to define a "minimum ISA" is through these
hardware capabilities: the sparc specs and implementations are not
linear.  As a result the ordered opcodes architectures we define in
opcodes (that correspond to ISAs in our case) are rather artificial.
Consider for example the `v9v' opcodes architecture:

v9v: V9 with OSA2011 and T4 additions, integer multiply and Fujitsu fp
     multiply-add.

Where OSA2011 (Oracle SPARC Architecture 2011) is an extension to
SPARC-V9 (a spec) and "T4 additions" refer to the T4 extensions to
OSA2011, plus a bunch of specific instructions (integer multiply and the
FJ floating-point multiply-add).

So yes, at least in sparc we need to live with many many hardware
capabilities, and these capabilities are only increasing with the
introduction of new versions of the spec and processors.



More information about the Gnu-gabi mailing list