flat assembler
Message board for the users of flat assembler.

flat assembler > Main > Stack Realignment "Techniques"

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author
Thread Post new topic Reply to topic
Furs



Joined: 04 Mar 2016
Posts: 1318
I have absolutely no idea what the hell you're talking about, doesn't even look like english anymore. I guess hysteria. I think this part says it all (from second link)
Microsoft wrote:
Nonvolatile registers are required to retain their values across a function call and must be saved by the callee if used.
And you said:
system error wrote:
There is no requirement to save the XMM registers in 64-bit ABI.
Yeah, sure, "no requirement", lmao. Laughing

Just FYI, callee = the function I compiled, in case you don't understand english. caller = the function CALLING my function (I have no control over that). So if my function (the callee) uses the registers, it must save them, the same way it saves other non-volatile registers like rbp, rbx, and so on. There's absolutely no god damn difference between xmm6 and rbp in this respect here.

And yes, my function does use xmm6-xmm9 in this example (used a simple asm stmt with clobbers as testcase -> asm("":::"xmm6","xmm7","xmm8","xmm9")), that's why GCC saves them. I mean, that's the point of the testcase.
Post 01 Sep 2017, 19:53
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
This is the most INCOMPETENT IDIOT I've ever seen in my existence on this board.

Furs: The registers must be saved the callee

No my b1tchslapping question to your INCOMPETENT face: WHO IS CALLEE??

Callee is my code and your code!! Don't you ever get it after I taught you the same thing in over 4 full threads? It's not required by the ABI. It is required by YOUR CODE. It's the user's own requirement and choice if you want to save it or not. So, it is not part of the ABI's requirement.

Try scratching XMM15 or R15 in calling a MessageBox (an ABI-compliant API) in your code and see if it returns a seg fault or violates any MS64 ABI!

TRY NOW and let everybody here see how incompetent you're in interpreting a simple technical documentation! OMG hahahaha xD
Post 02 Sep 2017, 05:02
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
And no Furs..... the MS64 ABI never defines, uses or specifies the AVX instruction set.

hahahaha xD
Post 02 Sep 2017, 05:05
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
I think I am done schooling this incompetent idiot. Sorry for terrorizing your thread and making you look like a completely helpless 'expert'! It was fun trolling you anyway. hahahaha xD
Post 02 Sep 2017, 05:46
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1318
lol man, are you seriously so dense to not understand that ABI specifies an interface? Even the name says: Application Binary INTERFACE. This means *both* functions adhering to it must comply to it (an interface establishes rules for both entities so they can talk to each other, BOTH caller and callee).

The ABI doesn't care how you save the registers. It requires that they are unchanged when your function exits, because that's what the calling function expects. So if your function uses them, they *must* be saved as the ABI says, because the caller expects them to be unchanged. Period. An ABI dictates the behavior of both your function AND the caller's (when calling it). They must both *agree* on the same rules.

You don't understand shit. Oh and ABI is not API. It's not just Windows API functions that adhere to the ABI. For example, the function I gave as example eventually will be a callback function for a DSP plugin, and the caller obviously expects that XMM6-15 are unchanged when calling my function because it assumes it uses the MS ABI (which says you must save them, contrary to the pure bullshit you said).

Frankly who cares about explaining it anyway? GCC generated that code. The GCC you said "is not coded by idiots", so it must be doing it right. That makes you the idiot, here, using your own words and logic. You dare question the non-idiot GCC? Razz

And yeah we all know the "omg I spoke so much bullshit and got schooled so hard and now I'll just say I was trolling all along hahahahaha!!" cop-out Wink
Post 02 Sep 2017, 14:46
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
OMG! hahaha. This dude above me is really that incompetent in interpreting a simple technical doc ;D

No Furs, what MS asks you to do is to use your common sense in dealing with non-volatile registers. It's not a specifc requirement. This "common sense" exists across all calling conventions. It also applies to general coding techniques as well. It is NOT a defining characteristics of MS64-ABI. It exists in stdcall, vectorcall, ccall or even in general use of the registers. This "common sense" is translated into pre-school language: "If u want to preserve it and use it later, SAVE IT. If not, don't bother. You're not breaking any conventions if you don't do that"!

And I stated to you when I b1tchslapped you in other threads, the requirements for MS-64 ABI are only 3:

1. Stack must be aligned to 16
2. Create shadow space
3. Integers in GPR. Floats in XMM registers, alternating fashion if both exists.

Others are just common sense. And NO. MS-64 bit ABI has no official support for AVX instructions and registers like you tried to convince the unsuspecting audience via your "expert garbage" talks!! NOOOOO!! No align-32! No YMM. No "vzeroupper". No no no!! <============= hahahaha xD
Post 03 Sep 2017, 07:27
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
l[The GCC you said "is not coded by idiots", so it must be doing it right. That makes you the idiot, here, using your own words and logic. You dare question the non-idiot GCC?


Unless you come up with your own C-compiler, calling them idiots is not valid, if it comes from your BIG MOUTH. GCC is used by millions of programmers and form the back end of other high-level languages.

You??? You don't even know the difference between a signed and unsigned integer. Look how I b1tchslapped your incompetent face in this C-specific thread using a C code!

https://board.flatassembler.net/topic.php?t=19904&view=next

Your pathetic "expert" solution to Y2038 problem was to change the date from your "DATE" applications of the OS? OMG!! hahahaha xD

Wasn't that embarrassing? xD
Post 03 Sep 2017, 08:08
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 685
Location: Adelaide
Quote:
...what MS asks you to do is to use your common sense in dealing with non-volatile registers.

Pretty specific actually
https://msdn.microsoft.com/en-us/library/6t169e9c.aspx
Quote:
The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered nonvolatile and must be saved and restored by a function that uses them.
Post 03 Sep 2017, 08:15
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
sinsi wrote:
Quote:
...what MS asks you to do is to use your common sense in dealing with non-volatile registers.

Pretty specific actually
https://msdn.microsoft.com/en-us/library/6t169e9c.aspx
Quote:
The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered nonvolatile and must be saved and restored by a function that uses them.


That recommendation also exists in other calling conventions. Even without calling convention, anybody that uses a register that must be preserved, should make the effort in saving and restoring them. This is common sense, regardless of calling convention or not. If you scratch a non-volatile register and have no intention of preserving them then you don't have to. In both cases, you're not violating any specific requirement of the ABI and will not throw any segmentation fault at you. ABI-compliant APIs DO NOT RELY on the states of the non-volatile registers. That's the other way of saying it.
Post 03 Sep 2017, 08:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16149
Location: Hyperborea
Maybe you are talking in crossed purposes here. There are two sides to the register preservation. The input values to a procedure do not have any defined values in the non-volatile registers. But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry. This is actually a requirement of the calling convention. It isn't subject to the whims of "common sense", it proscribes the expected behaviour.
Post 03 Sep 2017, 08:45
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry.
That's common sense. Anybody on stdcall also applies this sense - Save and and restore the registers you want preserved. Is this unique only to MS64-bit ABI?
Post 03 Sep 2017, 08:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16149
Location: Hyperborea
system error wrote:
revolution wrote:
But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry.
That's common sense.
Yes, but the important point is that it is also a requirement. "Common sense" is vague and imprecise, everyone has their own idea of what they think it is.
Post 03 Sep 2017, 08:50
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
system error wrote:
revolution wrote:
But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry.
That's common sense.
Yes, but the important point is that it is also a requirement. "Common sense" is vague and imprecise, everyone has their own idea of what they think it is.


It's not a requirement. It's a recommendation for the user's side. Just because you found the word "must" in it doesn't make one a requirement. It's a general way of saving non-volatile registers, convention or not. The techniques is there ever since 8088 era.
Post 03 Sep 2017, 08:56
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 685
Location: Adelaide
Quote:
It's not a requirement.

That's just wrong. The official MS ABI specs say if you use a nonvolatile register you must preserve it.

Common sense would be saving any register you use, not just nonvolatile.
Post 03 Sep 2017, 09:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16149
Location: Hyperborea
system error wrote:
It's not a requirement. It's a recommendation for the user's side.
The term "non-volatile" tells us that we must preserve them if we would like our code to work without problems. You can always follow a completely different calling convention within your own internal code if you wish to, but all that would do is change the requirements that you follow. At the end of the day you must follow something, even if that "something" is different for each and every procedure (aka "chaos").
Post 03 Sep 2017, 09:07
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
sinsi wrote:
That's just wrong. The official MS ABI specs say if you use a nonvolatile register you must preserve it.


revolution wrote:
system error wrote:
It's not a requirement. It's a recommendation for the user's side.
The term "non-volatile" tells us that we must preserve them if we would like our code to work without problems.


No. Let's see this pseudocode;

Code:
mov r15,0xBABE
fastcall [MessageBoxA],rcx,rdx,r8,r9
fastcall [printf],msg
mov r15,0
mov rcx,0
call [ExitProcess]    


Now tell me how's whoring up R15 to different values would prevent the MS ABI being implemented and run successfully in this case? Why would I bother saving R15 if I don't want it to be preserved? Am I violating the ABI just because I'm scratching R15 and do not preserve its value?

How's my code be in any non-compliant state, if I don't preserve R15?

You're reading MSDN without using your common sense or taking everything on face-value. Be SMART.


Last edited by system error on 03 Sep 2017, 09:21; edited 1 time in total
Post 03 Sep 2017, 09:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16149
Location: Hyperborea
It is the APIs that preserve R15 for you. The APIs don't know if you need the value in R15 or not, but they will follow the ABI and make sure to return it back to you unchanged. So you can be sure that the value in R15 after those two API calls is still the same.

And you must preserve R15 for any API that calls your code. If you have a callback procedure then be sure to use your "common sense" and preserve all the non-volatile registers.
Post 03 Sep 2017, 09:20
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
It is the APIs that preserve R15 for you. The APIs don't know if you need the value in R15 or not, but they will follow the ABI and make sure to return it back to you unchanged. So you can be sure that the value in R15 after those two API calls is still the same.


That's just a general technique commonly used in stdcall as well. That doesn't make it any more "requirement" in MS-64-bit ABI.

Quote:
And you must preserve R15 for any API that calls your code. If you have a callback procedure then be sure to use your "common sense" and preserve all the non-volatile registers.


No. I don't have to. Whoring up R15 doesn't make any seg fault or to make my code be in any "non-compliant" state. I preserve R15 only where and when I think it should be preserved. The subsequent call to [printf] simply doesn't care if R15 is scratch of not.

Geezzz, where are you guys coming from? xD
Post 03 Sep 2017, 09:34
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 685
Location: Adelaide
Try changing RBX (or RBP, RSI, RDI etc.) in your windows procedure, see how far you get before the boom.
Post 03 Sep 2017, 09:39
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
sinsi wrote:
Try changing RBX (or RBP, RSI, RDI etc.) in your windows procedure, see how far you get before the boom.


Calling two successive API's MessageBoxA and printf don't require any non-volatiles involved. Why should I bother changing them in the first place?

See, this is where you're missing the whole point of "recommendation" vs "requirement".

If you don't align the stack to 16, you'll be boomed when calling MessageBoxA
If you don't allocate stack space, your'll be boomed in the face ... soon enough.
If you use the wrong registers, you'll be boomed as well.

That's 3 requirements of MS64 ABI. Violate any of these and you'll be BOOMED!

Scratching R15 will not create any boom if you're not interested in using or preserving it.

You guys are way funnier than I thought xD
Post 03 Sep 2017, 09:49
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

< 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 © 1999-2018, Tomasz Grysztar.

Powered by rwasa.