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

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1055 bytes --]

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

[hiro]

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

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

[Lucio De Re]

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.

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

[Chris McGee]

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 simple things like C have become sharp edges that cut people. 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’ve read some of the 9front kernel code trying to make it work on raspberry pi. I admit that I didn’t find any bugs at that time. The code is relatively easy to follow even for me. So, I suppose it’s working nicely.

Chris

> On Sep 3, 2018, at 12:07 AM, Lucio De Re <lucio.dere@gmail.com> wrote:
> 
>> 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.
> 

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

[Ethan Gardener]

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

[Lucio De Re]

On 9/3/18, Ethan Gardener <eekee57@fastmail.fm> 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.

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

[Ethan Gardener]

On Tue, Sep 4, 2018, at 11:51 AM, Lucio De Re wrote:
> On 9/3/18, Ethan Gardener <eekee57@fastmail.fm> 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.

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 792 bytes --]

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

[Lucio De Re]

On 9/2/18, Chris McGee <newton688@gmail.com> 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.

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

[Steve Simon]

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.

nothing cleverer than that (imho). Sorry, no magic.

-Steve


> On 2 Sep 2018, at 19:16, Lucio De Re <lucio.dere@gmail.com> wrote:
> 
>> On 9/2/18, Chris McGee <newton688@gmail.com> 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.

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

[Iruatã Souza]

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

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ã Souza <iru.muzgo@gmail.com> 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?
>
>

[-- Attachment #2: Type: text/html, Size: 1513 bytes --]

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

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 <newton688@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 1655 bytes --]

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

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 <newton688@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 1659 bytes --]

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

[Tyga]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

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 <charles.forsyth@gmail.com>
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 <newton688@gmail.com> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 2729 bytes --]

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1160 bytes --]

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

[Dave MacFarlane]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

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

>

[-- Attachment #2: Type: text/html, Size: 1800 bytes --]

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

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

[Ethan Gardener]

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

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

[Iruatã Souza]

On Wed, Sep 5, 2018 at 4:45 AM Chris McGee <newton688@gmail.com> 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 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?

Take a look at greenarraychips.com and how Chuck Moore tries to
simplify the whole instead of software or hardware.

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 568 bytes --]

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

[Bakul Shah]

On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee <newton688@gmail.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.

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?

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

[Lucio De Re]

On 9/6/18, Bakul Shah <bakul@bitblocks.com> 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.

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

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1886 bytes --]

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

[Ethan Gardener]

On Thu, Sep 6, 2018, at 1:32 AM, Bakul Shah wrote:
> On Wed, 05 Sep 2018 07:42:52 -0400 Chris McGee <newton688@gmail.com> 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

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

[Richard Miller]

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

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2106 bytes --]

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

[Chris McGee]

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

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

[Richard Miller]

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

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

[Ori Bernstein]

On Wed, 5 Sep 2018 09:30:22 +1000, Tyga <cyberfonic@gmail.com> 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

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

[Ethan Gardener]

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