flat assembler
Message board for the users of flat assembler.

flat assembler > High Level Languages > In f(g(x),h(y)), which should i do first - g or h?

Author
Thread Post new topic Reply to topic
tthsqe



Joined: 20 May 2009
Posts: 714
C:
Code:
int g(int); int h(int); int f(int, int); int F(int x, int y){return f(g(x),h(y));}


ARM64 gcc 6.3.0 -Os -std=c++11:
Code:
F(int, int): stp x29, x30, [sp, -32]! add x29, sp, 0 stp x19, x20, [sp, 16] mov w20, w1 bl g(int) mov w19, w0 mov w0, w20 bl h(int) mov w1, w0 mov w0, w19 ldp x19, x20, [sp, 16] ldp x29, x30, [sp], 32 b f(int, int)


x86-64 gcc 7.1 -Os -std=c++11:
Code:
F(int, int): push rbp push rbx mov ebp, edi mov edi, esi sub rsp, 8 call h(int) mov edi, ebp mov ebx, eax call g(int) mov esi, ebx mov edi, eax pop rax pop rbx pop rbp jmp f(int, int)
Post 13 Aug 2017, 10:02
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
C/C++ does not guarantee the order of evaluation of function parameters. It seems weird, but not even C++17 fixed it completely. This is why I stress to people that they should not rely on something "just because it works" since the compiler is allowed to do it in any order. This is actually a big source of problems for variadic templates and their parameter pack expansions within a function...

The reason for this is due to optimizations. If the compiler is able to reorder the function calls in parameter evaluation so that the code is better, it has the opportunity to do it. If the language didn't allow it, the compiler would have no such freedom.

If you want a specific order, use something like:
Code:
int F(int x, int y) { int _g = g(x); return f(_g, h(y)); }
Post 13 Aug 2017, 16:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15871
Location: 162173 Ryugu
I think this belongs in the HLL section so I moved it.
Post 14 Aug 2017, 04:50
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15871
Location: 162173 Ryugu
The more I learn about C the more I realise it has many subtle and devastating traps for the unwary programmer. You can't just write the code, you have to write the code and then examine and maintain it for the next infinity years to make sure that the latest update to the compiler doesn't break it.
Post 14 Aug 2017, 19:35
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 258
Location: Belarus
revolution wrote:
The more I learn about C the more I realise it has many subtle and devastating traps for the unwary programmer. You can't just write the code, you have to write the code and then examine and maintain it for the next infinity years to make sure that the latest update to the compiler doesn't break it.

Well, in fact most cases of undefined behaviour are actually things that are strange for a HLL, like relying on NULL-pointer dereferencing, overflowed values, etc. So, if you avoid such stuff and a few special cases, you’re almost safe. This fact doesn’t render C/C++ being good languages though.
Post 14 Aug 2017, 20:09
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15871
Location: 162173 Ryugu
Why does C even have undefined behaviour? Should it not refuse to compile because of bad or contradictory input?
Post 14 Aug 2017, 20:20
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1172
revolution wrote:
Why does C even have undefined behaviour? Should it not refuse to compile because of bad or contradictory input?
Please no. For example, in constexpr functions in C++, undefined behavior is disallowed and compilers give error.

This may sound ideal, but in fact royally pisses me (and a lot of people) off. You can't even use reinterpret_cast or unions with type-punning (or an equivalent C-style cast; basically, you can't read the bytes of a memory as a type other than the original type, period). That would be so fucking useful for some abstract functions. GCC used to allow it as a special extension, but now it fails to compile "because the language says so" (not because of technical limitations), which pisses me off.

I hope a special place in hell is reserved for the pathetic piece of shit who even cheered for this "feature". I can understand a WARNING for undefined behavior (that can be suppressed) but flat-out ERRORING out because of a retarded incompetent moron who thinks "his way is the only way to code"? It's not often I wish bad on people but in this case, you know who you are (yea I know even his name but won't say it here for... reasons; he's of course part of the shitty C++ committee)


Anyway, undefined behavior exists because every platform is different. C/C++ try to be portable, but won't (shouldn't) disallow you from using platform-specific quirks if you want to do it.
Post 14 Aug 2017, 21:31
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 2004-2018, Tomasz Grysztar.

Powered by rwasa.