> First let me tell you that having this kind of discussion is really helping > and no-one > (I hope) is getting angry about it here.
Thank you Yann. I'm a person who love to study about the efforts made by senior engineers in human civilization. Here is a good reading for such a kind of person to extend knowledge about MMU and TLB. http://www.broadcom.com/collateral/wp/SB-1_WP100-R.pdf It's lengthy and takes time to finish reading. Pages I would emphasis on; Page-2; "it helps to understand the problems that the architects were trying to solve." Page-3; "it means that even a small system must program the MMUs on the PowerPC if it wishes to control ..." "PowerPC turn off the MMUs when an exception occurs. But this also shuts down the behavior control over memory (and I/O device registers to manipulate). "To survive this, the interrupt service routine must reactivate (immediately) MMUs, ..." "There is no clean way to have exception occur ourside the translation mechanism." This document was written by an admirable seasoned programmer and I think the WP is very fine text book for any CPU designers. -nisimura On Tue, Dec 17, 2013 at 9:50 PM, Yann Sionneau <yann.sionn...@gmail.com> wrote: > Le 17/12/13 13:25, Toru Nishimura a écrit : > >> Well, I can not understand many of you argue against me. What >> I have been telling is some CPU implementation like MIPS, Nios2 >> and AVR32, all are very silimar to LM32, have no facility to turn off >> TLB and the decision is quite reasonable to me. >> > First let me tell you that having this kind of discussion is really helping > and no-one (I hope) is getting angry about it here. > Discussing about this design question is helping me at least to have my mind > clear about the different options/alternatives. > The pros the cons about those kind of design choices ... > So I really enjoy that anyone is giving his opinion on this subject, and > even more when those opinions diverge :) > > To me it looks like an optimization that "eret" restores back TLB status > (ON/OFF). > So that you don't need any extra instructions to do it. > And BTW, LM32 already has this sort of mechanism: upon exception IE.IE is > cleared (meaning external interrupts are disabled) and saved in IE.EIE > Then, upon "eret", IE.IE gets its value back from IE.EIE (in pseudocode : > IE.IE = IE.EIE;) > > So it seems logical to do the same for PSW and its I/D TLB ON-OFF switch. > > MIPS is using kseg to access memory with TLB ON, but LM32 does not have such > an addressing mode that goes untranslated (in fact translated but statically > being directly mapped by stripping off the top bit) like MIPS. > So the fact that the CPU designer chose to disable TLB upon exception could > help. > And then, if in fact it does not help and for some reason you really need to > enable it, as it was said earlier you *can* enable it manually. > > About adding CSRs to LM32: there is really only 5 bits available for CSR > IDs, it's too bad but adding CSR by another mean would be intrusive I think > (or if you have a non-intrusive way that don't rely on using GPR or memory > accesses let me know :)) > > Thanks again for sharing your experience on this matter. > > Cheers! > > -- > Yann _______________________________________________ Devel mailing list Devel@lists.milkymist.org https://ssl.serverraum.org/lists/listinfo/devel
