3 ms·

At that point, why not introduce special i63 and u63 types and use the hidden bit 63 as 'soft carry flag' to detect over/undeflow. 63 bits of integer range ough

At that point, why not introduce special i63 and u63 types and use the hidden bit 63 as 'soft carry flag' to detect over/undeflow. 63 bits of integer range ought to be enough for anyone ;) (as soon as bit 63 is set, the number would be in 'overflow state', but at the same time the lower 63 bits would preserve the wrap-around value in case that's useful). On the other hand, compilers are already free to check the CPU carry flag bit and trap on it. Those flag bits are just not exposed to programming languages (which IMHO is a serious 'dissonance' between assembly and high level languages), also CPU flags can't be carried around with their associated result value and go 'viral' like NaNs (but whether that's even useful instead of trapping immediately is another question).

jusuhi 3y ago
Because i63 won't help with 32 bit variables.
- flohofwoe 3y ago
  ...which is a bit of a weak reason when there are hardly any 32-bit CPUs around anymore though. Picking a narrower integer type makes sense in specific situations like tightly packed structs, but in that case it usually doesn't matter whether the integer range is 2^31 or 2^32, if you really need the extra bit of range it's usually ok to go to the next wider integer type.
  - jusuhi 3y ago
    Feel free to generalize my argument to i31 and i15. Also, look around you and realize that non-64-bit microprocessors outnumber 64-bit machines by orders of magnitude. There is more to the world than your laptop and smartphone. (Just within 1m of myself at this very moment I see 4 devices with a 32 bit microprocessor in them, and I'm sitting in a coffee shop reading a book. Well, and browsing HN now and then.)
    - flohofwoe 3y ago
      There's actually a better solution if you allow the compiler some wiggle room: Zig and C23 (and probably a couple other languages) support arbitrary width integers, so integer types like u15, i3, i1 or even u512 etc... are something entirely 'normal', and even useful in day-to-day coding when mixing signed and unsigned integer math (for instance Zig disallows to assign an unsigned integer to a signed integer of the same width, but it's perfectly fine to assign a 7-bit unsigned integer to an 8-bit signed integer). Down on the CPU such operations happen on the register width, and if the integer width exceeds the register width, are unrolled into a chain of op-with-carry instructions (same way we did 16- or 32-bit math back on 8-bit processors).
    - saagarjha 3y ago
      Surely your laptop and smartphone have several 32-bit microprocessors in them.
  - Findecanor 3y ago
    Pretty much all "64-bit" CPU architectures out there also have specific instructions for 32-bit arithmetic. They were designed that way partly on purpose, to cater for the enormous amount of existing program code that has been written with the assumption that an `int` is 32 bits. A large portion of that code also written with the assumption that they are also 2's complement and wrapping.
deleted 3y ago
[deleted]

jusuhi 3y ago

Because i63 won't help with 32 bit variables.

flohofwoe 3y ago
...which is a bit of a weak reason when there are hardly any 32-bit CPUs around anymore though. Picking a narrower integer type makes sense in specific situations like tightly packed structs, but in that case it usually doesn't matter whether the integer range is 2^31 or 2^32, if you really need the extra bit of range it's usually ok to go to the next wider integer type.
- jusuhi 3y ago
  Feel free to generalize my argument to i31 and i15. Also, look around you and realize that non-64-bit microprocessors outnumber 64-bit machines by orders of magnitude. There is more to the world than your laptop and smartphone. (Just within 1m of myself at this very moment I see 4 devices with a 32 bit microprocessor in them, and I'm sitting in a coffee shop reading a book. Well, and browsing HN now and then.)
  - flohofwoe 3y ago
    There's actually a better solution if you allow the compiler some wiggle room: Zig and C23 (and probably a couple other languages) support arbitrary width integers, so integer types like u15, i3, i1 or even u512 etc... are something entirely 'normal', and even useful in day-to-day coding when mixing signed and unsigned integer math (for instance Zig disallows to assign an unsigned integer to a signed integer of the same width, but it's perfectly fine to assign a 7-bit unsigned integer to an 8-bit signed integer). Down on the CPU such operations happen on the register width, and if the integer width exceeds the register width, are unrolled into a chain of op-with-carry instructions (same way we did 16- or 32-bit math back on 8-bit processors).
  - saagarjha 3y ago
    Surely your laptop and smartphone have several 32-bit microprocessors in them.
- Findecanor 3y ago
  Pretty much all "64-bit" CPU architectures out there also have specific instructions for 32-bit arithmetic. They were designed that way partly on purpose, to cater for the enormous amount of existing program code that has been written with the assumption that an `int` is 32 bits. A large portion of that code also written with the assumption that they are also 2's complement and wrapping.

deleted 3y ago

[deleted]