3 ms·

It could be, if the hardware supported it. Consider this quote from that page: "in some debug configurations overflow is detected and results in a panic" That

It could be, if the hardware supported it. Consider this quote from that page: "in some debug configurations overflow is detected and results in a panic" That's not good enough. We want to always detect it! Many critical bugs are caused by this in production builds too. Solving it at the language level would require inserting branches on every integer operation which is obviously not acceptable.

tialaramex 3y ago
> That's not good enough. We want to always detect it So, select the configuration where that's the behaviour? overflow-checks = true > Solving it at the language level would require inserting branches on every integer operation Yes, so that's what you have to do if you actually want this, if you won't pay for it then you can't have it.
- andersa 3y ago
  Well, the whole point of my post was that I would really like a hardware feature that does it without overhead. How that would work behind the scenes, I have no idea. Not a hardware engineer.
  - tialaramex 3y ago
    If you really want it, use it. Hardware vendors optimise stuff they see being done, they don't optimise stuff that somebody mentioned on a forum they'd kinda like but have never used because it was expensive. Maybe if you have Apple money and can buy ARM or something then you could just express such whims, but for mere mortals that's not an option. Newer CPUs in several lines clearly optimise to do Acquire-Release because while it's not the only possible concurrency ordering model, it's the one the programmers learned, so if you make that one go faster your benchmark numbers improve. Modern CPUs often have onboard AES. That's not because it won a competition, not directly, it's because everybody uses it - without hardware support they use the same encryption in software. The Intel 486DX and then the Pentium happened because it turns out that people like FPUs, and eventually enough people were buying an FPU for their x86 computer that you know, why not sell them a $100 CPU and a $100 FPU as a single device for $190, they save $10 and you keep the $80+ you saved because duh, that's the same device as the FPU nobody is making an actual separate FPU you fools. Even the zero-terminated string, which I think is a terrible idea, is sped up on "modern" hardware because the CPU vendors know C programs will use that after the 1970s.

tialaramex 3y ago

> That's not good enough. We want to always detect it So, select the configuration where that's the behaviour? overflow-checks = true > Solving it at the language level would require inserting branches on every integer operation Yes, so that's what you have to do if you actually want this, if you won't pay for it then you can't have it.

andersa 3y ago
Well, the whole point of my post was that I would really like a hardware feature that does it without overhead. How that would work behind the scenes, I have no idea. Not a hardware engineer.
- tialaramex 3y ago
  If you really want it, use it. Hardware vendors optimise stuff they see being done, they don't optimise stuff that somebody mentioned on a forum they'd kinda like but have never used because it was expensive. Maybe if you have Apple money and can buy ARM or something then you could just express such whims, but for mere mortals that's not an option. Newer CPUs in several lines clearly optimise to do Acquire-Release because while it's not the only possible concurrency ordering model, it's the one the programmers learned, so if you make that one go faster your benchmark numbers improve. Modern CPUs often have onboard AES. That's not because it won a competition, not directly, it's because everybody uses it - without hardware support they use the same encryption in software. The Intel 486DX and then the Pentium happened because it turns out that people like FPUs, and eventually enough people were buying an FPU for their x86 computer that you know, why not sell them a $100 CPU and a $100 FPU as a single device for $190, they save $10 and you keep the $80+ you saved because duh, that's the same device as the FPU nobody is making an actual separate FPU you fools. Even the zero-terminated string, which I think is a terrible idea, is sped up on "modern" hardware because the CPU vendors know C programs will use that after the 1970s.