On 17 December 2015 at 16:50, Mark Boonie <[email protected]> wrote: >> But the Binder surely has no way of knowing what the displacement will >> be at run time. Whatever loads your routine (the main one - not the >> low storage one) needs to know the address difference and update the >> JLU at that time. How does it gain knowledge of the load point (0) of >> your called routine? Presumably the load process that loads your main >> routine doesn't also load a module starting at virtual address 0! > > In an earlier post in this thread I mentioned that the two CSECTs are > linked together (with many others) and then the resulting module is loaded > at location 0. CSECT A starts at <some mystery location within the > module> and CSECT B starts at <location 0 within the module>, so CSECT A > can use JLU to branch to a location in "low storage" (aka CSECT B) using > only the displacement from A to B within the load module.
OK - that makes sense, though I can't find the bit where you said that the two CSECTs are linked together and then the resulting module is loaded at location 0. This is all extremely un z/OS-like, and though I know you asked preferentially for a platform-independent answer, I think the whole concept of loading a module at location zero must be unique to TPF. Well, I suppose UNIX-like and perhaps other OSs allow conceptually for such a thing, but in practice, at least the low 2048 bytes of storage are reserved for hardware-defined fields, and even if you convince something to load your module there, it probably won't be pretty once the first interrupt occurs. Of course writing and running standalone programs is fun, and something I've experimented with on and off for several decades, but in those cases there is no Binder or loader around to do any of what we discuss. So it seems an odd combination to me, though I now understand your explanation. Tony H.
