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

[freqmax]

The M68000 CPU has no MMU and thus can't move memory around and always present a neat linear memory such that all executables start at address zero. Instead executables must by necessity be copied into an arbitrary memory position and be made to work from that memory position. 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 ?

[freqmax]

Alright so every executable on Amiga 0x000003F3 contains both code to be executed and address position list?

Such that when Exec is instructed to load an executable. It will copy the code to the allocated memory. Then Exec will use the table list of addresses and modify all address references..? before executing the code.

[freqmax]

By tradition or need? PowerPC has MMU asfair?

[freqmax]

It should be possible to use the "page table" that the MMU uses to recalculate these pointers faster than the task switch takes? But I understand the benefits of pointer messaging (brilliant!).

There is one clear benefit as I can se. By avoiding the MMU one can also remove the latency between the CPU to memory and I/O.

I had  a deeper look into the Amiga executable format. And if I understand this correctly. An arbitrary memory location is allocated and the instruction sequence (code) is copied there. In the next step the operating system (DOS?) will use the relocation table if any to alter any absolute code location on the fly.

Seems softkick works in a similar manner with relocation tables. However the creation of those seems to be more magic that ordinary compiled files. Though trapping a debugger seems reasonable to find all absolute references in a ROM file.

[freqmax]

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.

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.

[freqmax]

One could track resources and watch when the program exits to free those regardless if the program free'd them properly. And have a database of permissions for old software so one can automaticly apply restrictions.

I'm sure AmigaOS can be made more secure. But it will be a slight kludge at least for older software.

[freqmax]

@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.

[freqmax]

Suggestion, make new OS. And write an compability layer.

[freqmax]

The target is ARM or MIPS and only the type of relocation table (list) that my compiler produce will be supported.

Dunno if GCC/LLVM will produce PC relative code for ARM/MIPS though. m68k is not particular big in embedded for new designs..

[freqmax]

Code that is given a different pointer to input and scratch variable space for each instance run ought to also be re-entrant code?

An FPGA would be more complicated and require a little bit to much standby current. FPGA Replay has a quite fast m68k CPU alike clone.

[freqmax]

How did that "PURE" executables work in relation to this?

[freqmax]

This must mean that programs that has the PURE flag is feed with a parameter that tells it where this run of the code has it's variables etc.