flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
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: 701
In f(g(x),h(y)), which should i do first - g or h?
C:

Code:
int g(int);
int h(int);
int f(intint);
int F(int xint y){return f(g(x),h(y));}



ARM64 gcc 6.3.0 -Os -std=c++11:

Code:
F(intint):
        stp     x29x30, [sp, -32]!
        add     x29sp0
        stp     x19x20, [sp16]
        mov     w20w1
        bl      g(int)
        mov     w19w0
        mov     w0w20
        bl      h(int)
        mov     w1w0
        mov     w0w19
        ldp     x19x20, [sp16]
        ldp     x29x30, [sp], 32
        b       f(intint)



x86-64 gcc 7.1 -Os -std=c++11:

Code:
F(intint):
        push    rbp
        push    rbx
        mov     ebpedi
        mov     ediesi
        sub     rsp8
        call    h(int)
        mov     ediebp
        mov     ebxeax
        call    g(int)
        mov     esiebx
        mov     edieax
        pop     rax
        pop     rbx
        pop     rbp
        jmp     f(intint)

Post 13 Aug 2017, 10:02
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
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 xint y)
{
  int _g = g(x);
  return f(_gh(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: 15236
Location: 1I/ʻOumuamua
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: 15236
Location: 1I/ʻOumuamua
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: 83
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 Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15236
Location: 1I/ʻOumuamua
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: 867

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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.