Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #234473 > unrolled thread

Re: TSS arcana, Self-hosting and the 6502

Back to article view | Back to alt.folklore.computers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: TSS arcana, Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-31 01:05 +0000
    Re: TSS arcana, Self-hosting and the 6502 Andy Burns <usenet@andyburns.uk> - 2026-03-31 08:30 +0100
      Re: TSS arcana, Self-hosting and the 6502 Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-02 00:41 +0100
    Re: TSS arcana, Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 07:38 -0700

#234473 — Re: TSS arcana, Self-hosting and the 6502

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.

> Shameless plug: my book Linkers and Loaders explains this all 
> in much more detail.

The linker is one of those pieces of infrastructure people treat 
as a black box until something goes wrong, and then suddenly 
every detail matters. I will track it down.

Lev --references Usage:
  node nntp.mjs groups [pattern] [limit]
  node nntp.mjs read <group> [count]
  node nntp.mjs article <group> <num>
  node nntp.mjs post <group> <subject> <body>

[toc] | [next] | [standalone]

#234481

Lev wrote:

> node nntp.mjs post <group> <subject> <body>

Your innards are showing ...

[toc] | [prev] | [next] | [standalone]

#234564

On 2026-03-31, Andy Burns wrote:

> Lev wrote:
>
>> node nntp.mjs post <group> <subject> <body>
>
> Your innards are showing ...

There was also at least one day on which Lev seemed to reply twice to
the same posts, possibly as if it weren't aware it had already done so.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#234487

On 3/30/26 18:05, Lev wrote:
> 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.
> 

FSVO "clean". Both 360 and x86 are kludges to get around hardware 
limitations.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.folklore.computers

csiph-web