[continued from previous message]   
      
   can potentially be done more cheaply than a mutex (can be done in   
   premise using No-Cache memory rather than needing an L1 flush).   
      
   Well, or use write-through caching, which would mostly have the merit of   
   allowing for cheaper cache flushes (at the expense of being slower in   
   general than write-back caching).   
      
      
   In the case of RISC-V, there are the FENCE and FENCE.I instructions.   
   In my implementation, they are user-land only, and need to be   
   implemented as, say:   
      FENCE traps, and then performs an L1 flush.   
      FENCE.I traps, and then performs an L1 flush,   
        then also flushes the I$.   
      
   There is CBO, which allows:   
      CBO.FLUSH  Reg   
   Where, Reg gives the address of a cache line, which is then flushed from   
   the L1 D$. This at least mapped over.   
      
   There were CBO.INV and CBO.CLEAN, these did not map over exactly, and in   
   my case have been implemented as equivalent to FLUSH. INV could be   
   theoretically distinct in that it would discard unwritten cache lines,   
   but this wasn't really a thing IME, and making it equivalent to flush   
   sort of works in a "how do you prove that a preceding store wouldn't   
   have been written to RAM before reaching the INV?". CLEAN is sort of a   
   "reload address from RAM ignoring if the cache line was dirty.", also   
   was not a thing in my case.   
      
   For whatever reason, FENCE and FENCE.I were given full Imm12 encodings,   
   which is horribly wasteful. They were then defined as Rd=Rs1=Imm=0.   
   Decided to make it for FENCE.I so that Rd=0, Rs1!=0, Imm12 then behaves   
   like the CBO ops (so, effectively allowing for a "CBO.FLUSH.I Reg" to   
   flush a line in the I$).   
      
      
   Ended up adding an INVTLB instruction, but had put this in as a   
   non-standard instruction in the same general area used for   
   ECALL/EBREAK/RTE/etc.   
      
   Potentially, could make sense to add an "INVTLB Reg" instruction for   
   "Invalidate TLBE associated with this page rather than the whole TLB".   
   Had mostly dealt with this case by forging a dummy TLBE for this address   
   and then doing multiple LDTLBs in a row, which is kind of a crap way to   
   do it; but this is infrequent (mostly needed when a page has been   
   modified in the page table, and the handler code suspects the page is   
   still in the TLB).   
      
      
   Currently, does involve the questionable thing of maintaining a mock-up   
   of the TLB in RAM that code can use to check this stuff, but this is not   
   ideal. Unlike on the SH though, there is no MMIO mechanism to access the   
   TLB, nor any way for the CPU to inspect its contents directly. So, errm,   
   software mock-up it is. This does constrain the types of behaviors   
   allowed by the MMU though.   
      
   Adding the LLPTLB idea would complicate things, as any entry where the   
   page-table in question is present in the LLPTLB may need to be assumed   
   as potentially in the TLB (or, in effect, needing to evict the page   
   regardless of whether it is in the software view of the TLB). Though,   
   maybe a naive "always assume page is potentially in the TLB" is the   
   generally safer option here.   
      
   ...   
      
   >>   
   >> If the memory system implements TSO or similar, then one can simply   
   >> ignore the No-Cache behavior and achieve the same effect.   
   >>   
   >> ..   
   >>   
   >>   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)