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

[bloodline]

You must have misunderstood memory protection discussion on Amiga forums. You can't introduce memory protection in Amiga without breaking backwards compatibility and it has nothing to do with separate address spaces. AROS developers explained it quite we'll but can't find thread at the moment.

Fats is actually Staf... Yes he of AROS

[bloodline]

The reason for asking is that a lot of devices use ARM and MIPS processors that lack any MMU. And thus won't run any fancy unix which is entirely built on MMU that provide a separate address space for each process regardless of protection. This usally means only µCLinux remains as a free OS choice.

The main obstacle to get some Unix style environment is to be able to load arbitrary code into arbitrary locations. So I remembered that the 68000 lacked MMU but still provided arbitrary program loads and multitasking. But never investigated in depth how this was done.

The multiple address space requirement for UNIX was a design choice, while it incurs a hardware complexity penalty, the advantages have been listed in this thread. uLinux shows that UNIX doesn't actually need a per process address space to work, but you lose a few features.

This insight of AmigaOS-68k and MMU less processors now means I know how to make this happen in other environments. Decoding ELF binaries with relocation table and making use of it seems however way more complicated than the Amiga Huff format. The loader has to copy the ELF binary code into memory and then find the relocation table and interpretate it. This could form an self hosting ARM environment that works similar to AmigaOS 68k minus the custom graphics and sound.

ELF is a superior format to HUNK in my opinion, it provides all that HUNK did and more. Your understanding of how an executable file format works is incomplete there is plenty to learn and you seem keen, so keep reading!

[bloodline]

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 a lot of software wouldn't run with it and most people didn't need the overhead of virtual memory.

One of the biggest missed opportunities of AmigaOS was the lack of Public memory enforcement...

Amiga coders, myself included, were often self taught and young... We wrote stuff that worked, rather than stuff that followed the official spec. I had no idea what the memory flag MEMF_PUBLIC was for so I ignored it and programs still worked.

Had the OS freaked out when you shared a nonpublic memory block... Adding memory protection would have been so much easier... If I recall correctly, even the commodore engineers wilfully ignored the MEMF_PUBLIC flag :-/

[bloodline]

@donpalmera, I want to be able to run a partial general purpose OS. Such that one can login edit C-files and compile them. Mostly to be able to change functionality without setting up a cross development environment. Which is not always possible.

Code loading at arbitrary positions are done by miost OS:s. The difference is that computers with MMU can use a static memory position as opposed when you actually need the relocation table.

I found the x86-32-ELF format more complicated than Amiga-68k-HUFF. I didn't have a look at µCLinux in that aspect.


As for making use of MMU-less ARM (or perhaps MIPS). It's just noted that ELF decoding and relocation might be less straightforward than I thought. But most importantly is that I know gcc + ld may and will produce relocatable binaries. How to make it happen in code is another story. The next chapter is how to make multitasking happen. And perhaps if a sufficient handleable QFP surface mount CPU with MMU can be had.

Compile your code with the -fpic option ;-)