Unless your machine has error correcting memory. Then it will take literally forever.
(_____(_____________(#)~~~~~~
Unless your machine has error correcting memory. Then it will take literally forever.
Your CPU has big registers, so why not use them!
#include <x86intrin.h>
#include <stdio.h>
static int increment_one(int input)
{
int __attribute__((aligned(32))) result[8];
__m256i v = _mm256_set_epi32(0, 0, 0, 0, 0, 0, 1, input);
v = (__m256i)_mm256_hadd_ps((__m256)v, (__m256)v);
_mm256_store_si256((__m256i *)result, v);
return *result;
}
int main(void)
{
int input = 19;
printf("Input: %d, Incremented output: %d\n", input, increment_one(input));
return 0;
}
It doesn’t help that they keep deprecating and changing standard stuff every other version. It’s like they can’t make up their mind and everything may be subject to change. Updating to the most recent release can suddenly cause 10s or 100s of compiler warnings/errors and things may no longer behave the same. Then you look up the new documentation and realize that you have to refactor a large part of the codebase because the “new way” is for whatever reason vastly different.
This isn’t limited to JS. Too many times have I seen someone ask a question of how to do XYZ in language ABC where most of the replies were some form of “Just use this library bro” while not actually answering the question. And usually the library that’s being suggested is some big monolith that implements a ton of shit that no one really uses.
Interesting feature, I had no idea. I just verified this with gcc and indeed the return register is always set to 0 before returning unless otherwise specified.
spoiler
int main(void) { int foo = 10; }
produces:
push %rbp mov %rsp,%rbp movl $0xa,-0x4(%rbp) # Move 10 to stack variable mov $0x0,%eax # Return 0 pop %rbp ret
int main(void) { int foo = 10; return foo; }
produces:
push %rbp mov %rsp,%rbp movl $0xa,-0x4(%rbp) # Move 10 to stack variable mov -0x4(%rbp),%eax # Return foo pop %rbp ret