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

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

Re: Self-hosting and the 6502

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

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#234529

On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
> 
>> 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.
> 
> Could be worse. Could be Microsoft Windows.

No argument there. Unix is "good enough".

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

#234530

On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:

> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>
>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>
>>> 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.
>>
>> Could be worse. Could be Microsoft Windows.
>
> No argument there. Unix is "good enough".

Unix is obsolete. Linux is the way forward from here.

Even Ken Thompson thinks so.

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

#234537

On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
> On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
> 
>> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>>
>>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>>
>>>> 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.
>>>
>>> Could be worse. Could be Microsoft Windows.
>>
>> No argument there. Unix is "good enough".
> 
> Unix is obsolete. Linux is the way forward from here.
> 
> Even Ken Thompson thinks so.

tom-A-to tom-AH-to

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

#234538

On Wed, 1 Apr 2026 07:26:26 -0700
Peter Flass <Peter@Iron-Spring.com> wrote:

> On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
> > On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
> > 
> >> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
> >>>
> >>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
> >>>
> >>>> 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.
> >>>
> >>> Could be worse. Could be Microsoft Windows.
> >>
> >> No argument there. Unix is "good enough".
> > 
> > Unix is obsolete. Linux is the way forward from here.
> > 
> > Even Ken Thompson thinks so.
> 
> tom-A-to tom-AH-to
> 
O-regAno Ore-gano

Where's Plan 9?

-- 
Bah, and indeed Humbug.

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

#234552

On Wed, 1 Apr 2026 15:54:30 +0100, Kerr-Mudd, John wrote:

> Where's Plan 9?

A research backwater which got overtaken by events, by the sound of
it.

Unix, when it came out, was an important innovation in so many ways.
What, exactly, is useful about Plan 9?

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

#234554

Kerr-Mudd, John <admin@127.0.0.1> wrote:

> > > Unix is obsolete. Linux is the way forward from here.
> > > 
> > > Even Ken Thompson thinks so.
> > 
> > tom-A-to tom-AH-to
> > 
> O-regAno Ore-gano
> 
> Where's Plan 9?

<https://youtu.be/luIuvnKjb6E>

-- 
^Ï^.          Sn!pe, bird-brain.          My pet rock Gordon just is.

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

#234541

In article <10qj9ui$9sjf$1@dont-email.me>,
Peter Flass  <Peter@Iron-Spring.com> wrote:
>On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
>> On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
>> 
>>> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>>>
>>>>> 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.
>>>>
>>>> Could be worse. Could be Microsoft Windows.
>>>
>>> No argument there. Unix is "good enough".
>> 
>> Unix is obsolete. Linux is the way forward from here.
>> 
>> Even Ken Thompson thinks so.
>
>tom-A-to tom-AH-to

As usual, Lawrence is lying.  I'm quite sure he's unaware of
what Ken may or may not be thinking.

	- Dan C.

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

#234551

On Wed, 1 Apr 2026 07:26:26 -0700, Peter Flass wrote:

> On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
>>
>> On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
>>
>>> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>>>
>>>>> 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.
>>>>
>>>> Could be worse. Could be Microsoft Windows.
>>>
>>> No argument there. Unix is "good enough".
>>
>> Unix is obsolete. Linux is the way forward from here.
>>
>> Even Ken Thompson thinks so.
>
> tom-A-to tom-AH-to

That’s Ken “Mr Unix” Thompson. You know, the guy who headed up the
development of Unix at Bell Labs in the first place.

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

#234556

On 4/1/26 13:34, Lawrence D’Oliveiro wrote:
> On Wed, 1 Apr 2026 07:26:26 -0700, Peter Flass wrote:
> 
>> On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
>>>
>>> On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
>>>
>>>> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>>>>
>>>>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Could be worse. Could be Microsoft Windows.
>>>>
>>>> No argument there. Unix is "good enough".
>>>
>>> Unix is obsolete. Linux is the way forward from here.
>>>
>>> Even Ken Thompson thinks so.
>>
>> tom-A-to tom-AH-to
> 
> That’s Ken “Mr Unix” Thompson. You know, the guy who headed up the
> development of Unix at Bell Labs in the first place.

My point is Linux is Unix. Linux is getting most of the development 
these days, but it's like an upgraded version.

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

#234560

In article <10qk2nr$ipcc$2@dont-email.me>,
Peter Flass  <Peter@Iron-Spring.com> wrote:
>On 4/1/26 13:34, Lawrence D’Oliveiro wrote:
>> On Wed, 1 Apr 2026 07:26:26 -0700, Peter Flass wrote:
>> 
>>> On 3/31/26 20:01, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Tue, 31 Mar 2026 19:24:44 -0700, Peter Flass wrote:
>>>>
>>>>> On 3/31/26 18:27, Lawrence D’Oliveiro wrote:
>>>>>>
>>>>>> On Tue, 31 Mar 2026 17:15:13 -0700, Peter Flass wrote:
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Could be worse. Could be Microsoft Windows.
>>>>>
>>>>> No argument there. Unix is "good enough".
>>>>
>>>> Unix is obsolete. Linux is the way forward from here.
>>>>
>>>> Even Ken Thompson thinks so.
>>>
>>> tom-A-to tom-AH-to
>> 
>> That’s Ken “Mr Unix” Thompson. You know, the guy who headed up the
>> development of Unix at Bell Labs in the first place.
>
>My point is Linux is Unix. Linux is getting most of the development 
>these days, but it's like an upgraded version.

a) this troll has no idea what Ken Thompson uses or promotes and
what he doesn't use or promote.  b) you're right.  c) arguing
with Lawrence is a fruitless and ultimately frustrating
experience.  He obviousuly has a very high opinion of himself
and his cleverness.  He is wrong.

	- Dan C.

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

#234561

On Wed, 1 Apr 2026 14:29:31 -0700, Peter Flass wrote:

> My point is Linux is Unix. Linux is getting most of the development
> these days, but it's like an upgraded version.

A successor to what “Unix” used to stand for, yes. Officially “Unix”,
no.

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

#234535

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.

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

#234548

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.
>> 
>>       - Dan C.
>> 
> 
> 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 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.

In "proper" GE645/Multix style one should have each function in
its own segment.  And similarly for data structures.  But modern
programming style builds large data structures from tiny pieces
connected by pointers.  Also functions tend to be quite small.
In modern time inlining tend to produce much larger functions
at machine code level, but important transitory years it was
neccessary to efficiently support a lot of small functions.
Segmented approach leads to higher cost for general function
calls, with proper hardware support it could be twice as
expensive as non segmented call, but in practice implementations
had larger cost.

Concerning "implementing PIC in software", modern hardware have
native support for PC-relative addressing so as long as you
move given part as a single piece you can run it at any
memory location.  You get to different pieces via pointers,
which is not essentially different than segmented model.
Both segmented model and flat model with multiple shared
libraries needs software to coordinate loading, to
allocate addresses and manage needed data structures.

AFAICS main difference is that faulty address arithmetic
have good chance to be otside of segment bounds, so
hardware should catch it.  In paged address spaces
faulty address arithmetic may give valid page so
remain undetected.  I do not think that this is large
difference in practice: for performance reasons
programs are likely to put related pieces of data in
a single segment and then slightly out of bounds
references will just access wrong data.

-- 
                              Waldek Hebisch

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

#234516

In article <10qf16a$2t7c2$1@dont-email.me>, Lev  <thresh3@fastmail.com> wrote:
>[snip]
>David Wade wrote:
>
>> but users could send messages and files to each other,
>> and between machines which was sufficient
>
>Lawrence's point about VM/370 lacking inter-VM communication
>is overstated. The spool-based approach you describe (write
>file, send message, process, delete) is basically message
>passing. Not pretty, but it's the same primitive that
>microservices use now, just without the YAML.

Lawrence's point is just wrong.  He clearly never used these
systems.

	- Dan C.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web