Handling of exceptional events

[Jozott00]

In VADL, there must be a way to define the behavior in case of exception events. Such events include unknown instructions during decoding and illegal memory accesses.

The most obvious way would be to define such behavior using annotations. The behavior when an unknown instruction occurs during decoding could, for example, be defined with

[ unknown instruction : raise Exc(ExcCode::ILLEGAL_INSTR) ]
instruction set architecture RV64Zicsr = { 

   exception Exc(code: Bits<5>) = { ... }
   enumeration ExcCode: Bits<5> = { ILLEGAL_INSTR, ... }
}

In the case of an unknown instruction this works well as there is no dynamic information that needs to be provided to the raised exception (the failed statement can be read with PC in the exception).

However, there are cases where the exception handler needs to know some information about the failed operation. For example, if invalid memory is read, it may be relevant which address was attempted to be read.
With the above approach, we cannot pass the address value to the handler.
Using the lambda syntax would solve this problem

[ illegal read : (addr) -> raise IllegalRead(addr) ]
[ illegal write : (addr, value) -> raise IllegalWrite(addr, value) ]
memory MEM: Bits<64> -> Bits<8>;

However, it would introduce a new construct that is not yet part of VADL.

If we had something like a procedure in VADL (like a function with side effects but no return value), we could do something like this:

[ illegal read : handleIllegalRead ]
memory MEM: Bits<64> -> Bits<8>;

procedure handleIllegalRead(addr: Bits<64>) = {
   raise Exc(ExcCode::LOAD_ACC_FAULT)
}

However, it also introduces a new construct into VADL that is very powerful and has a big impact on the whole language.

Therefore, I currently have no real solution for how users can define the behavior for exceptional events.

[AndreasKrall]

In VADL, there must be a way to define the behavior in case of exception events. Such events include unknown instructions during decoding and illegal memory accesses.

The most obvious way would be to define such behavior using annotations. The behavior when an unknown instruction occurs during decoding could, for example, be defined with

[ unknown instruction : raise Exc(ExcCode::ILLEGAL_INSTR) ]
instruction set architecture RV64Zicsr = { 

   exception Exc(code: Bits<5>) = { ... }
   enumeration ExcCode: Bits<5> = { ILLEGAL_INSTR, ... }
}

In the case of an unknown instruction this works well as there is no dynamic information that needs to be provided to the raised exception (the failed statement can be read with PC in the exception).

We also could do it the other way around:

[raise ExceptionName : VADL::illegalInstruction]

Furthermore, it is necessary to support both the full system and user mode mode emulation in QEMU. For the user mode emulation we need to connect the exceptions with QEMU handling routines.

However, there are cases where the exception handler needs to know some information about the failed operation. For example, if invalid memory is read, it may be relevant which address was attempted to be read. With the above approach, we cannot pass the address value to the handler. Using the lambda syntax would solve this problem

[ illegal read : (addr) -> raise IllegalRead(addr) ]
[ illegal write : (addr, value) -> raise IllegalWrite(addr, value) ]
memory MEM: Bits<64> -> Bits<8>;

Here also the other direction will work:

[raise UnalignedAccess : (VADL::accessAddr & VADL::accessSizeShift) != 0]

However, it would introduce a new construct that is not yet part of VADL.

If we had something like a procedure in VADL (like a function with side effects but no return value), we could do something like this:

[ illegal read : handleIllegalRead ]
memory MEM: Bits<64> -> Bits<8>;

procedure handleIllegalRead(addr: Bits<64>) = {
   raise Exc(ExcCode::LOAD_ACC_FAULT)
}

However, it also introduces a new construct into VADL that is very powerful and has a big impact on the whole language.

Therefore, I currently have no real solution for how users can define the behavior for exceptional events.

An exception is a procedure. We do not want procedures in instructions, only in exceptions and in the processor specification. Another option is to use processes instead of procedures, we will need them anyway.