You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, I just noticed that you had taken over and started the proper fast-track process for this extension - thanks a lot!
I found one thing in the description for the compressed instructions:
In the case of the stack-pointer relative instructions we have
It computes its effective address by adding the zero-extended offset, scaled by 8
But not for the others.
Shouldn't it be the same there as well? I see the existing RV64 compressed encodings have the same scaling factor (by including immediate bits [7:3], and it would be beneficial to keep that here as well, for the increased immediate range (and avoiding the possibility for misaligned accesses, unless that's actually a desired feature).
Even if this was already the intended behavior, we should state it explicitly so there's no room for ambiguity
The text was updated successfully, but these errors were encountered:
Hi,
First of all, I just noticed that you had taken over and started the proper fast-track process for this extension - thanks a lot!
I found one thing in the description for the compressed instructions:
In the case of the stack-pointer relative instructions we have
But not for the others.
Shouldn't it be the same there as well? I see the existing RV64 compressed encodings have the same scaling factor (by including immediate bits
[7:3]
, and it would be beneficial to keep that here as well, for the increased immediate range (and avoiding the possibility for misaligned accesses, unless that's actually a desired feature).Even if this was already the intended behavior, we should state it explicitly so there's no room for ambiguity
The text was updated successfully, but these errors were encountered: