Open paulwratt opened 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:
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
I know its not MMU, but rather a mangement style
I'm not sure what you mean by this.
the post was not about an MMU device, so much as memory management through an MMU or MMU window. I though the explained style would be applicable to applications using the ZipCPU with an MMU (considering the original page had stated "MMU was in the works")
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.
Is it work putting together a App that can be applied to any MMU design, allowing measurement & stats as a side effect, something in the line of the "getting started" and "examples" mentioned on the ZBasic/ZcpuOS pages ..
Off the top of my head I cant think of anything "useful", except maybe an "MMU Playground" that can also show user vs supervisor usage/stats/etc
Glad to here you got at least 1 MMU design off the ground. As you found out, the MMU field can be a bit like comparing Apples to Oranges (actually more like Bok Choi to Mom's Cake).
Is it worth adding a SoftMMU, which again is (like you say) kinda differcult if you dont have an application/project that might use it (unless maybe you take into account the above mentioned MMU Playground).
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.