I wonder if such small structures that size is up to given architecture procesor word size like
struct Color {unsigned char a,r,g,b;}
struct Int32Pair {Int32 x,y;} // on 64 bit architecture
are guaranteed to be passed and returned in quick one registry way?
same with returning sse work types like _m128 (i mean in intermodular calls
not inline)
or are thay wasted by doing ram copies in calls?
Have a look on the ABI (application binary interface) of the compiler and/or operating system.
Because many libraries come with the operating system the operating system defines some standard for passing parameters to functions and how they can be stored in registers instead moving them accross the stack.
This is what the ABI is for. If some special passing mechanism is used it must be made sure that you do not link diffent calling conventions (ABIs) together. If I remember right there has been in the history of MS compilers a calling convention "fast call" that used nearly all registers to pass parameters. To make sure that the caller is aware of it the linker symbols for such functions has prepended an @. This way they make sure not to call a fastcall function from some code that is not aware of this.
Have a look on the ABI (application binary interface) of the compiler and/or operating system.
Because many libraries come with the operating system the operating system defines some standard for passing parameters to functions and how they can be stored in registers instead moving them accross the stack.
This is what the ABI is for. If some special passing mechanism is used it must be made sure that you do not link diffent calling conventions (ABIs) together. If I remember right there has been in the history of MS compilers a calling convention "fast call" that used nearly all registers to pass parameters. To make sure that the caller is aware of it the linker symbols for such functions has prepended an @. This way they make sure not to call a fastcall function from some code that is not aware of this.
those abi topics are confusing, but isnt there some common standards
that when i compile code with gcc to .o there is some specyfic convention - and if so how such passing of Color and Int32Pair physically look like?
maybe this is not so much important, though on the other side if at present machines every call of the functions equals to physical memcopy of the args record when optymizing this should be really avoided
yet one related thing
is this true that when optymizing i should revrite code such way to
minimalize local variables? each variable is storing and loading the
bytes, for example if i got 20 int variables versus 10 int variables (where those 10 are reused) is it more efficient?
im not sure if compiler is physically obliged to use all those 20 ram
variables when used in code or some of them after optymization are becoming virtual - and he is for example using only say 7 and the rest of mechanics is doing in the registers...
not sure as to this but some thinking suggest me that i should avoid populating local variables and reusing the small set of them - im not sure as to this
those abi topics are confusing, but isnt there some common standards
struct Color {unsigned char a,r,g,b;};
Color make_color() { Color c; c.r = 1; c.g = 2; c.b = 3; c.a = 4; return c; }make_color():
mov eax, 50462980
retmake_color():
movs r3, #4
movs r0, #0
bfi r0, r3, #0, #8
movs r3, #1
bfi r0, r3, #8, #8
movs r3, #2
bfi r0, r3, #16, #8
movs r3, #3
sub sp, sp, #8
bfi r0, r3, #24, #8
add sp, sp, #8
bx lr00FE4790 push ebp
00FE4791 mov ebp,esp
00FE4793 push ecx
00FE4794 mov word ptr [ebp-3],201h
00FE479A mov byte ptr [ebp-1],3
00FE479E mov byte ptr [c],4
00FE47A2 mov eax,dword ptr [c]
00FE47A5 mov esp,ebp
00FE47A7 pop ebp
00FE47A8 ret
alright, thats cool,
do you maybe know if it would work the same way with 64 bit
i mean something like
struct X {unsigned char a,b,c,d, e,f,g,h; }
X makeX()
{
X x;
x.a = 1;
x.b = 2;
x.c = 3;
x.d = 4;
x.e = 5;
x.f = 6;
x.g = 7;
x.h = 8;
return X;
}
will it be
makeX:
mov rax, 23486347850462980 //somethin
ret
__m128 makeM128i()
{
unsigned char y[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
__m128i m = _mm_loadu_si128(y) ;
return m;
}
do you maybe know if it would work the same way with 64 bit
gcc.godbolt.org. Try it out and see. Those all compile on AMD64 unless they say otherwise (like the ARM cross compilers).
