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

Different instruction encodings in RV32 and RV64? #152

Open
MasterJerryZh opened this issue Jul 4, 2021 · 4 comments
Open

Different instruction encodings in RV32 and RV64? #152

MasterJerryZh opened this issue Jul 4, 2021 · 4 comments

Comments

@MasterJerryZh
Copy link

Why instruction encodings of rev8 and zext.h are different in RV32 and RV64? But, other instructions that both belong to RV32 and RV64 don't have this characteristic, for example andn and clmul.

@JamesKenneyImperas
Copy link

This is because these instructions are specific aliases of more general GREV, PACK and PACKW instructions. This isn't obvious in the latest specification because this only documents four subsets of the B extension.

@MappleM
Copy link

MappleM commented Jul 5, 2021

This is because these instructions are specific aliases of more general GREV, PACK and PACKW instructions. This isn't obvious in the latest specification because this only documents four subsets of the B extension.

Hello, james! Thank you for your replay and I have understood that why different inst code appears. But I have a question now. It is place at page 31 in v1.0.0-38 bitmanip spec and it is blong to max inst. As show as below picture, I can't understand this sentence. What is the mean of "fuse them together" ? Can you help me? Thanks.

image

@JamesKenneyImperas
Copy link

Fusion is common optimization in which separate instructions are combined by hardware into a single operation internally. In this case, the hardware can optimize because the rD result from the first instruction does not need to be written back to the register file because it is used as a source argument in the second instruction and then discarded. Unless you are designing hardware, you can ignore this statement. If you want to know more, I'd suggest reading up on processor design in general (this is not RISC-V specific).

@MappleM
Copy link

MappleM commented Jul 5, 2021

Ok, I have got it. Thank you, James,you've done me a great favor.

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

No branches or pull requests

3 participants