Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 23, 2021 12:01 pm wrote:
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on September 23, 2021 9:37 am wrote:
> >
> > In other words, if I read your posts about segments correctly, you seem to be claiming
> > that there is zero correlation between the overly simplistic type system of the C programming
> > language (plus other languages from that era) and the downfall of segments.
>
> I don't think that's at all what I said.
>
> I said that segments are an extra complication, and that
> they don't add any value, so people dropped their use.
>
> I said nothing about the C language. In fact, it's an entirely language-agnostic statement.
>
> People love to blame C for various things, and claim that the "C model" made
> computer architecture much less interesting. You seem to be in that camp, and
> seem to try to claim that C had something to do with segments going away.
>
> Not so.
>
> C not wanting segments is not the cause, it's the correlation. Nobody wants
> segments. It's not that "C made computer architecture boring", it's that "learning
> what works and what does not" made for crazy useless features going away.
>
> Those crazy useless features may have been "exciting", but that doesn't make them good.
>
> If anything, the C language people bent over backwards to make excuses for horrible architecture features,
> and weakened the language more than they should have in order to allow for bad architecture decisions.
> Pretty much every single "undefined behavior" is about the language allowing for silly things.
>
> So what I am claiming is that segments - and by extension, "capability pointer architectures"
> - are a bad idea. They add unwanted complexity that doesn't actually buy users anything at
> all into one of the most important part of the CPU pipeline - the memory units.
>
> Don't do it. It's been a research subject for many decades, it's still a research
> subject (I see pointers to the ARM capability pointers in this thread), and it
> has never ever been successful. At what point do people just admit defeat?
>
> The fact is, the whole notion of passing magic pointers and trying to associate random state
> with them between two random untrusted but somehow cooperative entities is pure BS. And I claim
> that no amount of segmentation - whatever you call it - will make it anything else.
>
> Side note: that doesn't mean that you can't do other things. By all means add features like
> pointer coloring that is for debugging. The ARM memory tagging is actually very successful.
> It's not about some absolute pointer security, it's not about arbitrary segments, it's a reasonably
> low-overhead debugging aid that can catch bad uses early. And it still lives in the context
> of a regular flat address space, just one where you can add some region markers.
>
> So you can add exciting value add in the memory unit.
>
> It's just that segments or capabilities isn't it. Too much pain for no real gain.
>
> Linus

(I am writing this response without reading through the sub-tree of this forum node, so I would like to apologize in advance if I will write something that has been discussed there.)

You didn't write something unexpected, which is good from a certain viewpoint because it makes it easier to attack with some counter-arguments. You are defending the "paging-unit is superior to segments" viewpoint.

- Protected mode segments (80286 and later), with two privilege levels (kernel-space and user-space), are fully sufficient to implement a Unix-like operating system.

- A protected mode segment has a base address and a limit (usually with a granularity of at most 1 word) that only the kernel-space can modify directly.

- A downside of having a paging unit in a CPU is that the CPU must have L1+L2 caches (TLBs) storing virtual memory mappings (which is, in simplified terms, a hash-map implemented in hardware) and address-generation units (AGUs) which are separate from ALUs. In contrast to this, segments are much simpler: a linear GDT (global descriptor table, cached in L1D like any other data), adders, and comparators.

- Paging makes it more complicated to add more AGUs (in order to increase the number of loads&stores per cycle) compared to segment registers because the paging unit is logically a single shared resource - while segment registers (registers+adders+comparators) are more distributed/parallel in their nature.

- An instruction set architecture probably needs to support at least 8 segment registers in order to be future-proof and to make it a bit easier for the kernel and the user-space to manage memory.

- An issue on amd64/x86-64 is that it is impossible to disable the paging unit and to disable-or-repurpose AGUs so that, if you use just segments to implement an OS, you wouldn't need to pay the *implicit* tax associated with page translation. In other words: *not* using the MMU does, unfortunately, *not* result in more loads&stores per cycle on the CPU.

- Protected mode segments are fully sufficient to implement virtual memory, because exceeding the segment's limit is equivalent to a page fault. When a user-space instruction accesses memory beyond the segment's limit, the kernel can for example load missing data from a HDD/SSD drive, extend the limit of the segment in the global descriptor table (GDT on 80286+), and switch back to user-space which will re-execute the memory access instruction.

- Due to the linear nature of segments, segments are prone to memory fragmentation. This is *both* an issue and an advantage. One advantage for example is that, after memory defragmentation, related data is located closer together and related code is located closer together (in other words: segmentation can result in better L1D and L1I cache utilization compared to paging).

- Using protected mode segments to implement an OS requires a different style of thinking (different rules) than implementing an OS on top of paging. Going the way of segments means that the OS and user-space processes need to be more dynamic (i.e: somewhere between static compilation and just-in-time compilation).

- About pointers in the C programming language: C has a single pointer type. Nowadays, it tends to be either 32 or 64 bits in width. C doesn't support mixing 32-bit and 64-bit pointers in a single program because this would require the language to support two pointer types. Using '*' asterisk in the syntax of pointer types in C is, in hindsight, a clearly suboptimal programming language design decision both from run time performance viewpoint and from memory consumption viewpoint.

- Use of segments to implement an OS (without paging) depends on whether the programming language used to implement user-space apps supports multiple pointer types. For example, without multiple pointer types it is more complicated to safely distinguish a pointer to a local function from a pointer to a shared library function, or a pointer to local data from a pointer to shared data (irrespective of whether the pointers have different widths or the same width).

- If you would think about it more deeply and would not be resistant to thinking about large changes to an OS architecture, you wouldn't believe that (as you wrote) "C not wanting segments is not the cause, it's the correlation". You would believe the opposite: that programming languages with a single pointer type (which includes C) are among the primary causes of the downfall of segments. Eventually, you might also start to believe that there is a causal link between C's type system and the maximum number of loads&stores a CPU core can perform per cycle assuming a particular transistor budget.

- Your claim that "So what I am claiming is that segments [cut] are a bad idea. They add unwanted complexity that doesn't actually buy users anything at all into one of the most important part of the CPU pipeline - the memory units" - is a false statement. It is totally obvious that the hardware implementation of segments is simpler than the hardware implementation of paging, and it has a higher potential for concurrency inside of a CPU than paging. (I have removed/cut the part "... and by extension, capability pointer architectures" from the cited sentence.)

- Many programmers prefer to have a single pointer type in the programming language (and a single, extremely large, address space), instead of multiple pointer types. This has both positive and negative consequences. Not seeing, or on purpose ignoring, the negative consequences is a form of intellectual blindness.

- That said, an optimizing compiler and its runtime library can internally support multiple pointer types (widths) even if the programming language being compiled has a single pointer type. (Albeit, an optimizing compiler can in theory support any missing feature X irrespective of what X actually is, so the argument that "an optimizing compiler can support X even X isn't supported by the language" is a relatively weak argument.)

-atom