From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Tsukasa OI <research_trasio@irq.a4lg.com>,
Jan Beulich <jbeulich@suse.com>, Nelson Chu <nelson@rivosinc.com>
Cc: binutils@sourceware.org
Subject: [PATCH v4 2/3] RISC-V: Better support for long instructions (assembler)
Date: Fri, 25 Nov 2022 11:42:21 +0000 [thread overview]
Message-ID: <d8d2cda8e4b1a82f93fd9e9daa57f705c582d06f.1669376539.git.research_trasio@irq.a4lg.com> (raw)
In-Reply-To: <cover.1669376539.git.research_trasio@irq.a4lg.com>
From: Tsukasa OI <research_trasio@irq.a4lg.com>
Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.
1. It heavily depended on the bignum internals (radix of 2^16),
2. It generates "value conflicts with instruction length" even if a big
number instruction encoding does not exceed its expected length and
3. Because long opcode was handled separately (from struct riscv_cl_insn),
some information like DWARF line number correspondence was missing.
To resolve these problems, this commit:
1. Handles bignum (and its encodings) precisely and
2. Incorporates long opcode handling into regular instruction handling.
This commit will be tested on the separate commit.
gas/ChangeLog:
* config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field.
(create_insn) Clear long opcode marker.
(install_insn) Install longer opcode as well.
(s_riscv_insn) Likewise.
(riscv_ip_hardcode): Make big number handling stricter. Length and
the value conflicts only if the bignum size exceeds the expected
maximum length.
---
gas/config/tc-riscv.c | 41 ++++++++++++++++++++++++++++++++---------
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/gas/config/tc-riscv.c b/gas/config/tc-riscv.c
index 96d71dd1db60..0682eb355241 100644
--- a/gas/config/tc-riscv.c
+++ b/gas/config/tc-riscv.c
@@ -42,9 +42,13 @@ struct riscv_cl_insn
/* The opcode's entry in riscv_opcodes. */
const struct riscv_opcode *insn_mo;
- /* The encoded instruction bits. */
+ /* The encoded instruction bits
+ (first bits enough to extract instruction length on a long opcode). */
insn_t insn_opcode;
+ /* The long encoded instruction bits ([0] is non-zero on a long opcode). */
+ char insn_long_opcode[RISCV_MAX_INSN_LEN];
+
/* The frag that contains the instruction. */
struct frag *frag;
@@ -720,6 +724,7 @@ create_insn (struct riscv_cl_insn *insn, const struct riscv_opcode *mo)
{
insn->insn_mo = mo;
insn->insn_opcode = mo->match;
+ insn->insn_long_opcode[0] = 0;
insn->frag = NULL;
insn->where = 0;
insn->fixp = NULL;
@@ -731,7 +736,10 @@ static void
install_insn (const struct riscv_cl_insn *insn)
{
char *f = insn->frag->fr_literal + insn->where;
- number_to_chars_littleendian (f, insn->insn_opcode, insn_length (insn));
+ if (insn->insn_long_opcode[0] != 0)
+ memcpy (f, insn->insn_long_opcode, insn_length (insn));
+ else
+ number_to_chars_littleendian (f, insn->insn_opcode, insn_length (insn));
}
/* Move INSN to offset WHERE in FRAG. Adjust the fixups accordingly
@@ -3503,7 +3511,9 @@ riscv_ip_hardcode (char *str,
values[num++] = (insn_t) imm_expr->X_add_number;
break;
case O_big:
- values[num++] = generic_bignum[0];
+ /* Extract lower 32-bits of a big number.
+ Assume that generic_bignum_to_int32 work on such number. */
+ values[num++] = (insn_t) generic_bignum_to_int32 ();
break;
default:
/* The first value isn't constant, so it should be
@@ -3530,12 +3540,25 @@ riscv_ip_hardcode (char *str,
if (imm_expr->X_op == O_big)
{
- if (bytes != imm_expr->X_add_number * CHARS_PER_LITTLENUM)
+ unsigned int llen = 0;
+ for (LITTLENUM_TYPE lval = generic_bignum[imm_expr->X_add_number - 1];
+ lval != 0; llen++)
+ lval >>= BITS_PER_CHAR;
+ unsigned int repr_bytes
+ = (imm_expr->X_add_number - 1) * CHARS_PER_LITTLENUM + llen;
+ if (bytes < repr_bytes)
return _("value conflicts with instruction length");
- char *f = frag_more (bytes);
- for (num = 0; num < imm_expr->X_add_number; ++num)
- number_to_chars_littleendian (f + num * CHARS_PER_LITTLENUM,
- generic_bignum[num], CHARS_PER_LITTLENUM);
+ for (num = 0; num < imm_expr->X_add_number - 1; ++num)
+ number_to_chars_littleendian (
+ ip->insn_long_opcode + num * CHARS_PER_LITTLENUM,
+ generic_bignum[num],
+ CHARS_PER_LITTLENUM);
+ if (llen != 0)
+ number_to_chars_littleendian (
+ ip->insn_long_opcode + num * CHARS_PER_LITTLENUM,
+ generic_bignum[num],
+ llen);
+ memset(ip->insn_long_opcode + repr_bytes, 0, bytes - repr_bytes);
return NULL;
}
@@ -4612,7 +4635,7 @@ s_riscv_insn (int x ATTRIBUTE_UNUSED)
else
as_bad ("%s `%s'", error.msg, error.statement);
}
- else if (imm_expr.X_op != O_big)
+ else
{
gas_assert (insn.insn_mo->pinfo != INSN_MACRO);
append_insn (&insn, &imm_expr, imm_reloc);
--
2.38.1
next prev parent reply other threads:[~2022-11-25 11:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-19 7:10 [PATCH 0/2] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Tsukasa OI
2022-11-19 7:10 ` [PATCH 1/2] RISC-V: Make .insn tests stricter Tsukasa OI
2022-11-21 7:32 ` Jan Beulich
2022-11-23 8:20 ` Tsukasa OI
2022-11-23 8:56 ` Jan Beulich
2022-11-19 7:10 ` [PATCH 2/2] RISC-V: Better support for long instructions Tsukasa OI
2022-11-21 7:37 ` Jan Beulich
2022-11-23 8:40 ` Tsukasa OI
2022-11-23 8:44 ` Jan Beulich
2022-11-23 8:51 ` Tsukasa OI
2022-11-25 1:38 ` Nelson Chu
2022-11-25 2:33 ` Tsukasa OI
2022-11-22 0:43 ` [PATCH 0/2] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Nelson Chu
2022-11-23 8:30 ` [PATCH v2 " Tsukasa OI
2022-11-23 8:30 ` [PATCH v2 1/2] RISC-V: Make .insn tests stricter Tsukasa OI
2022-11-23 8:30 ` [PATCH v2 2/2] RISC-V: Better support for long instructions Tsukasa OI
2022-11-23 9:04 ` Jan Beulich
2022-11-24 2:34 ` Tsukasa OI
2022-11-24 7:31 ` Jan Beulich
2022-11-24 7:35 ` Tsukasa OI
2022-11-25 2:17 ` [PATCH v3 0/2] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Tsukasa OI
2022-11-25 2:17 ` [PATCH v3 1/2] RISC-V: Better support for long instructions (disassembler) Tsukasa OI
2022-11-25 8:03 ` Jan Beulich
2022-11-25 2:17 ` [PATCH v3 2/2] RISC-V: Better support for long instructions (assembler) Tsukasa OI
2022-11-25 8:15 ` Jan Beulich
2022-11-25 8:39 ` Tsukasa OI
2022-11-25 9:04 ` Jan Beulich
2022-11-25 9:18 ` Tsukasa OI
2022-11-25 9:56 ` Jan Beulich
2022-11-25 11:07 ` Tsukasa OI
2022-11-25 11:41 ` [PATCH v3 0/3] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Tsukasa OI
2022-11-25 11:41 ` [PATCH v3 1/3] RISC-V: Better support for long instructions (disassembler) Tsukasa OI
2022-11-25 11:42 ` [PATCH v4 0/3] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Tsukasa OI
2022-11-25 11:42 ` [PATCH v4 1/3] RISC-V: Better support for long instructions (disassembler) Tsukasa OI
2022-11-25 11:42 ` Tsukasa OI [this message]
2022-11-25 11:42 ` [PATCH v4 3/3] RISC-V: Better support for long instructions (tests) Tsukasa OI
2022-11-25 13:08 ` [PATCH v4 0/3] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Jan Beulich
2022-11-28 1:53 ` Nelson Chu
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=d8d2cda8e4b1a82f93fd9e9daa57f705c582d06f.1669376539.git.research_trasio@irq.a4lg.com \
--to=research_trasio@irq.a4lg.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=nelson@rivosinc.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).