Open freshLiver opened 7 months ago
Thank you for submitting a fix! To make sure that we test this, i'd suggest adding a test in the same style and file as this where you create test cases for Expect::Fail
and Expect::Success
that excercises this change.
Thank you for the suggestion! I have added some testing for checking immediate bit range, but currently only for RV32I instructions since I'm not familiar with the [CM]-extensions and the 64-bits instructions.
While adding the remaining testing cases, I encountered similar situations again on other instructions.
In these cases, the issue arises from directly setting the width to the actual width for executing the instruction, rather than configuring it based on the allowed number of imm bits specified in the instruction. Therefore, instructions that involve padding zeros seem to share the problem.
For example, in the case of beq
instruction, even though it allows the branch range to be ±4K (13 bits), due to imm[0] always being 0 to ensure the offset is a multiple of 2, effectively only 12 bits are used for imm.
/// A RISC-V signed immediate field with an input width of 13 bits.
/// Used in B-Type instructions.
///
/// It is defined as:
/// - Imm[31:12] = Inst[31]
/// - Imm[11] = Inst[7]
/// - Imm[10:5] = Inst[30:25]
/// - Imm[4:1] = Inst[11:8]
/// - Imm[0] = 0
constexpr static unsigned VALID_INDEX = 2;
template <unsigned index>
struct ImmB : public ImmSym<index, 13, Repr::Signed,
ImmPartSet<ImmPart<12, 31, 31>, ImmPart<11, 7, 7>,
ImmPart<5, 25, 30>, ImmPart<1, 8, 11>>,
SymbolType::Relative> {
static_assert(index == VALID_INDEX, "Invalid token index");
};
As these scenarios, which appear to be errors, are somewhat related to the instruction processing rather than simple typos, I would like to confirm whether these should be classified as errors and could directly modify the declared width when defining instructions without affecting the original instruction processing.
Description
As the issue desciption said, in the latest Ripes, the I-type instructions will check whether the given immediate part can fit in the instruction limitation.
For example, the
addi
instruction will ensure the given immediate is less than 13 bits, as the following image shows:However, the
lui
instruction's immediate part should only accept an immediate value that could fit in 20 bits, but current version doesn't handle this limitation correctly, as shown in the above image.Tracing
To find the problem, I use
std::cout
to dump thewidth
in thecheckFitsInWidth
function, which is for checking the immediate range:Then, rebuild the Ripes and test it with the following codes:
And found that the
width
oflui
instruction is misconfigured as 32, instead of 20:And this is origin from the the U-type instruction implementation, we can see that the
width
is configured as 32:Solve
By changing the width to 20, the bit range checking now works as expected, on the
lui
andauipc
:Testing
Currently I only use the provided testing utility for checking my changes didn't break it:
However, since I'm not that familiar with C++, I'm not sure whether I understood the bit range checking process correctly. If there is any problem in my changes, please me know.