The article is very recent (September 2023 [1]), mentions that "rax is used to return integer values" in the SysV ABI (hence implicitly the 64-bit SysV ABI). Also confirmed in this excerpt:
> Note that the top 56 bits in rax are not zeroed – they contain junk. This is fine b/c the compiler will only make callers check the lowest bit of a register for boolean operations. This is why changing the compiler’s “understanding” (ie the cast) is necessary.
... and yet, the function ABI is clearly i386 (fetching arguments from stack) and indeed everything is compiled with -m32 [2] (i.e. 32-bit SysV ABI). This is a strange contradiction in 2023. On the Intel/AMD side, x86_64 has been prevalent (and the default) for... more than 15 years?
It does not invalidate the article's point. But it is slightly confusing....
The article has too many x86 assumptions. The casts are most definitely _not_ free, because there are multiple operations like sign-extending, zero-extending, etc. which depend on the ABI. The fact that these are all almost free in x86 is irrelevant since some architectures will have to go out of their way to implement the operation (albeit the ABI is usually designed to make these operations simple). Similarly, I could also imagine another architecture having a shorter instruction to set a register to 0/1, or even one where _Bool is defined with the machine word size and thus doesn't need any cast whatsoever (not even sign extension).
On such architecture "casting to bool" would be free, but other, narrowing type conversions would not.
If I'm not mistaken, the `(bool)` is unnecessary due to how implicit conversion works: `In a return statement, the value of the operand of return is converted to an object having the return type of the function` [1] ...unless I understood it incorrectly :/
This misses the fact that signed integer promotions are generally not free because they require sign extension. For example, the cast in b() emits a `movsx` (move with sign-extension). `movsx` is not free in the ways that `mov` can be.
`mov` can be "free" in two ways:
- the compiler can frequently avoid emitting the `mov` when part of a larger operation
- modern CPUs handle `mov` instructions earlier in the pipeline
I'm quite confident the compiler will optimize that test-and-move away as soon as you use the bool for something, giving you the same assembly as a last century's `typedef bool int`.
C has had _Bool natively since the 1999 ISO standard (24 years ago). The standard header <stdbool.h> has "#define bool _Bool". (The ugly name "_Bool" was chosen to avoid conflicting with existing code.)
The upcoming C23 standard will define "bool" as a keyword.
No, marcosdumay wrote 'typedef bool int', by which he/she probably meant 'typedef int bool', which was not so uncommon when there was no native bool type in C, since the former would be illegal since the standard forbids typedefing already existent types such as int. strkitten informed about the probable typo.
> Note that the top 56 bits in rax are not zeroed – they contain junk. This is fine b/c the compiler will only make callers check the lowest bit of a register for boolean operations. This is why changing the compiler’s “understanding” (ie the cast) is necessary.
... and yet, the function ABI is clearly i386 (fetching arguments from stack) and indeed everything is compiled with -m32 [2] (i.e. 32-bit SysV ABI). This is a strange contradiction in 2023. On the Intel/AMD side, x86_64 has been prevalent (and the default) for... more than 15 years?
It does not invalidate the article's point. But it is slightly confusing....
[1] https://dxuuu.xyz/
[2] https://godbolt.org/z/ff8r44nKn