-Edit- @HenryCase I would be delighted to discuss these ideas with you, but as others have suggested please start a new thread, so we don't upset anyone :-)
Reply here:
http://www.amiga.org/forums/showthread.php?t=35580
HenryCase wrote:
@thread
First of all, I'd like to thank those that have responded to my memory protection posts, I've got a lot to digest there, and will do ASAP. However, it is late so I'll concentrate on bloodline's post quoted below, as it seems the most concise.
Actually, I think AJCopland's games console story is probably the easiest to understand...
I would also like to state that I think memory protection would be useful with Coldfire, especially if we want to move away from emulating every 68k instruction.
@bloodline
bloodline wrote:
HenryCase wrote:
My challenge is this. I have a program running which has got an important string "ABCDEF" stored in memory at real location "0x001" and virtual location "0x0FF". Using your knowledge of the Amiga's API architecture, I want you to try and corrupt this data. I am confident that whatever you suggest can be dealt with without breaking AmigaOS compatibility, so try and prove me wrong.
Task A Stores "ABCDEF" at 0x0FF.
Task A sends a message to Task B.
The message simply contains 0x0FF.
Task B looks at Address 0x0FF and it doesn't find "ABCDEF".
Reason:
0x0FF are two different Physical memory locations to the separate tasks. in fact Task B might even have some code at its 0x0FF, or anything!!!
The OS has no idea that Physical address 0x0001 has to be mapped to the same place in both tasks... in fact it might not even be possible to map that physical address to the same virtual address!
Neither of the Tasks can ever know the Physical address, as their 0x0001 is mapped somewhere else... different for each task!!!
So if I understand correctly you're saying that the data cannot be read by more than one task because the OS doesn't know how to share this information?
No, The OS can easily put in place measures to share data... Due to the design of AmigaOS, the OS cannot know what data needs to be shared. The systems put in place to provide this information at Exec's design phase were never enforced, and thus ignored... Not only by Developers but by the OS design team themselves!
If I have understood correctly, allow me to use your example but fix it with the MAU (yes I am still going to use that term to avoid confusion):
The problem is CPU's don't come with MAUs... they come with MMUs :-(
Task A requests to store "ABCDEF", the MAU stores it at location 0x0001 and passes back a pointer to that location through assigning a 'virtual memory space' 0x0FF.
But what is an MAU? Is it a piece of hardware? If so how on earth does it work? Where do we get one from?
Is it a piece of software? If so, are you really suggesting that we trap every single memory access made by a program on the off chance that something written to memory might be need to be shared? This would be so slow as to make the whole system pointless.
Task A sends a message through the MAU to Task B to look at memory space 0x0FF.
Task B makes the request to look at address 0x0FF, the MAU does not see a reason to not show this information, and fetches the string "ABCDEF" to pass on to Task B.
I have pointed out, as far as Task B is concerned 0x0FF does not relate to the same memory as What Task A sees as 0x0FF. Each task has it's own Address space... With Memory protection, each task effectively has its own computer... It has its own OS, it's own CPU and it's own memory, no other tasks exist in its universe... that is why memory protection is so safe.
Think of the Address space as being an island (imagine that the island is divided into 9 equal squares, this gives us a good 3x3 mental image, like a noughts and crosses board), and the Task as a small man living on that island.
The tasks can talk by sending messages... message in a bottle if you like!
In AmigaOS, Both Tasks (little men) live on the same Island, if Task A puts something in square one, then Task B can find that data in square one, since Square one is the same for both tasks.
With Memory Protection:
Each Task (little man), lives in it's own address space (on it's own little island). When Task A puts something in Square one on it's own island, that data doesn't magically appear in square one on Task B's island... In fact Task B probably has something different in square one! Neither Task can ever know the layout of each other's island.
The reason for this is the way AmigaOS is designed... In operating systems that have had Memory Protection from the start, the developers have had to make sure that data that needs to be shared is done so via Operating system mandated method. In AmigaOS this was never necessary, and thus Tasks do not provide the OS with the information it needs to allow memory to be shared.
So in terms of memory usage, what do you have? You have one location where the string is stored in memory, a simple look up table stored in memory that is controlled by the MAU, the MAU itself which provides this abstraction layer and offers opportunities to control memory usage, and the memory spaces used by the tasks.
What you are suggesting is a look up table that records every memory access on the off chance that it might need to be shared... Which is massively resource heavy undertaking... both CPU cycles and Memory... and even then HOW does the OS actually know that when Task B is referring to a particual memory location that it needs to be shared with another task? The tasks are no required by AmigaOS to let anyone know what they are up to!
What you are failing to see is that you can second guess what's going on because you know all sides of the equation... Task A and Task B only care about each other and expect to be able to mess around with each other's data structures. And the operating system (with memory protection) only cares about keeping tasks from messing around with each other's data structures.
With the design of AmigaOS there has never been the need to let the OS know that it's OK for task A to interfere with Task B... Thus no software has ever provided the OS with the information it needs to allow the tasks to Share Memory, in a Memory Protected environment.
The address 0x0FF can be called as many times as you want (please note this virtual memory value can only be assigned to one real memory space at a time), but each time the MAU will make a decision based on certain rules to determine whether that access is given.
But this is just it, programs written for AmigaOS do not provide enough information to the OS/MMU/MAU to allow it to make a decision as to what is shared and what is private.
It will also be giving programs non overlapping memory spaces to run in.
Does this explanation help?
EDIT: Should also say that I intend to separate kernel commands from the kernel itself so that its commands go through the MAU too (obviously with a high level of privileges). I thought that was worth pointing out in case you thought I was intending to do MP with the standard design Amiga kernel.
It's easy to design an OS with Memory Protection, there are numerous examples... what we have with AmigaOS is a system that has a 25 year development legacy of no Memory Protection, All existing programs assume this to be the case. You add memory protection and you have put them into a new environment that is no longer AmigaOS and they won't run.
