Coldfire AGAIN

[minator]

You need a binary scanner of some form, it scans the binary before you run it and adds in routines to replace the unsupported instructions.

Be a lot easier then writing a full emulator or JIT engine for a different CPU.

[minator]

You know full well that when you licence a core you don't buy the right to modify it.

That will depend on the exact terms of the license.  These aren't exactly shrink wrap licenses, probably specific to each licensee.

e.g. DEC, the designers of StrongARM had an ARM architectural license, that allowed them to design their own processor from scratch.

[minator]

In terms of software PPC is the easiest option as you've got as there exists 3 JIT engines for running 68K software.  There's also as pointed out the option of going to one of the newer OSs.

On the other hand getting hold of one of these engines is another matter...

--

Another option would be to do a combo of some sort, i.e. an FPGA for backwards compatibility and a modern SoC for new stuff.

This is what a modern SoC can provide:
OpenPandora

[minator]

biggun wrote:

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.

I don't think this is true.  It is entirely dependant on how you organise the system.

What you want to do is allow both an MP system and a classic system to run side by side but not allow the Classic OS to wreck the rest of the system.  You can use the MMU to contain Classic within a fixed area, you can also give it direct access to the chipset - the cost of going through the MMU is basically zero so it may as well be direct.

The only real problem is what happens if the Classic OS writes to the chipset while you are using the non classic OS.  It could then mess up your display.

This however can be fixed by making the new chipset "modal", that is you restrict certain features depending on which OS you are using.  Classic will see the chipset, the MP OS will see something slightly extra.

Basically what I'm thinking of setting aside a memory area specifically for the use of the MP mode, the MP OS's display port gets put in there and the Classic OS can't use the chipset to write to it - this should be pretty easy to implement in the FPGA (a control bit, a comparator and a couple of address registers which hold the range you don't want it to write to).

There is the matter of other I/O ports but these are slow anyway so abstracting them will make no difference.

It's not a perfect solution but it'd give you full graphics speed in both modes.

[minator]

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.

BTW it doesn't need to necessarily be an MP OS, it could be say AROS, the aim is just to ensure the Classic OS couldn't mangle the second OS's memory or display without effecting the speed of Classic OS.

[minator]

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.
They might be big in high end PC processors but I'm not talking about those.

I'm talking about a much simpler mechanism that checks for writes into forbidden memory areas.  There'll be a small number of these at most and the permissions can be represented by a single bit (ie 0 = Yes, 1 = No).
It can be set up like an MMU with (very simple) tables, but there's no need for virtual memory or anything like that.

The cost of switching tables on a task switch is zero - you wont need to switch tables on tasks and you wont even need to change them on switching OSs, you just need a single bit to represent the mode (MP OS or classic) and you just switch it.  The blitter then gets access to everything - the MP OS can look after it's own memory...

[minator]

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.

If you are going to reply to me and quote me you could at least read the entire post.

Secondly, you've blatantly quoted me out of context.

If you really think that comment is inaccurate or show any faulty knowledge on my part please explain why.


however...

An MMU might have been a big deal in 1985, but it's not today.  Some of the high end processors may have large MMUs but as I said (on the next line that you didn't quote) we're not talking about these.  In any case much of these will be taken up by the TLBs, these will not be necessary.

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.

A vector unit comparable to those is going to be quite considerably larger than any MMU, if you don't believe me have a look at a die photo of one of the Cell's SPEs - then compare how big it is to the MMU *it contains*.


--

There is a long term general anathema to using MMUs in the Amiga community, possibly based on the assumption that they slow memory access. More knowledgeable folks could argue that page table walks are slow and you have to switch page tables every time you switch tasks.

However, today, none of this is true.

MMUs will increase memory latency but the effect of this is utterly insignificant, I learned this when I first used BeOS about ten years ago.  It had full memory protection but it is every bit as responsive as any Amiga.

CPU designers know the slow parts in their designs and fix them in subsequent designs.  TLBs cache pages and this means page table walks are relatively rare.  Modern processors also shouldn't need to change the page table every time they switch tasks, e.g. the processors in my mobile phone have full memory protection and virtual memory support and they will not switch tables on a task switch - I know because I happen to of had the features of those particular processors explained to me yesterday.  I cannot say if it's true for all modern processors though.

However, as I said in my previous post what I'm suggesting is much simpler than this so wont have any of these complexities.

I have some ideas for implementation so I will put these down.

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

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