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

India reveals RISC-V CPU roadmap, expects product by 2023

pib.gov.in

Post reply on HN
Print view View original

61–70 of 73 posts

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#61

Post by kragen »

tormeh wrote: post #59
kragen wrote: post #51

Earlier quoted context omitted.

India has a glorious history of scholarship unparallelled by any other country, but that ended centuries ago. In terms of scholarship, modern India isn't 3–4 Swedens. It's 0.2 Swedens. As one very crude measure, the Swedish-language Wikipedia has 2.56 million articles. Urdu Wikipedia has 0.17 million articles, Hindi Wikipedia has 0.15 million articles, and the other Indian-language Wikipedias like Tamil are even less…

Not that it makes a huge difference to your argument, but most countries don't look good compared to Sweden. It's a country that hits well above its weight in science and technology. A bit like South Korea.

Agreed!

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#62

Post by kragen »

avianes wrote: post #60
saagarjha wrote: post #55

Earlier quoted context omitted.

Those are "simple" fusions that processor do perform productively. The thing with RISC-V is that a lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" except nobody is really doing that kind of fusion right now, so it's not clear if this is even feasible.

> lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" There are more macro-op fusion suggestions for RISC-V precisely because RV instructions are simple. This gives more opportunity for macro-op fusion. > so it's not clear if this is even feasible What macro-op-fusion are you talking about exactly? Most of the macro-op-fusion sugge…

> Most of the macro-op-fusion suggested are quite trivial and have already been implemented

In which chips, and how much of a win are they?

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#63

Post by avianes »

kragen wrote: post #62
avianes wrote: post #60

Earlier quoted context omitted.

> lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" There are more macro-op fusion suggestions for RISC-V precisely because RV instructions are simple. This gives more opportunity for macro-op fusion. > so it's not clear if this is even feasible What macro-op-fusion are you talking about exactly? Most of the macro-op-fusion sugge…

> Most of the macro-op-fusion suggested are quite trivial and have already been implemented In which chips, and how much of a win are they?

I talk about feasibility, not about design win in a high perf. circuit, since there is no real high perf. RISC-V today and since it's the feasibility that is questioned by the parent.

I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#64

Post by kragen »

avianes wrote: post #63
kragen wrote: post #62

Earlier quoted context omitted.

> Most of the macro-op-fusion suggested are quite trivial and have already been implemented In which chips, and how much of a win are they?

I talk about feasibility , not about design win in a high perf. circuit, since there is no real high perf. RISC-V today and since it's the feasibility that is questioned by the parent. I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.

What do you mean by "implemented"?

Clearly macro-op fusion is a computable transformation of the instruction stream, so macro-op fusion is certainly feasible. I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion. The Celio/Dabbelt/Patterson/Asanović tech report I linked yesterday shows that it's promising, but it's been six years and I'd like to know if that's actually being tried and how well it works.

Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive, but he left SiFive a couple years ago and might be out of date, and the Honey Badger designs are potentially a whole new ballgame.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#65

Post by avianes »

kragen wrote: post #64
avianes wrote: post #63

Earlier quoted context omitted.

I talk about feasibility , not about design win in a high perf. circuit, since there is no real high perf. RISC-V today and since it's the feasibility that is questioned by the parent. I can't say if the macro-op fusion will be enough to beat ARM & x86, but I can tell it's feasible.

What do you mean by "implemented"? Clearly macro-op fusion is a computable transformation of the instruction stream, so macro-op fusion is certainly feasible. I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion. The Celio/Dabbelt/Patterson/Asanović tech report I linked yesterday shows that it's promising, but it's been six years and I'd like to know if th…

> I think what Jha was questioning was whether catching up to ARM is feasible if your main weapon is macro-op fusion.

I don't think so, there are indeed unrealistic macro-op fusion patterns that can reasonably be described as "unfeasible" or "unrealistic".

But macro-op fusion patterns suggested in the RISC-V spec, papers about macro-op fusion on RISC-V, and the SiFive patent on macro-op fusion are realistic and feasible.

> Bruce Hoult's comment from a few months ago suggests that it wasn't really being tried at SiFive

Commits from SiFive people's in GCC [1] suggest that short-forward-branch macro-op fusion patterns are recognized by SiFive hardware.

I don't know if they recognize other macro-op fusion patterns.

But SiFive has a bunch of stuff to improve before diving into macro-op fusion.

[1]: https://patchwork.ozlabs.org/project/gcc/patch/2019043023474...

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#66

Post by whimsicalism »

sofixa wrote: post #42
qiskit wrote: post #17

Hopefully they'll take a holistic approach - from processor to memory to disk to kernel to application. India should have players in every aspect of technology. They should also invest more in research. Why does india have less supercomputers than sweden? Does this mean that india is doing less research in some aspects than a country of just 10 million people? https://en.wikipedia.org/wiki/TOP500 India is not and has…

It's also a matter of priorities. India has(had) significant amounts of people living in pretty bad conditions ( like poor quality housing with no running water). Which do you prioritise, lifting people out of poverty/squalid living conditions, research, industrial expansion, power projection (aircraft carriers so that India can protect it's interests, live up to it's potential, counter Chinese expansion), etc. ? The…

China has managed to do both.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#67

Post by sifar »

kragen wrote: post #51
oblio wrote: post #39

Earlier quoted context omitted.

> They should also invest more in research. Why does india have less supercomputers than sweden? Does this mean that india is doing less research in some aspects than a country of just 10 million people? India is huge, but only about 100 million Indians were considered part of the global middle class before Covid and now it's apparently only about 70 million. And the global middle class starts at about $3500 per year…

India has a glorious history of scholarship unparallelled by any other country, but that ended centuries ago. In terms of scholarship, modern India isn't 3–4 Swedens. It's 0.2 Swedens. As one very crude measure, the Swedish-language Wikipedia has 2.56 million articles. Urdu Wikipedia has 0.17 million articles, Hindi Wikipedia has 0.15 million articles, and the other Indian-language Wikipedias like Tamil are even less…

>> I think the problem with India is the people in charge

There is a subliminal sentiment in India - whatever it has achieved/achieves is despite the people in charge.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#68

Post by brucehoult »

kragen wrote: post #57
saagarjha wrote: post #55

Earlier quoted context omitted.

Those are "simple" fusions that processor do perform productively. The thing with RISC-V is that a lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" except nobody is really doing that kind of fusion right now, so it's not clear if this is even feasible.

Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it. In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://…

Certainly I didn't implement it, that was Andrew Waterman. I'm not a hardware person.

I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible.

There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#69

Post by brucehoult »

jabl wrote: post #9

IIRC the Shakti family didn't include the C extension, which would make it incompatible with most Linux distros who have chosen to require it. Is this still the case?

The very first Skakti test chip didn't support C. All their following ones do.

Vega doesn't seem to be supporting C extension. A very bad decision, if true. C is not expensive to support, and certainly cheaper than building larger icache to make up for not supporting it -- let alone the cost of compiling your own Linux distro if you don't support C.

I'm not aware of a single commercially-produced RISC-V microcontroller that doesn't support the C extension, so there's no reason at all that something with MMU and FPU wouldn't.

Leaving it out is just something that is possible for student projects and to simplify early teaching, not something that is a good idea to do in real life.

Re: India reveals RISC-V CPU roadmap, expects product by 2023

#70

Post by avianes »

brucehoult wrote: post #68
kragen wrote: post #57

Earlier quoted context omitted.

Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it. In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://…

Certainly I didn't implement it, that was Andrew Waterman. I'm not a hardware person. I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible. There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the…

> High end cores want to split everything up (RISC-V comes pre-split)

Yes but a high-end core does not necessarily splits instruction the same way as RISC-V does.

For instance an indexed store:

RISC-V ISA splits it into an ADD+STORE pattern which may be recognized by macro-op fusion, while a high-end core splits it into a store_address uop (that compute the effective address and update the address field into the store-buffer entry) and a store_data uop (that update the data field into the store-buffer entry, and this uop is "address agnostic")

Post reply on HN