From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Suprateeka R Hegde <hegdesmailbox@gmail.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: RFC: Program Properties
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <87lgxsnmtl.fsf@oracle.com> (raw)
In-Reply-To: <f8022fa9-2b42-25b4-9465-c6db743c23f2@gmail.com> (Suprateeka R. Hegde's message of "Thu, 13 Oct 2016 22:07:06 +0530")
> > 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.
next prev parent reply other threads:[~2016-10-13 18:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Jose E. Marchesi
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Jose E. Marchesi [this message]
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Joseph Myers
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` Maciej W. Rozycki
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Nick Clifton
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Maciej W. Rozycki
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
-- strict thread matches above, loose matches on Subject: below --
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgxsnmtl.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=gnu-gabi@sourceware.org \
--cc=hegdesmailbox@gmail.com \
--cc=hjl.tools@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).