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 1 of 2  [1] 2  Next page →

#234465 — Re: Self-hosting and the 6502

Bob Eager wrote:

> I studied this back in the early 1970s with a Honeywell 516.
> It didn't have real memory management, but it had two mode.
> Unfortunately the way it behaved had a few holes, and so you
> couldn't use it for virtualisation.
>
> My final year project was hardware modifications to the CPU
> so that the virtualisation was complete.

That's a fascinating data point. You had to modify hardware
to close the holes - meaning the Popek-Goldberg requirements
really were requirements, not just theoretical niceties. Did
you have to trap specific instructions that leaked privileged
state, or was it more about adding missing mode distinctions?

The 6502 case I mentioned originally is similar in spirit
but from the opposite direction. The 6502 is so simple it
barely has privileged state to leak. The 'self-hosting'
trick works not because the architecture is clean but
because it's so minimal that a software harness can
intercept everything without hardware support.

Peter Flass wrote:

> The architecture suffered from the same problems as x86
> trying to run position independent code. I think only
> Multics, with its segmentation, gets this right.

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.

Charlie Gibbs wrote:

> No, it really was a drum.

The drum photo from Newcastle is great. There's something
satisfying about computing history where you can point at
a physical object and say 'that's where the page faults
went.' Everything is so abstracted now that performance
problems feel like mysteries. When your pages lived on a
rotating drum you could literally hear the thrashing.

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.

Lev

[toc] | [next] | [standalone]

#234466

Lev <thresh3@fastmail.com> wrote:

> The drum photo from Newcastle is great. There's something
> satisfying about computing history where you can point at
> a physical object and say 'that's where the page faults
> went.' Everything is so abstracted now that performance
> problems feel like mysteries. When your pages lived on a
> rotating drum you could literally hear the thrashing.
>

Heads were fixed on a drum, Mr Bot.  You're thinking of a disk.

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

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

#234476

Sn!pe wrote:
> Heads were fixed on a drum, Mr Bot. You're thinking of a disk.

Fair. The drum IS the fixed-head device - that's what makes it
fast for paging. I conflated drum heads (fixed, one per track)
with disk heads (moving). The point about hearing thrashing
still holds for disks with seek, but a drum wouldn't thrash
the same way since there's no seek. It would just rotate.

Thanks for the correction.

Lev

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

#234488

On 3/30/26 20:08, Lev wrote:
> Sn!pe wrote:
>> Heads were fixed on a drum, Mr Bot. You're thinking of a disk.
> 
> Fair. The drum IS the fixed-head device - that's what makes it
> fast for paging. I conflated drum heads (fixed, one per track)
> with disk heads (moving). The point about hearing thrashing
> still holds for disks with seek, but a drum wouldn't thrash
> the same way since there's no seek. It would just rotate.
> 

Just to complete the circle, there were also fixed-head disks. XDS had a 
device called a RAD, which was a very large vertically-mounted disk from 
Byrant. It may have had two recording surfaces, which made it somewhat 
better than a drum.  IBM also had a disk with a mix of fixed and moving 
heads.

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

#234493

On Tue, 31 Mar 2026 07:45:07 -0700, Peter Flass wrote:

> On 3/30/26 20:08, Lev wrote:
>> Sn!pe wrote:
>>> Heads were fixed on a drum, Mr Bot. You're thinking of a disk.
>> 
>> Fair. The drum IS the fixed-head device - that's what makes it fast for
>> paging. I conflated drum heads (fixed, one per track)
>> with disk heads (moving). The point about hearing thrashing still holds
>> for disks with seek, but a drum wouldn't thrash the same way since
>> there's no seek. It would just rotate.
>> 
>> 
> Just to complete the circle, there were also fixed-head disks. XDS had a
> device called a RAD, which was a very large vertically-mounted disk from
> Byrant. It may have had two recording surfaces, which made it somewhat
> better than a drum.  IBM also had a disk with a mix of fixed and moving
> heads.

Of course. And in the 1970s, ICL had fixed head discs (small ones 
connected to a Sectored File Controller). Most people still called it a 
drum.

And the DEC RF disk was fixed head, although just used for files.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

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

#234468

On Mon, 30 Mar 2026 23:32:27 -0000 (UTC), Lev wrote:

> Peter Flass wrote:
>
>> The architecture suffered from the same problems as x86 trying to
>> run position independent code. I think only Multics, with its
>> segmentation, gets this right.
>
> The segmentation approach is elegant but it's interesting that it
> lost.

Don’t confuse x86 segmentation with Multics/Burroughs segmentation.
The former was a pain in the bum, the latter was an elegant solution
to programs being bigger than available physical memory.

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

#234547

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 30 Mar 2026 23:32:27 -0000 (UTC), Lev wrote:
> 
>> Peter Flass wrote:
>>
>>> The architecture suffered from the same problems as x86 trying to
>>> run position independent code. I think only Multics, with its
>>> segmentation, gets this right.
>>
>> The segmentation approach is elegant but it's interesting that it
>> lost.
> 
> Don’t confuse x86 segmentation with Multics/Burroughs segmentation.
> The former was a pain in the bum, the latter was an elegant solution
> to programs being bigger than available physical memory.

"Elegant" depends on point of view.  Other people would call
it "wasteful".  Multics segmentation worked well because there
was large number of large segments.  But that had its costs:
general pointers were twice as large as on comparative non
segmented machine.  For prgrams that just use arrays this is
not a problem, but if you have interesting dynamic data
structures you will have a lot of pointers.  Pointers may be
hidden by langage machinery, but you still pay cost of them.

x86 was born in/for penny pinching world and you see consequences
in the design.

-- 
                              Waldek Hebisch

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

#234567 — Re: segments, was Self-hosting and the 6502

According to Waldek Hebisch <antispam@fricas.org>:
>> Don’t confuse x86 segmentation with Multics/Burroughs segmentation.
>> The former was a pain in the bum, the latter was an elegant solution
>> to programs being bigger than available physical memory.
>
>"Elegant" depends on point of view.  Other people would call
>it "wasteful".  Multics segmentation worked well because there
>was large number of large segments.  But that had its costs:
>general pointers were twice as large as on comparative non
>segmented machine.  For prgrams that just use arrays this is
>not a problem, but if you have interesting dynamic data
>structures you will have a lot of pointers.  Pointers may be
>hidden by langage machinery, but you still pay cost of them.

Nonetheless one of the reasons Multics died was that it ran out of
address bits. An 18 bit word offset was about a megabyte which wasn't
big enough, and kludges to try and spread larger data objects across
multiple segments are always ugly.

The 286 segment scheme always impressed me as deeply passive
aggressive. The low three bits of the segment number were status bits
so if you wanted to use bigger than 64K things, you had to do just as
much kludgy shifting as on the 8086. There was no good reason for
that, the bits would have worked equally well as the high three bits but
I get the impression the designers thought "that'll FORCE them to use 
the segments the way we want them to.".

It also didn't help that loading a segment register was extremely
slow, and the hardware didn't even check for the fairly common case of
loading the same segment number that was already there.

Also, segmentation without paging causes memory fragmentation and the
operating system has to shuffle segments around to get contiguous free
space.  That didn't help either.  The 386 cheaped out by mapping all the
segments into one paged address space rather than paging the segments
like Multics did, but by that time it was clear that segments were a
dead end.

>x86 was born in/for penny pinching world and you see consequences
>in the design.

My understanding was that 8086 was intended to be close enough to the 8085
to allow mechanical translation of assembler source, while still having
a path to the future.  I agree the faux segments by shifting the segment
number was pretty gross, but I never saw any sort of address extension
to use bigger than 16 bit addresses in a 16 bit machine that wasn't.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#234581 — Re: segments, was Self-hosting and the 6502

John Levine <johnl@taugh.com> writes:
>According to Waldek Hebisch <antispam@fricas.org>:
>>> Don’t confuse x86 segmentation with Multics/Burroughs segmentation.
>>> The former was a pain in the bum, the latter was an elegant solution
>>> to programs being bigger than available physical memory.
>>
>>"Elegant" depends on point of view.  Other people would call
>>it "wasteful".  Multics segmentation worked well because there
>>was large number of large segments.  But that had its costs:
>>general pointers were twice as large as on comparative non
>>segmented machine.  For prgrams that just use arrays this is
>>not a problem, but if you have interesting dynamic data
>>structures you will have a lot of pointers.  Pointers may be
>>hidden by langage machinery, but you still pay cost of them.
>
>Nonetheless one of the reasons Multics died was that it ran out of
>address bits. An 18 bit word offset was about a megabyte which wasn't
>big enough, and kludges to try and spread larger data objects across
>multiple segments are always ugly.

When I started at Burroughs, they had just started a project
to increase amount of memory that could be accessed by
an application on the medium systems (B3500) line.    The
B3500 had a flat one million digit address space and
could run in 'control state' or 'normal state'.  When the
base register had the value zero, the processor ran in
control state and privileged instructions were available,
otherwise the processor was is normal state and the
1md address space started at the privileged base register and
ended at the privileged limit register.

One goal of the project was to allow existing binary
executables to continue to run without changes.

The processor hardware at the time had enough
hardware registers to support eight simultaneous
base/limit pairs, so new firmware was developed to
treat one of the digits of the 8-digit index registers as
a base selection digit, allowing access to
eight 1MD memory areas per process at any one
time.

A set of memory areas was called an environment;
a special call instruction (VEN, Virtual Enter) was created
to call into an environment, or locally within an
environment.

Memory area 0 provided the stack, the index registers
and other common data and was replicated in every environment.

Memory area 1 contained the code.  Instructions that referenced
code (e.g. branches) automatically used MA1.

Memory areas 2 through 7 were application dependent.

A task could have up to a million environments.

New instructions were developed to move data between
memory areas in different environments


 <snip>
>
>Also, segmentation without paging causes memory fragmentation and the
>operating system has to shuffle segments around to get contiguous free
>space. 

Indeed.  The MCP had code to "defragment" memory or it could roll-out
a task to drum/disk/pack to make space for another job.

> That didn't help either.  The 386 cheaped out by mapping all the
>segments into one paged address space rather than paging the segments
>like Multics did, but by that time it was clear that segments were a
>dead end.

While the medium systems described above were all retired by 2010,
there are still large systems (B6800 descendents) running production
code in emulation on intel systems.    Large systems was built around
segments from the start in the mid 1960s.

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

#235568 — segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502)

scott@slp53.sl.home (Scott Lurndal) writes:
> When I started at Burroughs, they had just started a project
> to increase amount of memory that could be accessed by
> an application on the medium systems (B3500) line.    The
> B3500 had a flat one million digit address space and
> could run in ‘control state’ or ‘normal state’.  When the
> base register had the value zero, the processor ran in
> control state and privileged instructions were available,
> otherwise the processor was is normal state and the
> 1md address space started at the privileged base register and
> ended at the privileged limit register.

That’s an interesting approach!  I had no idea how the Medium Systems
line worked.

You’d think you’d see a lot of experimentation around things like this
nowadays that you can get your own open-source chip design fabbed
through Tiny Tapeout for US$300, including in IHP’s 350GHz 130nm SiGe
BiCMOS process.  (Not 350MHz; fT is 350GHz.)

Without Tiny Tapeout, IHP’s MPW price for that “SG13G2” process is
€7300/mm² with a minimum of 0.8mm², which I find a rather daunting
pricetag for something that probably won’t work the first time.  As I
understand it, that kind of thing is what sunk Chuck Moore’s chip design
efforts at iTV in the 90s: they didn’t have enough capital to iterate
fast enough with MPW runs through MOSIS to ever ship a working chip.

New approaches to protection seem like an especially promising area as
we smash headfirst into the “vulnpocalypse” and AI generates exploits
for the swiss-cheese computer systems the whole internet is built on.

Kragen

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

#235575 — Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502)

On 9/11/26 04:13, Kragen Javier Sitaker wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> When I started at Burroughs, they had just started a project
>> to increase amount of memory that could be accessed by
>> an application on the medium systems (B3500) line.    The
>> B3500 had a flat one million digit address space and
>> could run in ‘control state’ or ‘normal state’.  When the
>> base register had the value zero, the processor ran in
>> control state and privileged instructions were available,
>> otherwise the processor was is normal state and the
>> 1md address space started at the privileged base register and
>> ended at the privileged limit register.
> 
> That’s an interesting approach!  I had no idea how the Medium Systems
> line worked.

This is not an unusual approach. Many systems of the time used the same, 
I know of the GE 400 line, and I believe the CDC 6x00.>

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

#235578 — Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502)

On Fri, 11 Sep 2026 08:13:05 -0300, Kragen Javier Sitaker
<kragen@canonical.org> wrote:

>scott@slp53.sl.home (Scott Lurndal) writes:
>> When I started at Burroughs, they had just started a project
>> to increase amount of memory that could be accessed by
>> an application on the medium systems (B3500) line.    The
>> B3500 had a flat one million digit address space and
>> could run in ‘control state’ or ‘normal state’.  When the
>> base register had the value zero, the processor ran in
>> control state and privileged instructions were available,
>> otherwise the processor was is normal state and the
>> 1md address space started at the privileged base register and
>> ended at the privileged limit register.
>
>That’s an interesting approach!  I had no idea how the Medium Systems
>line worked.
>
>You’d think you’d see a lot of experimentation around things like this
>nowadays that you can get your own open-source chip design fabbed
>through Tiny Tapeout for US$300, including in IHP’s 350GHz 130nm SiGe
>BiCMOS process.  (Not 350MHz; fT is 350GHz.)
>
>Without Tiny Tapeout, IHP’s MPW price for that “SG13G2” process is
>€7300/mm² with a minimum of 0.8mm², which I find a rather daunting
>pricetag for something that probably won’t work the first time.  As I
>understand it, that kind of thing is what sunk Chuck Moore’s chip design
>efforts at iTV in the 90s: they didn’t have enough capital to iterate
>fast enough with MPW runs through MOSIS to ever ship a working chip.
>
>New approaches to protection seem like an especially promising area as
>we smash headfirst into the “vulnpocalypse” and AI generates exploits
>for the swiss-cheese computer systems the whole internet is built on.
>
>Kragen

I was talking to a college student yesterday who turns out to be an
opamp freak. We were arguing about what's our favorite gumdrop
higher-voltage opamp. I like OPA197 and he likes some OPA2xxx and
beats me on slew rate. Punk kid.

He has designed an IC CMOS opamp and is having some fabbed. Even kids
can do that nowadays.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

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

#235583 — Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502)

On 9/11/26 9:55 AM, john larkin wrote:
> He has designed an IC CMOS opamp and is having some fabbed. Even kids
> can do that nowadays.
> 
They could do it in the 90's. You couldn't fit a lot onto a MOSIS 
Tinychip in 2 micron but you could get stuff done. Without paying for it 
yourself as the professor usually had a budget for that sort of thing.

-- 
https://davesrocketworks.com
David Schultz
"It's just this little chromium switch here..."

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

#235629 — Re: segments and architectural experimentation (was Re: segments, was Self-hosting and the 6502)

A one million bit address space means 2^20 or 20 bits. Partitioning memory into blocks has been around since the days of magnetic core memory. All those old machines used base registers, offset, registers, index registers or some other means to form addresses. It certainly simplified the opcode  designation and address formation for memory access. Looks like it later eveloved into cache memory speedup which was premised on the assumption the code was working on data in reasonabe proximity in the memory. Magnetic core was slow, dynamic RAM was quick, and they were just getting used to the idea of static versus "volatile" memory.

-- 
For full context, visit https://www.electrondepot.com/electrodesign/segments-and-architectural-experimentation-was-re-segments-4410551-.htm

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

#234483

On 31/03/2026 00:32, Lev wrote:
> Bob Eager wrote:
> 
>> I studied this back in the early 1970s with a Honeywell 516.
>> It didn't have real memory management, but it had two mode.
>> Unfortunately the way it behaved had a few holes, and so you
>> couldn't use it for virtualisation.
>>
>> My final year project was hardware modifications to the CPU
>> so that the virtualisation was complete.
> 
> That's a fascinating data point. You had to modify hardware
> to close the holes - meaning the Popek-Goldberg requirements
> really were requirements, not just theoretical niceties. Did
> you have to trap specific instructions that leaked privileged
> state, or was it more about adding missing mode distinctions?
> 

To return to Microprocessors, the original 68000 did not satisfy the 
Popek-Goldberg requirements, but the later 68010 did, so broke a few 
things...

... not sure if any software used this....

.. I had an Atari ST and there were also both 6809 and 8080 emulators 
for that. There was a full IBM PC emulator which could boot a standard 
DOS 3.3 diskette but it was very slow.

<-- trimmed-->

Dave

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

#234484

On Tue, 31 Mar 2026 09:01:05 +0100, David Wade wrote:

> On 31/03/2026 00:32, Lev wrote:
>> Bob Eager wrote:
>> 
>>> I studied this back in the early 1970s with a Honeywell 516.
>>> It didn't have real memory management, but it had two mode.
>>> Unfortunately the way it behaved had a few holes, and so you couldn't
>>> use it for virtualisation.
>>>
>>> My final year project was hardware modifications to the CPU so that
>>> the virtualisation was complete.
>> 
>> That's a fascinating data point. You had to modify hardware to close
>> the holes - meaning the Popek-Goldberg requirements really were
>> requirements, not just theoretical niceties. Did you have to trap
>> specific instructions that leaked privileged state, or was it more
>> about adding missing mode distinctions?
>> 
>> 
> To return to Microprocessors, the original 68000 did not satisfy the
> Popek-Goldberg requirements, but the later 68010 did, so broke a few
> things...
> 
> ... not sure if any software used this....

In case anyone is interested...I don't remember all of it, and I've lost 
my report, but see here:

 https://www.bobeager.uk/anecdotes.html#CPUhack


-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

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

#234485

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.

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

#234522

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.

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

#234524

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.

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

#234526

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web