```
// this is the type used in the intrinsics signature
// (and uint64_t is unsigned long, not unsigned long long...)
using u64 = unsigned long long;
```
Can somebody explain to me why uint64_t (unsigned long according to the post) cannot be used here?
(I didn't read the article but the headline said "C++" and it did not say asm {...}, so here is a brief description of what's going on)
if you want to multiply two 8 bit numbers together, worst case (biggest numbers), you need 16 bits to hold the answer.
if you want to multiply two 16 bit numbers together, you need 32 bits to hold the answer. and so on, so you need a hardware wordsize twice as big as what you are trying to do.
if you don't have 64 bits, and you decide to use 32 to mimic it, well 32's require 64's to hold the answer and we just agreed you don't have 64s, so you need to go to 16 to catch the overflow into 32 so you can piecewise handle the 16 bit halves of the 32 to mimic the 64 you are trying to pretend you have. It's really just like gradeschool multiplication on paper where you piecewise multiply and add the different pieces together appropriately.
-----
"in hardware", like inside the CPU, you can handle calculations in exactly the space you have because you have extra bit flags like "overflow" OVR and you can do shifts to handle a bit at a time, etc. or even a ton of extra bits that add up to 128 even though the results will be in 64 bit registers. at the level of C and C++ you don't have the facilities for that (a glaring omission imho, but so called smart people are dedicated to taking C even farther from being useful for what it's useful for)
It's basically: long* and long long* (the pointer types) are not compatible, and uint64_t is the "wrong" typedef on linux, or at least inconsistent with the way the intrinsics are defined.
Can somebody explain to me why uint64_t (unsigned long according to the post) cannot be used here?