mmu related

[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.

[ZipCPU]

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]

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).