Errr, correct me if I'm wrong, but as I read the v2 RISC-V spec (starting with the absence of a flags register!), plus some quality time on Google, RISC-V has no provision for integer computation errors besides divide by zero (which can be checked for). From the spec:
"We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior."
!!!
Or, RISC-V is a Worse is Better (https://en.wikipedia.org/wiki/Worse_is_better), New Jersey style processor, following the same exact model of the primacy of implementation simplicity.
Well, especially since we aren't going to get people to use "safe" languages prior to e.g. software errors killing 4-6 figures of people, I guess it's a really good thing you're adding tag bits that can be used to improve security in unsafe languages.
On the other hand, as a CPU for The Right Way operating systems and languages like Lisp, RISC-V would seem to be ... subpar, especially since who knows what other corners have or will be cut. (Yeah, I know you can check, and for Lisps, it would be fairly cheap to have fixnums be 32 to 29 bits (subtracting LSB bits for more tagging) and then promote them to bignums, but....)
While I think you're doing a very good thing for the world as it is, my personal interest has dropped ... but that's OK, I've got a couple of years to muse about this as you develop your design and get it into production.
I am personally very sympathetic to concerns about the efficiency of overflow checking. There has been some discussion of this on the riscv-hw mailing list, e.g. https://lists.riscv.org/lists/arc/hw-dev/2014-09/msg00007.ht.... The current position of the Berkeley team is that overflow checking just adds a single rarely taken branch, which can easily be predicted. If new data is produced (such as evaluating a wider range of instruction traces, e.g. those from programs not in C), there may well be an argument to be made for new instruction set additions. There is a plan for some sort of RISC-V consortium with representation from all major implementors, though this is will take a while to develop. I imagine we'll be discussing this at the RISC-V Workshop 14th-15th Jan in CA http://riscv.org/workshop/
> the current position of the Berkeley team is that overflow checking just adds a single rarely taken branch, which can easily be predicted
I find this argument VERY weak: you need many of these 'very rarely taken branch' overflow checking instructions and they pollute the instruction cache..
"We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior."
!!!
Or, RISC-V is a Worse is Better (https://en.wikipedia.org/wiki/Worse_is_better), New Jersey style processor, following the same exact model of the primacy of implementation simplicity.
Well, especially since we aren't going to get people to use "safe" languages prior to e.g. software errors killing 4-6 figures of people, I guess it's a really good thing you're adding tag bits that can be used to improve security in unsafe languages.
On the other hand, as a CPU for The Right Way operating systems and languages like Lisp, RISC-V would seem to be ... subpar, especially since who knows what other corners have or will be cut. (Yeah, I know you can check, and for Lisps, it would be fairly cheap to have fixnums be 32 to 29 bits (subtracting LSB bits for more tagging) and then promote them to bignums, but....)
While I think you're doing a very good thing for the world as it is, my personal interest has dropped ... but that's OK, I've got a couple of years to muse about this as you develop your design and get it into production.