On 2023-11-29, Sn!pe <snipeco.2@gmail.com> wrote:

> 'm/c' for 'machine' was standard usage in the late '60s - early '70s;

In some circles, perhaps, but I never saw it.

> I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

I can see some bored etymologist digging into the origins of this
slash notation. It appears in several fields.

Can't fly today, the A/C is U/S.

--
/~\ 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.

Sn!pe <snipeco.2@gmail.com> wrote:
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> On 28/11/2023 21:17, Andy Walker wrote:
>>> On 28/11/2023 16:15, Scott Lurndal wrote:
>>> [I wrote:]
>>>>> [...] I started with Atlas [apart from a brief go with
>>>>> Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].
>>>> Have you considered donating that to one of the museums (such as CHM?)
>>>
>>> Yes, but it's not in usable form and I have no great inclination to
>>> spend my declining years writing it up. The offer of GBP 10^6 or so
>>> might perhaps, but probably wouldn't, change my mind. The Computer
>>> Conservation Society already has a copy of the Atlas O/S, I believe.
>>>
>>> Atlas was a brilliant machine, with an innovative architecture and
>>> machine code, but the assembler [ABL] was execrable [though ingenious].
>>> You had to learn all the numbers for instructions; very few symbolics.
>>>
>>>> m/c must be a British abbreviation for something...
>>>
>>> Surely they have motor cycles in Left-Pondia? Not to be confused
>>> with M/cr, which is Manchester; nor with mc, which is a hammer.
>>>
>>> [Vir C:]
>>
>> It wasn't me that wrote m/c. But I have seen it used for machine. Not
>> recently though I think.
>
> [...]
>
> 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
> I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
>

Lemme guess - “tits up.”

--
Pete

Scott Lurndal <scott@slp53.sl.home> wrote:
> jgd@cix.co.uk (John Dallman) writes:
>> In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@kltpzyxm.invalid
>> (Charlie Gibbs) wrote:
>>> On 2023-11-28, Andy Walker <anw@cuboid.co.uk> wrote:
>>>> Yes, but how many programmers get to worry about such things? If
>>>> a compiler produces an executable that "doesn't work", it's dealt
>>>> with by the compiler writers rather than by the "higher-level"
>>>> program writers.
>>>
>>> Sometimes. On the other hand, if you have a compiler that's
>>> generating bad code in a program that you need yesterday, you
>>> might have to change your code to something equivalent which
>>> compiles successfully.
>>
>> And if you need to report compiler bugs, being able to point to exactly
>> what's wrong in the generated code means your bugs get fixed /much/
>> faster.
>
> And it may not even be a compiler bug, but a simple programming
> error. Stepping through the generated assembler with a debugger
> can be quite useful.
>

Being a user of my own compiler is where it gets interesting. One of the
first things I learned was “don’t blame the compiler”, at least until
there’s no other possibility. Now I’ll blame the compiler first, and spend
quite a bit of time, only to find out it’s my own application error.

--
Pete

Scott Lurndal <scott@slp53.sl.home> wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>> On 29/11/2023 09:44, John Dallman wrote:
>>> In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@kltpzyxm.invalid
>>> (Charlie Gibbs) wrote:
>> [I wrote:]
>>>>> Yes, but how many programmers get to worry about such things? If
>>>>> a compiler produces an executable that "doesn't work", it's dealt
>>>>> with by the compiler writers rather than by the "higher-level"
>>>>> program writers.
>>>> Sometimes. On the other hand, if you have a compiler that's
>>>> generating bad code in a program that you need yesterday, you
>>>> might have to change your code to something equivalent which
>>>> compiles successfully. BTDTGTS.
>>
>> Well, likewise. But [normally] that's a problem of re-writing
>> your program [and/or perhaps, eg, switching off aggressive optimisation]
>> rather than delving into the generated assembler. Anything else is even
>> more niche than the cases described earlier.
>
> It's much quicker, particularly in a very large application, to
> either debug post failure (e.g. SIGSEGV) with a good debugger
> in which case knowing the assembler is useful, or to set a breakpoint
> and step through the instruction sequence to see exactly what is
> happening. I've done this many times over the last four decades
> on systems from mainframes to microcontrollers. Most recently,
> this morning to debug a SIGSEGV in a C++ application.

Some days I practically live in the debugger.

>
>>
>>> And if you need to report compiler bugs, being able to point to exactly
>>> what's wrong in the generated code means your bugs get fixed /much/
>>> faster.
>> Yes, but since the 1980s the chances are that the "generated code"
>> is C or similar rather than assembler.
>
> I absolutely disagree with this statement. I haven't used a compiler
> that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
> any modern compiler (from Ada to Python) that generates intermediate
> C code.
>

I believe gcc has some type of fairly well-defined intermediate code. Some
compilers compile to this and use gcc’s back end to generate machine code.

> And as someone who has extensive experience debugging cfront (the
> original C++ compiler which generated C), the resulting C code
> is completely unreadable and hardly useful for debugging application
> code. I had to debug a register allocation issue with the underlying
> C compiler used to compile the output from cfront once, and the
> internal expression tree for the failed expression had five levels
> with dozens of terms. The issue was that the C compiler (for the
> motorola 88100, based on PCC) ran out of temporary registers when generating
> code for the expression.
>

--
Pete

On Wed, 29 Nov 2023 12:07:19 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Sn!pe <snipeco.2@gmail.com> wrote:

> > 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
> > I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
> >
>
> Lemme guess - “tits up.”

Of course - but then I thought m/c was well known too.

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

Ahem A Rivet's Shot <steveo@eircom.net> writes:
>On Wed, 29 Nov 2023 12:07:19 -0700
>Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Sn!pe <snipeco.2@gmail.com> wrote:
>
>> > 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
>> > I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
>> >
>>
>> Lemme guess - “tits up.”
>
>Of course - but then I thought m/c was well known too.

T/U is rather obvious (it is two words, after all),
m/c less so, although machine was my first guess.

I've notice that some british english words are often
not phonetically related to the actual pronunciation
(e.g. lester square :-).

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:

>> I absolutely disagree with this statement. I haven't used a compiler
>> that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
>> any modern compiler (from Ada to Python) that generates intermediate
>> C code.
>>
>
>I believe gcc has some type of fairly well-defined intermediate code.

In a manner of speaking, yes. It's not something the user will ever
see or need to debug, however.

>Some
>compilers compile to this and use gcc’s back end to generate machine code.

LLVM is the poster child for this, although gcc has had a more primitive
form for a couple decades.

According to Peter Flass <peter_flass@yahoo.com>:
>>> It wasn't me that wrote m/c. But I have seen it used for machine. Not
>>> recently though I think.
>>
>> [...]
>>
>> 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
>> I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
>>
>
>Lemme guess - “tits up.”

Temporarily Unavailable, of course. What else would it stand for?

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

John Levine <johnl@taugh.com> wrote:

> According to Peter Flass <peter_flass@yahoo.com>:
> >>> It wasn't me that wrote m/c. But I have seen it used for machine. Not
> >>> recently though I think.
> >>
> >> [...]
> >>
> >> 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
> >> I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
> >>
> >
> >Lemme guess - ╲tits up.╡
> >
>
> Temporarily Unavailable, of course. What else would it stand for?
>

≈:o)

--
^Ï^. Sn!pe, PA, FIBS - Professional Crastinator.
My pet rock Gordon just is.

Google Groups articles not seen here unless poster is whitelisted.

On Wed, 29 Nov 2023 21:44:16 +0000, Scott Lurndal wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter_flass@yahoo.com>
>>wrote:
>>
>>> Sn!pe <snipeco.2@gmail.com> wrote:
>>
>>> > 'm/c' for 'machine' was standard usage in the late '60s - early
>>> > '70s;
>>> > I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
>>> >
>>> >
>>> Lemme guess - “tits up.”
>>
>>Of course - but then I thought m/c was well known too.
>
> T/U is rather obvious (it is two words, after all), m/c less so,
> although machine was my first guess.
>
> I've notice that some british english words are often not phonetically
> related to the actual pronunciation (e.g. lester square :-).

We have two villages near here, both named Goodnestone.

They have two totally different pronunciations. One is Good-nes-stone. The
other is Gun-stone.

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

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

On 29 Nov 2023 at 22:54:50, Bob Eager <news0009@eager.cx> wrote:
> On Wed, 29 Nov 2023 21:44:16 +0000, Scott Lurndal wrote:
>
>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>>On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter_flass@yahoo.com>
>>>wrote:
>>>
>>>> Sn!pe <snipeco.2@gmail.com> wrote:
>>>
>>>> > 'm/c' for 'machine' was standard usage in the late '60s - early
>>>> > '70s;
>>>> > I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
>>>> >
>>>> >
>>>> Lemme guess - “tits up.”
>>>
>>>Of course - but then I thought m/c was well known too.
>>
>> T/U is rather obvious (it is two words, after all), m/c less so,
>> although machine was my first guess.
>>
>> I've notice that some british english words are often not phonetically
>> related to the actual pronunciation (e.g. lester square :-).
>
> We have two villages near here, both named Goodnestone.
>
> They have two totally different pronunciations. One is Good-nes-stone. The
> other is Gun-stone.

Same thing round here, with Bosham (pronounced Bozz'm) and Cosham (Cosh'm)

(Bosham is where King Canute had a palace).

On 29/11/2023 19:07, Peter Flass wrote:
> Some days I practically live in the debugger.

I retired last year. I could afford it, and my time isn't infinite.

There was no point in me learning about the future developments, so I
spent the last six months or so looking at the most common crashes in
the dumps our system collects from end users. (it's an embedded system
with a net connection) I often had to poke about in the assembly,
sometimes the optimiser does weird things.

BUT... if you're doing standard apps development I doubt you'll need to
do that often.

I was gratified that the last fix I ever submitted as a professional got
this comment from the guy who wrote the code: "Oh, THAT'S what's going
on" :)

Andy

On 28/11/2023 15:06, Scott Lurndal wrote:

> Worth mentioning more about the 80186. It incorporated a few extra
> instructions, but nothing very major.
>
> Principally, the reason for it was that it was a single chip solution (the
> 8086 required about 5 chips, as I recall). The 80186 incorporated the
> interrupt controller, DMA controller, etc. It was however (at the OS
> level) incompatible with the 8086.

My first PC was a XT clone (Olivetti Prodest PC1), and it had a 80188
clone: the NEC V40.

According to the wikipedia, it integrated a compatible 8251 USART, 8253
PIT and 8255 PPI.

On Fri, 01 Dec 2023 07:35:39 +0000, Juan wrote:

> On 28/11/2023 15:06, Scott Lurndal wrote:
>
>> Worth mentioning more about the 80186. It incorporated a few extra
>> instructions, but nothing very major.
>>
>> Principally, the reason for it was that it was a single chip solution
>> (the 8086 required about 5 chips, as I recall). The 80186 incorporated
>> the interrupt controller, DMA controller, etc. It was however (at the
>> OS level) incompatible with the 8086.
>
> My first PC was a XT clone (Olivetti Prodest PC1), and it had a 80188
> clone: the NEC V40.
>
> According to the wikipedia, it integrated a compatible 8251 USART, 8253
> PIT and 8255 PPI.

It also presumably had the barrel shifter from the V20/V30 8088/8086
equivalents, which improved multiply speed.

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

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

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.

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.

According to Lars Poulsen <lars@beagle-ears.com>:
>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.

There were two problems with 286 protected mode. One was that anything
that loaded a segment register was extremely slow, and the other was
that if you had any data structures bigger than 64K, you lose. Intel
went out of their way to make it miserable to use several segments for
one object by using three lowest bits of the segment number for status
stuff so consecutive segments would be 0, 8, 16 or maybe 3, 11, 19.

If you were willing to take the segment load performance hit and your
data all fit in 64K chunks, protected mode was fine.

The 386 mostly fixed the segment size problem but not the slow loads,
but by then nobody cared.

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

Lars Poulsen <lars@beagle-ears.com> writes:
>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

That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found
lacking.

According to Scott Lurndal <slp53@pacbell.net>:
>>I always felt that the Linux model of just a flat 32-bit address space
>>was a big step backwards
>
>That flat model, of course, predates linux by decades. Linus chose it
>because it made sense. Segmented schemes have all been found
>lacking.

Not really. Programmers loved the Burroughs mainframes with segmented
memory and a stack. They live on as Unisys Clearpath although Unisys
gave up building CPUs and now just runs an emulator on an x86. And
there are still plenty of people who say Multics was the best system
they ever used.

Architectures of any kind die for two reasons: they run out of address
bits, the vandor can't make them competitively fast, or both. As I
said a few messages back, the 286 suffered from both of those, loading
the segment registers was very slow, and the 64K segments were too
small.

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.

If we'd ended up using something like Pascal or PL/I with stronger
pointer typing, segmented machines would still be plausible.

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.

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

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

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>I always felt that the Linux model of just a flat 32-bit address space
>>>was a big step backwards
>>
>>That flat model, of course, predates linux by decades. Linus chose it
>>because it made sense. Segmented schemes have all been found
>>lacking.
>
>Not really. Programmers loved the Burroughs mainframes with segmented
>memory and a stack. They live on as Unisys Clearpath although Unisys
>gave up building CPUs and now just runs an emulator on an x86. And
>there are still plenty of people who say Multics was the best system
>they ever used.

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.

>
>Architectures of any kind die for two reasons: they run out of address
>bits, the vandor can't make them competitively fast, or both. As I
>said a few messages back, the 286 suffered from both of those, loading
>the segment registers was very slow, and the 64K segments were too
>small.
>
>A big difference between the computing world now and back in the 1960s
>and 1870s when people were designing segmented machines is that then

Who was designing memory subsystems in the 1870s? :-)

>If we'd ended up using something like Pascal or PL/I with stronger
>pointer typing, segmented machines would still be plausible.

No, they have all the shortcomings of segmentation (limiting
data structure size and physical memory checkerboarding when
not combined with some form of paging within the segment).

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

On 2023-12-13, Scott Lurndal <scott@slp53.sl.home> wrote:

> John Levine <johnl@taugh.com> writes:

>> A big difference between the computing world now and back in the 1960s
>> and 1870s when people were designing segmented machines is that then
>
> Who was designing memory subsystems in the 1870s? :-)

Charles Babbage?

--
/~\ 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 2023-12-13, 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.

In other words, a nightmare that continued from the mess that started
on the 8086/8. I shudder when I remember the hoops I had to jump
through when writing MS-DOS programs that accessed tables bigger
than 64K. Segment wrap-around, far pointer normalization to work
around it... blech!

--
/~\ 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 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.

At the time of this transition, languages were mostly locked in, and
most of them did not have semantics that could generalize to segments,
while paging of virtual memories that were larger than physical memories
simplified things a lot. So the physical memory was managed in segments
called pages, while the virtual memory became flat address space. And
soon it became hard to think of anything different.

Once the "reference model" was C and Unix, it seems nothing else could
get traction.

On Wed, 13 Dec 2023 17:25:19 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> On 2023-12-13, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
> > C for the 286 was a horror story with multiple memory models and
> > near and far pointers exposed in the source code.
>
> In other words, a nightmare that continued from the mess that started
> on the 8086/8.

Yep with added hardware protection.

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

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.

>>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
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 was the first person to try running BSD on an 11/750 which
was painful because it had a micrcode bug that made an instruction in
the inner loop of printf() fail. I had just finished getting a hosted
cross-building environment going on our 11/45 at Yale when Bill Joy
noticed the same thing at Berkeley, patched around the instruction and
rebuilt it on his 11/780 so that's what we used.)

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.

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