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

RISC-V: An Open Standard for SoCs

eetimes.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: RISC-V: An Open Standard for SoCs

#11

Post by gioele »

bsder wrote: post #8

The dirty secret is: nobody cares because the ISA doesn't matter. When programming a modern microcontroller, I regularly think: "Gee, I wish I had more pins." "Gee, I wish I had documentation on that peripheral." "Gee, I wish I had better tool support." or "Gee, I wish I had more RAM/Flash/MHz." I never think "Gee, I wish I had a better ISA". I applaud the effort to make an open microprocessor especially in light of…

> I never think "Gee, I wish I had a better ISA".

After programming with AltiVec, going back to MMX/SSE made me wish I had a better ISA.

Re: RISC-V: An Open Standard for SoCs

#13

Post by rwmj »

comex wrote: post #9
userbinator wrote: post #6

The widening gap between memory and core speeds suggests to me that traditional RISC philosophy is not the way forward for performance and efficiency; fixed-length instructions, load-store restrictions, and delay slots may make implementation easier and faster at a time when memory could keep up with the CPU and instruction decoding was the bottleneck, but now that memory is often the bottleneck, it makes sense to ha…

> Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, Speaking of this, I find it interesting that ARM went back to a fixed 32-bit instruction width for ARMv8 (from 16/32 in Thumb-2). Any idea why they chose to do this?

ARMv8 is targeted at very high end phones but mainly at servers (of course it will creep down into cheap feature phones eventually). My server has 16 GB of RAM which is small for an ARMv8 server. So memory pressure may be not such a problem.

However it's also worth saying that Cortex-A53 can run Thumb-2 instructions. Not sure about Cortex-A57.

Re: RISC-V: An Open Standard for SoCs

#14

Post by pjc50 »

userbinator wrote: post #6

The widening gap between memory and core speeds suggests to me that traditional RISC philosophy is not the way forward for performance and efficiency; fixed-length instructions, load-store restrictions, and delay slots may make implementation easier and faster at a time when memory could keep up with the CPU and instruction decoding was the bottleneck, but now that memory is often the bottleneck, it makes sense to ha…

I suppose now is the time for me to patent my idea of Huffman-coded instruction sets. Avoid wasting a single bit!

Re: RISC-V: An Open Standard for SoCs

#15

Post by mpoloton »

filereaper wrote: post #4

I can understand RISC-V's use in academic settings or if you truly want open hardware. But what's the commercial benefit? Its an open core, its lacking patents because the performance critical aspects have been patented by others in their designs, so how does this stack up in terms of performance? Can you make a processor design as fast as proprietary ones like the Linux effort? Second comes the issue of fabrication,…

I think Open ISAs such as SPARC, OpenRISC and RISCV and their related ecosystems and tools provide the following opportunities:

-Educational: Engaging more people in hardware design and creating a much bigger community who can understand and design complex systems without the need to start from scratch. Moreover, a larger community leads to the improvements and maturity quicker than propriety solutions.

-Commercial: I agree that they may not be able to compete with proprietary solutions in few applications in near future. However, in many applications the combination of open ISAs and proprietary solution enable faster customization and development time. A good example is NavSpark/Venus (http://navspark.mybigcommerce.com/), a GNSS solution based on Leon3 with an attractive price and competitive features comparable to the state of the art.

-Security: As mentioned by others

Re: RISC-V: An Open Standard for SoCs

#16

Post by renox »

bsder wrote: post #8

The dirty secret is: nobody cares because the ISA doesn't matter. When programming a modern microcontroller, I regularly think: "Gee, I wish I had more pins." "Gee, I wish I had documentation on that peripheral." "Gee, I wish I had better tool support." or "Gee, I wish I had more RAM/Flash/MHz." I never think "Gee, I wish I had a better ISA". I applaud the effort to make an open microprocessor especially in light of…

> The dirty secret is: nobody cares because the ISA doesn't matter.

I disagree!! While normal operations don't matter, think about features like 'trap on integer overflow', if it was widespread in the popular ISAs we would have language which would use this semantic and as a result less bugs.

Another interesting feature could be Azul's Vega realtime GC support but I don't know if this requires a change of the ISA, or if it's just a MMU feature..

Hardware capabilities/segmentation would also require support in the ISA.

That said I agree with you that the RISC-V is just 'yet another ISA' which doesn't have interesting technical features, it's main feature is that it is open and you can implement it without paying someone for the privilege.

Re: RISC-V: An Open Standard for SoCs

#17

Post by wolfgke »

rwmj wrote: post #13
comex wrote: post #9

Earlier quoted context omitted.

> Variable-length instructions are especially beneficial to code density, since often-used instructions can be encoded in fewer bytes, Speaking of this, I find it interesting that ARM went back to a fixed 32-bit instruction width for ARMv8 (from 16/32 in Thumb-2). Any idea why they chose to do this?

ARMv8 is targeted at very high end phones but mainly at servers (of course it will creep down into cheap feature phones eventually). My server has 16 GB of RAM which is small for an ARMv8 server. So memory pressure may be not such a problem. However it's also worth saying that Cortex-A53 can run Thumb-2 instructions. Not sure about Cortex-A57.

According to http://en.wikipedia.org/wiki/ARM_Cortex-A57 the Cortex-A57 supports Thumb-2 instructions.

Re: RISC-V: An Open Standard for SoCs

#18

Post by thesz »

userbinator wrote: post #6

The widening gap between memory and core speeds suggests to me that traditional RISC philosophy is not the way forward for performance and efficiency; fixed-length instructions, load-store restrictions, and delay slots may make implementation easier and faster at a time when memory could keep up with the CPU and instruction decoding was the bottleneck, but now that memory is often the bottleneck, it makes sense to ha…

You are not quite right, to put it mildly.

The real problem is energy efficiency, it shows its head everywhere, from embedded systems and tablets to supercomputers. Even desktops are affected - you can cut cost of machine by having less costly power supply.

Most of the time you are not constrained by information stored in instruction cache for RISC CPUs, because most of time is being spent in some tight loop. And you can see how hard it is to create an energy efficient implementation for x86, partially (and in noticeable part) because x86 decoder is complex.

Re: RISC-V: An Open Standard for SoCs

#19

Post by thesz »

modeless wrote: post #5

Looks cool! Disappointed that there's no option to trap on integer overflow. Languages don't support it because processors don't support it, and processors don't support it because languages don't require it; a vicious cycle that someone needs to break.

Most of the time you don't need integer overflow. When you need it, you can insert a check.

I consider integer addition commands in MIPS a mistake. They take up CPU real estate, they slow down design and in the end they are not even used!

The handling of division overflow in MIPS is more fair. If you can have a division that may iverflow, compiler inserts a check. Resources are wasted only here, not everywhere.

Re: RISC-V: An Open Standard for SoCs

#20

Post by modeless »

thesz wrote: post #19
modeless wrote: post #5

Looks cool! Disappointed that there's no option to trap on integer overflow. Languages don't support it because processors don't support it, and processors don't support it because languages don't require it; a vicious cycle that someone needs to break.

Most of the time you don't need integer overflow. When you need it, you can insert a check. I consider integer addition commands in MIPS a mistake. They take up CPU real estate, they slow down design and in the end they are not even used! The handling of division overflow in MIPS is more fair. If you can have a division that may iverflow, compiler inserts a check. Resources are wasted only here, not everywhere.

I'm going to assume you meant "most of the time you don't need integer overflow checks", because that makes more sense with the rest of your comment.

I couldn't disagree more. If you look at real programs, overflow would be a bug for the vast majority of the integer arithmetic instructions. Therefore overflow checking should be the default. Wraparound overflow is sometimes useful and should be available but it should not be the default.

For example, http://www.cs.utah.edu/~regehr/papers/overflow12.pdf finds that there are ~200 instances of overflowing integer arithmetic instructions in all of SPEC CINT2000 (many of which are bugs). Every other integer arithmetic instruction in SPEC CINT2000 (orders of magnitude more than 200, of course) should never overflow; overflow would definitely be a bug and overflow checks would be useful in catching such bugs.

See http://blog.regehr.org/archives/1154 for a more complete argument. I really hope that if an ISA really does become "the standard ISA for all computing devices" as RISC-V aspires to, that it supports integer overflow traps.

Post reply on HN