pjw wrote:Pardon my ignorance, but why is it so hard to make these compilers (FPC, C68,..) produce "pure" Qdos code, ie code that is non-self-modifying and position independent? AFAICS there is nothing inherent in the languages themselves that prevent it. Could it be fixed?
Another question borne of my ignorance: Could (some of, at least) those massive libraries that seem to be included with even the simplest programs be made to be pre-loaded as shareable toolkits a la Qlib_run, ptrmen_cde, etc? Wouldnt that be desirable?
When youre done tut-tuting and shaking your wise heads, please give me a kind, clear answer even I can understand

Per,
the simple reason why we want (and have, like in C68 and FreePascal) programs that need to self modify (and relocate) and not pure position independant code and data is
size vs.
performance. As you will know, PC and other address register-relative addressing only works +/- 32kBytes away, because the register offsets on a 680xx (with xx < 20) are only 16 bits wide.
You could work around this using jump islands (jump across larger address ranges with several PC relative branches in-between) or emulate PC-relativity with a base address register set to "here" and do run-time relocation in that address register on the fly, leaving the code in RAM unmodified. Obviously, you're buying "purity" for significantly worse performance and more complexity (and, the compilers ported from platforms that don't have such limitations and thus have absolutely no mechanisms to generate these work-arounds). Compilers for segmented DOS have jumped through hoops to address a similar problem in the x86 world and only got it acceptably(?) right only after years.
You could easily create full PC-relative, non-relocating programs by targetting only platforms >= 68020, but this doesn't really look like something we want.
You could also easily create full PC-relative, non-relocating programs by limiting yourself to no more than 32kBytes of code and 32kBytes of data, which is also quite a bit of a serious limitation.
68k Macs and 68k PalmOS handhelds used to have similar problems. MacOS solved this by limiting a single code resource to no more than 32kBytes, larger programs mangled together from several such resources, with inter-code-resource jumps to be managed by the programmer themselves, PalmOS did something similar, and you could easily receive a compiler/linker error basically saying "PROCEDURE too far away for a BRA, move it closer", which could get you in a serious mess re-arranging your code.
All in all, the downsides of "non-pure programs" seem to be much less inconvenient (to me, at least) than having to accept the alternative limitations.
On your other question: C68 has actually tried that approach, which basically boils down to shared libraries on other systems, towards the end of its active development. You can create so-called RLLs that represent shared libraries, are loaded on demand and stay resident for other programs to use. There's never been much uptake on this, although I think it somewhat works with the latest compiler and library patches. I don't know of a single program in the public that uses RLLs.