public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Dmitry Selyutin <ghostmansd@gmail.com>
To: binutils@sourceware.org, Alan Modra <amodra@gmail.com>
Cc: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Subject: Plugin-based opcode table
Date: Tue, 17 May 2022 15:37:36 +0300	[thread overview]
Message-ID: <CAMqzjev3_z+uGbh-0_rdJ06+m5Fn0naeEn5jTpz9Va01JBYSKw@mail.gmail.com> (raw)

Hello folks,

recently we've been discussing the opcode allocation for SVP64[0]. Either
the exact opcodes should be reserved for SVP64 needs, or there must be some
established and documented way to determine programmatically that the code
uses SVP64 extensions, and not other extension. Either way, we're waiting
for OpenPOWER Foundation decision.

Before this decision is taken, and OPF approves and documents it, we'd like
to have some option to adjust the opcodes dynamically, effectively
populating the opcodes table with SVP64 instructions. Or, alternatively,
have a way to provide the alternative opcode table. This way, we would not
pollute the opcodes table and vanilla binutils with opcodes not blessed by
OPF yet. We've been thinking of some plugin, with obvious candidates being
dlopen/dlsym combo. Sure the code will be public, as well as the whole work
around libresoc and SVP64. Also, we might opt to tune few other things via
plugin as well: SVP64 prefixed opcodes are a perfect example of the place
where we fork.

I recall there are plugins in binutils, but I'm not sure whether these are
designed to areas other than linker. I'm also not sure whether this is
supported, and if there is a sufficient documentation on API. A quick
search yields include/plugin-api.h, which might be not what we want.

We'd like to consult with binutils developers on how to approach this
issue, and collect a feedback. Thank you in advance!

[0] https://sourceware.org/pipermail/binutils/2022-May/120775.html

Best regards,
Dmitry

             reply	other threads:[~2022-05-17 12:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17 12:37 Dmitry Selyutin [this message]
2022-05-17 14:01 ` lkcl
2022-05-23 12:59   ` Alan Modra
2022-05-23 13:06     ` Dmitry Selyutin
2022-05-24  5:41       ` Alan Modra
2022-05-24 22:11         ` Dmitry Selyutin
2022-05-29  2:30       ` Peter Bergner
2022-05-29  9:13         ` Luke Kenneth Casson Leighton
2022-05-30 23:55           ` Paul Mackerras
2022-05-31  4:06             ` lkcl

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=CAMqzjev3_z+uGbh-0_rdJ06+m5Fn0naeEn5jTpz9Va01JBYSKw@mail.gmail.com \
    --to=ghostmansd@gmail.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=lkcl@lkcl.net \
    /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).