An ex-ARM engineer critiques RISC-V

Re:An ex-ARM engineer critiques RISC-V by spacenick88 on Sunday November 01, 2020 @03:41PM (#24962325)

I wonder how this interacts with branch prediction. Since overflows should happen very rarely I guess the branch on overflow should almost always predict as non taken. So wouldn't it be possible to have a "branch if add would overflow" instruction or even canonical sequence that a higher end CPU can completely speculate around and just use speculation rollback if it overflows?

I think an important design point here is that the languages that need a lot of dynamic overflow checks are primarily used on beefier CPUs so if you can get around the code size issue, making it performant only on more capable designs is fine since the overflow check will be rare on simpler CPUs.

[ Parent | on HN ]

Re:An ex-ARM engineer critiques RISC-V by pizlonator on Sunday November 01, 2020 @03:45PM (#24962354)

I don’t think that beefier cpu and overflow checks are that related. I mean, you’re right, I just want to place some limits on how right you are.

1. Folks totally run JS and other crazy on small CPUs.

2. Other safe languages (rust and swift I think?) also use overflow checks. It’s probably a good thing if those languages get used more on small cpus.

3. The C code that normally runs on small cpus is hella vulnerable today and probably for a long time to come. Compiling with sanitizer flags that turn on overflow checks is a valuable (and oft requested) mitigation. So theres a future where most arithmetic is checked on all cpus and with all languages.

And yeah, it’s true that the overflow check is well predicted. And yeah, it’s true that what arm and x86 do here isn’t the best thing ever, just better than risc-v.

[ Parent | on HN ]

Re:An ex-ARM engineer critiques RISC-V by spacenick88 on Sunday November 01, 2020 @04:44PM (#24962790)

Interestingly it seems rust only does full overflow checking in debug builds: https://huonw.github.io/blog/2016/04/myths-and-legends-about...

[ Parent | on HN ]

Re:An ex-ARM engineer critiques RISC-V by masklinn on Monday November 02, 2020 @02:09PM (#24971818)

By default yes, but you can enable overflow checking in release mode (it’s a conf / compiler flag), and it has standard functions for checked, wrapping, and saturating ops.

[ Parent | on HN ]

Re:An ex-ARM engineer critiques RISC-V by spacenick88 on Sunday November 01, 2020 @04:34PM (#24962702)

Yeah I know about 1 e.g. also MicroPython, no idea if that's used outside DIY though. I agree about rust but I would think that with much stronger type safety and static compilation it should be able to remove a lot more of the overflow checks and most that remain would be needed in correct C too. At least that's what I learned from my compilers prof who worked on Ada compilers for many years and that should be quite similar. But maybe that's my biased hope as I really really hate working with dynamic languages.

[ Parent | on HN ]

Re:An ex-ARM engineer critiques RISC-V by brandmeyer on Sunday November 01, 2020 @06:24PM (#24963452)

The current world record holder (in the published literature) for branch prediction is TAGE and its derivatives. The G stands for Geometric. It is composed of a family of global predictors that increase in length with a geometric progression. That's somewhat relieving since it means that the storage growth is not unlike that of mipmapping in computer graphics. A small constant k times maximum history length N.

But to a first approximation, if you double the density of conditional branches in the program, then you will need to roughly double the size of the branch prediction tables to get the same performance, even if all of them are correctly predicted 100% of the time.

[ Parent | on HN ]