Interesting development on MMU for Classic AmigaOS.

http://aminet.net/package/util/libs/MMULib.lha

What is interesting here is the MMU is being abstracted away from debugging tools.
what this means that potentialy, support different kind of mmu’s by replacing the MMU library, this should good development direction for Vampire cards that have incompatible MMU, and OS4 systems, that now map this to PPC MMU calls.

Last edited by NutsAboutAmiga on 08-Jul-2020 at 11:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

This is Thomas Richter's project. Good luck getting a 68080 version of MMU lib from him.

Quote:

NutsAboutAmiga wrote: Interesting development on MMU for Classic AmigaOS. http://aminet.net/package/util/libs/MMULib.lha

Nothing new but newer versions.

Quote:

What is interesting here is the MMU is being abstracted away from debugging tools. what this means that poetically, support different kind of mmu’s by replacing the MMU library, this should good development direction for Vampire cards that have incompatible MMU, and OS4 systems, that now map this to PPC MMU calls.

I don't know if the Vampire's Apollo Core would even have what is called an MMU. I believe the MPU (Memory Protection Unit) can mark certain regions with attributes but I'm not sure about page support or virtual address support. The MPU may not be capable of supporting much of the functionality of the MMULib. ThoR talked with Gunnar about implementing an MMU but Gunnar was reluctant as the extra address translations affect performance and hardware support takes considerable FPGA space for the 68k AmigaOS which doesn't use the MMU.

Maybe the PPC would benefit from MMU abstraction since later embedded PPC MMUs could be incompatible and simplified (requires more manual software support).

@NutsAboutAmiga

Quote:

what this means that poetically, support different kind of mmu’s

With rhyming opcodes?

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@matthey

Quote:

Maybe the PPC would benefit from MMU abstraction since later embedded PPC MMUs could be incompatible and simplified (requires more manual software support).

I’m pretty sure AmigaOS4.1 ExecSG already has that. Somewhere in the autodocs.

How ever 68k software does not, I’m not sure if that part is supported by Petunia, In fact I'm pritty sure its not.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@matthey

Quote:

I don't know if the Vampire's Apollo Core would even have what is called an MMU. I believe the MPU (Memory Protection Unit) can mark certain regions with attributes but I'm not sure about page support or virtual address support. The MPU may not be capable of supporting much of the functionality of the MMULib. ThoR talked with Gunnar about implementing an MMU but Gunnar was reluctant as the extra address translations affect performance and hardware support takes considerable FPGA space for the 68k AmigaOS which doesn't use the MMU.

It has MMU, Gunnar has been very clear about that. He has also said that without the MMU, the Vampire cards cannot work, and that if the MMU is exposed to the OS and user, it will break the entire system. What can one conclude from that? My guess, is that the MMU of the AC68080 is used "under the hood" to do memory mapping (for example to map chipram address on V3 cores etc, help EmuTOS with mapping that best "fits" Atari software etc), that it is used along with the second thread (AC68080 is hyperthreaded, rememember) to speed up blitting, DMA etc.

The AC68080 MMU is perhaps the most obfuscated feature of the entire core. Gunnar has expressed *some* interest... or rather, he can see the usefulness, in having a 68040 type PMMU implemented, as it would open up for lots of more usecases, but I doubt it is trivial to implement... a PMMU that isn't really the MMU, but just a "frontend" to the real MMU?... so many potential pitfalls.

Last edited by kolla on 09-Jul-2020 at 09:17 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: It has MMU, Gunnar has been very clear about that. He has also said that without the MMU, the Vampire cards cannot work, and that if the MMU is exposed to the OS and user, it will break the entire system. What can one conclude from that? My guess, is that the MMU of the AC68080 is used "under the hood" to do memory mapping (for example to map chipram address on V3 cores etc, help EmuTOS with mapping that best "fits" Atari software etc), that it is used along with the second thread (AC68080 is hyperthreaded, rememember) to speed up blitting, DMA etc.

Gunnar isn't always honest. It is true that there is address remapping but notice it is setup at startup and remains static after. An MMU can dynamically translate addresses at anytime using virtual address mappings to physical addresses. On the 68k MMU, there is a cache called the ATC (Address Translation Cache) which is often called a TLB on other MMUs. Performance is good when there is a hit in this cache but a miss requires walking through page tables in memory causing significant performance degradation. Modern MMUs often use multi-level address translation caches. All this support takes significant resources and hardware support.

Quote:

The AC68080 MMU is perhaps the most obfuscated feature of the entire core. Gunnar has expressed *some* interest... or rather, he can see the usefulness, in having a 68040 type PMMU implemented, as it would open up for lots of more usecases, but I doubt it is trivial to implement... a PMMU that isn't really the MMU, but just a "frontend" to the real MMU?... so many potential pitfalls.

It shouldn't be difficult to add an ATC, trap on an ATC miss and page walk in software like the embedded PPC MMUs. This often works well for embedded use where code is reused but not as well for general purpose processing like desktop use. Even with this simple support, performance can only degrade and resources are used which could be used to enhance performance elsewhere. Gunnar has chosen to showcase performance in FPGA over support for more advanced MMU using OSs. With an ASIC, all of this logic would need to be reevaluated but Gunnar has illogically ruled out that possibility and hyper-optimized for FPGA only.

@MEGA_RJ_MICAL

Quote:

With rhyming opcodes?

Why not? I started work on a 6502 emulator once. Proof of concept really. I got the basics working. But it wasn't completed. I needed a name for it like I need a name for all my projects. So I came up with a simple rhyme.

// MPU 6502. The rhyming 6502 emulator

Last edited by Hypex on 11-Jul-2020 at 06:31 PM.

@matthey

Quote:

It is true that there is address remapping but notice it is setup at startup and remains static after.

Well, do we know this for a fact? What prevents dedicated software, perhaps not even visible from within AmigaOS, from making use of the AC68080 MMU? How can you know for certain that there is no underlying «hypervisor»-like software running along with AmigaOS?

Quote:

An MMU can dynamically translate addresses at anytime using virtual address mappings to physical addresses.

Exactly, so it could for example be used to do superfast memcopy, by simply mapping the target addresses to the source addresses temporary, in the background, without exec knowing about it... right?

Last edited by kolla on 13-Jul-2020 at 07:07 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: Well, do we know this for a fact? What prevents dedicated software, perhaps not even visible from within AmigaOS, from making use of the AC68080 MMU? How can you know for certain that there is no underlying «hypervisor»-like software running along with AmigaOS?

I have seen no documentation and have little insight from when I was on the Apollo Team. My observations are guesses at best.

Quote:

Exactly, so it could for example be used to do superfast memcopy, by simply mapping the target addresses to the source addresses temporary, in the background, without exec knowing about it... right?

A memcopy with the MMU would only work for read only source and destination data. There is overhead in using the MMU in this way and data would need to be aligned to MMU pages. It would only be practical for large copies.

Linux uses a similar technique with the MMU to share code called Copy on Write.

https://en.wikipedia.org/wiki/Copy-on-write

COW can lead to inconsistent performance in a RTOS and watch out for the Dirty COW vulnerability.

@matthey

Quote:

A memcopy with the MMU would only work for read only source and destination data. There is overhead in using the MMU in this way and data would need to be aligned to MMU pages. It would only be practical for large copies.

And what kind of software fits that description?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Exactly, so it could for example be used to do superfast memcopy, by simply mapping the target addresses to the source addresses temporary, in the background, without exec knowing about it... right?

That just sounds like a really bad idea. Of course it is a cheat and not a real copy. Though it sounds neat doing it behind the back of the OS kernel is only the start of issues. It would work out well at the start by fooling the program into thinking it has a copy at top speed. But then the trouble begins when the copy is used. If it only needed a read only copy and the original didn't change that could be a goer. But if one of the two is modified then management needs to kick in. It would need some kind of memory "plane" layers working like sprites. Where changes in the other plane are exposed. Needing to manage blocks where it is different would then become impractical.

@Hypex

Yeah, but great for benchmarks, right?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: And what kind of software fits that description?

Probably none on the AmigaOS which is why I suggested COW which has some practical applications. A copy of data is usually not needed unless the ability to modify is planned. Sometimes modifications never happen saving the copy altogether although a better algorithm would use the original data and copy it when modifications were needed. The original data addresses (pages) may not be mapped to the current process in an OS with process isolation but COW can still be used to make a copy for any process.

Quote:

kolla wrote: Yeah, but great for benchmarks, right?

Rarely. MMU instructions require supervisor mode and page tables need changing so expect the setup and removal overhead to be many hundreds of cycles. The blitter could be used for chip to chip memory copies where it is faster than the CPU cores but it also has a setup time even though it can be setup from user mode and has more flexible alignment requirements. An SIMD unit probably would be low enough overhead and high enough performance to use for large memory copies with acceptable alignments.

@matthey

Hundreds of cycles (really?) on a hyperthreaded CPU with a mostly idle second thread... we know already that blitting is done in software on the second thread.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: Hundreds of cycles (really?) on a hyperthreaded CPU with a mostly idle second thread... we know already that blitting is done in software on the second thread.

Switching to supervisor mode is fairly expensive.

1) exception (19 cycles)
2) switch stacks (1 cycle)
3) save SR to stack (1 cycle)
4) set SR S-bit (5 cycles)
5) flush instruction pipeline (9 cycles)

These are my estimated best case timings for the 68060. Messing with the MMU is more expensive with MMU instructions taking at least 15 cycles. Adding a page entry will miss in the ATC (TLB) the first time causing a page table walk with 3 memory accesses. Memory which is not cached or caches which need flushing can add significantly to timings. MMUs have become specialized and are not setup for changing memory mappings often.

Multithreading is not going to gain much either as not much work is done in parallel.

@kolla

Quote:

Yeah, but great for benchmarks, right?

Yeah, it would be great for the read test. Until it got to the write test.

@kolla
It is easy to look for conspiracy theories where there is a lack of understanding and transparency. How can memory be so fast on the Apollo core in FPGA?

1) Even low end FPGAs use fairly modern memory. Customers don't want to use old EOL memory for their new hardware which may stay in production for years. While memory performance gains have been small compared to CPU performance (annually 20%-25% for CPU vs 2%-11% for memory), they add up over time when compared to older hardware.

2) A memory data prefetcher may prefetch repeated sequential memory reads. Usually after a DCache miss, noticing that the same code is repeated and a certain data cache read stride is detected, the next read can be speculatively prefetched reducing or possibly eliminating the penalty from the DCache miss. A hard core can usually only hide a DCache L1 miss by prefetching from L2 (usually an L1 miss would give a ~10 cycle bubble in the pipeline) but an FPGA core is much slower relative to memory so prefetching may be more effective (and fewer levels of caches are likely used as larger caches do not restrict performance as much). Gunnar has stated that the Apollo Core added memory prefetch.

FPGAs use modern die sizes which is possible because of mass production due to versatility of the product. The problem with an FPGA is inefficient routing. There are a limited number of paths provided. FPGAs have some commonly used resources which are nearly as fast as hard cores though. Optimum performance may require a deep pipeline with many small stages like a highly clocked hard core but allow large caches like a low clocked hard core. As I have pointed out before in other threads, sometimes it is better to have stronger cores and more efficient cache handling than push the limits of clock speed while executing bubbles a high percentage of the time. For example, ARM revealed that 70-80 percent of the processor cycles on an in order Cortex-A53 or Cortex-A55 are wasted on cache misses. Cortex-A53 cores are used in the Raspberry Pi 3. ARM moved to OoO for their lower power throughput core while the Raspberry Pi 4 also moved to OoO for better performance although it switched to an older high performance core rather than throughput core.

@matthey

Quote:

For example, ARM revealed that 70-80 percent of the processor cycles on an in order Cortex-A53 or Cortex-A55 are wasted on cache misses.

That's terrible! Do you have a link for this? I did an Internet search, but all I got back were false positives.

_________________
"Unix is supposed to fix that." -- Jay Miner

Quote:

bison wrote: That's terrible! Do you have a link for this? I did an Internet search, but all I got back were false positives.

Sure. It's on ARM's site.

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-neoverse-e1-platform-empowering-the-infrastructure-to-meet-next-generation-throughput-demands

The Neoverse E1 throughput core is the replacement for the popular Cortex-A53 and Cortex-A55. Adding OoO dropped wasted processing cycles from cache misses of 70%-80% down to 50% and SMT further dropped them to 30% according to the claim. It looked to me like ARM used to be hesitant to add OoO to their simpler cores to keep them lower power, smaller area, reduce security risk, etc. They were also resistant to adding SMT as they preferred to use their area advantage to add more cores (more cores is good for marketing like more clock speed and more bits).

Quote:

In the traditional applications class, Cortex-A5, Cortex-A7 and Cortex-A53 have very similar energy efficiency. Once a micro-architecture moves to Out-of-Order and increases the ILP/MLP speculation window and frequency there is a trade-off of power against performance which reduces energy efficiency. There’s no real way around this as higher performance requires more speculative transistors. This is why we believe in big.LITTLE as we have simple (relatively) in-order processors that minimise wasted energy through speculation and higher-performance out-of-order cores which push single-thread performance.

- Peter Greenhalgh, lead architect for the Cortex A53

https://www.anandtech.com/show/7591/answered-by-the-experts-arms-cortex-a53-lead-architect-peter-greenhalgh