split MODESW into MODESW.CAP and MODESW.INT #406
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tariqkurd-repo
force-pushed
the
split_modesw
branch
from
44bbf8d to
6a8a781
Compare
arichardson
approved these changes
Oct 4, 2024
There was a problem hiding this comment.
Since there are no arguments encoding space should not matter. I'm happy with this change since I don't think switching without knowing the target mode is ever useful.
@jrtc27 @jonwoodruff what do you think?
andresag01
approved these changes
Oct 4, 2024
|
Chatting around the office, @jonwoodruff, @gameboo and I are happy. |
tariqkurd-repo
added a commit
to tariqkurd-repo/riscv-cheri
that referenced
this pull request
Oct 9, 2024
MODESW is difficult to implement in higher performance implementations as it causes a lot of uncertainty in pre-decode and decode about which mode is currently being entered. It also causes a long sequential path through a wide-issue decode packet, compared with entering a specific mode which makes it much easier to determine the mode for each instruction. Therefore it is split into two which directly enter the named mode MODESW.CAP for cap mode and MODESW.INT for int mode, so that instructions can be decoded much more easily. It was only a single encoding before to try and reduced the 16-bit encoding space for C.MODESW. This is guaranteed not to be accepted without showing significant code-size reduction or performance improvement as part of the standardisation process. Only using 32-bit encodings means we can add a second encoding, and so be specific about which mode to enter. --------- Co-authored-by: Andrés Amaya Garcia <andres.amaya@codasip.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MODESW is difficult to implement in higher performance implementations as it causes a lot of uncertainty in pre-decode and decode about which mode is currently being entered. It also causes a long sequential path through a wide-issue decode packet, compared with entering a specific mode which makes it much easier to determine the mode for each instruction.
Therefore it is split into two which directly enter the named mode MODESW.CAP for cap mode and MODESW.INT for int mode, so that instructions can be decoded much more easily.
It was only a single encoding before to try and reduced the 16-bit encoding space for C.MODESW. This is guaranteed not to be accepted without showing significant code-size reduction or performance improvement as part of the standardisation process.
Only using 32-bit encodings means we can add a second encoding, and so be specific about which mode to enter.