How can executables work when being thrown into different addresses on 68000 ?

[psxphill]

However this would require that all data manipulations using an addresses within the program, jumps, etc. Must all be changed for every loaded program. So how has this been solved in AmigaOS ?

AmigaOS changes them for every loaded program. http://en.wikipedia.org/wiki/Amiga_Hunk
 

Who thinks that? Lots of microcontrollers provide limited memory protection without an MMU. I.e. write to address range X in user state causes an exception.

You missed his point. Most operating systems that use an MMU have separate memory spaces because it has other benefits, like avoiding memory fragmentation. Not because you need it to protect memory between tasks. If you don't have an MMU then you can't use separate address spaces or realistically protect memory between tasks.
 
Your limited memory protection sounds like the TLB in the 68EC040, which isn't really good enough for what AmigaOS uses the MMU for.
 
http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html

[psxphill]

You can't introduce memory protection in Amiga without breaking backwards compatibility and it has nothing to do with separate address spaces.

Only because software doesn't use MEMF_PUBLIC for memory that needs to be accessible by everyone (because it's never been mandatory).
 
 
MEMF_PUBLIC: Memory that must not be mapped, swapped,
or otherwise made non-addressable. ALL
MEMORY THAT IS REFERENCED VIA INTERRUPTS
AND/OR BY OTHER TASKS MUST BE EITHER PUBLIC
OR LOCKED INTO MEMORY! This includes both
code and data.
 
You could easily make it mandatory for data that needs to be passed between processes to have MEMF_PUBLIC and protect everything else. I believe there was software on the Amiga that did that and supported virtual memory as well. It wasn't that popular because most people didn't need the overhead of virtual memory and a lot of software wouldn't run with it. I think it would be quite easy to patch legacy applications to provide the correct flags though. You could also add a compatibility mode that forces all memory allocated by a task to be allocated with MEMF_PUBLIC.
 
It doesn't protect much, because a lot of data needs to be accessed by multiple tasks and there is currently no call to allow you to allocate memory that can be accessed by your task and one/many specific tasks.
 
Once you have MEMF_PUBLIC then you might be able to do per task address spaces as well.
 
The other problem you have is that because of no resource tracking, if an application does crash due to an invalid memory access it's still going to take the machine down anyway. Which might be worse than silently letting it corrupt memory & is certainly a much harder problem to fix.

[psxphill]

This is not enough because many private structures to user applications are made public by the operating system. For example struct Window to represent open window is a public structure (writable to everyone). This requires fixes to Intuition which in order can render existing software unusable.

It doesn't require fixes to Intuition, it merely requires that you allocate the memory as public. It would be entirely possible to enforce it for new programs and not for old programs, by forcing old programs to have MEMF_PUBLIC for all their allocations.
 
You could argue that this wouldn't protect much, but not that it can't be done.

[psxphill]

Unfortunately your operating system stops functioning if structures are made private.

I'm not 100% sure what you mean.
 
If by that you're saying that not specifying MEMF_PUBLIC on memory that needs to be accessible by another task will cause the system to become unstable, then I agree. However we're not discussing that issue at all.
 
The operating system stops functioning if a program calls Disable() or Forbid(). Memory protection would prevent some accidental or malicious memory accesses from going unnoticed.
 
On 68000 you can do similar bad things to the operating system by using odd addresses.
 
Arguing for a robust operating system where one task can't take down the whole machine is a whole different ball game & trying to solve those issues would involve throwing everything away and starting again.
 

If you don't have an MMU but have some sort of memory protection you can:
Protect the kernel and it's memory. Protect memory mapped devices like NOR flash from being corrupted by a runaway user process. Depending how how fine grained it is you can protect other processes from the active process by restricting the active process to working within the memory allotted to it. I know a lot of that doesn't apply to AmigaOS.

If it's fine grained enough that you can protect the active process then it's basically an MMU. Protecting a handful of ranges of memory doesn't count as memory protection (AmigaOS already does that itself).
 

The difference is that computers with MMU can use a static memory position as opposed when you actually need the relocation table.

I've yet to see an operating system that uses an MMU to avoid ever having to re-locate executable files. The way windows executables works is they have an address they are linked to, but there is enough information that they can be relocated. If it can load it to the address the file wants then it saves time relocating it.
 

That is no problem but messages should not be public to everyone. To support this scheme messages should be allocated in a manner that they can be shared with target task (as designated by mp_SigTask) but not all message ports have designated target task.

You can never can know what task needs to be able to write to your memory. If you use Read() to fill your message then the memory needs to be writable by a task created by the filesystem. To do what you propose in every circumstance isn't simple, although it could be used in some cases.

[psxphill]

I would disagree there. You could have a protection unit that could generate exceptions based on ranges that are selectable in byte resolution and it wouldn't be an MMU.

Why wouldn't it be?
 

SAS/C and GCC which have built-in support to build re-entrant (pure) code. They use custom startup code to copy data segment to newly allocated space. Pointer to data segment is placed to a4 and code is compiled to address variables relative to a4. Some special care is needed by a programmer, though.

I don't know if they also store a4 in struct Task tc_UserData, but that is another way of doing it.