Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I will be using RISC-V in my next chip

adapteva.com

Post reply on HN
Print view View original

31–40 of 100 posts

Re: Why I will be using RISC-V in my next chip

#31

Post by legulere »

dbdjxjcnd wrote: post #2

SIMD and VLIW are the future of microprocessors, and unfortunately it doesn't seem like this ISA will be able to support them.

By what I've been told, VLIW makes only really sense in some use cases such as DSP processors. With general purpose computing it happens way too often that you can't find enough instructions that are independent of each other. For the case where it is possible to execute instructions in parallel, you can make your CPU superscalar. The simple nature of the RISC-V ISA probably should make supercalarability easy and performant.

Re: Why I will be using RISC-V in my next chip

#32

Post by _chris_ »

protomyth wrote: post #29
_chris_ wrote: post #22

Earlier quoted context omitted.

There's a chapter in the current RISC-V manual that explains how you could make a RISC-V-like VLIW ISA. But VLIW is most certainly NOT the "future". VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code. And the concept of baking into your ISA what the designer believes is the "perfect functional unit mix" is an anti-pattern. What's the perfect mix depe…

"VLIW demands an even "mix" of instruction types,and it's hugely incompatible with general-purpose application core." Has anyone ever done a study / experiment of a VLIW with multiple hardware threads and how that would impact the need for an even mix?

The studies I've seen have shown that the FU mix is heavily skewed and changing on every basic block, particularly when you offload the DLP to a more efficient vector/SIMD unit.

I'm not sure I see how MT would solve the mix problem, if each thread gets an issue cycle (and each thread itself has a bad mix).

Re: Why I will be using RISC-V in my next chip

#33

Post by protomyth »

_chris_ wrote: post #32
protomyth wrote: post #29

Earlier quoted context omitted.

"VLIW demands an even "mix" of instruction types,and it's hugely incompatible with general-purpose application core." Has anyone ever done a study / experiment of a VLIW with multiple hardware threads and how that would impact the need for an even mix?

The studies I've seen have shown that the FU mix is heavily skewed and changing on every basic block, particularly when you offload the DLP to a more efficient vector/SIMD unit. I'm not sure I see how MT would solve the mix problem, if each thread gets an issue cycle (and each thread itself has a bad mix).

I was just thinking that the the bad mixes might on average fill in the gaps to what the processor actually had for resources.

Re: Why I will be using RISC-V in my next chip

#34

Post by zhemao »

legulere wrote: post #31
dbdjxjcnd wrote: post #2

SIMD and VLIW are the future of microprocessors, and unfortunately it doesn't seem like this ISA will be able to support them.

By what I've been told, VLIW makes only really sense in some use cases such as DSP processors. With general purpose computing it happens way too often that you can't find enough instructions that are independent of each other. For the case where it is possible to execute instructions in parallel, you can make your CPU superscalar. The simple nature of the RISC-V ISA probably should make supercalarability easy and per…

We already have a RISC-V superscalar out-of-order core, the Berkeley Out-of-Order Machine (BOOM).

https://github.com/ucb-bar/riscv-boom

Re: Why I will be using RISC-V in my next chip

#35

Post by creshal »

protomyth wrote: post #33
_chris_ wrote: post #32

Earlier quoted context omitted.

The studies I've seen have shown that the FU mix is heavily skewed and changing on every basic block, particularly when you offload the DLP to a more efficient vector/SIMD unit. I'm not sure I see how MT would solve the mix problem, if each thread gets an issue cycle (and each thread itself has a bad mix).

I was just thinking that the the bad mixes might on average fill in the gaps to what the processor actually had for resources.

Even GPUs, which have arguably far more predictable instruction mixes, struggled massively to get a useful utilization on VLIW architectures – AMD tried two different ones from 2006 to 2011 before they finally gave up on the concept and started using RISC architectures like Nvidia had been using all the time.

Re: Why I will be using RISC-V in my next chip

#36

Post by chei0aiV »

nickpsecurity wrote: post #30
purpled_haze wrote: post #28

Earlier quoted context omitted.

Even though it isn't GPL anymore, how exactly would it kill all hope?

How much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you'r…

How does the GPL prevent those costs from being recovered?

Re: Why I will be using RISC-V in my next chip

#37

Post by wmf »

protomyth wrote: post #29
_chris_ wrote: post #22

Earlier quoted context omitted.

There's a chapter in the current RISC-V manual that explains how you could make a RISC-V-like VLIW ISA. But VLIW is most certainly NOT the "future". VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code. And the concept of baking into your ISA what the designer believes is the "perfect functional unit mix" is an anti-pattern. What's the perfect mix depe…

"VLIW demands an even "mix" of instruction types,and it's hugely incompatible with general-purpose application core." Has anyone ever done a study / experiment of a VLIW with multiple hardware threads and how that would impact the need for an even mix?

The point of VLIW is to eliminate the hazard detection and scheduling logic required by normal superscalar, but SMT would require much of that logic to be added back. So VLIW can't really use SMT. VLIW could use FGMT (e.g. barrel processor) or SoEMT, but those can't fill the empty issue slots caused by bad instruction mix.

Re: Why I will be using RISC-V in my next chip

#38

Post by colejohnson66 »

nickpsecurity wrote: post #30
purpled_haze wrote: post #28

Earlier quoted context omitted.

Even though it isn't GPL anymore, how exactly would it kill all hope?

How much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you'r…

How does the GPL prevent them from making money? Sure, I have essentially the source code of someone's processor, but unless I have millions of dollars to fabricate a chip, the source's only use is to learn how things work.

Intel, if they wanted to, could release the source code of their microcode for their processors under the GPLv2 and not provide the signing certificate (like TiVo did), and all people would be able to do with it is study it. What am I gonna do with the source code of a processor? Build an emulator? I already have the instruction manual...

Re: Why I will be using RISC-V in my next chip

#39

Post by nickpsecurity »

chei0aiV wrote: post #36
nickpsecurity wrote: post #30

Earlier quoted context omitted.

How much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you'r…

How does the GPL prevent those costs from being recovered?

By allowing anyone to knock off the chip without paying back the R&D. There's already a huge market of counterfeits and clones coming out of China for most things you can think of. It's even easier without reverse engineering: hand design to a fab, individual or MPW, then package and sell the chips.

Very little of the price of chips you buy is the material or packaging costs. It's mostly R&D recoup, marketing, administrative, and profit. Most of these companies get all that straight through sales of the chips. Eliminate everything but a tiny margin over physical costs and whats left for further development?

Re: Why I will be using RISC-V in my next chip

#40

Post by nickpsecurity »

colejohnson66 wrote: post #38
nickpsecurity wrote: post #30

Earlier quoted context omitted.

How much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you'r…

How does the GPL prevent them from making money? Sure, I have essentially the source code of someone's processor, but unless I have millions of dollars to fabricate a chip, the source's only use is to learn how things work. Intel, if they wanted to, could release the source code of their microcode for their processors under the GPLv2 and not provide the signing certificate (like TiVo did), and all people would be abl…

Main reply here:

https://news.ycombinator.com/item?id=10873839

Microcode is a separate issue that's debateable. Their CPU hardware, patents, logistics, ecosystem, and branding are real source of revenue. Microcode release might nit hurt them. However, it might contain trade secret methods for utilizing hardware in a clever way that could give competition (mainly startups) an edge. Biggest players, esp AMD, probably already RE'd it.

That said, Im for opening up microcode and even push for microcoded RISC-V. The reason is you can do all kinds of stuff from optimizing algorithms to atomic functions. There were also HLL-to-microcode compilers in the past to make it easier.

Look up PALcode on Alpha ISA if you want a nice hybrid, too.

Post reply on HN