Int128 in assembler

[aw27]

Nevertheless you can't do the RDX:RAX thing in VS (if that was your plan) as already explained, so this is strictly assembler.

I know, it is something that can eventually be explored only in Assembler. Not either within the Windows ABI or the System V ABI.
However, I can not visualize a good way to explore it in a ASM only application. Don't be afraid to post a solution if you have it.

[nidud]

deleted

[aw27]

It is not a routine that proves what you want. You need to make a function that calls that routine and then calls the same or a similar routine in order to produce something useful that can be printed - in other words make a f*g application, stop bluffing. When you try that you will see you are wasting CPU cycles with those maneuvers.

[hutch--]

What fascinates me with this discussion is the level of fud involved, you have in Windows a published ABI and it handles from BYTE to QWORD, above that (SSE, AVX) you use pointers to larger data sizes OR you directly load SSE or AVX registers then call the procedure. Now I have no doubt that you can do things in different ways if you have code at the receiving end that will handle it but its hard to beat a single pointer when the alternative is to have to re-assembler weird techniques back into a usable data type.

I have no doubt its character building and may even be amusement but its not an improvement over the published ABI. Now an alternative is to create a structure if you have to pass a variety of different sizes to the same proc. Ensure the data in the struct is aligned correctly, big first dropping down in size to the smaller sizes then pass a single structure pointer and you have probably hit the big time in terms of the most efficient technique to call a procedure with variable sized arguments.

[aw27]

What fascinates me with this discussion is the level of fud involved,

Nothing forbids us from inventing our own ABI and use it inside our ASM only application - practically the only restriction is keep aligned what needs to be aligned to prevent an exception. But in almost every case there is little to no advantage in inventing a new ABI (this includes the VectorCall, which can be advantageous only with specially tailor made routines).

Large data will need to be passed with pointers, like it or not. And return values will continue limited by the size of registers as well or returned  in pointers. Now, comes @nidud saying that we can return values in 2 registers instead of one (he got the idea from the 32-bit way of returning a 64-bit value ). Looks like an appealing idea if we abstract how we are going to deal with the data in 2 registers on the calling end.
@nidud says "easy, see that we can multiply and come up with a 256 bit value in 4 registers!" (I am sure we can also come up with a 512 bit value in 8 registers).

What else can we do out of that mess of data spread across multiple registers?
If we need to call a function we will have to move data around to new registers (which may end up being a "musical chairs" game) or save it in memory (something we were trying to avoid at all costs in the first place).

[nidud]

deleted

[jj2007]

Look, nobody has disputed the fact that you need a pointer to return a value larger than 64-bit in Windows 64 unless you use a vector to do so. In the case of __int128 and larger integer values (the subject of this tread) I recommended, based on experience, not to do so and use pointers instead.

In the case of __int128, returning the value in xmm0 would be a natural choice.

[aw27]

In the case of __int128, returning the value in xmm0 would be a natural choice.

Complete nonsense. 

[aw27]

It was the big software corporations and chip manufactures who invented things like vectorcall and System V to improve performance. You think they where all wrong, Idiots even?

Sorry, I believed you were the socialist guy in here. I never though that about big corporations, they are the best think in this World  :t

[nidud]

deleted

[jj2007]

In the case of __int128, returning the value in xmm0 would be a natural choice.

Complete nonsense. 

Your remark is about as competent as saying that returning DWORD values in eax is "complete nonsense".
(ok ok, I know I shouldn't feed the troll, but he looks soooo hungry... poor beast :shock:)

[nidud]

deleted

[aw27]

I never though that about big corporations, they are the best think in this World  :t

So who's the idiot then?

I guess you already got the confirmation from the mirror:
"Mirror, mirror, on the wall,
Who in this land is the most idiot of all?"

:t

[aw27]

In the case of __int128, returning the value in xmm0 would be a natural choice.

Complete nonsense. 

Your remark is about as competent as saying that returning DWORD values in eax is "complete nonsense".
(ok ok, I know I shouldn't feed the troll, but he looks soooo hungry... poor beast :shock:)

LOL, you are becoming less and less intelligent every day. 

[hutch--]

 

Maybe we shoud have moved this discussion to Romper Room.  :P