Add normative rules for B extension #2562
Conversation
Signed-off-by: James Ball <[email protected]>
Signed-off-by: James Ball <[email protected]>
| - name: slli-uw_ind | ||
| tags: ["norm:slli-uw_ind"] | ||
|
|
||
| # === Zbb: Basic Bit-Manipulation === |
There was a problem hiding this comment.
Many of these extension level normative rules seem like they are general overview and not normative text. More specific versions of them are repeated in the instructions section below, so I'd drop the overview rules/tags. I commented on a few of them, but there are several others.
There was a problem hiding this comment.
Thanks for the feedback. Should I make a follow-up PR to remove those tags from the extension level sections and keep them only at the instruction level?
There was a problem hiding this comment.
That would be great. The easiest way to do so right now is for you to create a branch in your CSC fork based on the B-ext-merge branch (https://github.com/RISC-V-Certification-Steering-Committee/riscv-isa-manual/tree/B-ext-merge). Then you can create a PR on the CSC fork targeting the B-ext-merge (instead of main) and it will update this PR automatically when it is merged. We'll figure out a better system soon, but this will work until that's sorted out.
…ion in this chapter anymore Signed-off-by: James Ball <[email protected]>
Signed-off-by: James Ball <[email protected]>
…rc-b_op already. Signed-off-by: James Ball <[email protected]>
Ammarahwakeel
left a comment
Ammarahwakeel
left a comment
There was a problem hiding this comment.
I may be missing something, but I did run the Makefile and resolved similar errors. Some of those were related to tags being in the .adoc file instead of the YAML file, and vice versa. At the time I opened the PR, there were no errors and the draft PDF built correctly, so I’m wondering how this orc-b_behave error slipped through.
As I just discussed in another comment, we've apparently fallen into an unexpected aspect of Git related to forks. Most of my development in Git has been in projects where I just made changes in a branch and didn't need to use a fork like the ISA manual requires of you (unless you have higher privileges than I do). So, I was caught off guard when PR #2518 was merged a few days ago and it followed typical Git behavior of squashing all the hundreds of commits in that PR down to one in the upstream. Since Git relies on commits and not file content differences like other source control solutions (e.g., Perforce, SCCS, etc.) now Git thinks that our CSC fork's main and all the forks of it (like yours) and all the branches and PRs off of main (like we have for each chapter in the ISA manual) have hundreds of commits ahead of the upstream and so doing a PR from these is a complete mess. Two work around this, @jordancarlin helped me yesterday to create a new-main branch and the B-ext-merge branch. We had to use the git cherry-pick facility to move your commits from its original branch off main into B-ext-merge. This is a somewhat error prone process and we did resolve merge conflicts the best we could. Seems like we didn't get everything which is concerning but not completely unexpected when doing a cherry-pick so then I had to fix up some remaining issues like you've noticed. Other like @rpsene and @mmhus ([email protected]) should see this too. I'll be working with Moiz today (new CSC TPM working for RVI) to figure out our way out of this mess. It's going to be the case for all the many branches and PRs we've created in our CSC fork for each of the chapters. So we'll need a more robust and scalable solution then this cherry-pick solution. |
|
I'm looking into the RISC-V membership privileges in GitHub and I think the
Base Permission needs to be Write so that members can cerate Branches of
all repositories under the RISC-V organizaiton.
…On Fri, Jan 9, 2026 at 9:23 AM james-ball-qualcomm ***@***.***> wrote:
*james-ball-qualcomm* left a comment (riscv/riscv-isa-manual#2562)
<#2562 (comment)>
I may be missing something, but I did run the Makefile and resolved
similar errors. Some of those were related to tags being in the .adoc file
instead of the YAML file, and vice versa. At the time I opened the PR,
there were no errors and the draft PDF built correctly, so I’m wondering
how this orc-b_behave error slipped through.
As I just discussed in another comment, we've apparently fallen into an
unexpected aspect of Git related to forks. Most of my development in Git
has been in projects where I just made changes in a branch and didn't need
to use a fork like the ISA manual requires of you (unless you have higher
privileges than I do). So, I was caught off guard when PR #2518
<#2518> was merged a few
days ago and it followed typical Git behavior of squashing all the hundreds
of commits in that PR down to one in the upstream. Since Git relies on
commits and not file content differences like other source control
solutions (e.g., Perforce, SCCS, etc.) now Git thinks that our CSC fork's
main and all the forks of it (like yours) and all the branches and PRs off
of main (like we have for each chapter in the ISA manual) have hundreds of
commits ahead of the upstream and so doing a PR from these is a complete
mess.
Two work around this, @jordancarlin <https://github.com/jordancarlin>
helped me yesterday to create a new-main branch and the B-ext-merge branch.
We had to use the git cherry-pick facility to move your commits from its
original branch off main into B-ext-merge. This is a somewhat error prone
process and we did resolve merge conflicts the best we could. Seems like we
didn't get everything which is concerning but not completely unexpected
when doing a cherry-pick so then I had to fix up some remaining issues like
you've noticed.
Other like @rpsene <https://github.com/rpsene> and @mmhus
<https://github.com/mmhus> ***@***.***) should see this too.
I'll be working with Moiz today (new CSC TPM working for RVI) to figure
out our way out of this mess. It's going to be the case for all the many
branches and PRs we've created in our CSC fork for each of the chapters. So
we'll need a more robust and scalable solution then this cherry-pick
solution.
—
Reply to this email directly, view it on GitHub
<#2562 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN6ZCF5OUFKRT5HHK2XW34F62UPAVCNFSM6AAAAACRC23EG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRZGEYTIMJWHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Oh, that makes sense now. Thank you for the detailed explanation. I see why my PR showed 200+ commits instead of just my own four, and I understand how the fork and squash merge behavior caused this complexity. I appreciate all the effort in managing the cherry-picks and branch restructuring to merge a single PR. |
|
Rafael and I are looking into updating the permissions correctly.
…On Fri, Jan 9, 2026 at 10:04 AM Bill Traynor ***@***.***> wrote:
I'm looking into the RISC-V membership privileges in GitHub and I think
the Base Permission needs to be Write so that members can cerate Branches
of all repositories under the RISC-V organizaiton.
On Fri, Jan 9, 2026 at 9:23 AM james-ball-qualcomm <
***@***.***> wrote:
> *james-ball-qualcomm* left a comment (riscv/riscv-isa-manual#2562)
> <#2562 (comment)>
>
> I may be missing something, but I did run the Makefile and resolved
> similar errors. Some of those were related to tags being in the .adoc file
> instead of the YAML file, and vice versa. At the time I opened the PR,
> there were no errors and the draft PDF built correctly, so I’m wondering
> how this orc-b_behave error slipped through.
>
> As I just discussed in another comment, we've apparently fallen into an
> unexpected aspect of Git related to forks. Most of my development in Git
> has been in projects where I just made changes in a branch and didn't need
> to use a fork like the ISA manual requires of you (unless you have higher
> privileges than I do). So, I was caught off guard when PR #2518
> <#2518> was merged a few
> days ago and it followed typical Git behavior of squashing all the hundreds
> of commits in that PR down to one in the upstream. Since Git relies on
> commits and not file content differences like other source control
> solutions (e.g., Perforce, SCCS, etc.) now Git thinks that our CSC fork's
> main and all the forks of it (like yours) and all the branches and PRs off
> of main (like we have for each chapter in the ISA manual) have hundreds of
> commits ahead of the upstream and so doing a PR from these is a complete
> mess.
>
> Two work around this, @jordancarlin <https://github.com/jordancarlin>
> helped me yesterday to create a new-main branch and the B-ext-merge branch.
> We had to use the git cherry-pick facility to move your commits from its
> original branch off main into B-ext-merge. This is a somewhat error prone
> process and we did resolve merge conflicts the best we could. Seems like we
> didn't get everything which is concerning but not completely unexpected
> when doing a cherry-pick so then I had to fix up some remaining issues like
> you've noticed.
>
> Other like @rpsene <https://github.com/rpsene> and @mmhus
> <https://github.com/mmhus> ***@***.***) should see this too.
>
> I'll be working with Moiz today (new CSC TPM working for RVI) to figure
> out our way out of this mess. It's going to be the case for all the many
> branches and PRs we've created in our CSC fork for each of the chapters. So
> we'll need a more robust and scalable solution then this cherry-pick
> solution.
>
> —
> Reply to this email directly, view it on GitHub
> <#2562 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAN6ZCF5OUFKRT5HHK2XW34F62UPAVCNFSM6AAAAACRC23EG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMRZGEYTIMJWHE>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
|
@Ammarahwakeel, thanks for the understanding. I'm working with @jrgrimm11, @jordancarlin, and @mmhus to straighten this out. @wmat, are you saying the ISA manual doesn't have an intentional policy of requiring forks instead of branches? Branches would be easier to deal with so I'm a fan of that. There must be some other tradeoffs involved but that's not my forte. |
|
@james Ball ***@***.***> I don't see why members shouldn't
be able to Branch and issue PRs from those branches. We can manage who can
merge PRs easily, so it shouldn't be an issue. Rafael and I will get the
permissions sorted shortly.
…On Fri, Jan 9, 2026 at 1:45 PM james-ball-qualcomm ***@***.***> wrote:
*james-ball-qualcomm* left a comment (riscv/riscv-isa-manual#2562)
<#2562 (comment)>
@Ammarahwakeel <https://github.com/Ammarahwakeel>, thanks for the
understanding. I'm working with @jrgrimm11 <https://github.com/jrgrimm11>,
@jordancarlin <https://github.com/jordancarlin>, and @mmhus
<https://github.com/mmhus> to straighten this out.
@wmat <https://github.com/wmat>, are you saying the ISA manual doesn't
have an intentional policy of requiring forks instead of branches? Branches
would be easier to deal with so I'm a fan of that. There must be some other
tradeoffs involved but that's not my forte.
—
Reply to this email directly, view it on GitHub
<#2562 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN6ZCLCCSQVB3G6ALOQA34F7ZMTAVCNFSM6AAAAACRC23EG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZQGE2TAMJTHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@james-ball-qualcomm I am a bit confused here, why is this PR made directly into riscv/riscv-isa-manual instead of csc fork for CSC review. Have the CSC reviewers reviewed this chapter? |
|
You should talk to Jamie and Moiz. |
mmhus
added
the
NormRules
|
I have reviewed and updated the B-extension normative rules, new PR has been created here: #2628 . This one can be closed now |
7 participants
This is a replacement for PR RISC-V-Certification-Steering-Committee#175 which had too many unrelated commits and file changes for some reason.
##Credits / Contributions
Ammarah wrote the normative rules for the B extension.
@ayeshaanwaar05 wrote the normative rules for the instructions.
@EmanNasar001 authored the YAML file