3 ms·

Chicken, meet egg: We did not include special instruction set support for over ow checks on integer arithmetic operations. Most popular programming languages d

by alricb 12y ago

Chicken, meet egg: We did not include special instruction set support for over ow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a signicant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior. [1] Please Regehr, don't hurt them. [2] [1] Spec, section 2.4 https://s3-us-west-1.amazonaws.com/riscv.org/riscv-spec-v2.0.pdf https://s3-us-west-1.amazonaws.com/riscv.org/riscv-spec-v2.0... [2] http://blog.regehr.org/archives/1154 http://blog.regehr.org/archives/1154

tachyonbeam 12y ago
I happen to be implementing my own JavaScript JIT compiler and I can tell you that SpiderMonkey, V8 and my compiler all perform a lot of overflow checks. This is because in JavaScript, all numbers are doubles, but JITs typically try to represent them as integers where possible, because integer operations have lower latency. Scheme and Common Lisp also rely on overflow checks to optimize small integers as "fixnums" instead of always using arbitrary precision arithmetic. Not having hardware support for overflow checks would complicate the implementation of many dynamic languages, and reduce their performance significantly. Not sure what this guy was thinking. It can't be that hard to implement some overflow flag you can branch on, I mean, adders basically produces that information for free, don't they? Seems like a poor design choice.
- ajb 12y ago
  Hmm; carry is free, not sure about overflow. But more generally, it's an extra output, for what would otherwise be one-output operations. Put it this way - if a lot of javascript operations could modify a piece of global state, that would be trivial on a trivial interpreter, but I bet it would add a lot of complexity to your JIT. Same goes for CPUs - no problem for simple implementations, but it would add complexity to an out-of-order or other clever microarchitecture.
  - kps 12y ago
    > Hmm; carry is free, not sure about overflow. Overflow is just the final carry out XOR the second-last carry bit, so it's practically free. Of course RISC-V doesn't have a carry bit either!
hornetblack 12y ago
Mill architecture support it, by having multiple add instructions. add is wraparound add. addx returns a NaR^[1]. addw returns a double width value. As Mill stores integer size of registers these instructions apply to all integer sizes and vectors, without having separate instructions for each width (and vectors). [1] NaR will propagate an error, but trigger an exception if it's stored or branched on.
renox 12y ago
Yes, in this day and age, making a new ISA worst than the MIPS ISA (which had TRAP on integer overflow) with regards to integer overflow behaviour is really annoying. IMHO this is cost saving going too far.. I wish that the mill succeed instead, at least it brings new things regarding security!

by alricb 12y ago

tachyonbeam 12y ago

I happen to be implementing my own JavaScript JIT compiler and I can tell you that SpiderMonkey, V8 and my compiler all perform a lot of overflow checks. This is because in JavaScript, all numbers are doubles, but JITs typically try to represent them as integers where possible, because integer operations have lower latency. Scheme and Common Lisp also rely on overflow checks to optimize small integers as "fixnums" instead of always using arbitrary precision arithmetic. Not having hardware support for overflow checks would complicate the implementation of many dynamic languages, and reduce their performance significantly. Not sure what this guy was thinking. It can't be that hard to implement some overflow flag you can branch on, I mean, adders basically produces that information for free, don't they? Seems like a poor design choice.

ajb 12y ago
Hmm; carry is free, not sure about overflow. But more generally, it's an extra output, for what would otherwise be one-output operations. Put it this way - if a lot of javascript operations could modify a piece of global state, that would be trivial on a trivial interpreter, but I bet it would add a lot of complexity to your JIT. Same goes for CPUs - no problem for simple implementations, but it would add complexity to an out-of-order or other clever microarchitecture.
- kps 12y ago
  > Hmm; carry is free, not sure about overflow. Overflow is just the final carry out XOR the second-last carry bit, so it's practically free. Of course RISC-V doesn't have a carry bit either!

hornetblack 12y ago

Mill architecture support it, by having multiple add instructions. add is wraparound add. addx returns a NaR^[1]. addw returns a double width value. As Mill stores integer size of registers these instructions apply to all integer sizes and vectors, without having separate instructions for each width (and vectors). [1] NaR will propagate an error, but trigger an exception if it's stored or branched on.

renox 12y ago

Yes, in this day and age, making a new ISA worst than the MIPS ISA (which had TRAP on integer overflow) with regards to integer overflow behaviour is really annoying. IMHO this is cost saving going too far.. I wish that the mill succeed instead, at least it brings new things regarding security!