Coldfire AGAIN

[biggun]

Einstein wrote:

* I would like to point out that there are other ways to stabilize a system. 99% of crashed come from bad pointer arithmetic. You can try to reduce the harm cause by the bad pointer by enforcing memory protection (for a high cost) or you can use coding styles which will not cause this problem in the first place. A would like to point out that the Amiga Oberon programs did NEVER crash!

It's like saying we don't need Police Departments, only if people behave than we could rid of'em have gain an economic boost, but unfortunately this is not reality.

Your post clearly shows that you are NOT understanding the concept of AMIGA OS.


Memory protection on CLASSIC AMIGA is impossible and useless ! That's a fact which is obvious to those with some programming experience.
 
If you want to argue about useless things ok.
But please use another thread for this

[biggun]

Its not about glorifying. Its about facts!

For "proper" protection you need to sandbox and abstract all and everything.

This means no direct access to Blitter or any HW anymore!

This is the opposite direction of the original AMIGA and the NATAMI or Coldfire designs.

Asking for memory protection makes only sense for people and systems that are willing to trade a lot of performance for abstraction.

Full memory protection => No more direct access to blitter.
A Coldfire with SuperAGA will be very fast but
if you ask for MP then you it will crawl.

Please understand that Coldfire and MP are mutually exclusive.
If you want to argue for MP DON'T do it in the Coldfire thread.  

[biggun]

FrenchShark wrote:
@BigGun, AJCopland

Hello,

the software is intended for the 5282 coldfire which has a USP and SSP like the V4 even if it is a V2 core.
The CPU only has 60 MIPS of computing power.

I think you and we are working in the same direction, to the same goal.

Our goal is to integrate the SuperAGA and a CPU into one single Chip.
This single chip will reduce cost and enable people to again produce real cheap AMIGAs.

We are evaluating the Coldfire right now.
If we are happy with the Coldfire evaluation then we want to combine the SuperAGA + a new Coldfire with (700 MIPS) into one chip.

Thanks to Genesis help we have relative fast V4 development systems that we use for testing right now. The Natami will come shortly. You can "cludge" the Coldfire board ontot the Natami - then it will look like a CPU exypansion card to the Natami. This makes a good system to evaluate AMIGA OS running on Coldfire combined with a very high performing AGA chipset.

If you are interested in joining this project then tell us.
We could get you a V4 board.

Cheers
Gunnar

[biggun]

Question was: Can trashing Chipmem trash the system


Answer: Yes.
There is more than pictures in chipmem.
For example, there are Copperlist in chipmem.
If you thrash the copper list then the copper couldeven  *fuck* up the Disk DMA.
In Chipmem could be IO buffers where disk-IO read/writes too.

Why not simply have a CustomChip.lbrary (obviously a better name would need to be chosen), which has functions for reading or writing to the chipset registers... that would act as a simple and suitable hal...

The problem is not the access alone.
Example:
You have programm which has a IO buffer at address $10000
The program calls an disk function to load data into this buffer the program has a typo in this call and ask to load to address $40000 instead.

"Kabunga !" Your IO-call now screws-up the program at this address.

Solution: The IO routine needs to have a list of all memory block belonging to your program it needs to compare your address and length with all entries in this list to verify that your DMA request will actually go to your block.
Will this be fast?
 
Same example:
You want to use the blitter to draw ONE! Char on the screen.
Same risk : Instead blitting into your buffer you could sénd a wrong adresss and the blitter will bit unto someoneelse memory.

Solution:
The blit function will now need to compare your address ptr and length will all memory blocks belonging to your programm.

Effect: Checking if the pointer are in legal ranges takes a lot of time. Much more time than using the blitter saves.

The orignal AMIGA allowed usage of DMA and Blitter to accelerate the system.
If you need to check ranges for each blitter call the overhead will be HUUGEE!

[biggun]

minator wrote:

You could do the same trick in the copperlist, DMA and blitter as was done by the MMU. You could design the SuperAGA chipset in such a way that the OS can say to the chipset what actions are allowed by certain tasks like the MMU allows to limit access to certain memory areas. This would normally not impact speed as it is done in parallel. Only when some non-allowed action is asked an exception is raised, just like an exception is raised by the MMU when a wrong memory address is accessed.
This would work best when the SuperAGA and CPU are integrated in one chip.

Don't even have to do that - address range restrictions could be imposed by including an MMU of sorts in the FPGA.  Hit specific memory areas and an exception could be raised on the Coldfire, the MP OS would then kick in and handle it - i.e. the MP OS could handle things like the disc I/O.

No offense, but these proposals are frankly total non sense.


A Blitter that has a MMU will be extremly expensive to build and its performance will be dissapointing.
Using the Blitter will have a huge overhead as your MMU Blitter table will need to be replaced when switching tasks.

Please get a clue about the HW costs of implementing an MMU  and the overhead of maintaining the MMU tables by the OS.

[biggun]

To be honest, I think that MP can help programmers detect more bugs. I find OS4's current level of protection very useful, as it catches mistakes that would have gone undetected on OS3.x and lower.

Hans

As I said before. UAE is great for development.
You can patch UAE to get your MMU feature for no money.
Then you can use this feature during development to detect bugs.

Adding MMU to real HW  would increase the price of the device significant!
If you add the MMU into the HW you will double the costs and lowering performance on the final device.

A clever solution might be to use a free UAE version for the testing. This development UAE can including all bells and whistles of an emulated MMU. It will allow you to detect and fix your bugs early.

[biggun]

minator wrote:

A Blitter that has a MMU will be extremly expensive to build and its performance will be dissapointing.
Using the Blitter will have a huge overhead as your MMU Blitter table will need to be replaced when switching tasks.

Please get a clue about the HW costs of implementing an MMU and the overhead of maintaining the MMU tables by the OS.

You see to have an odd idea of just how big and slow MMUs are - they're neither big nor slow.  They're so small in fact they can be found in almost every processor except the very smallest microcontrollers.

In other words my friend you have no clue about HW design.

Please get a clue how much resources that would eat in a FPGA design and then come back with proposals.

If I would have the choice to
A) add a MMU around my blitter

B) to get for the same resources a Vector unit compareable to CELL/ALTIVEC/SSE

For me the choice will be clear.

[biggun]

Hi Metalman,

metalman wrote:
People have been referencing a Coldfire V5 chip in this thread, but this is the current top of the line Coldfire chip that I can find listed on the Freescale site.
MCF5484
Its listed as a V4e core. (new V4 versions for running Linux® applications are the MCF5445X series) Are there any actual V5 core chips being produced?

Yes, there are V5 cores.

http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.freescale.com%2Fwebapp%2Fsps%2Fsite%2Foverview.jsp%3FnodeId%3D0162468rH3YTLC6951fgqk7SDQBWB3&ei=vxz3R9KOHoyQ-ALpp9UQ&usg=AFQjCNGLN56Z3xK5lVnjc1IjPbCh7agRAw&sig2=wiy0UeX65B-siy_LoBI8MQ
For example the HP LaserJet P2015dn Printers use as Processor a 400 MHz Motorola ColdFire V5

The MCF5485 has a digikey price of $33 per unit 1 (it includes a MMU, FPU, Ethernet, USD, DDR/SDR-SDRAM Controller, ect ...)

Yes, you can get 266Mhz Coldfire V4e for $20

The coldfire series is similar to the 680x0 series but not 100% code compatible. It seems like missing instructions have been added back to the coldfire as new core generations are released. It's possible that some future V5 core coldfire chips might make it possible to emmulate a 680x0, but based on the problems raised in this thread, it seems unlikely.

The V4 can execute 68k binaries
The question is not if it works, but how big the average performance impact it.
BTW several people are evaluating in this direction already:
http://projects.powerdeveloper.org/project/coldfire/707

So wouldn't it be more practical to just use a current coldfire V4e core (like the MCF5485) as a system co-processor and run the OS on a actual 680x0 and only run blitter routines,  ect, that can be rewritten to run as native code on the coldfire, and while getting the benefit of additional HW functions the MCF5485 makes available as part of the 68000 family of chips?

I see where you are coming from. And for a test system your idea is okay.

Regarding using the Coldfire. I can only speak for the concept idea of the NatAmi www.natami.net here.

The Natami draws a lot of performance out of the SuperAGA blitter. A good Blitter will always be faster than a good CPU. This is because of the way a blitter more effectively pipeline and can fully use the chip select lines, which a CPU can not. When you connect the same memory to a blitter and a CPU, then the CPU can reach at best case 50% of the possible blitter speed.  
As the SuperAGA Blitter is many times faster than the Coldfire it makes no sense to use the Coldfire as blitter.
It could make sense to use the Coldfire as main CPU.

I'm very curious to see the results of the Coldfire performance evaluation.
I think that a Coldfire combined with SuperAGA in one chip the the potential to be a winner.
The beauty of this SOC is that you can get blistering fast Blitter plus a decent CPU in one chip for $20.


The question that I'm wondering a bit is how fast do we need to be. Yes I know its cool to be faster than the fastest Cell.
But seriously, how fast does a AMIGA OS system need to be to be fast?
Is the performance of a 68030 with 50 MHz OK?
Is the performance of a 68030 with 100 MHz OK?
Is the performance of a 68030 with 200 MHz OK?
Is the performance of a 68030 with 500 MHz OK?
Is the performance of a 68030 with 1000 MHz OK?

Cheers

[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!

[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

[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