Timeline for Vectorized 16-bit addition in Standard C
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2023 at 0:15 | vote | accept | CPlus | ||
| Feb 26, 2023 at 23:45 | answer | added | Davislor | timeline score: 5 | |
| Feb 26, 2023 at 17:30 | history | edited | CPlus | CC BY-SA 4.0 |
Fixed subtle program error
|
| Feb 26, 2023 at 2:17 | comment | added | chux |
@user16217248 Consider the reverse, how do you know it does? Is it something you know is defined by C or just (uintptr_t)b&1 works. IAC, you code never tests that case as malloc() always returns memory aligned for all cases. "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement ...."
|
|
| Feb 26, 2023 at 1:42 | comment | added | CPlus | @chux-ReinstateMonica How so? | |
| Feb 26, 2023 at 1:38 | comment | added | chux |
@user16217248 if ((uintptr_t)b&1) { does not portably test b alignment and *b++ += a; does not certainly rectify alignment to match 64-bit objects.
|
|
| Feb 24, 2023 at 17:22 | history | edited | CPlus | CC BY-SA 4.0 |
Branchless hack; 2's Complement assertion
|
| Feb 23, 2023 at 20:19 | history | edited | CPlus | CC BY-SA 4.0 |
Bugfix
|
| Feb 23, 2023 at 19:37 | comment | added | user555045 | Well I don't know about that, but the linked SWAR addition would work (for both signed and unsigned numbers, and overflow is well-defined using that algorithm) | |
| Feb 23, 2023 at 19:36 | comment | added | CPlus |
@harold It seems making a unsigned, concatenating them, and then conditionally negating the result with 'subtract' flag, functions as intended. Repeating the bits of -1 produces a very different result than negating the repeated bits of 1. The latter is what functions as intended.
|
|
| Feb 23, 2023 at 19:33 | comment | added | CPlus | @harold It might be because repeating the bits works unexpectedly for negative numbers. | |
| Feb 23, 2023 at 19:30 | comment | added | CPlus |
@harold It seems if a is negative results are incorrect.
|
|
| Feb 23, 2023 at 19:23 | comment | added | user555045 |
No, -1 + 1 also carries into the next short
|
|
| Feb 23, 2023 at 19:22 | history | edited | CPlus | CC BY-SA 4.0 |
Added comments
|
| Feb 23, 2023 at 19:20 | comment | added | CPlus | @harold If at least one operand is nonnegative and no overflow occurs, will the result be expected? | |
| Feb 23, 2023 at 19:18 | comment | added | user555045 |
That's not really true though. The problem in the vectorized version is caused by unsigned overflow, which does not always correspond to overflow of the original signed integers. Eg -1 + -1 produces a carry (and thus breaks the vectorized version), but would not be an overflow condition for signed 16-bit integers. Fortunately there is a proper SWAR addition
|
|
| Feb 23, 2023 at 19:11 | history | edited | CPlus | CC BY-SA 4.0 |
I have already improved upon the code myself; The older version no longer needs review
|
| Feb 23, 2023 at 18:37 | comment | added | CPlus | @G.Sliepen Yes. The reasoning is overflow here results in unexpected results (such as the carry bits overflowing into the next value) but so would overflow in a non-vectorized version, being undefined behavior. The assumption is no overflow should or will occur. | |
| Feb 23, 2023 at 18:34 | comment | added | G. Sliepen | Have you thought about overflow? | |
| Feb 23, 2023 at 18:01 | history | asked | CPlus | CC BY-SA 4.0 |