From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22166 invoked from network); 3 Sep 2021 19:12:25 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Sep 2021 19:12:25 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B9AD79C875; Sat, 4 Sep 2021 05:12:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DE3109C870; Sat, 4 Sep 2021 05:11:58 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="d3KygMgK"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D1AEC9C870; Sat, 4 Sep 2021 05:11:56 +1000 (AEST) Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by minnie.tuhs.org (Postfix) with ESMTPS id 0186C9BA1E for ; Sat, 4 Sep 2021 05:11:56 +1000 (AEST) Received: by mail-qv1-f54.google.com with SMTP id g11so247642qvd.2 for ; Fri, 03 Sep 2021 12:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g0oqm/FpVxh7EhVwuj4S0OJ21MF5+2kNIUKFBw/uPpU=; b=d3KygMgKcPT3lMjbHix/pD4X1ze0P80+C5/bTlYWpKDDzvnLbwfGKCXhKybhV/EUff 8+5d0aKv4WwmQCcwdNxF+HsXdpI6OEkIBBFrdcl8RUO2p+8cs8h3fhsvXSXS6ME8UU0B s42JX3QqiMdmofA8VzsslBagW8QUgH7TtmSH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g0oqm/FpVxh7EhVwuj4S0OJ21MF5+2kNIUKFBw/uPpU=; b=ZERKPxt+MhbjN8JCvl75X/8poPrgKTtcvQVnflDe2kOL/6PUYUBJrC3mF+Jiy+Jj89 wpHJzW++E7SNB0AR3UO9NDN2MshW7rcRIVcoG7dnwLc8xyLz8ja2N33qyE3yi5+exJ5x shsnVytEZXJX9Uas5DKlsMTMgSYDXHccn/dNFyZD5UQYYBMj2sZhU83eVfW45WyZGnFI +Cd2Feauy/PKlK4EnDlEfWRcxvoIs9l+eNdVt5bXQQivON6lePNxfSxMgmo445SARmUP JmTlUJWK1nqy0g985w0WBET8lq2fIguMGmLO1uRoVjJEhUTgmHwBTyMQqIH65oIJklvS 815g== X-Gm-Message-State: AOAM53113VZZ9l0sqZxMKEegG80sRse2QzyYbAnIEj6/Aeb8lLUArD4h wzgyTzFZhxP0fl37WF6PvDbbIVYLnr9DfDdmN7v+xw== X-Google-Smtp-Source: ABdhPJzLFM8g2WFanMP8ho7e8rrPvbIwWOrfWvPTrZfFTfgbM3dBb0TErcngSB4C6Y4s6VPCKODOVBZyKncLiFX0F24= X-Received: by 2002:a0c:ef0d:: with SMTP id t13mr306617qvr.21.1630696314835; Fri, 03 Sep 2021 12:11:54 -0700 (PDT) MIME-Version: 1.0 References: <20210903172848.GF13471@mcvoy.com> In-Reply-To: <20210903172848.GF13471@mcvoy.com> From: Clem Cole Date: Fri, 3 Sep 2021 15:11:28 -0400 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="0000000000009525f205cb1c124a" Subject: Re: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000009525f205cb1c124a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Larry - it's the compiler (code generator) folks that I really feel bad for. They had to deal with the realities of the ISA in many ways more than we do and for them, it's getting worse and worse. BTW - there was a misstatement in a previous message. A current CISC system like the INTEL*64 is not implemented as a RISC =C2=B5code, nor are current more RISCy machine= s like the SPARX and Alpha much less the StrongARM and its followers. What they are internally are *data flow machines *which is why you getting a mixing of instruction ordering, scoreboarding, and all sorts of complexities that blows our mind. At least at the OS we have been used to doing things in parallel, exceptions and interrupts occurring and we have reasoned our ways through things. Butler Lampson and Leslie Lamport gave a parallel calculus to help verify things (although Butler once observed at an old SOSP talk that the problem with parallel is what does 'single step the processor mean anymore.' ). So the idea while the processor is not a PDP-10 or PDP-11 much less a 360/91 or a CDC-6600, we build a model in our heads that does simplify the machine(s) as much as possible. We ensure at least that is correct and then, build up more complexity from there. To me, the problem is that we too often do a poor job of what should be the simple stuff and we continue to make it too complicated. Not to pick on any one group/code base, but Jon's recent observation about the Linux kernel FS interface is a prime point. It's not the processor that was made complex, it's the SW wanting to be all things to all people. To me what Unix started and succeed at its time, and clearly Plan9 was attempted in its time (but failed commercially) was to mask if not toss out as much of the complexity of the HW and get to a couple of simple and common ideas and all programs could agree. Going back to the idea of the bear of the 'slittle brain and try to expose the simplest way to computation. Two of the best Unix talks/papers ever, Rob's "cat -v is a bad idea" and Tom's "All Chips that Fit" has morphed into "I have 64-bits of address space I can link anything into my framework" and "what I power and cool in my current process technology" [a SoC is not different that the board level products that some of us lived]. I recently read a suggestion that the best way to teach begging students to be "good programmers" was to "introduce them to as many frameworks as possible and teach as little theory as they need." I nearly lost my dinner. Is this what programming has come to? Framework/Access Methods/Smart Objects .... To be fair, my own employer is betting on DPC++ and believing OneAPI as the one ring to rule them all. There is a lot to be said of "small is beautiful." How did we get from Sixth Edition UNIX with K&R1 to today? One transistor and one line a code at a time. =E1=90=A7 On Fri, Sep 3, 2021 at 1:29 PM Larry McVoy wrote: > I am exactly as Adam described, still thinking like it is a PDP-11. > Such an understandable machine. For me, out of order execution kind > of blew up my brain, that's when I stopped doing serious kernel work, > I just couldn't get to a mental model of how you reasoned about that. > > Though I was talking to someone about it, maybe Clem, recently and > came to the conclusion that it is fine, we already sort of had this > mess with pipelines. So maybe it is fine, but out of order bugs my > brain. > > On Fri, Sep 03, 2021 at 10:10:57AM -0700, Adam Thornton wrote: > > Much of the problem, I think, is that: > > > > 1) an idealized PDP-11 (I absolutely take Warner's point that that > > idealization never really existed) is a sufficiently simple model that = a > > Bear Of Little Brain, such as myself, can reason about what's going to > > happen in response to a particular sequence of instructions, and get > fairly > > proficient in instructing the machine to do so in a non-geological > > timeframe. > > > > 2) a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way > > smarter than I am. (I mean, I do realize that this particular venue ha= s > a > > lot of those people in it...but, really, those are people with > > extraordinary minds.) > > > > There are enough people in the world capable of doing 1 and not 2 that = we > > can write software that usually mostly kinda works and often gets stuff > > done before collapsing in a puddle of nasty-smelling goo. There aren't > > many people at all capable of 2, and as the complexity of systems > > increases, that number shrinks. > > > > In short, this ends up being the same argument that comes around every = so > > often, "why are you people still pretending that the computer is a PDP-= 11 > > when it clearly isn't?" Because, as with the keys and the streetlight, > > that's what we have available to us. Only a grossly oversimplified mod= el > > fits into our heads. > > > > Adam > > > > On Fri, Sep 3, 2021 at 8:57 AM Warner Losh wrote: > > > > > > > > > > > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross wrote: > > > > > >> I'm curious about other peoples' thoughts on the talk and the overal= l > > >> topic? > > >> > > > > > > My comment is that the mental map that he presents has always been a > lie. > > > At least it's been a lie from a very early time. > > > > > > Even in Unibus/Qbus days, the add-in cards had some kind of processor > > > on it from an early time. Several of the VAX boards had 68000 or > similar > > > CPUs that managed memory. Even the simpler MFM boards had buffer > > > memory that needed to be managed before the DMA/PIO pulled it out > > > of the card. There's always been an element of different address spac= es > > > with different degrees of visibility into those address spaces. > > > > > > What has changed is all of these things are now on the SoC die so > > > you have good visibility (well, as good as the docs) into these thing= s. > > > The number of different things has increased, and the for cross domai= n > > > knowledge has increased. > > > > > > The simplistic world view was even inaccurate at the start.... > > > > > > Warner > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > --0000000000009525f205cb1c124a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Larry - it's the compiler (code generator) folks th= at I really feel bad for. They had to deal with the realities of the ISA in= many ways more than we do and for them,=C2=A0it's getting worse and wo= rse.=C2=A0 BTW - there was a misstatement in a previous message. A current = CISC system like the INTEL*64 is not implemented=C2=A0as a RISC =C2=B5code,= nor are current more RISCy=C2=A0machines like the SPARX and Alpha much les= s the StrongARM and its followers.=C2=A0 =C2=A0What they are internally are= data flow machines which is why you getting a mixing of instruction= ordering, scoreboarding, and all sorts of complexities that blows our mind= .

=C2=A0At least at the OS we have been used to doing = things in parallel, exceptions and interrupts occurring and we have reasone= d our ways through things.=C2=A0 Butler Lampson and Leslie Lamport gave a p= arallel calculus to help verify things (although=C2=A0Butler once observed= =C2=A0at an old SOSP=C2=A0talk that the problem=C2=A0with parallel is what = does 'single step the processor mean anymore.' ).

So the idea while the processor is not a PDP-10 or PDP-11 much less a= 360/91 or a CDC-6600, we build a model in our heads that does simplify the= machine(s) as much as possible.=C2=A0 We ensure=C2=A0at least that is corr= ect and then, build up more complexity from there.=C2=A0 =C2=A0
To me, the problem=C2=A0is that we too often do a poor job of wha= t should be the simple stuff and we continue to make it too complicated.=C2= =A0 Not to pick on any one=C2=A0group/code base, but Jon's recent obser= vation=C2=A0about the Linux kernel FS interface is a prime point.=C2=A0 It&= #39;s not the processor that was made complex, it's the SW wanting to b= e all things to all people.=C2=A0 =C2=A0

To me what Un= ix started and succeed at its time, and clearly Plan9 was attempted in its = time (but failed commercially) was to mask if not toss out as much of the c= omplexity of the HW and get to a couple of simple and common ideas and all = programs could agree.=C2=A0 Going back=C2=A0to the idea of the bear of the = 'slittle brain and try to expose the simplest=C2=A0way to computation.<= /div>

Two of the best=C2=A0Unix talks/papers ever, Rob's= "cat -v is a bad idea" and Tom's "All Chips that Fit&qu= ot; has morphed into "I have 64-bits of address space I can link anyth= ing into my framework" and=C2=A0 "what I power and cool in my cur= rent process technology" [a SoC is not different that the board level = products that some of us lived].

I recently read a sug= gestion that the best way to teach begging students=C2=A0to be "good p= rogrammers" was to "introduce them to as many frameworks as possi= ble and teach as little theory as they need." I nearly lost my dinner.= =C2=A0 Is this what programming has come to?=C2=A0 =C2=A0Framework/Access= =C2=A0Methods/Smart Objects ....=C2=A0 =C2=A0To be fair, my own employer is= betting on DPC++=C2=A0and believing OneAPI as the one ring to rule them al= l.

There is a lot to be said of "small is beautif= ul."=C2=A0 How did we get from Sixth Edition UNIX with K&R1 to tod= ay?=C2=A0 One transistor and one line a code at a time.=C2=A0
=C2= =A0
= 3D""=E1=90=A7

On Fri, Sep 3, 2021 at 1:29 PM Larr= y McVoy <lm@mcvoy.com> wrote:
=
I am exactly as Ada= m described, still thinking like it is a PDP-11.
Such an understandable machine.=C2=A0 =C2=A0For me, out of order execution = kind
of blew up my brain, that's when I stopped doing serious kernel work, I just couldn't get to a mental model of how you reasoned about that.
Though I was talking to someone about it, maybe Clem, recently and
came to the conclusion that it is fine, we already sort of had this
mess with pipelines.=C2=A0 So maybe it is fine, but out of order bugs my brain.

On Fri, Sep 03, 2021 at 10:10:57AM -0700, Adam Thornton wrote:
> Much of the problem, I think, is that:
>
> 1) an idealized PDP-11=C2=A0 (I absolutely take Warner's point tha= t that
> idealization never really existed) is a sufficiently simple model that= a
> Bear Of Little Brain, such as myself, can reason about what's goin= g to
> happen in response to a particular sequence of instructions, and get f= airly
> proficient in instructing the machine to do so in a non-geological
> timeframe.
>
> 2) a modern CPU?=C2=A0 Let alone SoC?=C2=A0 Fuggedaboutit unless you&#= 39;re way, way
> smarter than I am.=C2=A0 (I mean, I do realize that this particular ve= nue has a
> lot of those people in it...but, really, those are people with
> extraordinary minds.)
>
> There are enough people in the world capable of doing 1 and not 2 that= we
> can write software that usually mostly kinda works and often gets stuf= f
> done before collapsing in a puddle of nasty-smelling goo.=C2=A0 There = aren't
> many people at all capable of 2, and as the complexity of systems
> increases, that number shrinks.
>
> In short, this ends up being the same argument that comes around every= so
> often, "why are you people still pretending that the computer is = a PDP-11
> when it clearly isn't?"=C2=A0 Because, as with the keys and t= he streetlight,
> that's what we have available to us.=C2=A0 Only a grossly oversimp= lified model
> fits into our heads.
>
> Adam
>
> On Fri, Sep 3, 2021 at 8:57 AM Warner Losh <imp@bsdimp.com> wrote:
>
> >
> >
> > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross <crossd@gmail.com> wrote:
> >
> >> I'm curious about other peoples' thoughts on the talk= and the overall
> >> topic?
> >>
> >
> > My comment is that the mental map that he presents has always bee= n a lie.
> > At least it's been a lie from a very early time.
> >
> > Even in Unibus/Qbus days, the add-in cards had some kind of proce= ssor
> > on it from an early time. Several of the VAX boards had 68000 or = similar
> > CPUs that managed memory. Even the simpler MFM boards had buffer<= br> > > memory that needed to be managed before the DMA/PIO pulled it out=
> > of the card. There's always been an element of different addr= ess spaces
> > with different degrees of visibility into those address spaces. > >
> > What has changed is all of these things are now on the SoC die so=
> > you have good visibility (well, as good as the docs) into these t= hings.
> > The number of different things has increased, and the for cross d= omain
> > knowledge has increased.
> >
> > The simplistic world view was even inaccurate at the start.... > >
> > Warner
> >

--
---
Larry McVoy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 l= m at mcvo= y.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.mcvoy.com= /lm
--0000000000009525f205cb1c124a--