Skip to content
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

Is th.flurw from xtheadfmemidx really supported on RV32? #49

Open
topperc opened this issue Apr 24, 2024 · 1 comment · May be fixed by #50
Open

Is th.flurw from xtheadfmemidx really supported on RV32? #49

topperc opened this issue Apr 24, 2024 · 1 comment · May be fixed by #50

Comments

@topperc
Copy link

topperc commented Apr 24, 2024

The xtheadfmemidx doc says "All instructions are available for RV32 and RV64". But th.flurw seems identical to th.flrw on RV32.

I found this patch that removed some of the "u" instructions from RV32 for xtheadmemidx. 5d38f4f

cmuellner added a commit to cmuellner/thead-extension-spec that referenced this issue Apr 25, 2024
The XTheadFMemIdx instruction that perform a zero-extension of the index
register (those with a `u` in the name) are identical to the
sign-extension counterparts on RV32. Therefore, it does not make sense
to offer both for RV32.

Further, the table lists the 8-byte loads/stores as compatible with the
`F` extensions. However, 8-byte loads won't fit into single-precision
floating-point register. And 8-byte stores can't be performed from a
single-precision floating-point register. Instead of defining truncation
and extension for these cases, let's make the instructions only
available for those cases where they make sense.

Fixes XUANTIE-RV#49.

Signed-off-by: Christoph Müllner <[email protected]>
@cmuellner
Copy link
Contributor

We should drop th.flurw from RV32, just like we did with th.lur* and th.sur* in the referenced change for the XTheadMemidx extension. The whole table in the XTheadFMemIdx seems to be incorrect and deserves a rework.

Afaik, there is no implementation of XTheadFMemIdx in any of T-Head's RV32 cores. The E902 and the E906 only implement XTheadCmo and XTheadSync. So we can safely edit the spec (and all implementations that follow) without worrying too much.

@cmuellner cmuellner linked a pull request Apr 25, 2024 that will close this issue
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 a pull request may close this issue.

2 participants