Coldfire AGAIN

[Hans_]

bloodline wrote:

You put an OS layer inbetween memory allocation functions and the real memory. This MMU gives the memory allocation functions the impression that it is writing directly to the memory, when in reality it is controlling memory allocation/deallocation and protecting unwanted memory access.

I don't understand... The way memory protection would work is that each task gets it's own address space... in effect each task gets up to 4gig of address space to itself. I shall expalin the reprocussions of this later...

A good book on how MMU's work should give you a better understanding... The intel developer docs are a great place to start!

You don't need to create separate memory spaces to have full memory protection. In fact, now that many CPUs have 64-bit addressing, there are those who argue that a single linear address space is a good idea. Doing this would allow the existing messaging system to work fine, with the added restriction that programmers do need to mark the appropriate memory as shared.

In order for Amiga OS to have full memory protection whilst still allowing old software to run, there is only one option: place the old apps in a sandbox. There the old apps can do all the naughty things that they used to get away with because the rules were never enforced. Unfortunately, this does mean significant rewrites of some OS modules such as intuition, which didn't follow the rules either.

Hans

[Hans_]

Kronos wrote:
"the existing messaging system" would have to be updated to 64Bit in order to make full use of it, but that would require a recompile.


Wether it would actually do anything in regard to MP is questionable and would atleast require further measures (which will break source-compability too).

Updating to 64-bit would only need to be done on a 64-bit processor. Seeing as that jump is going to break stuff anyway, migration to a 64-bit processor would be a good time at which to make the necessary changes.

At a bare minimum, memory for messages should be marked as shared. Even better, message allocation/deallocation functions should be created that do this. What I was trying to say is that we wouldn't need a completely new message passing system. There would be additional restrictions, but the fundamentals would remain the same. The differences would be enough that old apps would have to run in a sandbox.

Hans

[Hans_]

bloodline wrote:
Hans!! There is nothing wrong with the message system, the problem is what is sent in those messages! The OS doesn't know what they contain and they could contain anything! :-)

I agree. The thing that would change in a system with full MP is that programmers will have to allocate memory appropriately and be more careful about what's in the messages.

Hans

[Hans_]

bloodline wrote:

On a system like MacOX, to alter a system structure you have to use a specific OS function, this means that Apple can mess around with how the OS works and the Tasks are none the wiser... In AmigaOS due to it's open nature, tasks tended to alter system structures directly, which means the Amiga design team couldn't alter the system under hood... it also means they couldn't protect the OS anymore... as soon as you protect the OS, the tasks can't access the data they are used to accessing. Intuition, for example, actually documents this as an official method of working!!!! Apple would never allow anything like that!!!!

Way back when PowerPC cards were just coming out, programming guidelines were published that explicitly said something along the lines of:

In future OS structures will not be directly accessible. Use OS functions to access OS structures/data or your code will break in future versions of the OS.

The problem was, they never got round to providing all the accessor functions required.

Hans

[Hans_]

biggun wrote:

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.

I don't think that direct access to the Blitter was what Commodore wanted. IIRC, they begged people to NOT bang the hardware directly (after giving them the HW reference manuals :lol:). I'd suggest creating APIs for the NatAMI hardware; not necessarily for MP purposes, but to avoid HW conflicts, and to save people from having to write duplicate code unnecessarily.

Hans

[Hans_]

biggun wrote:

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.

I don't think that the performance will be as bad as you claim. The MMU table could be quite coarse, and would only cover chip RAM. Swapping the tables would only have to be done for tasks that actually use the blitter. Probably just changing the base-pointer to the table would be best; the table itself only needs to be checked if the blitter is actually used. So you don't have to swap the entire table every time.

Having said that, I'm pretty sure that PCI cards can DMA to memory that a particular task doesn't own. The solution, of course, is to provide drivers that do the access. In the case of the Amiga Blitter, having all functions contain pointers to bitmap structures and thus, enforcing blitter within those bitmaps only, would be an easier, and more efficient, solution. This way you could use the CPU's MMU to check that the bitmaps are accessible by the current task.

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

[Hans_]

... and back to Coldfire. Where did the Coldfire discussion leave off before the MP tangent?

Hans

[Hans_]

biggun wrote:

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.

Not that I'm advocating the creation of a chipset MMU, but I don't think that it will be anywhere near as expensive as you claim. You wouldn't need the address remapping part, just a single bit per page indicating if the task is allowed to access the RAM or not. You could even group multiple contiguous pages into blocks for efficiency.

Of course it will lower performance slightly, but no more than the MMU in modern CPUs. All modern processors have them.

Personally I'd be more in favour of an API that prevents you from doing anything stupid (look at the rest of my previous post).

Hans