(_____(_____________(#)~~~~~~

  • 0 Posts
  • 5 Comments
Joined 3 years ago
cake
Cake day: April 11th, 2022

help-circle
  • 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
    


  • 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.