IRC channel logs
2023-08-21.log
back to list of logs
<muurkha>oriansj: I don't know of any MMUs that exist as a separate part at all, although I know some have existed <muurkha>my current plan for an MMU is to check local-variable accesses and maybe instance-variable accesses at compile time so I can compile them to regular machine instructions that need no dynamic checking to run on a machine without an MMU <muurkha>and then compile accesses to linear memory to invoke a millicode routine that traverses a page table in software, so it can safely run on a machine without an MMU <muurkha>and provide an ARM-like load-multiple instruction in the virtual machine which copies one or more words from linear memory to successive local variables, and a corresponding store-multiple instruction <muurkha>my prototypes so far suggest that with even a very simple compiler I should be able to get a slowdown of only about 75% <muurkha>my Thumb-2 assembly sketch of software page table traversal is: <muurkha> and r5, r7 @ as before, limit index range <muurkha> ubfx r0, r5, #10, #22 @ unsigned bitfield extract of 22 bits <muurkha> ldr r0, [r8, r0, lsl #2] @ load page pointer <muurkha> ubfx r5, r5, #2, #8 @ implicitly discard problematic low bits <muurkha> ldr r5, [r0, r5, lsl #2] @ load desired word <muurkha>that's for the single-word access case, with the desired virtual memory address in r5, a bit mask for valid virtual memory addresses in r7, and the page table base pointer in r8. it handles unaligned access in an arguably undesirable way <muurkha>obviously this is going to be more than 4x slower than a regular unchecked physical memory access, but I'm banking on the fact that most accesses are to local variables rather than linear memory <muurkha>but even the above is just 9 estimated cycles on my target platform <oriansj>muurkha: nice. a very efficient (in terms of removing hardware) apporach to the problem. <oriansj>I've been toying with a couple different designs. 1) make some physical memory address special and only the supervisor process would have access to that page of physical memory. A single pin to swtich between the pointers values in memory 2) 2 pins: READ, WRITE which then allow the reading or writing of the MMU's internal registers. 3) scrap the concept of external MMU and just have an internal MMU which only really needs a single <oriansj>register to point to the pagetable which the process would be using.