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

Groups > alt.folklore.computers > #234535

Re: Self-hosting and the 6502

Show all headers | View raw

In article <10qho2h$3plnk$1@dont-email.me>,
Peter Flass  <Peter@Iron-Spring.com> wrote:
>On 3/31/26 16:45, Dan Cross wrote:
>> In article <10qglro$3dj57$1@dont-email.me>,
>> Peter Flass  <Peter@Iron-Spring.com> wrote:
>>> On 3/30/26 16:32, Lev wrote:
>>>>
>>>> The segmentation approach is elegant but it's interesting
>>>> that it lost. Flat address spaces won commercially even
>>>> though they're worse for the problem. Paging won over
>>>> segmentation, position-independent code stayed hard until
>>>> relatively recently (and still isn't free on x86). Is
>>>> there a good account of why segmentation died? I've seen
>>>> hand-waving about 'complexity' but Multics ran fine.
>>>
>>> Cost. It's Betamax vs. VHS, or OS/2 vs. Windows. The best technical
>>> approach loses to something worse, but cheaper.
>> 
>> I'm not sure I agree with that, actually.  The observation was
>> that logical segments could be constructed from paged virtual
>> memories.  Moreover, if you squint at it right, GE-645-style
>> segments are kind of like a two-level paging structure of the
>> type we see on e.g., x86 or ARM (granted; the address space was
>> much larger for Multics).
>> 
>> But if that's the case, do you need the fancy segment-aware
>> addressing modes?  System designers subsequent to Multics and
>> the 645->6180->DPS/8m lineage don't seem to think so, and I
>> don't think they were dummies.
>
>Partly, unix is a dumbed-down Multics for cheap commodity hardware, and 
>hardware designers ever after just designed for unix. It's the least 
>common denominator.

I'm not sure that's the right historical framing.  Certainly,
Unix took many ideas from Multics, and it definitely stripped
many, many things away.  I think that _a_ way to look at it is
that it distilled many of the essential ideas to their essence,
and implemented them in as simple and straight-forward a manner
as possible, without being overly simplistic: in that sense, I
wouldn't call it "dumbed-down".  They were certainly constrained
by the hardware they ran on, though.  I confess that I find the
idea of a PDP-11 in 1971/1972 being a "commodity" kind of funny;
within a factor of two, it probably cost as much as a reasonable
house in suburban New Jersey at the time.

But more generally, this conflates hardware design with software
requirements, and I don't think that the conclusion necessarily
follows.  There were a lot of system designs post-Multics that
didn't use segmentation in the same way Multics did, but were
decidedly not Unix-like at all, and segmentation was not a
panacea: there was a lot of complexity that went into Multics to
accommodate the segmented architecture.  The interviwe THVV did
with Doug McIlroy where Doug referred to "the mysteries of the
linkage segment" having been "untangled" by the time they were
implementing the EPL compiler are telling, I think.

The dig against Unix may have been warranted at some time, but
again it's not clear to me that it still holds.  Modern
descendents of Unix are far more complex in every way than
Multics ever was (this is not a good thing), and they also do a
lot more.  Could they have done so more elegantly with a more
Multics-like system design; something treating memory closer to
a single-store?  Perhaps.  Perhaps not.  Some nice things flow
out of Unix's "all IO is a stream of bytes" model that are
awkward in Multics' "mapped segments" single-store model.  It's
interesting to speculate, though!

>I'm far from a hardware authority, but without proper segmentation 
>you're stuck implementing PIC in software, while it should be part of 
>the address translation hardware/microcode.

I think this is the more relevant part, but it shows an implicit
assumption: that PIC in software is _a priori_ inferior to
hardware-driven segmentation.  First, I'm not sure the two are
anything other than tangentially related: even on Multics, as I
understand it, "gate" segments for cross-ring calls are
essentially position independent for security reasons, using
jump vectors at the beginning of the segment so that the target
of an inter-segment call can do validation of the request from a
potentially lesser-privileged ring; this suggests that the
hardware mechanism is not itself sufficient for all intersegment
procedure linkage, and that you need something like PIC anyway.
Second, logical segments in a paged virtual address space _can_
be statically linked at absolute (virtual) addresses, and don't
require PIC to work.

Shared objects are a different story, but even then, is there a
significant difference between the GOT/PLT and the linkage
segment?  One might argue that DSOs would benefit from direct
hardware support, but evidence suggests we'd still need
non-trivial software support.  We know that we can build logical
segments from paged virtual address spaces: it is the more
general abstraction.  So then, is richer hardware support
intrinsically better?  If so, how?

Moreover, we've recognized that microcode itself is not a great
way to implement a computer.  Being able to handle more
complexity in the instruction set a la microcoding begs the
question: do we need and/or want that additonal complexity?
Evidence suggests that we do not; the 801 project showed that
it's rarely used.

On the other hand, microcode does make CPUs field-patchable,
which is nice.

	- Dan C.

Back to alt.folklore.computers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-30 23:32 +0000
  Re: Self-hosting and the 6502 snipeco.2@gmail.com (Sn!pe) - 2026-03-31 00:36 +0100
    Re: Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-31 03:08 +0000
      Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 07:45 -0700
        Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-31 14:56 +0000
  Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 23:38 +0000
    Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-04-01 16:50 +0000
      Re: segments, was Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-02 03:07 +0000
        Re: segments, was Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-02 16:21 +0000
          segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-11 08:13 -0300
            Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502) Peter Flass <Peter@Iron-Spring.com> - 2026-09-11 07:29 -0700
            Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502) john larkin <jl@glen--canyon.com> - 2026-09-11 07:55 -0700
              Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502) David Schultz <david.schultz@earthlink.net> - 2026-09-11 13:06 -0500
            Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502) someone <2a59d59e3809f827ce709d3815e3950eef4a6a93af5557a93a7fdfba71460843@example.com> - 2026-09-14 16:45 +0000
  Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-03-31 09:01 +0100
    Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-31 09:49 +0000
  Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 07:31 -0700
    Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 23:45 +0000
      Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 17:15 -0700
        Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 01:27 +0000
          Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 19:24 -0700
            Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 03:01 +0000
              Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-01 07:26 -0700
                Re: Self-hosting and the 6502 "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-04-01 15:54 +0100
                Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 20:35 +0000
                Re: Self-hosting and the 6502 snipeco.2@gmail.com (Sn!pe) - 2026-04-01 21:49 +0100
                Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 16:08 +0000
                Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 20:34 +0000
                Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-01 14:29 -0700
                Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 22:37 +0000
                Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 22:52 +0000
        Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 13:54 +0000
        Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-04-01 17:31 +0000
  Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 22:23 +0000

csiph-web