ZipCPU
commented
1 year ago Thanks for writing, and sharing your interest!
Unfortunately, I'm not quite sure what you are trying to share. For example:
I know its not MMU, but rather a mangement style
I'm not sure what you mean by this.
The MMU requirements have changed since the first draft was built. The first draft required that the MMU sit on the bus, between the bus interface and the actual bus. It was a Wishbone->Wishbone translator. However, in order to be bus independent, the new (as yet unwritten) MMU will need to sit between the CPU and the various bus handlers. As a result it will now need to translate CPU bus request information to CPU bus request information, rather than Wishbone protocol request to Wishbone protocol request.
Getting the page faults right will remain an issue as well. Often the CPU issues write requests to the bus and doesn't wait around for their result. That won't work with an MMU, since you'll have to trap the CPU's write request as soon as you know a page fault exists and before the CPU goes on to the next instruction.
My plan is to set it up so that:
- When the CPU is in supervisor mode, requests go untranslated to the bus.
- When the CPU is in user mode (GIE set), request addresses get translated.
- I had planned on a 16-bit context value. A context value of "zero" would be a system context, or no-translation. This would allow user-mode programs (think kernel tasks) to run on the physical address space and still be interrupted. Any other context would denote a user.
- Since this original plan, it has been suggested that I partition the MMU space so that there are two pages per user task: the user page and a supervisor page, such as the kernel might use when servicing the user task. Switching between the two should be made simple and easy--perhaps requiring only the bottom bit of the context to switch or some such.
- Also, the AXI front end no longer supports a dedicated address space such as the ZipSystem did/does. So, I'll need to pick some addresses for interacting with and controlling the MMU. I'm not yet certain if I'll modify the AXI front end to create a special address carve out, as I did with the ZipSystem, or carve out ZipSystem addresses within the MMU, or ... something else.
- The first MMU was fully associative. I think that was also part of the problem I had when verifying it. Therefore, I'd like to make the next MMU so that each page has a dedicated TLB entry given by the pages address, rather than allowing the CPU to place page entries wherever within the table that the CPU wished to do so.
- My caches also have the problem where it is difficult to clear a portion of the cache, rather than the whole cache. A new (to be determined) MMU flag might fix this.
None of this is hard, but decisions on all of this new design still need to be made.
Frankly, the biggest problem I have with the MMU at present is not the technology part of it but the practical/business part: none of my projects (currently) require one. So far, the ZipCPU has handled all of the projects I've needed it for quite nicely. Now, that may change in the near future, but that's how the matter currently stands.
Dan
paulwratt
not sure how far along the MMU branch is, but having read the article (I think) on why its blocking certain forward movement I thought this might be worth a read (and the follow up post): https://github.com/jart/cosmopolitan/pull/609#issuecomment-1247046556
I know its not MMU, but rather a management style, which seems like it might be applicable, with the technique having certain advantages that even a 32bit address space could use.