5 ms·
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
by asb 12y ago
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.html 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/ http://riscv.org/workshop/
- renox 12y ago> 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..