Skip to content

Clarify the word "canonical" in "canonical NaN"#2867

Open
dramforever wants to merge 1 commit intoriscv:mainfrom
dramforever:clarify-canonical-nan
Open

Clarify the word "canonical" in "canonical NaN"#2867
dramforever wants to merge 1 commit intoriscv:mainfrom
dramforever:clarify-canonical-nan

Conversation

@dramforever
Copy link
Copy Markdown

We define a "canonical NaN" for each format, which is unrelated to the concept of canonical encodings in IEEE 754. The latter only makes sense for decimal encodings anyway. Add a non-normative note clarifying this.

IEEE 754-2019 adds a clarifying note that "In binary interchange formats, all number and NaN encodings are canonical." However, I think it's more confusing to explain it this way in the context of this note, so I didn't mention it.

cc @Icenowy

See also a similar clarification for WebAssembly: WebAssembly/spec#1614

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 10, 2026

Normative Rule Changes Detected

This PR modifies normatively tagged text. Please review the changes below to ensure they are intentional.

View Detected Changes

Normative Tag Change Report

riscv-spec Specification

================================================================================
Tag Changes Report
================================================================================

Reference file: ref/riscv-spec-norm-tags.json
Current file: build/riscv-spec-norm-tags.json
Added 3 tags:
  * "norm:sret_dt": "If the Ssdbltrp extension is implemented, when SRET is executed in HS-mode, if the new privilege mod..."
  * "norm:sret_v0": "When executed in M-mode or HS-mode (i.e., V=0), SRET first determines what the new privilege mode wi..."
  * "norm:sret_v1": "When executed in VS-mode (i.e., V=1), SRET sets the privilege mode according to , in vsstatus sets S..."

Deleted 3 tags:
  * "norm:mret_dt": "If the Ssdbltrp extension is implemented, when SRET is executed in HS-mode, if the new privilege mod..."
  * "norm:mret_v0": "When executed in M-mode or HS-mode (i.e., V=0), SRET first determines what the new privilege mode wi..."
  * "norm:mret_v1": "When executed in VS-mode (i.e., V=1), SRET sets the privilege mode according to , in vsstatus sets S..."

Modified 18 tags:
  * "norm:D_flen_64":
      Reference: "The D extension widens the 32 floating-point registers, f0-f31, to
64 bits (FLEN=64 in <<fprs&..."
      Current:   "The D extension widens the 32 floating-point registers,
f0-f31, to 64 bits (FLEN=64 in <<fprs&..."
  * "norm:Zabha_amocas-BH_ignore_bits":
      Reference: "The
AMOCAS.[B|H] instructions similarly ignore the image:../../build/images-out/stem-2aa35a881e52a66..."
      Current:   "The
AMOCAS.[B|H] instructions similarly ignore the �1�
bits of the original value in rd."
  * "norm:Zabha_rd_sign_extension":
      Reference: "Byte and halfword AMOs always sign-extend the value placed in rd, and ignore
the image:../../build/i..."
      Current:   "Byte and halfword AMOs always sign-extend the value placed in rd, and ignore
the �0� bits of the ori..."
  * "norm:bf16_subnorm":
      Reference: "All of the BF16 instructions in the extensions defined in this specification (i.e., Zfbfmin, Zvfbfmi..."
      Current:   "BF16 computational instructions defined in this chapter support all IEEE 754-2008 features, includin..."
  * "norm:f_ieee_compliance":
      Reference: "single-precision floating-point computational instructions compliant
with the IEEE 754-2008 arithmet..."
      Current:   "computational instructions
compliant with the <<ieee754-2008, IEEE 754-2008 arithmetic standar..."
  * "norm:flt-s_fle-s_signaling":
      Reference: "FLT.S and FLE.S perform what the IEEE 754-2008 standard refers to as
signaling comparisons: that is,..."
      Current:   "FLT.S and FLE.S perform what IEEE 754-2008
refers to as signaling comparisons: that is, they set the..."
  * "norm:fmv-d-x_op":
      Reference: "FMV.D.X moves the double-precision value encoded in IEEE 754-2008
standard encoding from the integer..."
      Current:   "FMV.D.X moves the
double-precision value encoded in the IEEE 754-2008 encoding from the
integer regi..."
  * "norm:fmv-h-x_op":
      Reference: "FMV.H.X moves the half-precision value encoded in IEEE 754-2008 standard encoding from the lower 16 ..."
      Current:   "FMV.H.X moves the half-precision value encoded in the IEEE 754-2008 encoding from the lower 16 bits ..."
  * "norm:fmv-w-x_op":
      Reference: "FMV.W.X moves the single-precision value encoded in IEEE 754-2008 standard encoding from the lower 3..."
      Current:   "FMV.W.X moves the single-precision value encoded in the IEEE 754-2008 encoding from the lower 32 bit..."
  * "norm:fmv-x-d_op":
      Reference: "FMV.X.D moves
the double-precision value in floating-point register rs1 to a
representation in IEEE ..."
      Current:   "FMV.X.D moves the double-precision value in
floating-point register rs1 to a representation in the I..."
  * "norm:fmv-x-h_op":
      Reference: "FMV.X.H moves the half-precision
value in floating-point register rs1 to a representation in IEEE
75..."
      Current:   "FMV.X.H moves
the half-precision value in floating-point register rs1 to a
representation in the IEE..."
  * "norm:fmv-x-w_op":
      Reference: "FMV.X.W moves the single-precision value in floating-point register rs1 represented in IEEE 754-2008..."
      Current:   "FMV.X.W moves
the single-precision value in floating-point register rs1 represented
in the IEEE 754-..."
  * "norm:ieee_std_subnormal":
      Reference: "Operations on subnormal numbers are handled in accordance with the IEEE 754-2008 standard."
      Current:   "Operations on subnormal numbers are handled in accordance with IEEE 754-2008."
  * "norm:ieee_std_tininess":
      Reference: "In the parlance of the IEEE standard, tininess is detected after rounding."
      Current:   "In the parlance of IEEE 754-2008, tininess is detected after rounding."
  * "norm:ld_rsv_rst":
      Reference: "For implementations with the "A" standard extension, there is no valid
load reservation."
      Current:   "For implementations with the Zalrsc standard extension, there is no valid
load reservation."
  * "norm:pma_amo_zabha_req":
      Reference: "The AMOs specified by the Zabha extension require the same level of support as
the corresponding ins..."
      Current:   "The AMOs specified by the Zabha extension require the same level of support as
the corresponding ins..."
  * "norm:xret_clr_lr_resv":
      Reference: "If the A extension is supported, the xRET instruction is allowed to
clear any outstanding LR address..."
      Current:   "If the Zalrsc extension is supported, the xRET instruction is allowed to
clear any outstanding LR ad..."
  * "norm:zihpm_op_sz_mode_acc_partition":
      Reference: "These counters are
divided between the "Zicntr" and "Zihpm" extensions."
      Current:   "These counters are
divided between the Zicntr and <<zihpm,Zihpm>> extensions."

================================================================================
Summary: 24 total changes
  Added:    3
  Deleted:  3
  Modified: 18
================================================================================

What happens next:

  • This comment is informational only and does not block merging
  • When this PR is merged, a GitHub issue will be automatically created with the NormRules label for CSC tracking
  • If these changes are unintentional, please update the PR before merging

How to update reference files (if needed):

make update-ref
git add ref/*.json
git commit -m "Update normative tag reference files"

Note: New tags (additions) are automatically added to the reference files when PRs are merged to main. Only modifications and deletions require manual review.

This comment was automatically generated by the normative tag check workflow.

Copy link
Copy Markdown
Member

@aswaterman aswaterman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Funny, even the Wikipedia article on NaN includes this caveat.

@aswaterman
Copy link
Copy Markdown
Member

@dramforever you need to sign your commit with your RSA key as described in https://github.com/riscv/riscv-isa-manual/blob/275f9c941ba4ee71f66cc338ad75e78e68f51a41/CONTRIBUTING.md#signing-github.qkg1.topmits--step-by-step then amend the commit and force-push over the branch.

We define a "canonical NaN" for each format, which is unrelated to the
concept of canonical encodings in IEEE 754. The latter only makes sense
for decimal encodings anyway. Add a non-normative note clarifying this.

IEEE 754-2019 adds a clarifying note that "In binary interchange
formats, all number and NaN encodings are canonical." However, I think
it's more confusing to explain it this way in the context of this note,
so I didn't mention it.

Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
@dramforever dramforever force-pushed the clarify-canonical-nan branch from 71a2745 to aa7ad7d Compare April 10, 2026 23:46
@dramforever
Copy link
Copy Markdown
Author

Oops, missed that signing requirement. Should be signed now.

@aswaterman
Copy link
Copy Markdown
Member

@dramforever No problem; it is a recent requirement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants