[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

On Thu, Dec 8, 2016 at 5:39 AM, Joerg Schilling <schily at schily.net> wrote:

> Back to the Bourne Shell:
>
> The original Bourne Shell did not use malloc, but rather had a SIGSEGV
> handler
> that used to extend the "string stack" called "stak" via sbrk() whenever
> the
> code tried to access data beyond the end ot the heap.
>

​Right although the 68K was not the first or the only system to have that
problem - again IIRC Series/1 and maybe one of the PE systems.  You are
correct then SunOS and >>some<< of the 68000 based system did have the
problem you suggested.  And in fact, Masscomp (and Apollo) which used
68000's (but used two of them so could run full VM) could survive that
style of fault (because it never occurred).

BTW: the "conceptual problem" , you mentioned while true, is being a little
harsh.   As the one of the 68K designers (Les Crudele) said to me once,
when they wrote the microcode, there were not thinking about instruction
restart - so the issue was that Nick did not save enough state to do it.

The model for the 68000 that they were using was the base/limit PDP-11 and
the original PDP-10.  Also at the time, the competition was the 6800, the
8080, Z80, 6502.   They were trying to put a PDP-11/70 on chip (without
getting into trouble like CalData did - which Les, Nick and team were very
aware having been DEC and CalData customers before they were at Moto].
While we think of the 68000 family has being 32 bit, the fact is inside it
is a 16 bit system (the barrel shifter and execution functions are 16).
And it was a skunk works project -- the 6809 was Moto's real processor.
It was an experiment done by a couple of rogue engineers that said - hey we
can do better,   The fact was they made a chip that was good enough to
actually compete with the Vax in the end, because it was fast enough AND
they had the wisdom to define 32 bits of address space and 32 bit
operations (again having been PDP-11 users), but as Les used to say - part
of the thinking was that while DEC was moving to the Vax, they had hoped to
break into the area that they 16 bits minis claimed - which they in-fact
did.

And if you think in terms of a Clay Christensen's disruption theory, the
fact that VM did not work easily (i.e. was a "worse" technology than the
Vax) was ok - a new breed of customer did not care.  68000 was huge
success, despite Moto marketing ;-)

To me the larger issue with the 68010 was that when Nick did add the
restart microcode, the new '10 microcode actually dumped version dependant
state on the external stack (in Intel terminology -different "step" '10 put
different state on the external stack or worse, could not restart an
instruction that had been saved from a different step processor).

This screw up was a huge issue when we did replaced the "executor" with a
68010, because it meant that all cpu boards had to be the same processor
microcode revision. Masscomp was of course the first to make an MP, so was
the the first firm to run into the issue (I remember debugging it - we
could not reproduce the issue because of course tjt and my own machine's by
chance had "MPU" boards as we called them with the same step -- it was one
of the field service guys that realized that the customer system had a
mixed step board -- i.e. when they replaced a single MPU in the field, the
system stopped working).  IIRC:  Moto never fixed the '10, as that
processor was reasonably short lived in the open market.   They did fix the
microcode in the '20 so the state on the external stack was independent of
stepping.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161208/a7a937ff/attachment.html>

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]



The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
that used to extend the "string stack" called "stak" via sbrk() whenever the
code tried to access data beyond the end ot the heap.

 

The V6 (Mashey) shell did that.   I thought they’d gotten rid of that by the time the Bourne Shell rolled around.

 

When we ported  UNIX to the Denelcor HEP supercomputer, we had only a single base-offset segment (albeit 64 bits).   The data and stack were allocated from that.   In fact, the “stack” was a linked list.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20161208/ac89eaee/attachment.html>

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[Chet Ramey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On 12/8/16 11:38 AM, Ron Natalie wrote:
> /
> 
> The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
> that used to extend the "string stack" called "stak" via sbrk() whenever the
> code tried to access data beyond the end ot the heap./
> 
> / /
> 
> The V6 (Mashey) shell did that.   I thought they’d gotten rid of that by
> the time the Bourne Shell rolled around.

That was one of the changes Bourne made during the deliberations over
which shell would be the Unix "standard" for Bell Labs.  It was always
an efficiency hack, meant to address Mashey shell user concerns about
performance.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

Chet Ramey <chet.ramey at case.edu> wrote:

> On 12/8/16 11:38 AM, Ron Natalie wrote:
> > /
> > 
> > The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
> > that used to extend the "string stack" called "stak" via sbrk() whenever the
> > code tried to access data beyond the end ot the heap./
> > 
> > / /
> > 
> > The V6 (Mashey) shell did that.   I thought they???d gotten rid of that by
> > the time the Bourne Shell rolled around.

Do you like to say that the Mashey shell also used the string stack and a 
SIGSEV handler?

Well, from a talk from Stephen Bourne I know that both the Bourne Shell and the 
Mashey shell did start as a modified Thompson shell. I should have a look at the
Thompson shell sources...

> That was one of the changes Bourne made during the deliberations over
> which shell would be the Unix "standard" for Bell Labs.  It was always
> an efficiency hack, meant to address Mashey shell user concerns about
> performance.

I am not sure whether this kind of SIGSEGV based string handling helps to have 
a good performance. Having a string stack (regardless of what the low level 
part of the implementation looks like) definitely helps. I am using a similar
technique in my "smake" program and it turns out that the concept of a string
stack is helpful when you write software that needs to create many 
intermediate string copies of unpredictable length.

What I definitely know is that replacing the low level support code from 
Stephen Bourne (stak.c) with an implementation based on the ideas from Geoff 
Collyer did not affect the performance of the Bourne Shell.

The Korn shell did introduce something similar (maybe even also from Geoff 
Collyer with ksh88) and ksh93 is the fastest known shell implementation if it 
is compiled the way, it is in the OpenSolaris integration of the Solaris "ON"
code base.

For today, numbers definitely look different. 30% of the total amount of CPU 
time spend by the Bourne Shell is spend by the conversion from multy-byte 
strings to wide strings and vice versa. BTW: "dash" is faster than bash just 
because it does not imlement multy-byte support. If it did, it would become 
slower than bash.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[Paul Ruizendaal]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]


> Do you like to say that the Mashey shell also used the string stack and a 
> SIGSEV handler?
Don't think it did: http://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s2/sh.c

> Well, from a talk from Stephen Bourne I know that both the Bourne Shell and the 
> Mashey shell did start as a modified Thompson shell. I should have a look at the
> Thompson shell sources…
Also did not: http://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/sh.c

[TUHS] Moto and MMU issues -- was Unix & Memory Management Units (MMU)

[arnold]

Getting a bit off topic...

schily at schily.net (Joerg Schilling) wrote:

> For today, numbers definitely look different. 30% of the total amount of CPU 
> time spend by the Bourne Shell is spend by the conversion from multy-byte 
> strings to wide strings and vice versa. BTW: "dash" is faster than bash just 
> because it does not imlement multy-byte support. If it did, it would become 
> slower than bash.

Interesting. Gawk stores everything in multibyte form and only converts
to/from wide characters when needed (length, substr, match, a few others).

I don't have timings either way, but I'm pretty sure that gawk doesn't
spend anything like 30% of its time doing those conversions. :-)

Arnold