16 Jan
2017
16 Jan
'17
1:44 a.m.
http://thenewstack.io/not-expected-understand-explainer/
in case you haven't seen it yet.
Cheers, Warren
16 Jan
16 Jan
3:15 a.m.
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
10:11 a.m.
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(a)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
5:49 p.m.
"... 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(a)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(a)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.
http://www.mcvoy.com/lm
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 
11:19 a.m.
Warren Toomey <wkt(a)tuhs.org> wrote:
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(a)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.
11:26 a.m.
On 16/01/17, Tony Finch wrote:
Warren Toomey <wkt(a)tuhs.org> wrote:
Rob Pike observed on Twitter:
https://twitter.com/rob_pike/status/820777895689732096
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
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. 
3:35 p.m.
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
2668
days inactive
2668
days old
6 comments
7 participants
participants (7)
-
Angelo Papenhoff -
Brantley Coile -
Larry McVoy -
Marc Rochkind -
Random832 -
Tony Finch -
Warren Toomey