From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Chris McGee Date: Sun, 2 Sep 2018 12:31:54 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000001ae9470574e5f7a4" Subject: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e01a4772-ead9-11e9-9d60-3106f5b1d025 --0000000000001ae9470574e5f7a4 Content-Type: text/plain; charset="UTF-8" Hi All, I'm reading this article about how they are going through the giant heaping pile of Linux kernel code and trying to come up with safer practices to avoid the "dangers" of C. The prevailing wisdom appears to be that things should eventually be rewritten in Rust some day. https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ I'm curious how the Plan 9 C compiler fits into this story. I know that it was designed to avoid many of the pitfalls of standard C. Does it try to address some of these dangers or is it focused on making code more readable so that problems are more apparent? How does everyone feel about the Plan 9/9front kernel? Have they gone through hardening/testing exercises over the years? I'm curious what tools are available to help discover bugs. Cheers, Chris --0000000000001ae9470574e5f7a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I'm reading this= article about how they are going through the giant heaping pile of Linux k= ernel code and trying to come up with safer practices to avoid the "da= ngers" of C. The prevailing wisdom appears to be that things should ev= entually be rewritten in Rust some day.

https://lwn.net/S= ubscriberLink/763641/c9a04da2a33af0a3/

I'm= curious how the Plan 9 C compiler fits into this story. I know that it was= designed to avoid many of the pitfalls of standard C. Does it try to addre= ss some of these dangers or is it focused on making code more readable so t= hat problems are more apparent?

How does everyone = feel about the Plan 9/9front kernel? Have they gone through hardening/testi= ng exercises over the years? I'm curious what tools are available to he= lp discover bugs.

Cheers,
Chris
--0000000000001ae9470574e5f7a4-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: hiro <23hiro@gmail.com> Date: Sun, 2 Sep 2018 18:52:38 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e01e31c0-ead9-11e9-9d60-3106f5b1d025 "prevailing wisdom" sounds like an oxymoron. The plan 9 kernel has not enjoyed the pressure of attacks like more common operating systems. If you want to help, it's easy to discover bugs by reading the source code, which is very short and readable. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Lucio De Re Date: Sun, 2 Sep 2018 20:16:39 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e05faba0-ead9-11e9-9d60-3106f5b1d025 On 9/2/18, Chris McGee wrote: > I'm reading this article about how they are going through the giant heaping > pile of Linux kernel code and trying to come up with safer practices to > avoid the "dangers" of C. The prevailing wisdom appears to be that things > should eventually be rewritten in Rust some day. > Like hell they will! By the time they have even a minute portion of Linux running under a different language, the language-du-jour will have moved on. It's a monolith, it cannot be translated, unless it is mechanically. And we know how brilliant that is likely to be. > How does everyone feel about the Plan 9/9front kernel? Have they gone > through hardening/testing exercises over the years? I'm curious what tools > are available to help discover bugs. > Simplicity is Plan 9's most relevant trait here, but that's where you draw the line. If anyone feels like finding possible security holes in the Plan 9 or the 9front kernels, they have to have very strong motivation to do it. In general that motivation is spelled M-O-N-E-Y and no one is likely to find the 9 flavours worthy of a big lump of that resource. My opinions, of course. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Simon Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Sun, 2 Sep 2018 20:18:14 +0100 Message-Id: References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0863798-ead9-11e9-9d60-3106f5b1d025 the most significant change that plan9=E2=80=99s c made (that i can think of= ) is compile time type checking between modules /files. this helps but is not a huge improvement to safety. the main reasons plan9=E2=80=99s kernel is fairly safe is its clean and simp= le design, which makes problems less likely. nothing cleverer than that (imho). Sorry, no magic. -Steve > On 2 Sep 2018, at 19:16, Lucio De Re wrote: >=20 >> On 9/2/18, Chris McGee wrote: >> I'm reading this article about how they are going through the giant heapi= ng >> pile of Linux kernel code and trying to come up with safer practices to >> avoid the "dangers" of C. The prevailing wisdom appears to be that things= >> should eventually be rewritten in Rust some day. >>=20 > Like hell they will! By the time they have even a minute portion of > Linux running under a different language, the language-du-jour will > have moved on. It's a monolith, it cannot be translated, unless it is > mechanically. And we know how brilliant that is likely to be. >=20 >> How does everyone feel about the Plan 9/9front kernel? Have they gone >> through hardening/testing exercises over the years? I'm curious what tool= s >> are available to help discover bugs. >>=20 > Simplicity is Plan 9's most relevant trait here, but that's where you > draw the line. If anyone feels like finding possible security holes in > the Plan 9 or the 9front kernels, they have to have very strong > motivation to do it. In general that motivation is spelled M-O-N-E-Y > and no one is likely to find the 9 flavours worthy of a big lump of > that resource. >=20 > My opinions, of course. >=20 > Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net References: From: =?UTF-8?Q?Iruat=c3=a3_Souza?= Message-ID: <807fabbc-e97a-4e60-1562-a126dd79008a@gmail.com> Date: Sun, 2 Sep 2018 12:21:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e08e0f90-ead9-11e9-9d60-3106f5b1d025 On 09/02/2018 09:31 AM, Chris McGee wrote: > I'm curious what > tools are available to help discover bugs. > Does simplicity and clarity count? From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <807fabbc-e97a-4e60-1562-a126dd79008a@gmail.com> In-Reply-To: <807fabbc-e97a-4e60-1562-a126dd79008a@gmail.com> From: Charles Forsyth Date: Mon, 3 Sep 2018 02:03:37 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="00000000000027036d0574ed1dd9" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0974524-ead9-11e9-9d60-3106f5b1d025 --00000000000027036d0574ed1dd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The Plan 9 C compiler doesn't take an insane view of the meaning of "undefined behaviour", which makes a big difference. It also assumes you know how to write loops if they need to be fast (which frankly hasn't really mattered at the O/S level, esp on modern hardware), so it won't "optimise" essential code out of your program by miscalculating the ranges during "aggressive-loop-optimisation". No doubt it could be better, but it could easily be worse. The executable is also finite size, not unbounded-but-finite. For a compiler of a language the size and complexity of C (without some ANSI crud), I think it's not far off a size comparable to the language complexity (although it could be a bit smaller); meanwhile, by treating "compiling C" as a subset problem of "compiling C++", gcc and especially clang are vast whales whistling at the wrong frequency for the problem. On Sun, 2 Sep 2018 at 20:23, Iruat=C3=A3 Souza wrote: > On 09/02/2018 09:31 AM, Chris McGee wrote: > > I'm curious what > > tools are available to help discover bugs. > > > > Does simplicity and clarity count? > > --00000000000027036d0574ed1dd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The Plan 9 C compiler doesn't take an insane view of t= he meaning of "undefined behaviour", which makes a big difference= .
It also assumes you know how to write loops if they need to be fast (= which frankly hasn't really mattered at the O/S level, esp on modern ha= rdware),
so it won't "optimise" essential code out = of your program by miscalculating the ranges during "aggressive-loop-o= ptimisation".
No doubt it could be better, but it could easi= ly be worse.
The executable is also finite size, not unbounded-bu= t-finite.
For a compiler of a language the size and complexity of= C (without some ANSI crud), I think it's not far off a size comparable= to the language complexity
(although it could be a bit smaller);= meanwhile, by treating "compiling C" as a subset problem of &quo= t;compiling C++", gcc and especially clang are vast whales whistling a= t the wrong frequency for the problem.

On Sun, 2 Sep 2018 at 20:23, Iruat=C3=A3 Souza <<= a href=3D"mailto:iru.muzgo@gmail.com">iru.muzgo@gmail.com> wrote:
On 09/02/2018 09:31 AM, Chris McGee w= rote:
> I'm curious what
> tools are available to help discover bugs.
>

Does simplicity and clarity count?

--00000000000027036d0574ed1dd9-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Sun, 2 Sep 2018 19:03:51 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000aa4d6c0574edf414" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e09bb488-ead9-11e9-9d60-3106f5b1d025 --000000000000aa4d6c0574edf414 Content-Type: text/plain; charset="UTF-8" To me, one of the big advantages for Plan 9 is structural, not necessarily related to C. There's no need to put everything in the kernel and one can have different specialized kernels (e.g. kenfs), so long as the basic protocols are followed. On Sun, Sep 2, 2018 at 9:32 AM Chris McGee wrote: > Hi All, > > I'm reading this article about how they are going through the giant > heaping pile of Linux kernel code and trying to come up with safer > practices to avoid the "dangers" of C. The prevailing wisdom appears to be > that things should eventually be rewritten in Rust some day. > > https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ > > I'm curious how the Plan 9 C compiler fits into this story. I know that it > was designed to avoid many of the pitfalls of standard C. Does it try to > address some of these dangers or is it focused on making code more readable > so that problems are more apparent? > > How does everyone feel about the Plan 9/9front kernel? Have they gone > through hardening/testing exercises over the years? I'm curious what tools > are available to help discover bugs. > > Cheers, > Chris > --000000000000aa4d6c0574edf414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To me, one of the big advantages for Plan 9 is structural,= not necessarily related to C. There's no need to put everything in the= kernel and one can have different specialized kernels (e.g. kenfs), so lon= g as the basic protocols are followed.

On Sun, Sep 2, 2018 at 9:32 AM Chris McGee <newton688@gmail.com> wrote:
Hi All,
I'm reading this article about how they are going through t= he giant heaping pile of Linux kernel code and trying to come up with safer= practices to avoid the "dangers" of C. The prevailing wisdom app= ears to be that things should eventually be rewritten in Rust some day.


I'm curious how the Plan 9 C= compiler fits into this story. I know that it was designed to avoid many o= f the pitfalls of standard C. Does it try to address some of these dangers = or is it focused on making code more readable so that problems are more app= arent?

How does everyone feel about the Plan 9/9fr= ont kernel? Have they gone through hardening/testing exercises over the yea= rs? I'm curious what tools are available to help discover bugs.

Cheers,
Chris
--000000000000aa4d6c0574edf414-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Lucio De Re Date: Mon, 3 Sep 2018 06:07:00 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0a8c236-ead9-11e9-9d60-3106f5b1d025 On 9/2/18, hiro <23hiro@gmail.com> wrote: > "prevailing wisdom" sounds like an oxymoron. > Yes, real wisdom is for some (evolutionary? counter-evolutionary?) reason unlikely to prevail. Go figure. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris McGee Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 3 Sep 2018 08:40:28 -0400 Message-Id: References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0ad199e-ead9-11e9-9d60-3106f5b1d025 Thanks everyone. This is pretty much what I expected was the case. I just wa= nted to confirm my understanding. Plan 9 C was re-engineered with some focus on readable code. Readability is expected to make bugs more apparent, m= aking it less =E2=80=9Cdangerous.=E2=80=9D Linux is so huge and hard to read= that even simple things like C have become sharp edges that cut people. Whi= le the idea that many eyes makes bugs shallower seems to have failed in the w= orld of complex behemoth software it may work here. I=E2=80=99ve read some of the 9front kernel code trying to make it work on r= aspberry pi. I admit that I didn=E2=80=99t find any bugs at that time. The c= ode is relatively easy to follow even for me. So, I suppose it=E2=80=99s wor= king nicely. Chris > On Sep 3, 2018, at 12:07 AM, Lucio De Re wrote: >=20 >> On 9/2/18, hiro <23hiro@gmail.com> wrote: >> "prevailing wisdom" sounds like an oxymoron. >>=20 > Yes, real wisdom is for some (evolutionary? counter-evolutionary?) > reason unlikely to prevail. >=20 > Go figure. >=20 > Lucio. >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1535997499.784480.1495319464.0DE4D730@webmail.messagingengine.com> From: Ethan Gardener To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" In-Reply-To: References: Date: Mon, 3 Sep 2018 18:58:19 +0100 Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0b1ff68-ead9-11e9-9d60-3106f5b1d025 On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: > While the idea that many eyes makes bugs shallower seems to have failed > in the world of complex behemoth software it may work here. I think it worked for a while, but eventually complexity grew beyond even the many eyes approach. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1535997499.784480.1495319464.0DE4D730@webmail.messagingengine.com> References: <1535997499.784480.1495319464.0DE4D730@webmail.messagingengine.com> From: Lucio De Re Date: Tue, 4 Sep 2018 12:51:58 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0d07772-ead9-11e9-9d60-3106f5b1d025 On 9/3/18, Ethan Gardener wrote: > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: >> While the idea that many eyes makes bugs shallower seems to have failed >> in the world of complex behemoth software it may work here. > > I think it worked for a while, but eventually complexity grew beyond even > the many eyes approach. > Could even be that the many-eyes approach encouraged the complexity; in fact, that could easily be the unintended consequence. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1536060800.1875390.1496082208.13EE7020@webmail.messagingengine.com> From: Ethan Gardener To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" In-Reply-To: Date: Tue, 4 Sep 2018 12:33:20 +0100 References: <1535997499.784480.1495319464.0DE4D730@webmail.messagingengine.com> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0d496b8-ead9-11e9-9d60-3106f5b1d025 On Tue, Sep 4, 2018, at 11:51 AM, Lucio De Re wrote: > On 9/3/18, Ethan Gardener wrote: > > On Mon, Sep 3, 2018, at 1:40 PM, Chris McGee wrote: > >> While the idea that many eyes makes bugs shallower seems to have failed > >> in the world of complex behemoth software it may work here. > > > > I think it worked for a while, but eventually complexity grew beyond even > > the many eyes approach. > > > Could even be that the many-eyes approach encouraged the complexity; > in fact, that could easily be the unintended consequence. I suppose it made complexity seem less bad, for a while, but I was thinking economic factors likely drove it to get more complex. Also, I get the impression that some people just love complexity, but these days I'm not so sure. Complexity does have some real benefits. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <1535997499.784480.1495319464.0DE4D730@webmail.messagingengine.com> <1536060800.1875390.1496082208.13EE7020@webmail.messagingengine.com> In-Reply-To: <1536060800.1875390.1496082208.13EE7020@webmail.messagingengine.com> From: Chris McGee Date: Tue, 4 Sep 2018 07:41:40 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000e2ed3b05750a2487" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0d85834-ead9-11e9-9d60-3106f5b1d025 --000000000000e2ed3b05750a2487 Content-Type: text/plain; charset="UTF-8" > > Could even be that the many-eyes approach encouraged the complexity; > > in fact, that could easily be the unintended consequence. > > I suppose it made complexity seem less bad, for a while, but I was > thinking economic factors likely drove it to get more complex. Also, I get > the impression that some people just love complexity, but these days I'm > not so sure. Complexity does have some real benefits. > I hadn't considered this. I just assumed that complexity = job security + sell + lock-in. It's easy to love something that is raking in the cash. --000000000000e2ed3b05750a2487 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Could even be that the many-eyes approach encouraged the complexity; > in fact, that could easily be the unintended consequence.

I suppose it made complexity seem less bad, for a while, but I was thinking= economic factors likely drove it to get more complex.=C2=A0 Also, I get th= e impression that some people just love complexity, but these days I'm = not so sure.=C2=A0 Complexity does have some real benefits.

I hadn't considered this. I just assumed that comp= lexity =3D job security=C2=A0+ sell + lock-in. It's easy to love someth= ing that is raking in the cash.
--000000000000e2ed3b05750a2487-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Charles Forsyth Date: Wed, 5 Sep 2018 00:17:55 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000ddbcb4057513de7e" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0dd1cb6-ead9-11e9-9d60-3106f5b1d025 --000000000000ddbcb4057513de7e Content-Type: text/plain; charset="UTF-8" Plan 9 C implements C by attempting to follow the programmer's instructions, which is surprisingly useful in systems programming. The big fat compilers work hard to find grounds to interpret those instructions as "undefined behaviour". On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > Hi All, > > I'm reading this article about how they are going through the giant > heaping pile of Linux kernel code and trying to come up with safer > practices to avoid the "dangers" of C. The prevailing wisdom appears to be > that things should eventually be rewritten in Rust some day. > > https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ > > I'm curious how the Plan 9 C compiler fits into this story. I know that it > was designed to avoid many of the pitfalls of standard C. Does it try to > address some of these dangers or is it focused on making code more readable > so that problems are more apparent? > > How does everyone feel about the Plan 9/9front kernel? Have they gone > through hardening/testing exercises over the years? I'm curious what tools > are available to help discover bugs. > > Cheers, > Chris > --000000000000ddbcb4057513de7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Plan 9 C implements C by attempting to follow the programm= er's instructions, which is surprisingly useful in systems programming.=
The big fat compilers work hard to find grounds to interpret those ins= tructions as "undefined behaviour".

On Sun, 2 Sep 2018 at 17:32, C= hris McGee <newton688@gmail.com> wrote:



I'm cu= rious how the Plan 9 C compiler fits into this story. I know that it was de= signed to avoid many of the pitfalls of standard C. Does it try to address = some of these dangers or is it focused on making code more readable so that= problems are more apparent?

How does everyone fee= l about the Plan 9/9front kernel? Have they gone through hardening/testing = exercises over the years? I'm curious what tools are available to help = discover bugs.

Cheers,
Chris
--000000000000ddbcb4057513de7e-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Tyga Date: Wed, 5 Sep 2018 09:30:22 +1000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000005deb3d0575140bbd" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0e89b4a-ead9-11e9-9d60-3106f5b1d025 --0000000000005deb3d0575140bbd Content-Type: text/plain; charset="UTF-8" Ha HA ! Good one ! I believe that the core of the problem with the C language is that is based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD x64 are vastly more complex so "optimising" C compilers are trying to make something simple take advantage of something far more complex. Perhaps we should call them "complexifying" compilers. Generally, model-to-model transformations (which is effectively what compilers do under the covers) are easier to define when we transform from a higher level of abstraction to a lower level of abstraction. As folks in the MBSE field explain it, trying to put a pig together from sausages. On Wed, 5 Sep 2018 at 09:20, Charles Forsyth wrote: > Plan 9 C implements C by attempting to follow the programmer's > instructions, which is surprisingly useful in systems programming. > The big fat compilers work hard to find grounds to interpret those > instructions as "undefined behaviour". > > > On Sun, 2 Sep 2018 at 17:32, Chris McGee wrote: > >> Hi All, >> >> I'm reading this article about how they are going through the giant >> heaping pile of Linux kernel code and trying to come up with safer >> practices to avoid the "dangers" of C. The prevailing wisdom appears to be >> that things should eventually be rewritten in Rust some day. >> >> https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/ >> >> I'm curious how the Plan 9 C compiler fits into this story. I know that >> it was designed to avoid many of the pitfalls of standard C. Does it try to >> address some of these dangers or is it focused on making code more readable >> so that problems are more apparent? >> >> How does everyone feel about the Plan 9/9front kernel? Have they gone >> through hardening/testing exercises over the years? I'm curious what tools >> are available to help discover bugs. >> >> Cheers, >> Chris >> > --0000000000005deb3d0575140bbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ha HA !=C2=A0 Good one !

I believe that= the core of the problem with the C language is that is based upon abstract= ing the PDP-11 instruction set.=C2=A0 CPUs, such as Intel/AMD x64 are vastl= y more complex so "optimising" C compilers are trying to make som= ething simple take advantage of something far more complex.=C2=A0 Perhaps w= e should call them "complexifying" compilers.

Generally, model-to-model transformations (which is effectively what = compilers do under the covers) are easier to define when we transform from = a higher level of abstraction to a lower level of abstraction.=C2=A0 As fol= ks in the MBSE field explain it, trying to put a pig together from sausages= .

On Wed, 5 Sep = 2018 at 09:20, Charles Forsyth <charles.forsyth@gmail.com> wrote:
Plan 9 C implements C by attempting to follow t= he programmer's instructions, which is surprisingly useful in systems p= rogramming.
The big fat compilers work hard to find grounds to interpre= t those instructions as "undefined behaviour".


On Sun, 2 Sep 2018 = at 17:32, Chris McGee <newton688@gmail.com> wrote:
Hi All,

I'm read= ing this article about how they are going through the giant heaping pile of= Linux kernel code and trying to come up with safer practices to avoid the = "dangers" of C. The prevailing wisdom appears to be that things s= hould eventually be rewritten in Rust some day.

https://lwn.net/SubscriberLink/763641/c9a04da2a33af0a3/
<= div>
I'm curious how the Plan 9 C compiler fits into this= story. I know that it was designed to avoid many of the pitfalls of standa= rd C. Does it try to address some of these dangers or is it focused on maki= ng code more readable so that problems are more apparent?

How does everyone feel about the Plan 9/9front kernel? Have they go= ne through hardening/testing exercises over the years? I'm curious what= tools are available to help discover bugs.

Cheers= ,
Chris
--0000000000005deb3d0575140bbd-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Chris McGee Date: Tue, 4 Sep 2018 22:29:24 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000a75bd40575168bea" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0ec9b5a-ead9-11e9-9d60-3106f5b1d025 --000000000000a75bd40575168bea Content-Type: text/plain; charset="UTF-8" > I believe that the core of the problem with the C language is that is > based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD > x64 are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Perhaps we > should call them "complexifying" compilers. > > Generally, model-to-model transformations (which is effectively what > compilers do under the covers) are easier to define when we transform from > a higher level of abstraction to a lower level of abstraction. As folks in > the MBSE field explain it, trying to put a pig together from sausages. > I wonder if the hardware world suffers from some of the same complexity problems the software world does. Is it possible to build much simpler hardware as well or are there real physical properties that force them to be as complex as they are now? --000000000000a75bd40575168bea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I believe that the core of the problem with the C= language is that is based upon abstracting the PDP-11 instruction set.=C2= =A0 CPUs, such as Intel/AMD x64 are vastly more complex so "optimising= " C compilers are trying to make something simple take advantage of so= mething far more complex.=C2=A0 Perhaps we should call them "complexif= ying" compilers.

Generally, model-to-model tr= ansformations (which is effectively what compilers do under the covers) are= easier to define when we transform from a higher level of abstraction to a= lower level of abstraction.=C2=A0 As folks in the MBSE field explain it, t= rying to put a pig together from sausages.
I wonder if the hardware world suffers from some of the same co= mplexity problems the software world does. Is it possible to build much sim= pler hardware as well or are there real physical properties that force them= to be as complex as they are now?
--000000000000a75bd40575168bea-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 4 Sep 2018 20:25:00 -0700 From: Ori Bernstein To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-Id: <20180904202500.d4e629511996125d643d7635@eigenstate.org> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0f0851c-ead9-11e9-9d60-3106f5b1d025 On Wed, 5 Sep 2018 09:30:22 +1000, Tyga wrote: > Ha HA ! Good one ! > CPUs, such as Intel/AMD x64 > are vastly more complex so "optimising" C compilers are trying to make > something simple take advantage of something far more complex. Ironically, because of the complexity in the CPUs, many of the optimizations make less of a difference now -- they're essentially optimizing just in time compilers under the hood, so even terrible code will run acceptably quickly. -- Ori Bernstein From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1536135561.3026040.1497260856.5FF478D2@webmail.messagingengine.com> From: Ethan Gardener To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" In-Reply-To: <20180904202500.d4e629511996125d643d7635@eigenstate.org> Date: Wed, 5 Sep 2018 09:19:21 +0100 References: <20180904202500.d4e629511996125d643d7635@eigenstate.org> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0f82b6e-ead9-11e9-9d60-3106f5b1d025 On Wed, Sep 5, 2018, at 4:25 AM, Ori Bernstein wrote: > > > CPUs, such as Intel/AMD x64 > > are vastly more complex so "optimising" C compilers are trying to make > > something simple take advantage of something far more complex. > > Ironically, because of the complexity in the CPUs, many of the optimizations > make less of a difference now -- they're essentially optimizing just in time > compilers under the hood, so even terrible code will run acceptably quickly. This is an example of a real benefit to complexity, one I'm personally happy about. It's good for us 9fans, whether we want to use Plan 9's 20 year old compilers, or implement our own compilers for new or existing languages, or whatever. My ego still tries to complain about using something I don't understand, but in doing so it's really fighting its own interests. -- The lyf so short, the craft so long to lerne. -- Chaucer From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Dave MacFarlane Date: Wed, 5 Sep 2018 07:23:27 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000008c2b4e05751e0192" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e0ffacd6-ead9-11e9-9d60-3106f5b1d025 --0000000000008c2b4e05751e0192 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 4, 2018, 22:31 Chris McGee, wrote: > > I believe that the core of the problem with the C language is that is >> based upon abstracting the PDP-11 instruction set. CPUs, such as Intel/AMD >> x64 are vastly more complex so "optimising" C compilers are trying to make >> something simple take advantage of something far more complex. Perhaps we >> should call them "complexifying" compilers. >> >> Generally, model-to-model transformations (which is effectively what >> compilers do under the covers) are easier to define when we transform from >> a higher level of abstraction to a lower level of abstraction. As folks in >> the MBSE field explain it, trying to put a pig together from sausages. >> > > I wonder if the hardware world suffers from some of the same complexity > problems the software world does. Is it possible to build much simpler > hardware as well or are there real physical properties that force them to > be as complex as they are now? > Wasn't that the whole point of RISC? > --0000000000008c2b4e05751e0192 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, = Sep 4, 2018, 22:31 Chris McGee, <= newton688@gmail.com> wrote:
=

I believe that the core of the problem with the C= language is that is based upon abstracting the PDP-11 instruction set.=C2= =A0 CPUs, such as Intel/AMD x64 are vastly more complex so "optimising= " C compilers are trying to make something simple take advantage of so= mething far more complex.=C2=A0 Perhaps we should call them "complexif= ying" compilers.

Generally, model-to-model tr= ansformations (which is effectively what compilers do under the covers) are= easier to define when we transform from a higher level of abstraction to a= lower level of abstraction.=C2=A0 As folks in the MBSE field explain it, t= rying to put a pig together from sausages.
I wonder if the hardware world suffers from some of the same co= mplexity problems the software world does. Is it possible to build much sim= pler hardware as well or are there real physical properties that force them= to be as complex as they are now?
=

Wasn't that the who= le point of RISC?
--0000000000008c2b4e05751e0192-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Chris McGee Date: Wed, 5 Sep 2018 07:42:52 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000004f6e05751e472a" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e10eaa24-ead9-11e9-9d60-3106f5b1d025 --000000000000004f6e05751e472a Content-Type: text/plain; charset="UTF-8" > Wasn't that the whole point of RISC? > It could be, but after having looked briefly at the size of the design for RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. They even built their own high level hardware language (Chisel) that generates Verilog using Scala. Yuck. Also, there's appears to be quite alot of compiler optimizations in gcc for RISC-based chips. Could you get away with a much simpler, smaller hardware design and still run Plan 9 in a reasonable way? Maybe one side of the software/hardware divide has to take on more complexity to help simplify the other side? --000000000000004f6e05751e472a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Wasn't that the whol= e point of RISC?

It could be, b= ut after having looked briefly at the size of the design for RISC-V Rocket = and especially BOOM I wonder if it's all overly complicated. They even = built their own high level hardware language (Chisel) that generates Verilo= g using Scala. Yuck.

Also, there's appears to = be quite alot of compiler optimizations in gcc for RISC-based chips.
<= div>
Could you get away with a much simpler, smaller hardware= design and still run Plan 9 in a reasonable way? Maybe one side of the sof= tware/hardware divide has to take on more complexity to help simplify the o= ther side?
--000000000000004f6e05751e472a-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1536154535.3101424.1497581560.1364EF09@webmail.messagingengine.com> From: Ethan Gardener To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" References: In-Reply-To: Date: Wed, 5 Sep 2018 14:35:35 +0100 Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e11b5314-ead9-11e9-9d60-3106f5b1d025 On Wed, Sep 5, 2018, at 12:42 PM, Chris McGee wrote: > > They even built their own high level hardware language (Chisel) that generates Verilog using Scala. Yuck. >>From what I've heard of Verilog and VHDL, this is the sane approach. I only have second hand knowledge of these languages, my source is a guy who wrote his own language to compile to Verilog. :) > Could you get away with a much simpler, smaller hardware design and still run Plan 9 in a reasonable way? They did while developing Plan 9. (sorry :) Complex hardware just makes it easier to get higher performance. > Maybe one side of the software/hardware divide has to take on more complexity to help simplify the other side? I think so, and not just at that one divide. I tried designing an 8-bit CPU, but found I had to make complicated decisions to cram a reasonable instruction set into just 8 bits. I would need a broad and deep knowledge set to make good choices. Then there's Plan 9's file interface, where there's very few operations and they're very easy to use, but I think it must have required a lot of experience and careful design to choose the semantics which make those operations so easy to use. A lot of Plan 9's simplicity is like that, it took experience and careful thought to make those simple interfaces and write that seemingly simple code. -- The lyf so short, the craft so long to lerne. -- Chaucer From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Iruat=C3=A3_Souza?= Date: Wed, 5 Sep 2018 08:38:35 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e12a558a-ead9-11e9-9d60-3106f5b1d025 On Wed, Sep 5, 2018 at 4:45 AM Chris McGee wrote: > > >> Wasn't that the whole point of RISC? > > > It could be, but after having looked briefly at the size of the design fo= r RISC-V Rocket and especially BOOM I wonder if it's all overly complicated= . They even built their own high level hardware language (Chisel) that gene= rates Verilog using Scala. Yuck. > > Also, there's appears to be quite alot of compiler optimizations in gcc f= or RISC-based chips. > > Could you get away with a much simpler, smaller hardware design and still= run Plan 9 in a reasonable way? Maybe one side of the software/hardware di= vide has to take on more complexity to help simplify the other side? Take a look at greenarraychips.com and how Chuck Moore tries to simplify the whole instead of software or hardware. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Chris McGee Date: Wed, 5 Sep 2018 19:59:58 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000000b29290575289328" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e13b3ab2-ead9-11e9-9d60-3106f5b1d025 --0000000000000b29290575289328 Content-Type: text/plain; charset="UTF-8" > Take a look at greenarraychips.com and how Chuck Moore tries to > simplify the whole instead of software or hardware. > Thanks, that is a very interesting read on the topic of asynchronous and highly parallel computing. I'm not sure if the designs for these are very simple though. --0000000000000b29290575289328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Take a look at greenarraychips.com and how Chuck Moore tries to
simplify the whole instead of software or hardware.
Thanks, that is a very interesting read on the topic of asynch= ronous and highly parallel computing. I'm not sure if the designs for t= hese are very simple though.
--0000000000000b29290575289328-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bakul Shah To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Wed, 05 Sep 2018 07:42:52 -0400." References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36151.1536193971.1@bitblocks.com> Date: Wed, 5 Sep 2018 17:32:51 -0700 Message-Id: <20180906003258.9A428156E400@mail.bitblocks.com> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e15afe4c-ead9-11e9-9d60-3106f5b1d025 On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee wrote: > > It could be, but after having looked briefly at the size of the design for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level hardware language (Chisel) that > generates Verilog using Scala. Yuck. These are just tools. By embedding Chisel in Scala they can take advantage of Scala's strong typing etc. By generating verilog they can advantage of existing tool chains to produce an FPGA or ASIC or for simulation. The h/w design tool chains are pretty complex. Hard to imagine any organization has a stomach to replace them with something simpler. You can still produce simple hardware design. > Also, there's appears to be quite alot of compiler optimizations in gcc for > RISC-based chips. If you don't do this, cpu resources are not used efficiently. H/W can provide a lot of computing resources that can be used in parallel but none of the programming languages in use provide a way to get to them effectively. Part of the difficulty is that C/C++ are too low level and their processor "model" is no longer the reality. Modern CPUs have 2-3 levels of caching, TLBs etc. > Could you get away with a much simpler, smaller hardware design and still > run Plan 9 in a reasonable way? Maybe one side of the software/hardware > divide has to take on more complexity to help simplify the other side? Look at what Prof. Nicklaus Wirth did for Oberon. https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html But if all you want to do is just run plan9 why even bother? From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20180906003258.9A428156E400@mail.bitblocks.com> References: <20180906003258.9A428156E400@mail.bitblocks.com> From: Lucio De Re Date: Thu, 6 Sep 2018 05:40:06 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e169b2a2-ead9-11e9-9d60-3106f5b1d025 On 9/6/18, Bakul Shah wrote: > > But if all you want to do is just run plan9 why even bother? > But that is disingenuous, isn't it? What one wants is Plan 9 as a model for what may be a family of hardware APIs. It makes sense to promote massive parallelism, but the API to it should be sufficiently simple for a single individual to manage. Most computing devices today are single-user, even those like my new Android phone that offer shared user capabilities. Incidentally, the authorisation model in this case is inadequate for my purpose (share with a pre-teen). So we have layers and we need the complexity to be shoved into well-tested, sealed boxes that can be trusted, while the surface remains as simple as 9P. Any other model, I would prophesise, will reduce to DNA, with luggage such a model is condemned to carry. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20180906003258.9A428156E400@mail.bitblocks.com> In-Reply-To: From: Chris McGee Date: Thu, 6 Sep 2018 07:41:21 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000006736c60575325f48" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e17856ae-ead9-11e9-9d60-3106f5b1d025 --0000000000006736c60575325f48 Content-Type: text/plain; charset="UTF-8" > What one wants is Plan 9 as a > model for what may be a family of hardware APIs. It makes sense to > promote massive parallelism, but the API to it should be sufficiently > simple for a single individual to manage. > This is the what I wonder about. Is this possible at the hardware level and still support an equally simple, understandable, yet capable, software system on top? By extension, would Plan 9 would run on such a system or if it would require some fundamental changes to adapt to it. For example, does C really need to be thrown out or can it be revised. > Most computing devices today are single-user, even those like my new > Android phone that offer shared user capabilities. Incidentally, the > authorisation model in this case is inadequate for my purpose (share > with a pre-teen). > I am in this boat too, however I have a general aversion to cloud computing and so I would need some household multi-user systems for data storage and heavy processing tasks or some distributed equivalent. > So we have layers and we need the complexity to be shoved into > well-tested, sealed boxes that can be trusted, while the surface > remains as simple as 9P. > My trouble is that I don't trust the sealed boxes anymore after Meltdown, Spectre, Rowhammer, etc. Perhaps simple and auditable hardware might help with this. --0000000000006736c60575325f48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What one wants is Plan 9 as a
model for what may be a family of hardware APIs. It makes sense to
promote massive parallelism, but the API to it should be sufficiently
simple for a single individual to manage.

This is the what I wonder about. Is this possible at the hardware level = and still support an equally simple, understandable, yet capable, software = system on top? By extension, would Plan 9 would run on such a system or if = it would require some fundamental changes to adapt to it. For example, does= C really need to be thrown out or can it be revised.
=C2=A0<= br>
Most computing devices today are single-user, even those like my new
Android phone that offer shared user capabilities. Incidentally, the
authorisation model in this case is inadequate for my purpose (share
with a pre-teen).

I am in this boat too= , however I have a general aversion to cloud computing and so I would need = some household multi-user systems for data storage and heavy processing tas= ks or some distributed equivalent.
=C2=A0
So we have layers and we need the complexity to be shoved into
well-tested, sealed boxes that can be trusted, while the surface
remains as simple as 9P.

My trouble is = that I don't trust the sealed boxes anymore after Meltdown, Spectre, Ro= whammer, etc. Perhaps simple and auditable hardware might help with this.
--0000000000006736c60575325f48-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1536241071.2844369.1498804520.321D1E43@webmail.messagingengine.com> From: Ethan Gardener To: 9fans@9fans.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" In-Reply-To: <20180906003258.9A428156E400@mail.bitblocks.com> References: <20180906003258.9A428156E400@mail.bitblocks.com> Date: Thu, 6 Sep 2018 14:37:51 +0100 Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e197153a-ead9-11e9-9d60-3106f5b1d025 On Thu, Sep 6, 2018, at 1:32 AM, Bakul Shah wrote: > On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee wrote: > > Could you get away with a much simpler, smaller hardware design and still > > run Plan 9 in a reasonable way? Maybe one side of the software/hardware > > divide has to take on more complexity to help simplify the other side? > > Look at what Prof. Nicklaus Wirth did for Oberon. > https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html Oh I'd forgotten about Oberon! I started to look at it years ago, but assumed it was more complex than it actually is. It's hard to believe primary development only lasted 4 years. My point of contact with it was an OpenGL application with innovative culling of hidden objects. It was perfectly smooth, no latency; not bad for an operating system roughly in the same class as Inferno. One to put back on my to-do list. >>From the preface of P.O.System.pdf > In spite of the small number of man-years spent on > realizing the Oberon System, and in spite of its > compactness letting its description fit a single book, it > is not an academic toy, but rather a versatile > workstation system that has found many satisfied > and even enthusiastic users in academia and > industry. -- The lyf so short, the craft so long to lerne. -- Chaucer From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Richard Miller <9fans@hamnavoe.com> Date: Thu, 6 Sep 2018 18:48:02 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e2a46c5c-ead9-11e9-9d60-3106f5b1d025 > It could be, but after having looked briefly at the size of the design for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level hardware language (Chisel) that > generates Verilog using Scala. Yuck. It's possible to build a simple and perfectly usable RISC-V processor on an FPGA in verilog. The one I use is https://github.com/cliffordwolf/picorv32 , written by Clifford Wolf. Its small size means it can be (and has been) formally verified, and (for some applications at least) you can compensate for the modest performance by putting lots of them on one chip. > Also, there's appears to be quite alot of compiler optimizations in gcc for > RISC-based chips. Again, it's possible to build a simple and perfectly usable C compiler for RISC-V without going overboard with optimisation. I've been working on re-targeting the Plan 9 C toolchain for RISC-V. It's at the stage where it can successfully compile itself, but floating point support is not yet complete. If anyone is interested, let me know. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Thu, 6 Sep 2018 12:08:55 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000000d8cb3057538a088" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e2a975c6-ead9-11e9-9d60-3106f5b1d025 --0000000000000d8cb3057538a088 Content-Type: text/plain; charset="UTF-8" Thank you. This is fantastic. I've been looking into running Plan 9 in JSLinux ( https://bellard.org/jslinux/ and https://bellard.org/jslinux/tech.html) and came across riscvemu (https://bellard.org/riscvemu/). I wonder if it might be a useful for trying things on. On Thu, Sep 6, 2018 at 10:48 AM Richard Miller <9fans@hamnavoe.com> wrote: > > It could be, but after having looked briefly at the size of the design > for > > RISC-V Rocket and especially BOOM I wonder if it's all overly > complicated. > > They even built their own high level hardware language (Chisel) that > > generates Verilog using Scala. Yuck. > > It's possible to build a simple and perfectly usable RISC-V processor > on an FPGA in verilog. The one I use is > https://github.com/cliffordwolf/picorv32 , written by Clifford Wolf. > Its small size means it can be (and has been) formally verified, and > (for some applications at least) you can compensate for the modest > performance by putting lots of them on one chip. > > > Also, there's appears to be quite alot of compiler optimizations in gcc > for > > RISC-based chips. > > Again, it's possible to build a simple and perfectly usable C compiler > for RISC-V without going overboard with optimisation. I've been > working on re-targeting the Plan 9 C toolchain for RISC-V. It's at > the stage where it can successfully compile itself, but floating point > support is not yet complete. If anyone is interested, let me know. > > --0000000000000d8cb3057538a088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you.=C2=A0 This is fantastic.

I&#= 39;ve been looking into running Plan 9 in JSLinux (https://bellard.org/jslinux/=C2=A0 and=C2=A0https://bellard.org/jslinux/tech.ht= ml) and came across riscvemu (https://bellard.org/riscvemu/). I wonder if it might be a useful for t= rying things on.

On Thu, Sep 6, 2018 at 10:48 AM Richard Miller <9fans@hamnavoe.com> wrote:
<= /div>
> It could be, but after having look= ed briefly at the size of the design for
> RISC-V Rocket and especially BOOM I wonder if it's all overly comp= licated.
> They even built their own high level hardware language (Chisel) that > generates Verilog using Scala. Yuck.

It's possible to build a simple and perfectly usable RISC-V processor on an FPGA in verilog.=C2=A0 The one I use is
https://github.com/cliffordwolf/picorv32 , written by Cl= ifford Wolf.
Its small size means it can be (and has been) formally verified, and
(for some applications at least) you can compensate for the modest
performance by putting lots of them on one chip.

> Also, there's appears to be quite alot of compiler optimizations i= n gcc for
> RISC-based chips.

Again, it's possible to build a simple and perfectly usable C compiler<= br> for RISC-V without going overboard with optimisation.=C2=A0 I've been working on re-targeting the Plan 9 C toolchain for RISC-V.=C2=A0 It's a= t
the stage where it can successfully compile itself, but floating point
support is not yet complete.=C2=A0 If anyone is interested, let me know.
--0000000000000d8cb3057538a088-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris McGee Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 6 Sep 2018 17:21:09 -0400 Message-Id: <9205E070-EAD3-40A5-9F06-92DCF217BB98@gmail.com> References: In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e2b9b77e-ead9-11e9-9d60-3106f5b1d025 Thanks Richard, This looks like it fits the bill: open, small, simple. How was it formally v= erified? This doesn=E2=80=99t seem to need any of the chisel/scala suff, which is gre= at. How can I help with the compiler port? Which fpga board do you recommend? Chris On Sep 6, 2018, at 1:48 PM, Richard Miller <9fans@hamnavoe.com> wrote: >> It could be, but after having looked briefly at the size of the design fo= r >> RISC-V Rocket and especially BOOM I wonder if it's all overly complicated= . >> They even built their own high level hardware language (Chisel) that >> generates Verilog using Scala. Yuck. >=20 > It's possible to build a simple and perfectly usable RISC-V processor > on an FPGA in verilog. The one I use is > https://github.com/cliffordwolf/picorv32 , written by Clifford Wolf. > Its small size means it can be (and has been) formally verified, and > (for some applications at least) you can compensate for the modest > performance by putting lots of them on one chip. >=20 >> Also, there's appears to be quite alot of compiler optimizations in gcc f= or >> RISC-based chips. >=20 > Again, it's possible to build a simple and perfectly usable C compiler > for RISC-V without going overboard with optimisation. I've been > working on re-targeting the Plan 9 C toolchain for RISC-V. It's at > the stage where it can successfully compile itself, but floating point > support is not yet complete. If anyone is interested, let me know. >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9205E070-EAD3-40A5-9F06-92DCF217BB98@gmail.com> References: <9205E070-EAD3-40A5-9F06-92DCF217BB98@gmail.com> From: Richard Miller <9fans@hamnavoe.com> Date: Fri, 7 Sep 2018 09:32:21 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] Is Plan 9 C "Less Dangerous?" Topicbox-Message-UUID: e2d5b3fc-ead9-11e9-9d60-3106f5b1d025 > This looks like it fits the bill: open, small, simple. How was it formally verified? http://www.clifford.at/papers/2017/riscv-formal/slides.pdf > How can I help with the compiler port? Compiling & testing lots of library code would likely reveal remaining bugs. Also it might be useful to adapt the arm soft floating point code to use on RISC-V cores without hardware fp (like picorv32 or HiFive1). A 64-bit version of the compiler might also be of interest. Contact me off-list to join in. > Which fpga board do you recommend? I use the myStorm BlackIce https://www.tindie.com/products/Folknology/blackice-ii/ with a Lattice ICE40 FPGA. Not as powerful as altera or xilinx, but it works with yosys (Clifford's open-source verilog toolchain). For experimenting with a real RISC-V ASIC there's HiFive1 (has hardly any RAM so small embedded projects only). The HiFive Unleashed should be capable of running Plan 9 but will be expensive.