»

[shoggoth]

What's this about the PMMU slowing things down? I've used the PMMU in the 030 and 060 in some personal project, and I can't really note any real performance hit when using it. Maybe it's an issue when you're running on an 8Mhz CPU with no cache, but it's definitely not an issue on a 060, for example.

Maybe I missed the point completely. Can someone shed some light on this for me?

[Kronos]

ops:

[biggun]

shoggoth wrote:
What's this about the PMMU slowing things down? I've used the PMMU in the 030 and 060 in some personal project, and I can't really note any real performance hit when using it. Maybe it's an issue when you're running on an 8Mhz CPU with no cache, but it's definitely not an issue on a 060, for example.

Maybe I missed the point completely. Can someone shed some light on this for me?

If you have a address range of 1GB and 4KB pages then you 260,000 MMU entries for this. These a Megabytes of MMU table data!

Your MMU can remember a limited number of page entries on Chip. (64 pages in case of the 68060).
64 Page entries equall to 256 KB of memory.

If your program is bigger than 256 KB and jumps around in memory a lot then your on CHIP MMU entries on chip are too few. This means your MMU needs to re-read these entries from memory constantly.

In worth case scenario is can go as far as your MMU end up needing to reload one MMU table entry per memory access.
Its common to see this behavior on certain memory stress test. Affective algorithms can degrade perfromance by up to 50%.


A MMU adds overhead to the Chip.
Motorola 68060 chip with FPU and MMU was advertised with 60 MHz clockrate. The same CPU without FPU and MMU was running with 75 MHZ.

A MMU will add overhead and latency.
The Latency can be hidden by creating a more complex address generation pipeline and by using on chip cache(to cache to MMU tables).

Please mind that even the most simplest MMU with just one Bit per page to indicate access allowed, will need an MMU-table of 32KB.
Creating a MMU with a on chip cache and a dynamic reloading of MMU table missed is complex.
Putting the whole MMU table on chip is a simpler design but it would eat 32K on chip cache memory.

The MMU on the chip is a lot of overheat.
There is a good reason that no one does a MMU on blitter!

[A6000]

biggun wrote:
A MMU adds overhead to the Chip.
Motorola 68060 chip with FPU and MMU was advertised with 60 MHz clockrate. The same CPU without FPU and MMU was running with 75 MHZ.

A MMU will add overhead and latency.
The Latency can be hidden by creating a more complex address generation pipeline and by using on chip cache(to cache to MMU tables).

Please mind that even the most simplest MMU with just one Bit per page to indicate access allowed, will need an MMU-table of 32KB.
Creating a MMU with a on chip cache and a dynamic reloading of MMU table missed is complex.
Putting the whole MMU table on chip is a simpler design but it would eat 32K on chip cache memory.

The MMU on the chip is a lot of overheat.
There is a good reason that no one does a MMU on blitter!

The presence of an FPU was the reason why the full '060 could not officially run at 75mhz, some rev6 '060s can run at 100mhz.

leaving out the MMU was an economic decision.

The benefits of an MMU, like memory protection, outweigh the speed penalty. even though the amigaOS is not suited to memory protection, an MMU IS still useful as proven by ENFORCER.

[biggun]

A6000 wrote:
The benefits of an MMU, like memory protection, outweigh the speed penalty. even though the amigaOS is not suited to memory protection, an MMU IS still useful as proven by ENFORCER.

You are missing the point of the discussion.

One statement was that a CPU MMU can help to create a more robust system - this is clear.

The discussion was about that to have a"full" protection you need to encapsulate all memory writes - this includes memory writes of CPU and other chips like the Blitter.
The AMIGA system is full of devices which can create DMA writes. Blitter/IDE-DiskDMA/SCSI-DMA/Floppy/PCI Cards/...
For the "dream"-protection you would need to encapsulate all these DMA sources into their own MMU bubbles.

Developing a chipset MMU is expensive in both development time and chip resources!
Setting up a chipset MMU will have a big performance penalty on custom chips.

Cheers

[AJCopland]

Since we were originally talking about ColdFire and I don't care about MMU :-D I was wondering why no-one ever seems to mention the Turbo-CF (Yahoo group for it)?

It has downloadable designs etc though I don't believe it's ever been built.

I think I once read a thread about it but it was discounted becuase of the usual "ColdFire can't execute 68k code" blahblahblah. Since people on here are saying that they can I'd like to know what other things are wrong with the Turbo-CF design and whether it'd be worth trying to build one from the schematics?

If it IS a totally worthless design then could someone explain why?

Andy

EDIT: corrected _some_ of my appalling grammar

[AJCopland]

*bump*

anyone?

[A6000]

If coldfire could be made to run 68k code without error, then wouldn't elbox have done it by now?, they have had the dragon coldfire accelerator in "development" for at least 4 years now, I think only biggun really believes coldfire can work.

[Bandis]

Elbox have had SharkPPC "in development" since October 2000.
I guess we cant use amigaos with PPC then?

Gunnar is evaluating the cpu with a proper dev-platform right now. He is atleast conducting serious work instead of spinning.

regards
Bandis

[minator]

There is a good reason that no one does a MMU on blitter!

I think you'll find GPUs have MMUs.

If your program is bigger than 256 KB and jumps around in memory a lot then your on CHIP MMU entries on chip are too few. This means your MMU needs to re-read these entries from memory constantly.

That's why they invented large pages. These can be anything up to 1GB in size on some processors.

In worth case scenario is can go as far as your MMU end up needing to reload one MMU table entry per memory access.
Its common to see this behavior on certain memory stress test. Affective algorithms can degrade perfromance by up to 50%.

This hurt Cell at one point, the initial FFT benchmarks showed it outrunning a Pentium 4 by 40X over. They later added support for 16MB pages and performance went up to 100X faster than a P4.

[minator]

About this idea I was on about...

What's needed is a way to protect certain memory regions and registers from errant data. This can't be done properly for existing Classic Amiga of course but I think it can be used to allow a second OS to exist alongside without Classic writing over it's data.

The memory system doesn't need to be divided into lots of pages. You could say assign an area above address X to OS2 and simply forbid any access from OS1. If this address is on a neat power of 2 boundry you won't even need to check every address bit. A set of comparison registers would allow a set of regions to be protected.

You could also partition the registers in the chipset so new registers were in one region while old registers were in another. This will allow you to protect these registers from "classic" OS1 apps. New OS1 apps could be allowed to access these registers by assigning them an intermediate mode.
e.g. you can have new chunky modes and you can add to them the notion of an OS switch (i.e. these registers will be saved and restored when the system switched between OSs - otherwise you'll get corruption).

If you wanted to protect specific registers that could be done by checking against the current mode. OS2 will set the mode every time it switches between itself and OS1. This could be useful for specific registers such as disc control and I/O, if these are written to, OS2 can be woken up to pipe to the I/O to a HD (or whatever) in a safe manner.


This probably isn't well explained but adding a few registers, comparators and a few mode bits will give a form of protection that will allow one OS to be protected from another, this gives you a path to evolve towards using a full memory protected OS in the future. Yes there will be some performance impact but this will be insignificant, especially compared to memory access which is the real performance bottleneck.

[biggun]

minator wrote:
About this idea I was on about...

What's needed is a way to protect certain memory regions and registers from errant data. This can't be done properly for existing Classic Amiga of course but I think it can be used to allow a second OS to exist alongside without Classic writing over it's data.

The memory system doesn't need to be divided into lots of pages. You could say assign an area above address X to OS2 and simply forbid any access from OS1. If this address is on a neat power of 2 boundry you won't even need to check every address bit. A set of comparison registers would allow a set of regions to be protected.

You could also partition the registers in the chipset so new registers were in one region while old registers were in another. This will allow you to protect these registers from "classic" OS1 apps. New OS1 apps could be allowed to access these registers by assigning them an intermediate mode.
e.g. you can have new chunky modes and you can add to them the notion of an OS switch (i.e. these registers will be saved and restored when the system switched between OSs - otherwise you'll get corruption).

If you wanted to protect specific registers that could be done by checking against the current mode. OS2 will set the mode every time it switches between itself and OS1. This could be useful for specific registers such as disc control and I/O, if these are written to, OS2 can be woken up to pipe to the I/O to a HD (or whatever) in a safe manner.


This probably isn't well explained but adding a few registers, comparators and a few mode bits will give a form of protection that will allow one OS to be protected from another, this gives you a path to evolve towards using a full memory protected OS in the future. Yes there will be some performance impact but this will be insignificant, especially compared to memory access which is the real performance bottleneck.

Lets say we enclose old apps in address-range bubble.
Does it help anything?
The applications of OS 1 can still trash OS1.
And the applications of OS2 can still trash OS2.

I see where you coming from and I know that you only have the best intentions (being them impossible to do or not).

The thing is that this discussion has nothing to do with Coldfire or Classic Amigas. Please respect that this discussion is off-topic here.

If you want to continue the discussion about MMU and Memprotection, it would be nice to do this in the thread about this topic.

Thanks in advance

[minator]

The thing is that this discussion has nothing to do with Coldfire or Classic Amigas. Please respect that this discussion is off-topic here.

If you want to continue the discussion about MMU and Memprotection, it would be nice to do this in the thread about this topic.

First you slag off the idea of an MMU, than you ask that I suggest something, then when I do it's off topic? Have you ever considered going into politics?

Lets say we enclose old apps in address-range bubble.
Does it help anything?
The applications of OS 1 can still trash OS1.
And the applications of OS2 can still trash OS2.

I see where you coming from and I know that you only have the best intentions (being them impossible to do or not).

It's up to OS2 how it handles things, I assume it'll just abstract the hardware in a sensible way and thus not allow apps to trash one another.

--

However here's a question for you.
The Amiga, when it was launched was ahead in both software and hardware.
If the aim of Natami's is to bring the Amiga up to date why is it being thought of in terms of hardware only?

It makes sense to do a a first revision as an Amiga clone for 3.x, but going forward do you really intend to stick with OS3.x?

[AJCopland]

minator wrote:
However here's a question for you.
The Amiga, when it was launched was ahead in both software and hardware.
If the aim of Natami's is to bring the Amiga up to date why is it being thought of in terms of hardware only?

It makes sense to do a a first revision as an Amiga clone for 3.x, but going forward do you really intend to stick with OS3.x?

How about: because one is possible the other is adding memory protection retroactively whilst maintaining full compatibility :-D

Also it was me that's been pushing to get this ColdFire thread onto er... well talking about ColdFire crazily enough. Which was why the other thread was started by bloodline over in "Memory Protection AGAIN".

Andy

I've been reading this thread with great interest. Darksun raises a very good point, I think. If you look at the performance level possible with a modern Intel or AMD chip, the cpu time lost to emulating the 68k instructions is very small, I think.

Also, please consider this: the best solution to buggy old software crashing a nice new and fast Amiga system is to have a system that is nice enough that people will want to program for it _now_, correcting the problem by not only replacing those applications with new, but by releasing patches to old games and apps that have these sort of bugs.

It is not so hard to run a hardware-level debugger, say, oh, that guy ran out of coffee right here where there's this pointer arithmetic error, and just correct it by writing a small wrapper to the app that loads patches! I did this all the time on Macs - with resedit - and on winbloze boxes, too, and I can't imagine that amiga programmers from back in the day wrote code that is any harder to understand than that of other coders from that era.

People will flock to an os that can meet the challenge of not tormenting its users. Here is a good example of why:

http://picasaweb.google.com/patrick.killourhy/Winbloze/photo#5199703060705812642

This is not a fake image, it's a pic I took yesterday. Imagine if you were this gas station chain's mgmt and could order Amigas to replace the damned things to correct the loss of ad revenue (this sign is next to the I5 freeway and clearly visible from a _long_ way off) every time winbloze goes wonky! I really think people are at that point with these damned machines of ours.

I really wish luck to anyone trying to make an Amiga that can hold its own in performance these days, or even just be built out of available parts, and this is my small advice to them: dare to piss people off by 'breaking' some old functionality, because you'll never get it done otherwise. Hopefully I can buy a new 'Amiga' someday, even if it is not 100% compatible with the old stuff - I say this simply because I am really frustrated, as a programmer, at how poorly designed operating systems are when compared to other types of software (relational databases come to mind here).

-p.