Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

unchecked integer overflows

This is my one big beef with the RISC-V ISA, after I went over it with a fine toothed comb, otherwise it's brilliant to my untutored eyes, and the ISA doc, a paper I read about the same time about how difficult it was to make ISAs super fast, etc. helped explain why, e.g. the VAX ISA took so long to make faster, and was probably doomed, while Intel got lucky? with x86.

Anyway, the large integer math e.g. crypto people are not happy about it, the lack of support for anything other than being able to check for divide by zero means their code will be slow compared to older ISAs that support it. And their justification in the ISA doc is that the most popular languages nowadays don't check for this, which is not the sort of thing I want to see for an ISA that's billing itself as a big thing for the future. I very much got Worse Is Better/the New Jersey vibes from this....

Although this discussion a couple of weeks ago implies it's getting some consideration: https://groups.google.com/a/groups.riscv.org/forum/#!searchi...



Intel didn't get "lucky". Going superscalar (and OoO) with CISC ISA's like the VAX, IBM/360, x86, ... obviously isn't impossible (as illustracted by IBM's zNext and Intel's everything), but it's VERY difficult (thus hard to design and verify => time to market risks) and expensive (it takes a lot of logic and more pipeline stages). An ISA like RISC-V tries to avoid as much as _practical_ of these obstackles, thus making it easier & cheaper for implementations to be fast. This part is straight out of the DEC Alpha playbook.

Re. large integers: the RISC-V 2.0 (non-priv) ISA is frozen solid so any change would have to be an extension. I've been gently pushing for the mythical vector extension to be at least friendly to large integers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: