Hi, MicroBlaze soft processor only uses physical addresses on the data cache. For the instruction cache, we use virtual addresses and to avoid aliasing problems we use process ID as part of the cache tag. This also has the benefit of avoiding flushing of the instruction cache on task switch since the new task will have a different process ID. So MicroBlaze doesn't need to flush any cache on a task switch.
MMU enables a number of features which all can improve performance like copy-on-write, demand-paging, etc. Göran -----Original Message----- From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Michael Schnell Sent: Monday, September 07, 2009 10:06 AM To: uClinux development list Subject: Re: [uClinux-dev] multiple arch with MMU/noMMU > I feel noMMU might give better performance. I suppose this greatly depends on the chip available and the application you want to do. Regarding the processor chip, with most brands the MMU and non-MMU chips will differ in much more than just the MMU-ness: different clock frequency, different memory interfaces and of course different price. I use the NIOS CPU (soft-core embedded in an Altera FPGA). Here I found that, while the maximum clock frequency allowable (and thus calculation speed) is not greatly affected, the average memory access seems to take about the double count of clock cycles (with cache enabled !). This might be caused partly by the fact that (other than with ARM) the cache seems to use physical addresses instead of virtual. But this is turn avoids the need to flush the cache with any task switch (that is what the ARM system does). So with many task switches the NIOS concept seems to be better, while the ARM concept might be faster with fewer task switches (and thus does appear better with DMIPS tests). Regarding software, the MMU does cost performance when tasks are switches (especially if cache flushing is necessary), but it might help to avoid some complexity in other areas. Within the FPGA, the MMU does introduce considerable additional coast in terms of needed gates and internal memory blocks. -Michael _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
