On Wed, 13 Dec 2023 09:49:17 -0800, Lars Poulsen wrote:

> On 12/12/2023 3:46 PM, Scott Lurndal wrote:
>> That flat model, of course, predates linux by decades. Linus chose it
>> because it made sense. Segmented schemes have all been found lacking.
>
> Segmented schemes make sense in a context. In the early days of single
> job at a time, the context would be a language that could express
> segments as an embodiment of the semantics of that language. Later, in a
> multi-job environment, language semantics was just one aspect of memory
> management requirements, task/job separation was another.
> A "page" is a segment ... typically of a standardized size.

Pages and segments are not necessarily the same thing.

Some systems have/had both. Large segments (e.g. 256kB), each with
different properties (e.g. read ony, read/write, executable). The smaller
pages to split up each segment for use when implementing virtual memory;
pages all had the properties of the segment.

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

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

Lars Poulsen <lars@beagle-ears.com> wrote:
> On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> The '286 was mostly just a faster 8086. Its protected mode was brain
>> damaged.
>
> I used 80286 protected mode in an embedded project, and it was pretty
> wonderful. Our code was written in C, and we used a compiler that mated
> well with a "DOS Extender" to get beyond the 1MB limitations of the
> basic 8086 model. We hacked the "malloc()" to give us a new segment for
> each data structure, which gave us hardware bounds checking, which in
> turn gave us greatly accellerated debugging.
>
> I always felt that the Linux model of just a flat 32-bit address space
> was a big step backwards.

It’s the least common denominator, which is why Linux/Unix is easily
portable to so many diverse systems. The Multics model is much better, but
requires specialized hardware.

>
> 286 protected mode was not a full memory management system for a paging
> multiuser OS, but there was a use case where it worked VERY well.
>
>

--
Pete

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
> John Levine <johnl@taugh.com> wrote:
>
>> A big difference between the computing world now and back in the 1960s
>> and 1870s when people were designing segmented machines is that then
>> the important software was written in machine-specific assembler,
>> while now it's all in C or other languages which don't really care
>> about the underlying instruction set, although C and its decendants
>> have assumptions about byte addressed flat memory baked deep into them.
>
> C for the 286 was a horror story with multiple memory models and
> near and far pointers exposed in the source code.
>

When I first started looking at the architecture, I thought all the memory
models were just nuts.

--
Pete

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>Speaking as a Burroughs programmer who wrote portions of the MCP, I can't
>>agree with that. Our segmentation scheme was there simply
>>for backward compatability in the medium systems line.
>>
>>The large systems version lives on in Clearpath Libra for
>>backward compatability with applications built in the 1960s.
>>
>>There have been no new designs with segmentation for decades
>>and the effort to enhance the large systems
>>architecture and maintain compatability when E-mode was
>>added wasn't a simple exercise.
>
>I can believe it, but how much of that was because the segments were
>too small? My impression is that's what killed all the segmented
>architectures, and by the time you came up with a segment scheme with
>bigger addresses, you might as well just adopt a generic flat address
>and use all the free software that supports it.

Certainly segment _size_ was an important constraint. Before we
revamped the medium systems architecture, a task/job/process was
limited to 500 kilobytes of memory (1 million digits). The
segmentation scheme that we added, for backward compatability,
couldn't support more than a million digits without significant
changes to the instruction set (which had 6-digit address operands);
so segmentation was the only way to maintain backward compatability
and preserve the ability to execute 1965 binaries without performance
killing emulation.

Adding paging within a segment, to ameliorate the pain of memory
fragmentation wasn't really possible at the time.

>
>>>Oh, and Linux chose flat addressing because linux is a copy of Unix
>>>and Unix grew up on Vaxes with flat memory. It made sense only in that
>>>it made sense to copy the memory model along with everything else.
>>
>>Unix grew up on the PDP-11 with fixed segment sizes.
>
>I was there and not really. On the 11/45 and 11/70 you got 64K of

I was there using v6 on an 11/34. Granted, never had a chance
to use the 11/70, but heavily used the 11/780 (loved it!). Our
11/44 ran custom software acting as a terminal controller.

>instruction space and 64K of data space. The hardware divided each
>into eight 8K pages but they were too big to be useful so each segment
>was always contiguous and could be from 8K to 64K in 8K increments.
>When Berkeley moved BSD to the Vax we all moved there and didn't look
>back.

I played a bit with the 32-bit WE Unix on the /780 on weekends, but we
always ran VMS in production. The earliest versions of VMS
we were using still used some RSX-11 utilities running in
compatability mode. Never used BSD.

>The Vax's paging enabled shared libraries and mapped files and
>much larger programs on 4BSD. That's where all modern Unix
>and linux trace back to, even though some of them do so
>by merging the good bits of BSD into other varieties like
>System V.

We were working with AT&T/USL during the SVR4 development
when the BSD stuff was merged in. A large part of that was
user-level stuff, but it also included job-control and
iirc resource limit controls in the kernel itself.

According to Scott Lurndal <slp53@pacbell.net>:
>>I was there and not really. On the 11/45 and 11/70 you got 64K of
>
>I was there using v6 on an 11/34. Granted, never had a chance
>to use the 11/70, but heavily used the 11/780 (loved it!). Our
>11/44 ran custom software acting as a terminal controller.
>
>>instruction space and 64K of data space. The hardware divided each
>>into eight 8K pages but they were too big to be useful so each segment
>>was always contiguous and could be from 8K to 64K in 8K increments.

At Yale we had an 11/45 with an aftermarket cache that made it nearly
as fast as an 11/70. We also built some of the first bitmapped
terminals, using giant state of the art 2K RAMs. There were 16
terminals each with 32K bytes of memory that could be mapped into both
the 11/45's address space and an adjacent 11/05 that ran a terminal
emulator. The first thing I did was to let you map your terminal
memory into the top half of the data space which was fast but losing
half of your address space was painful.

Then I noticed that the 11/45 had a third supervisor mode intended
between user and kernel with its own address space. Unix didn't use
it, so I mapped the screen memory into supervisor space, set the
program status so that for user programs the supervisor was the
"previous" mode, and then could use hardware move to/from previous
space instructions. The C compiler didn't generate those so we had
some little assembler routines to manage screen memory. It worked
great, the undergrads wasted tons of time writing screen hackery.

--
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

On 2023-12-13, Peter Flass <peter_flass@yahoo.com> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>> John Levine <johnl@taugh.com> wrote:
>>
>>> A big difference between the computing world now and back in the 1960s
>>> and 1870s when people were designing segmented machines is that then
>>> the important software was written in machine-specific assembler,
>>> while now it's all in C or other languages which don't really care
>>> about the underlying instruction set, although C and its decendants
>>> have assumptions about byte addressed flat memory baked deep into them.
>>
>> C for the 286 was a horror story with multiple memory models and
>> near and far pointers exposed in the source code.
>
> When I first started looking at the architecture, I thought all the memory
> models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:
>>> C for the 286 was a horror story with multiple memory models and
>>> near and far pointers exposed in the source code.

Yup, that's a consequence of the segments being too slow and too
small. On a more sensible segmented archiecture you could
put every allocated chunk of storage in a segment and the static
stuff in another segment so it's all be handled by the compiler.

>> When I first started looking at the architecture, I thought all the memory
>> models were just nuts.
>
>Yeah, too bad the Motorola 68000 arrived just a bit too late.

The 68000 was there. But when IBM was designing the IBM PC and they
decided at the last minute to move to a 16 bit chip while keeping the
8 bit memory and peripherals, the 8088 was available in quantity but
the 68008 was just samples. So here we are.

--
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

On 14 Dec 2023 at 21:52:06, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2023-12-13, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>
>>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>>> John Levine <johnl@taugh.com> wrote:
>>>
>>>> A big difference between the computing world now and back in the 1960s
>>>> and 1870s when people were designing segmented machines is that then
>>>> the important software was written in machine-specific assembler,
>>>> while now it's all in C or other languages which don't really care
>>>> about the underlying instruction set, although C and its decendants
>>>> have assumptions about byte addressed flat memory baked deep into them.
>>>
>>> C for the 286 was a horror story with multiple memory models and
>>> near and far pointers exposed in the source code.
>>
>> When I first started looking at the architecture, I thought all the memory
>> models were just nuts.
>
> Yeah, too bad the Motorola 68000 arrived just a bit too late.

I liked the Texas 9900 instruction set.

On Fri, 15 Dec 2023 07:22:33 +0000, Bob Martin wrote:

> On 14 Dec 2023 at 21:52:06, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>> On 2023-12-13, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>
>>>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>>>> John Levine <johnl@taugh.com> wrote:
>>>>
>>>>> A big difference between the computing world now and back in the
>>>>> 1960s and 1870s when people were designing segmented machines is
>>>>> that then the important software was written in machine-specific
>>>>> assembler, while now it's all in C or other languages which don't
>>>>> really care about the underlying instruction set, although C and its
>>>>> decendants have assumptions about byte addressed flat memory baked
>>>>> deep into them.
>>>>
>>>> C for the 286 was a horror story with multiple memory models and
>>>> near and far pointers exposed in the source code.
>>>
>>> When I first started looking at the architecture, I thought all the
>>> memory models were just nuts.
>>
>> Yeah, too bad the Motorola 68000 arrived just a bit too late.
>
> I liked the Texas 9900 instruction set.

My favourite is the ICL 2900 instruction set - loosely based on the
Manchester MU5. Great for compiler writers.

http://www.ancientgeek.org.uk/ICL/The_ICL_2900_Series.pdf

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

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

On 15 Dec 2023 07:22:33 GMT
Bob Martin <bob.martin@excite.com> wrote:

> I liked the Texas 9900 instruction set.

Yes it was nice - the chip itself somewhat less so.

There was a 9900 based machine being built by a fellow student when
I was at college. The board was built, the wiring tested, all the other
components were in their sockets the time had come to put that 0.9" wide
sixty four pin ceramic packaged processor into its socket - many members of
the university processor group (student club) were present to watch ...

It really did not want to go in - not because the legs were splayed,
it was a ceramic package with straight legs. Instead it provided an object
lesson in the meaning of the term insertion force. In the end padded
support went under the board while the precious processor was tapped into
its socket with the aid of a small rubber mallet.

I stopped wanting to build one.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Bob Martin <bob.martin@excite.com> writes:
>On 14 Dec 2023 at 21:52:06, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2023-12-13, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>>>
>>>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>>>> John Levine <johnl@taugh.com> wrote:
>>>>
>>>>> A big difference between the computing world now and back in the 1960s
>>>>> and 1870s when people were designing segmented machines is that then
>>>>> the important software was written in machine-specific assembler,
>>>>> while now it's all in C or other languages which don't really care
>>>>> about the underlying instruction set, although C and its decendants
>>>>> have assumptions about byte addressed flat memory baked deep into them.
>>>>
>>>> C for the 286 was a horror story with multiple memory models and
>>>> near and far pointers exposed in the source code.
>>>
>>> When I first started looking at the architecture, I thought all the memory
>>> models were just nuts.
>>
>> Yeah, too bad the Motorola 68000 arrived just a bit too late.
>
>I liked the Texas 9900 instruction set.

The Burroughs medium systems instruction set was a joy to
work with. It was BCD, so one never needed to convert
between decimal and hex, or decimal and octal.

The instruction set basically mapped 1-1 to COBOL verbs.

COMPUTE HQ1 = (B - 1) / 14 + 1. 526 CARD 1 65428
01 065428 MVN 11A103 100000 100336 CODE
01 065446 MVN 110303 217556 100340 CODE
01 065464 DEC 030303 100336 100340 CODE
01 065482 MVN 110306 100340 100344 CODE
01 065500 MVN 11A115 000000 000351 CODE
01 065518 MVN 11A119 000000 100366 CODE
01 065536 DIV 06A221 140000 100344 100366 CODE
01 065560 MVN 11A105 100000 100386 CODE
01 065578 MVN 11A115 000000 000392 CODE
01 065596 INC 011920 100366 100386 CODE
01 065614 MVN 110101 000391 217452 CODE

INSPECT COURSE-B REPLACING ALL " " BY ZEROS. 531 CARD 1 65864
01 065864 MVN 110607 000774 100008 CODE
01 065882 SEA 39B101 400000 600000 050384 CODE
01 065906 NEQ 25 0C065962 CODE
01 065916 MVA 10A202 F0F0F0 400000 CODE
01 065934 INC 01A107 200000 100008 CODE
01 065952 BUN 27 0C065882 CODE

On 2023-12-15, John Levine <johnl@taugh.com> wrote:

> According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:
>
>>>> C for the 286 was a horror story with multiple memory models and
>>>> near and far pointers exposed in the source code.
>
> Yup, that's a consequence of the segments being too slow and too
> small. On a more sensible segmented archiecture you could
> put every allocated chunk of storage in a segment and the static
> stuff in another segment so it's all be handled by the compiler.
>
>>> When I first started looking at the architecture, I thought all the memory
>>> models were just nuts.
>>
>> Yeah, too bad the Motorola 68000 arrived just a bit too late.
>
> The 68000 was there. But when IBM was designing the IBM PC and they
> decided at the last minute to move to a 16 bit chip while keeping the
> 8 bit memory and peripherals, the 8088 was available in quantity but
> the 68008 was just samples. So here we are.

You're right, I should have said 68008.

Someone once said, "Isn't it fortunate that the iAPX432 flopped?
Otherwise some horrible Intel architecture might have taken over
the world."

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On 15/12/2023 09:18, Bob Eager wrote:
> My favourite is the ICL 2900 instruction set - loosely based on the
> Manchester MU5. Great for compiler writers.

That's the first machine I used professionally. I quite liked the
DECsystem10 we had at Uni.

I went from the 2900 to an Intel 8085. Yuck. I spent quite a lot of my
career with 8085/8086/286 (yes, occasionally in protected mode), 386...
- and I never liked any of them.

More recently I used ARM chips, and TBH I don't really know what they
are like. I never needed to, they are fast enough without needing assembler.

Andy

On Fri, 15 Dec 2023 21:22:57 +0000, Vir Campestris wrote:

> On 15/12/2023 09:18, Bob Eager wrote:
>> My favourite is the ICL 2900 instruction set - loosely based on the
>> Manchester MU5. Great for compiler writers.
>
> That's the first machine I used professionally. I quite liked the
> DECsystem10 we had at Uni.

I used a PDP-10 (it was an old KA-10, and was never known as a
DECsystem-10) for a year. Hoping to build a replica soon.

> I went from the 2900 to an Intel 8085. Yuck. I spent quite a lot of my
> career with 8085/8086/286 (yes, occasionally in protected mode), 386...
> - and I never liked any of them.

My next was a Z80, then VAX, then 8086. I'd done PDP-11 long before.

> More recently I used ARM chips, and TBH I don't really know what they
> are like. I never needed to, they are fast enough without needing
> assembler.

I only really looked at instruction sets in the context of writing
compilers.

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

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

John Levine <johnl@taugh.com> schrieb:
> According to Scott Lurndal <slp53@pacbell.net>:

> Architectures of any kind die for two reasons: they run out of address
> bits, the vandor can't make them competitively fast, or both.

Market share also plays a large role. Large number of systems sold
can support large development teams, which have the resources to
make them better.

And for this, a large software base plays a huge role, hence x86
and the "synergies" between Microsoft and Intel.

On 2023-12-17, Thomas Koenig <tkoenig@netcologne.de> wrote:

> John Levine <johnl@taugh.com> schrieb:
>
>> Architectures of any kind die for two reasons: they run out of address
>> bits, the vandor can't make them competitively fast, or both.
>
> Market share also plays a large role. Large number of systems sold
> can support large development teams, which have the resources to
> make them better.
>
> And for this, a large software base plays a huge role, hence x86
> and the "synergies" between Microsoft and Intel.

As I always used to say,

The only reason everybody uses COBOL is that everybody uses COBOL.

--
/~\ Charlie Gibbs | Life is perverse.
\ / <cgibbs@kltpzyxm.invalid> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin