HenryCase wrote:
Hans_ wrote:
In theory it's all possible simply because we know that humans can do it.
I think that's one of the factors that is driving me on.
bloodline wrote:
In an MP OS, one would define that the pointer returned by AllocMem() is for the use of the calling task only.
In AmigaOS the pointer returned by AllocMem() is free for any task to use, this is defined behaviour.
Okay, so Amiga software expects to be able to use pointers defined by other Amiga software.
Right. Data structures (which the pointers point to) can be shared between tasks and system libraries. In an MP OS you can't share the data structures.
So there is almost a pool of memory pointers.
No, memory pointers are nothing but the address of the data structure in memory. For example on a real Amiga I know that $DFF180 always points to colour register 0, so I can write to that address if I want to alter that colour register... you see a pointer is nothing but a number, a programmer could allocate some memory, and then write anywhere he chooses within that area, a pointer to which would be an arbitrary number. If a program needed to share that pointer it could use that arbitrary number in a function call or pass it to another program... the OS has no way to know that that arbitrary number is a pointer... does that make sense?
Can we put these memory pointers in an OS controlled environment and control which programs we'd like to use these pointers?
No, there is nothing special about these pointers.
The nearest thing to what you are suggesting is a sandbox...
In the place of the pointers in the application code we put a 'port' to the shared pointer area.
No, the CPU doesn't use 'ports'... it just pushes numbers around, a pointer is just a number that points to a data structure.
When a program then wants to access the data or instruction in memory a request to the OS goes to through that port. The OS then uses the pointer itself, and the outcome of this action is stored in a 'quarantine' area in memory. The OS then tries to determine (based on past experience and/or user preference) whether that data should be given to the application.
The program doesn't make a request. The program tells the CPU to load some data. No requests are made, the CPU just does it.
But you still miss the point. If you know you have a pointer then find there are ways and means to trap it, etc, its very slow... but the take home point here is that there is NO WAY TO KNOW WHAT IS A POINTER and WHAT IS JUST DATA :-)
Way I see it, if a program causes a computer to crash, we should be able to determine when it crashed, and what was the last value (data or instruction) to be passed for processing, right? If we can do this, we have options when it comes to crash protection (which is the main benefit of MP IMO), as long as we catch the value before it is passed for execution (or maybe before storage in its designated memory location).
When an Amiga program goes wrong, it can randomly write anywhere in the memory. This puts the computer in an unknown state, once the machine is in an unknown state you can't recover, unless you have a full backup of the Memory.
Memory protection means, that when the program goes wrong, it can only destroy it's own data/code... Only that task is in an unknown state.
Or maybe we don't have those options... can you give me typical low level examples of what causes a computer to crash?
If the programmer has made a mistake, then the CPU might write some data over some important operating system code.
Hans_ wrote:
What exactly is wrong with allowing old software to be fully-allocated in shared-memory and run in a sand-box?
I want to see the AmigaOS 3.1 API succeed as much as possible as I see it as a bridge between different Amiga-based OSs. A sandbox is okay, but it would split the community again as there would be a new 'native' API. AROS is in the unique position to bring the Amiga world together, and I don't want to see it lose that.
The AmigaOS 3.1 API is common to all AmigaOS clones.. so that's that...
Hans_ wrote:
Henry is suggesting getting the compiler to insert the MEMF_SHARED flag (and/or whatever else woulld be used) whenever it's necessary. The problem is that finding out when it's necessary is incredibly complex.
Correct, I'm advocating making memory private by default. The 'finding out when sharing is neccessary' task I am trying to pass to humans.
But nothing would work if memory was private by default, because MEMF_PRIVATE was never enforced on AmigaOS it was ignored... not just by app programers but the operating system designers too.
bloodline wrote:
He needs to understand that the messages and message passing are not the problem, it's the contents that's the problem.
So I would prefer it if we could keep a examples as simple as possible.
bloodline, I appreciate your approach here. I agree it is best to keep the information you are all giving me as simple as possible, I do feel like I am slowly getting my head around the larger issues here, thank you for your patience (and everyone elses). The thing is I'm finding this discussion rather interesting, and as I'm getting more information it's throwing up more questions and possibilities in my head. Please forgive/understand my curiosity!
My big concern is that you are attempting to solve a problem, without having an understanding of basic operating system design or even a simple grounding in assembler.
I think though you are missing the point, because you don't understand how a computer actually works. I think you really need to learn assembler, 68k is very easy and really fun... there are loads of good books both online and in good computer stores.
