-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow compressed hints to be expanded #287
base: master
Are you sure you want to change the base?
Conversation
This leads to different values in RVFI. The RISC-V spec allows this behaviour: "simple implementations can ... execute a HINT as a regular computational instruction". Without this feature, such implementations cannot be verified using RVFI.
1bd4fa6
to
51fd1a7
Compare
@@ -120,6 +120,7 @@ static struct option options[] = { | |||
{"disable-writable-misa", no_argument, 0, 'I'}, | |||
{"disable-fdext", no_argument, 0, 'F'}, | |||
{"mtval-has-illegal-inst-bits", no_argument, 0, 'i'}, | |||
{"c-hints-expand", no_argument, 0, 'H'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would rather not have 'H' used as the single character switch, as it probably should be reserved for hypervisor. I would suggest to only have a long option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to, although if I understand correctly, it will mean some refactoring of this file, as currently all the options have short forms and that's what is selected for in the big switch statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can use any number beyond the ascii-table. Just remember to remove the short form of this option from the print_usage()
function.
For example,
#DEFINE C_HINTS_EXPAND_OPT 1000
{"c-hints-expand", no_argument, 0, C_HINTS_EXPAND_OPT},
case C_HINTS_EXPAND_OPT:
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Shouldn't the compressed hints always be expanded? In other words, why do we need rv_c_hints_expand?
- The expansion seems correct to me.
- Testing: what tests exist? Shouldn't we have some tests for checking this functionality as part of the PR?
|
A few thoughts on testing, as I'm not super clear on what tests would look like:
|
The current Sail model hints implementation is a continued mess of people overcomplicating things and doing the wrong thing. See #112 and follow the chain back to earlier discussions. I fully support completely axing the distinction between hints and non-hints at decode time; it’s unnecessary complexity, confusing for people reading the model and gets the disassembly wrong (using some self-invented nonsense mnemonics rather than what both GNU and LLVM toolchains use). The only special casing should be for when extensions are enabled that give the hints additional meaning. |
@jrtc27 Fine by me. I'm happy to do a PR to simplify things back again. |
I honestly don’t know why #31 wasn’t merged and instead the current approach was written and merged. It should just be as I originally proposed. |
I guess the prose spec really doesn't allow that interpretation: presumably they want to make absolutely sure that non-extended code can't use the HINTs and expect them to be nops. |
That’s how toolchains implement them and cores that don’t give the hints special meaning implement them. That’s how the spec intends them to be implemented without further extensions: I think that’s pretty clear that they really are those instructions without additional hint meaning assigning extensions. |
Also note that there are some (new Zce) compressed ops that don't expand to
full width ops.
…On Fri, Jul 21, 2023 at 9:52 AM Jessica Clarke ***@***.***> wrote:
That’s how toolchains implement them and cores that don’t give the hints
special meaning implement them. That’s how the spec intends them to be
implemented without further extensions:
[image: image]
<https://user-images.githubusercontent.com/816232/255234910-43d1183c-32eb-4d4d-9883-b359b5c9841f.png>
I think that’s pretty clear that they really are those instructions
without additional hint meaning assigning extensions.
—
Reply to this email directly, view it on GitHub
<#287 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJQRMQWGKS4WJ4WOM4TXRKXT3ANCNFSM6AAAAAA2QB6ZGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
That doesn’t change anything. Those need implementing directly, but these don’t. |
In the cadd test within riscv-arch-tests, the instruction in inst_5 inst_5:
// rs1==x0, rs2==x2, rs1_val == (2**(xlen-1)-1), rs1_val == 2147483647
// opcode: c.add; op1:x0; op2:x2; op1val:0x0; op2val:-0xb503
TEST_CR_OP( c.add, x0, x2, 0, 0x0, -0xb503, x8, 20, x4) is considered an invalid instruction. Has there been any progress regarding hint instructions? |
Hmm, interesting. IIRC, this change should only affect tracing rather than whether instructions are legal or not. |
This is already a HINT?
The PR here just expands it to actually execute the ADD with zero as the destination. |
I would support closing this PR and just deleting the hints. The only reason I can think to keep them is for nicer disassembly, but that seems marginal and if the disassembly isn't correct at the moment anyway then I don't think it makes sense to keep them. Any objections? |
Would work fine for me! |
This leads to different values in RVFI. The RISC-V spec allows this behaviour:
"simple implementations can ... execute a HINT as a regular computational instruction".
Without this feature, such implementations cannot be verified using RVFI.