For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
In the IBM system, communication between users would have required
communication between VMs. In other words, a (virtual) peer-to-peer
network. But IBM didn?t have anything like that for close to another
two decades.
Depends on what you mean "close to that". The VMCF facility provided a >transport, but there wasn't much that used it until TCP/IP ....
... but users could send messages and files to each other, and between >machines which was sufficient.....
Sort of. TSS programs had CSECTs which were read-only and position independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process
This is not all that different from ELF shared libraries in Unix
and linux, which have position independent pages and the PLT and
GOT with process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all
in much more detail.
For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position independent
with one copy shared among all processes, and PSECTs which were read-write and
needed a separate copy per process which had pointers that were relocated when
loaded. The calling sequence had a pair of addresses for each routine, one to the PSECT (the R-con) and one to the CSECT (the V-con). In retrospect it would
have made more sense to use one address for the PSECT and pick up the code address from a known location in the PSECT. My guess is that they hoped there would be routines with no static data so they could skip the R-con, but as far
as I know they never did that.
It is easy to write position independent 360 code since all references are relative to base registers. You load a base register to point to wherever the code is (BALR R,0 was the usual way) and off you go. The routine would keep a pointer to the PSECT in another register set up from the calling sequence, so the routine can directly address both its code and its data without extra instructions. The calling sequence was slower than the OS/360 version, but even the OS version was quite slow with register saves and save area chaining.
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
John Levine wrote:
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process
The CSECT/PSECT split maps almost exactly to modern text/data
segments in ELF. The R-con/V-con pair in the calling sequence
is what surprises me - carrying two pointers per routine where
a single indirection through the PSECT would have worked.
This is not all that different from ELF shared libraries in Unix
and linux, which have position independent pages and the PLT and
GOT with process-specific pointers to the shared code.
The GOT is basically the PSECT pointer table extracted into its
own section. Were the ELF designers directly aware of TSS or did
they arrive at the same solution independently? Position
independent shared code has a limited number of clean solutions.
On 3/30/26 17:58, John Levine wrote:
Highly recommended. I have a copy sitting on my shelf now.For TSS/360 all address constants have to be copied and relocated each
time a program is loaded, and then it needs two memory fetches instead
of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process which had
pointers that were relocated when loaded. The calling sequence had a
pair of addresses for each routine, one to the PSECT (the R-con) and
one to the CSECT (the V-con). In retrospect it would have made more
sense to use one address for the PSECT and pick up the code address
from a known location in the PSECT. My guess is that they hoped there
would be routines with no static data so they could skip the R-con, but
as far as I know they never did that.
It is easy to write position independent 360 code since all references
are relative to base registers. You load a base register to point to
wherever the code is (BALR R,0 was the usual way) and off you go. The
routine would keep a pointer to the PSECT in another register set up
from the calling sequence,
so the routine can directly address both its code and its data without
extra instructions. The calling sequence was slower than the OS/360
version, but even the OS version was quite slow with register saves and
save area chaining.
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with
process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
On Tue, 31 Mar 2026 07:35:37 -0700, Peter Flass wrote:
On 3/30/26 17:58, John Levine wrote:
Highly recommended. I have a copy sitting on my shelf now.For TSS/360 all address constants have to be copied and relocated each >>>> time a program is loaded, and then it needs two memory fetches instead >>>> of one to access the referenced address.
Sort of. TSS programs had CSECTs which were read-only and position
independent with one copy shared among all processes, and PSECTs which
were read-write and needed a separate copy per process which had
pointers that were relocated when loaded. The calling sequence had a
pair of addresses for each routine, one to the PSECT (the R-con) and
one to the CSECT (the V-con). In retrospect it would have made more
sense to use one address for the PSECT and pick up the code address
from a known location in the PSECT. My guess is that they hoped there
would be routines with no static data so they could skip the R-con, but
as far as I know they never did that.
It is easy to write position independent 360 code since all references
are relative to base registers. You load a base register to point to
wherever the code is (BALR R,0 was the usual way) and off you go. The
routine would keep a pointer to the PSECT in another register set up
from the calling sequence,
so the routine can directly address both its code and its data without
extra instructions. The calling sequence was slower than the OS/360
version, but even the OS version was quite slow with register saves and
save area chaining.
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with
process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
I have every book in that series, if you're referring to the Macdonald/ Elsevier set.
I also have the Levine book.
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific >pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
In the IBM system, communication between users would have required
communication between VMs. In other words, a (virtual) peer-to-peer
network. But IBM didn?t have anything like that for close to another
two decades.
Depends on what you mean "close to that". The VMCF facility provided a >>transport, but there wasn't much that used it until TCP/IP ....
... but users could send messages and files to each other, and between >>machines which was sufficient.....
You could hook the virtual card punch in one machine to the virtual reader
in another through a virtual card chute. The RSCS daemon used that to >communicate with other processes on the same machine, and over networks
to other machines. That was BITNET which grew to 3000 nodes and provided >email and a vibrant community of discussion lists in the late 1980s.
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and
linux, which have position independent pages and the PLT and GOT with >>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much
more detail.
I can't lie, your book on the subject is fantastic. And I think it is
still one of the _only_ books available on linkers and loaders
specifically?
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and linux, which
have position independent pages and the PLT and GOT with process-specific >>pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much more detail.
I can't lie, your book on the subject is fantastic. And I think
it is still one of the _only_ books available on linkers and
loaders specifically?
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> >>wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>linux, which have position independent pages and the PLT and GOT with >>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>still one of the _only_ books available on linkers and loaders >>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine <johnl@taugh.com> >>>wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>>linux, which have position independent pages and the PLT and GOT with >>>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>>still one of the _only_ books available on linkers and loaders >>>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I can't >find a mention online, but I have a copy.
When I wrote the book proposal in 1999 (yes, that long ago) part of the
pitch was that there had been linkers and loaders since the late 1940s
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I can't >find a mention online, but I have a copy.
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part of the>> pitch was that there had been linkers and loaders since the late 1940sThere had been an entire book, but it was only a monograph really. I can't find a mention online, but I have a copy.
but there'd never been more than the occasional article or chapter. So
either this was the book that the world had been awaiting for half a
century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
In article <n3488uF2repU8@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:
According to Dan Cross <cross@spitfire.i.gajendra.net>:
In article <10qf67n$2u8s$2@gal.iecc.com>, John Levine >>>><johnl@taugh.com>
wrote:
[snip]
This isn't all that different from ELF shared libraries in Unix and >>>>>linux, which have position independent pages and the PLT and GOT with >>>>>process-specific pointers to the shared code.
Shameless plug: my book Linkers and Loaders explains this all in much >>>>>more detail.
I can't lie, your book on the subject is fantastic. And I think it is >>>>still one of the _only_ books available on linkers and loaders >>>>specifically?
When I wrote the book proposal in 1999 (yes, that long ago) part of
the pitch was that there had been linkers and loaders since the late
1940s but there'd never been more than the occasional article or
chapter. So either this was the book that the world had been awaiting
for half a century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
There had been an entire book, but it was only a monograph really. I
can't find a mention online, but I have a copy.
What was the title? And who are/were the author(s)?
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
1940s but there'd never been more than the occasional article orpitch was that there had been linkers and loaders since the late
chapter. So either this was the book that the world had been awaiting
for half a century, or this will prove that there is no market for it.
It kind of did both, never selling huge numbers but still in print.
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaitingpitch was that there had been linkers and loaders since the late >>>> 1940s but there'd never been more than the occasional article or
for half a century, or this will prove that there is no market for it. >>>> It kind of did both, never selling huge numbers but still in print.
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go
and find it!
Bob Eager <news0009@eager.cx> writes:
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaiting >>>>> for half a century, or this will prove that there is no market for it. >>>>> It kind of did both, never selling huge numbers but still in print.pitch was that there had been linkers and loaders since the late >>>>> 1940s but there'd never been more than the occasional article or
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go >>and find it!
https://archive.org/details/assemblersloader0000barr/page/n1/mode/2up
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
Bob Eager <news0009@eager.cx> writes:
On Wed, 01 Apr 2026 17:15:19 +0100, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:
On Wed, 01 Apr 2026 02:06:34 +0000, John Levine wrote:[Linkers and Loaders:]
When I wrote the book proposal in 1999 (yes, that long ago) part ofThere had been an entire book, but it was only a monograph really. I
chapter. So either this was the book that the world had been awaiting >>>>> for half a century, or this will prove that there is no market for it. >>>>> It kind of did both, never selling huge numbers but still in print.pitch was that there had been linkers and loaders since the late >>>>> 1940s but there'd never been more than the occasional article or
can't find a mention online, but I have a copy.
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
That's the one. I didn't quite remember the title correctly. I had to go
and find it!
https://archive.org/details/assemblersloader0000barr/page/n1/mode/2up
On Wed, 1 Apr 2026 17:15:19 +0100, Andy Walker wrote:
David Barron's 1068 monograph? This is called "Assemblers and
Loaders", but it does include a chapter on "Loaders and Linkage
Editors".
How about Ulrich Drepper?s 47-page document on ?How To Write Shared >Libraries?, written a couple of decades ago? He is/was the principal >maintainer of GNU libc. So he goes into issues like versioning and
backward compatibility, which is a lot more important on Linux systems
today than it was back on computer systems of, say, the 1980s.
Lev wrote:
node nntp.mjs post <group> <subject> <body>
Your innards are showing ...
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of
There had been an entire book, but it was only a monograph really. I can't >> find a mention online, but I have a copy.˙˙˙˙David Barron's 1068 monograph?˙ This is called "Assemblers and
Loaders", [...].
On 01/04/2026 17:15, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of
There had been an entire book, but it was only a monograph really. I can't >>> find a mention online, but I have a copy.˙˙˙˙David Barron's 1068 monograph?˙ This is called "Assemblers and
Loaders", [...].
accuracy, the publication date was not /that/ early! Typo for "1968".
[I find that I now do so little actual typing, as opposed to dabbing,
that typos now abound in what I type, and are difficult to spot in the >typeface that my monitor uses and with the eyes that my head uses.]
Andy Walker <anw@cuboid.co.uk> writes:
Well, 1066 is a notable date in your neck of the woods...David Barron's 1068 monograph?˙[...].I don't suppose anyone was deceived, but in the interests of
accuracy, the publication date was not /that/ early! Typo for "1968".
Andy Walker <anw@cuboid.co.uk> writes:
On 01/04/2026 17:15, Andy Walker wrote:
On 01/04/2026 10:53, Bob Eager wrote:I don't suppose anyone was deceived, but in the interests of >>accuracy, the publication date was not /that/ early! Typo for "1968".
There had been an entire book, but it was only a monograph really. I can't >>>> find a mention online, but I have a copy.˙˙˙˙David Barron's 1068 monograph?˙ This is called "Assemblers and
Loaders", [...].
[I find that I now do so little actual typing, as opposed to dabbing,
that typos now abound in what I type, and are difficult to spot in the >>typeface that my monitor uses and with the eyes that my head uses.]
Well, 1066 is a notable date in your neck of the woods...
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 13 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 27:44:36 |
| Calls: | 211 |
| Files: | 21,502 |
| Messages: | 80,905 |