Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

Thanks Richard, This looks like it fits the bill: open, small, simple. How was it formally verified? This doesn’t seem to need any of the chisel/scala suff, which is great. How can I help with the compiler port? Which fpga board do you recommend? Chris On Sep 6, 2018, at 1:48 PM, Richard

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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 for > RISC-V Rocket and especially BOOM I wonder if it's all overly complicated. > They even built their own high level

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> 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.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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,

Re: [9fans] Is Plan 9 C "Less Dangerous?"

> > 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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

Thanks everyone. This is pretty much what I expected was the case. I just wanted to confirm my understanding. Plan 9 C was re-engineered with some focus on readable code. Readability is expected to make bugs more apparent, making it less “dangerous.” Linux is so huge and hard to read that even

Re: [9fans] Is Plan 9 C "Less Dangerous?"

On 9/2/18, hiro <23h...@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.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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: >

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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"

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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?

Re: [9fans] Is Plan 9 C "Less Dangerous?"

the most significant change that plan9’s 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’s kernel is fairly safe is its clean and simple design, which makes problems less likely.

Re: [9fans] Is Plan 9 C "Less Dangerous?"

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

Re: [9fans] Is Plan 9 C "Less Dangerous?"

"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.

[9fans] Is Plan 9 C "Less Dangerous?"

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.