Simplify translationException

[trdthg]

Introduce an new Enum AccessException:

union AccessException = {
  AccessExceptionLoad  : unit,
  AccessExceptionSAMO  : unit,
  AccessExceptionFetch : unit,
}

to simplify the translation from AccessType to ExceptionType.

[Timmmm]

Makes sense, but tbh I think the old code is quite a bit simpler and easier to follow.

Maybe something like this might be a slight improvement:

let is_page_fault = ...;

match access {
  Atomic(_)    => if is_page_fault then E_SAMO_Page_Fault() else E_SAMO_AccessFault(),
  Load(_)     => if is_page_fault then E_Load_Page_Fault() else E_Load_AccessFault(),
...

[github-actions]

Test Results

2 115 tests  ±0   2 115 ✅ ±0   23m 33s ⏱️ -8s
    1 suites ±0       0 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 816f11f. ± Comparison against base commit 89935a8.

[trdthg]

The main reason I have to do this is that, in #1419, PTW_Error was expanded into a recursive structure.

// Failure modes for address-translation/page-table-walks
// Note: Ideally we could use 'PTW_Implicit : (PTW_Error, ...)' in 'PTW_Error' but recursive types are not supported by sail
private union PTW_Implicit_Error = {
  PTW_I_Invalid_Addr  : unit,         // invalid source address
  PTW_I_No_Access     : unit,         // physical memory access error for a PTE
  PTW_I_Invalid_PTE   : unit,         // invalid page table entry or ptr PTE when level = 0
  PTW_I_No_Permission : unit,         // insufficient page permissions
  PTW_I_Misaligned    : unit,         // misaligned superpage
  PTW_I_PTE_Update    : unit,         // PTE update needed but not enabled
  PTW_I_Ext_Error     : ext_ptw_error // parameterized for errors from extensions
}
private union PTW_Error = {
  PTW_Invalid_Addr     : unit,          // invalid source address
  PTW_No_Access        : unit,          // physical memory access error for a PTE
  PTW_Invalid_PTE      : unit,
  PTW_No_Permission    : unit,
  PTW_Misaligned       : unit,          // misaligned superpage
  PTW_PTE_Needs_Update : unit,          // PTE update needed but not enabled
  PTW_Ext_Error        : ext_ptw_error, // parameterized for errors from extensions

  PTW_Implicit         : (PTW_Implicit_Error,                 // error during implicit access/page-walk
                          bits(64),                           // faulting address of implicit access/page-walk
                          MemoryAccessType(mem_payload)), // access type of implicit
}

which made translationException extremely difficult to handle. I could refactor it to

struct PTW_Error {
	type: PTW_ErrorType,
	stage: Stage,           // in which stage does PTW_Error occur?
	addr: bits(64),         // only used when stage == Stage_G
	accesstype: AccessType, // same as above
}

But I think it also won't make translationException simpler, your suggestion maybe will become

if is_gpage_fault then E_SAMO_GPage_Fault() else if is_page_fault then E_SAMO_Page_Fault() else E_SAMO_AccessFault(), 🤔

[nadime15]

To be honest there are a lot of things I am sure we dont have to copy and probably should not copy from #1419. For example introducing of 3 different TLB's, introducing of the Stage_S, Stage_VS, Stage_G variables and even adding a new PTW_Implicit_Error union (it just duplicated what we have).

We could indicate whether this is an implicit but modifying the PTW_Result type and a boolean, from this:

private type PTW_Result('v : Int), is_sv_mode('v) = result((PTW_Output('v), ext_ptw), (PTW_Error, ext_ptw))

to:

// Add a boolean flag to indicate whether the access was implicit or explicit with GPA Addr
// Extend with additional metadata as needed, or introduce a dedicated struct
// to provide explicit naming and stronger typing for related fields.
private type PTW_Result('v : Int), is_sv_mode('v) = 
result((PTW_Output('v), ext_ptw), (PTW_Error, bool, bits(64), ext_ptw))

This just one of many solutions. Or modifying PTW_Error etc.

I work on the 2-Stage Address Translation and I think things can be handled easier without doing the exact same as it in #1419.

[trdthg]

OK, then we'll consider this refactor later.