How to determine if an instruction is long or short at the event of an exception? (Variable Length Instructions)

Xfce4 0
Viewed 66

My question is about Chapter 5 in this link.

I have an Error Correction Code which simply increments the program counter (PC) by 2 or 4 bytes according the length of the instruction at the time of exception. The core is e200z4.

As far as I know e200z4 can support Fixed Length Instructions of 4 bytes, too.

The thing I don't understand is that: To determine if Variable Length Instructions (VLE) enabled, we need to check the VLEMI bit in the ESR (Exception Syndrome Register). However, this register always contains 0x00000000. The only interrupt that we end up with is Machine Check Interrupt (IVOR1) (during Power On and Off tests with increasing On and fixed Off intervals).

So, why does the CPU not provide the information about the length of the instruction if VLE is used at the moment of interrupt, for instance via VLEMI bit inside ESR? How could I determine if the instruction at the time of interrupt is 2 bytes or 4 bytes long is fixed length or variable length?

Note1: isOpCode32Bit below is decoding opCode to determine instruction length, but isOpCode32Bit is relevant only if isFixedLength is 0, i.e. when (syndrome & VLEMI_MASK) is equal to 1. So, we need to have VLEMI value in syndrome somehow, but ESR seems to be always 0x00 (why?).

Note2: As mentioned before, we always end up in IVOR1 and the instruction address right before the interrupt is reachable (provided in a register).

// IVOR1 (Machine Check Interrupt Assembly part):
(ASSEMBLY)(mfmcsr r7)  // copy MCSR into register 7 (MCSR in Chapter 5 in the link)
(ASSEMBLY)(store r7 &syndrome)

// IVOR2:
(ASSEMBLY)(mfesr r7)  // copy ESR into register 7 (ESR in Chapter 5 in the link)
(ASSEMBLY)(store r7 &syndrome)

------------------------------------------------------
#define VLEMI_MASK 0x00000020uL

isFixedLength = ((syndrome & VLEMI_MASK) == 0);

if (isFixedLength  || isOpCode32Bit)
{
    PC += 4;    // instruction is 32-bit, increase PC by 4
}
else
{
    PC += 2;    // instruction is 16-bit, increase PC by 2
}
interrupt-handling cpu-architecture embedded exception c
1 Answers

When it comes to how these exception handlers work in real systems:

  • Sometimes handling the exception only requires servicing a page fault (e.g. via copy on write or disc reload).  In such cases, we don't even need to know the length of the instruction, just the effective memory address the instruction is accessing, and the CPUs generally offer that value.  If the page fault can be serviced, then re-running that faulting instruction (without advancing the PC) is appropriate (and if not, then halting the program, also without advancing the PC, is appropriate.)

  • In other cases, such as software emulation for instructions not present in this hardware, presumably hardware designers consider that such a software handler needs to decode the faulting instruction in order to emulate it, and so will figure out the instruction length anyway.

Thus, hardware turns the job of understanding the faulting instruction over to software.  As such system software needs to have deep knowledge of the instruction set architecture, while also likely requiring customization for each different hardware instantiation of the instruction set.

So, why does the CPU not provide information about the length of the instruction at the moment of interrupt inside ESR?

No CPU that I know tells us of the length of an instruction that caused an exception.  If they did, that would be convenient — but only for toy exception handlers.  For real systems, ultimately, this isn't a true burden.

How to determine if an instruction is long or short at the event of an exception? (Vairable Length Instructions)

Decode the instruction (while considering any instruction modes the CPU was in at the time of exception)!

Erik Eidt0
Related