Shorten the time spent checking instruction length

[qwe661234]

I think we can pass the value of instruction length in IR to the exception handler rather than verifying it each time the emulate function is called, because we only need the value of rv->compressed in the exception handler.

[jserv]

Once we complete the instruction decoding, we can definitely know the length of instruction(s) pointed by specific address. Would it make sense?

[qwe661234]

Once we complete the instruction decoding, we can definitely know the length of instruction(s) pointed by specific address. Would it make sense?

Yes, we can know the length of instruction once instruction decoding completes. However, we should send a value to the exception handler if we want to reduce the number of times we check the instruction length.

[jserv]

Yes, we can know the length of instruction once instruction decoding completes. However, we should send a value to the exception handler if we want to reduce the number of times we check the instruction length.

If we can look up the instruction length (RV32 vs. RV32C) from a specific address, there is no need to preserve extra parameter in exception handlers. Let's keep it simple and stupid (KISS principle).

[qwe661234]

Yes, we can know the length of instruction once instruction decoding completes. However, we should send a value to the exception handler if we want to reduce the number of times we check the instruction length.

If we can look up the instruction length (RV32 vs. RV32C) from a specific address, there is no need to preserve extra parameter in exception handlers. Let's keep it simple and stupid (KISS principle).

Sorry, I miss the important information that we get instruction length by parsing instruction opcode, instead of specific address. If we don't want to pass more parameter to exception handlers, we need to save more information in struct riscv_t.

[jserv]

Since preliminary basic block was introduced, speculated execution can take place without frequent instruction length checks. That is, the explicit transition from 32-bit ISA to 16-bit counterpart (vice versa) can be lazily evaluated in a basic block.

[qwe661234]

Since preliminary basic block was introduced, speculated execution can take place without frequent instruction length checks. That is, the explicit transition from 32-bit ISA to 16-bit counterpart (vice versa) can be lazily evaluated in a basic block.

I think the idea above is checking instruction length in a basic block. However, there is a situation I am unsure whether it will occur or not. If a 32-bit instruction and a 16-bit compressed instruction coexist in the same basic block, it is unsafe to determine whether the instruction is compressed in basic block.

[Risheng1128]

We need to know the instruction is compressed or not when the exception occurred. So, I think that rv->compressed can be determined until the exception occurred.

For example, rewrite instruction jal as following:

case rv_insn_jal: { /* JAL: Jump and Link */
        ...
        /* check instruction misaligned */
        if (insn_is_misaligned(rv->PC)) {
+           rv->compressed = false;
            rv_except_insn_misaligned(rv, pc);
            return false;
        }
        /* can branch */
        return true;
    }

Therefore, we don't need to pass instruction length to exception handler and avoid to check rv->compressed frequently.

[qwe661234]

We need to know the instruction is compressed or not when the exception occurred. So, I think that rv->compressed can be determined until the exception occurred.

For example, rewrite instruction jal as following:

case rv_insn_jal: { /* JAL: Jump and Link */
        ...
        /* check instruction misaligned */
        if (insn_is_misaligned(rv->PC)) {
+           rv->compressed = false;
            rv_except_insn_misaligned(rv, pc);
            return false;
        }
        /* can branch */
        return true;
    }

Therefore, we don't need to pass instruction length to exception handler and avoid to check rv->compressed frequently.

Ok, I think it is better idea, I will follow this idea.

[Risheng1128]

The commit Move instruction length checking should merge into the commit Reduce instruction length checking.

[jserv]

Read https://cbea.ms/git-commit/ carefully for writing informative git commit messages.
You should explain the purpose of the proposed changes as well as their advantages.

[jserv]

Again, read https://cbea.ms/git-commit/ carefully.

• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

Last but not least, clearly state how the proposed changes would be beneficial.

[jserv]

Do you understand what Wrap the body at 72 characters means?

[jserv]

By the way, use QuillBot to improve your writing.

[qwe661234]

Do you understand what Wrap the body at 72 characters means?

I see, I need to change line when characters in a line more than 72.