Coldfire AGAIN

[metalman]

biggun wrote:

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.

V5 ColdFire Core: Full Superscalar
For example the HP LaserJet P2015dn Printers use as Processor a 400 MHz Motorola ColdFire V5

You found what I did when I searched the first time for a V5 coldfire. The document you linked is a Roadmap document, what I can't find is an link to a actual V5 chip datasheet.

biggun wrote:

metalman wrote:
The MCF5485 has a digikey price of $33 per unit 1 (it includes a MMU, FPU, 10/100 Ethernet, USB 2.0, DDR/SDR-SDRAM Controller, PCI Interface, ect ...)

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

Which one?
The MCF5445X series and the MCF548x series which are designed to work with the Linux Development kits, with royalty-free, open-source software demonstration applications provided, seem to me to be the best choices.

M5484LITE: Linux Development Kit for the ColdFire MCF548x Family

biggun wrote:

metalman wrote:
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:
Coldfire MCF54455 Project

Seems there are some major problems or products like the Dragon would be shipping by now. Maybe if some more 680x0 instructions are added back in a V5 chip it might work.

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.[/quote]

Cool!!! Wasn't considering someone designing a new AGA hardware blitter.  

Use the coldfire as a co-processor to run coldfire.library routines that have been re-written to run native code on the coldfire such a floating-point math ect...

biggun wrote:
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.

I see the Coldfire as a way to add MMU, FPU, USB, Ethernet, DDR/SDR-SDRAM Controller, PCI Interface,  hardware functions using the Coldfire as a co-processor.

MCF548x Reference Manual

biggun wrote:
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

A computer only seems as fast as its slowest bottle neck.

The Amiga hardware design philosophy was to offload as many functions as possible to fast co-processors.
Giving the main cpu more idle time by offloading more routines to co-processors (video, FPU, ect) makes the whole systems apparent speed faster.

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

 :oops:

[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 :lol:

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