Unexpected differences in sstatus bits following sret

[GuMys-WanJS]

Description

During differential testing between Spike and an RTL implementation, we observed a mismatch in the value of the sstatus CSR after trap handling and an sret instruction. To further investigate this discrepancy, we compared the same test on two Spike versions and found that Spike itself shows different behavior across releases:

v1.0.1: 0x8000000200006000  
RTL:    0x8000000200006020  
v1.1.1: 0x8000000200006220

Thus, the sstatus bits restored aftersretdiffer between:

• RTL vs. Spike, and
• Spike v1.0.1 vs. Spike v1.1.1.

The observed differences involve lower fields of sstatus (e.g., bits around 0x20 and 0x220), which are updated differently between versions.
We would like to ask:

• Was this behavioral change introduced intentionally?
• If so, which commit or specification revision introduced this update?

Clarifying this would help us properly track version-specific CSR behavior and maintain consistency in our model.

[aswaterman]

The behavior is correct.

Bit 9 is part of the VS field, which was added by the V extension in commit 7221b28

Bit 5 is SPIE, which the spec says is supposed to be set by SRET. This behavior was introduced in d392463 -- before v1.0.1 -- so it's hard to reconcile what you're seeing in the old version.

If you need any more info, you'll need to spend the time to dig it up.