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