[TUHS] Article on 'not meant to understand this'

[TUHS] Article on 'not meant to understand this'

[Warren Toomey]

http://thenewstack.io/not-expected-understand-explainer/

in case you haven't seen it yet.

Cheers, Warren

[TUHS] Article on 'not meant to understand this'

[Larry McVoy]

Yeah, saw it.  I'm of the opinion that you aren't really truly an OS
person unless you've written a context switcher.  I wrote one for a
user level threading package I did for Udi Manber as a grad student.
I did most of the work in C and then dropped to assembler for the
trampoline.

It's really not that complicated, I think people make it out to be
a bigger deal than it is.  You're saving state (registers), switching
stacks, and changing the return address so you return in the new 
process.

Well, not that complicated on a simple machine line a VAX or a 68K
or a PDP11.  I sort of stopped playing in assembler when super scalar
out of order stuff came around and I couldn't get the mental picture 
of what was where.

On Mon, Jan 16, 2017 at 11:44:44AM +1000, Warren Toomey wrote:
> http://thenewstack.io/not-expected-understand-explainer/
> 
> in case you haven't seen it yet.
> 
> Cheers, Warren

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Article on 'not meant to understand this'

[Brantley Coile]

I agree that one lacks true understanding of operating systems until one codes a process switch. My first was in 1979 on a home brew 6800 (not 68k).  It was made easier by the fact that the 6800 saved all 64 bits of registers on each interrupt. All that was necessary was to wire a timer interrupt and change the value of SP in the handler.  

  Brantley Coile


Sent from my iPad

> On Jan 15, 2017, at 10:15 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Yeah, saw it.  I'm of the opinion that you aren't really truly an OS
> person unless you've written a context switcher.  I wrote one for a
> user level threading package I did for Udi Manber as a grad student.
> I did most of the work in C and then dropped to assembler for the
> trampoline.
> 
> It's really not that complicated, I think people make it out to be
> a bigger deal than it is.  You're saving state (registers), switching
> stacks, and changing the return address so you return in the new 
> process.
> 
> Well, not that complicated on a simple machine line a VAX or a 68K
> or a PDP11.  I sort of stopped playing in assembler when super scalar
> out of order stuff came around and I couldn't get the mental picture 
> of what was where.
> 
>> On Mon, Jan 16, 2017 at 11:44:44AM +1000, Warren Toomey wrote:
>> http://thenewstack.io/not-expected-understand-explainer/
>> 
>> in case you haven't seen it yet.
>> 
>> Cheers, Warren
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Article on 'not meant to understand this'

[Marc Rochkind]

"... one lacks true understanding of operating systems until ..."

With this as the standard, I have a false understanding of operating
systems. So, I am ready for the post-truth society we are entering. Are
you? ;-)

On Mon, Jan 16, 2017 at 3:11 AM, Brantley Coile <brantleycoile at me.com>
wrote:

> I agree that one lacks true understanding of operating systems until one
> codes a process switch. My first was in 1979 on a home brew 6800 (not
> 68k).  It was made easier by the fact that the 6800 saved all 64 bits of
> registers on each interrupt. All that was necessary was to wire a timer
> interrupt and change the value of SP in the handler.
>
>   Brantley Coile
>
>
> Sent from my iPad
>
> > On Jan 15, 2017, at 10:15 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > Yeah, saw it.  I'm of the opinion that you aren't really truly an OS
> > person unless you've written a context switcher.  I wrote one for a
> > user level threading package I did for Udi Manber as a grad student.
> > I did most of the work in C and then dropped to assembler for the
> > trampoline.
> >
> > It's really not that complicated, I think people make it out to be
> > a bigger deal than it is.  You're saving state (registers), switching
> > stacks, and changing the return address so you return in the new
> > process.
> >
> > Well, not that complicated on a simple machine line a VAX or a 68K
> > or a PDP11.  I sort of stopped playing in assembler when super scalar
> > out of order stuff came around and I couldn't get the mental picture
> > of what was where.
> >
> >> On Mon, Jan 16, 2017 at 11:44:44AM +1000, Warren Toomey wrote:
> >> http://thenewstack.io/not-expected-understand-explainer/
> >>
> >> in case you haven't seen it yet.
> >>
> >> Cheers, Warren
> >
> > --
> > ---
> > Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170116/1e536dc1/attachment.html>

[TUHS] Article on 'not meant to understand this'

[Tony Finch]

Warren Toomey <wkt at tuhs.org> wrote:

> http://thenewstack.io/not-expected-understand-explainer/

Rob Pike observed on Twitter:

https://twitter.com/rob_pike/status/820777895689732096

> The article misses an important fact: A few years later we understood it
> well and could do it much simpler.

https://twitter.com/rob_pike/status/820777988924981254

> We are always learning, and that comment was as much a note to the
> author as to the reader. Now, stack switching is almost trivial.

https://twitter.com/rob_pike/status/820778110253613056

> A similar thing happened a generation earlier figuring out subroutine
> (function) calls. Whole books were written. Now it's an instruction.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Variable 4, becoming
southerly or southwesterly 4 or 5, occasionally 6 in South Utsire and Forties.
Slight or moderate, occasionally rough in north Forties. Occasional rain or
drizzle. Good, occasionally poor.

[TUHS] Article on 'not meant to understand this'

[Angelo Papenhoff]

On 16/01/17, Tony Finch wrote:
> Warren Toomey <wkt at tuhs.org> wrote:
> 
> > http://thenewstack.io/not-expected-understand-explainer/
> 
> Rob Pike observed on Twitter:
> 
> https://twitter.com/rob_pike/status/820777895689732096
> 
> > The article misses an important fact: A few years later we understood it
> > well and could do it much simpler.
> 
> https://twitter.com/rob_pike/status/820777988924981254
> 
> > We are always learning, and that comment was as much a note to the
> > author as to the reader. Now, stack switching is almost trivial.
> 
> https://twitter.com/rob_pike/status/820778110253613056
> 
> > A similar thing happened a generation earlier figuring out subroutine
> > (function) calls. Whole books were written. Now it's an instruction.

The author also actually missed the part that we're not supposed to
understand. I'll just paste what I posted on hackernews:

I don't think it's the context switching in general that we're not
expected to understand, since it's pretty much the same in v7 but the
comment is gone. Dmr actually explained the problem on his website
(https://www.bell-labs.com/usr/dmr/www/odd.html). savu is used to save
the current call stack, retu is used to switch to a saved call stack.
The problem is that the function which did the savu was not necessarily
the same as the function that does the retu, so after retu the function
could have the call stack of a different function. As dmr explained,
this worked with the PDP-11 compiler but not with the interdata
compiler. In V7 the stack switching was moved into separate functions,
save and resume. save retured 0 and resume returned 1 so that an if
statement could be used to check if the return from save was actually
that of resume after the stack switch (the same trick as that of fork).
This way the code that was to be executed after a stack switch was in
the same function and stack frame as the one that did the save (as
opposed to swtch).

Note that Lions doesn't explain this either, he assumed that the
difficulty was with with u_rsav and u_ssav, but those are still in v7
with the comment gone (he probably wasn't that wrong though, it really
is confusing, but it's just not what the comment refers to)

aap

[TUHS] Article on 'not meant to understand this'

[Random832]

On Mon, Jan 16, 2017, at 06:26, Angelo Papenhoff wrote:
> I don't think it's the context switching in general that we're not
> expected to understand, since it's pretty much the same in v7 but the
> comment is gone. Dmr actually explained the problem on his website
> (https://www.bell-labs.com/usr/dmr/www/odd.html). savu is used to save
> the current call stack, retu is used to switch to a saved call stack.
> The problem is that the function which did the savu was not necessarily
> the same as the function that does the retu, so after retu the function
> could have the call stack of a different function. As dmr explained,
> this worked with the PDP-11 compiler but not with the interdata
> compiler. In V7 the stack switching was moved into separate functions,
> save and resume. save retured 0 and resume returned 1 so that an if
> statement could be used to check if the return from save was actually
> that of resume after the stack switch (the same trick as that of fork).
> This way the code that was to be executed after a stack switch was in
> the same function and stack frame as the one that did the save (as
> opposed to swtch).

My impression was that the 'magic' part was that it relied on the C both
process's stacks containing registers saved by the C function prologue
routine [csv, the kernel version can be found in conf/m*.s], and that
the return statement in swtch [which calls cret] restores those
registers. Ritchie alludes to this with "This worked on the PDP-11
because its compiler always used the same context-save mechanism; with
the Interdata compiler, the procedure return code differed depending on
which registers were saved. ", and, well, there's a reason the FreeBSD
cpu_switch function the article mentions is written in assembly rather
than C.

> Note that Lions doesn't explain this either, he assumed that the
> difficulty was with with u_rsav and u_ssav, but those are still in v7
> with the comment gone (he probably wasn't that wrong though, it really
> is confusing, but it's just not what the comment refers to)
> 
> aap

[TUHS] Article on 'not meant to understand this'

[Noel Chiappa]

    > From: Angelo Papenhoff

    > The problem is that the function which did the savu was not necessarily
    > the same as the function that does the retu, so after retu the function
    > could have the call stack of a different function. As dmr explained,
    > this worked with the PDP-11 compiler but not with the interdata
    > compiler.

To put it slightly differently, in PDP-11 C all stack frames look identical,
but this is not true of other machines/compilers. So if routine A called
savu(), and routine B called aretu(), when the call to aretu() returned,
procedure B is still running, but on procedure A's stack frame. So on machines
where A's stack frame looks different from B's, hilarity ensues.

(Note that aretu() was significantly different from retu() - the latter
switched to a different process/stack, whereas aretu() did a 'non-local goto'
[technically, switched to a different stack frame on the current stack] in the
current process.)


    > Note that Lions doesn't explain this either, he assumed that the
    > difficulty was with with u_rsav and u_ssav .. (he probably wasn't that
    > wrong though, it really is confusing, but it's just not what the comment
    > refers to)

Right. There are actually _three_ sets of saved stack info:

	int	u_rsav[2];	/* save r5,r6 when exchanging stacks */
	int	u_qsav[2];	/* label variable for quits and interrupts */
	int	u_ssav[2];	/* label variable for swapping */

and it was the interaction among the three of them that I found very hard to
understand - hence my (incorrect) memory that the 'you are not' comment
actually referred to that, not the savu/aretu stuff!

Calls to retu(), the primitive to switch stacks/processes, _always_ use
rsav. The others are for 'non-local gotos' inside a process.

Think of qsav as a poor man's exception handler for process software
interrupts. When a process is sleeping on some event, when it is interrupted,
rather than the sleep() call returning, it wakes up returning from the
procedure that did the savu(qsav). (That last is because sleep() - which is
the procedure that's running when the call to aretu(qsav) returns - does a
return immediately after restoring the stack to the frame saved in qsav.)

And I've forgotten exactly how ssav worked - IIRC it was something to do with
how when a process is swapped out, since that can happen in a number of
ways/places, the stack can contains calls to various things like expand(),
etc; when it's swapped back in, the simplest thing to do is to just throw that
all away and have it go back to where it was just before it was decided to
swap it out.

       Noel

[TUHS] Article on 'not meant to understand this'

[Steve Johnson]

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

I was well aware of the comment in V6, but had no idea what it
referred to.   When Dennis and I were porting what became V7 to the
Interdata 8/32, we spent about 10 frustrating days dealing with savu
and retu.  Dennis did his most productive work between 10pm and 4am,
while I kept more normal hours.  We would pore over the crash dumps
(in hex, then a new thing for us--PDP-ll was all octal, all the
time).  I'd tinker with the compiler, he'd tinker with the code and
we would get it to limp, flap its wings, and then crash.  The problem
was that the Interdata had many more registers than the PDP-11, so the
compiler only saved the register variables across a call, where the
PDP-11 saved all the registers.  This was just fine inside a process,
but between processes it was deadly.  After we had tried everything
we could think of, Dennis concluded that the fundamental architecture
was broken.  In a couple of days, he came up with the scheme that
ended up in V7.

It was only several years later when I saw a T-shirt with savu and
retu on it along with the famous comment that I realized what it had
referred to, and enjoyed the irony that we hadn't understood it
either...

Steve

----- Original Message -----
From: "Brantley Coile" <brantleycoile@me.com>
To:"Larry McVoy" <lm at mcvoy.com>
Cc:<tuhs at tuhs.org>
Sent:Mon, 16 Jan 2017 05:11:02 -0500
Subject:Re: [TUHS] Article on 'not meant to understand this'


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