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
[email protected]
https://ssl.serverraum.org/lists/listinfo/devel
