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

[matthey]

Pure flag only indicates this program can be made resident (preloaded to ram with resident command). Internally programs can have different means to achieve re-entrancy. It could be semaphore or dynamically allocate ram for each instance.

Code initialization may be different for a pure program but I believe the AmigaOS (dos.library?) has code that maintains a list of currently used pure programs (resident list?), allows for finding and reusing the code and flushes the code under certain conditions. ThoR probably knows all the details of how it works. The AmigaOS does have the Resident CLI command to make pure programs resident (it can also show the use count of resident commands) and the H (Hold not Hidden) file attribute flag to make them resident when first used (requires the Pure bit also) without using the Resident command (saves a few lines in the S:Startup-Sequence for making Assign, Mount and Execute resident for example). There appears to be automagic support from the AmigaOS.

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

[guest11527]

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

First, the PURE flag is just a pure indicator bit (no pun intended) for the resident program that is tested; trying to make a program resident with the pure flag cleared creates an error, but the resident program does actually not check for pure-ness in any other way. The ARP/Software distillery version of it had at least a checksum they tested for, but CBM removed that logic (but otherwise used lots of code from the software distillery to replace the tripos/BCPL code).
How other resident programs work is really program dependent. I personally avoid using global memory for such programs and put everything on the stack; there is no higher magic otherwise. Oh yes, probably avoid using code from the standard library. memcpy/strcpy and frieds are fine, but high-level stuff like printf()/fopen() are not. Use the dos PrintF() instead, for example.