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 > Heap > Furs & system error: BFF

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:

zhak wrote:
But don't forget, that even one byte leads to wasting another 511 on disk space and 4095 in memory (assuming win executables with default file/section alignment). So, unless pushed to the limits, saving one or two bytes doesn't win anything

Well for a simple program yes, but I mean it does add up. You obviously aren't going to call just one function, and the ABI applies to ANY compliant function!

GCC devs saw a difference of between 5%-20% in executable sizes on average when changing from PUSH to MOV on Linux ABI (Linux ABI supports PUSH just fine with no overhead). So they reverted it. GCC defaults to PUSH by default for any ABI except MS ABI. (that means PUSH including on Linux 64-bit ABI). (the options -mpush-args and -mno-accumulate-outgoing-args I mean)


system error wrote:
No, you INCOMPETENT big mouth. The face-saving question that you should ask YOUR BRAIN righit now is; Why does an INCOMPETENT attempt to save so much space result in poor, substandard and inferior code on modern CPUs?.

Why does the reason matter? Stop grasping at straws in desperation

It's simple math.

Bloat = size. See: https://en.wikipedia.org/wiki/Software_bloat

Quote:

Quote:
Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory, DISK SPACE or processing power, or have higher hardware requirements than the previous version—whilst making only dubious user-perceptible improvements or suffering from feature creep.

In this case, let's analyze it:

Is 5 greater than 1? MOV is more bloated. So accept your defeat.
Is the performance the same for modern CPUs? Yes so we ignore it.

So please ask again "bloated where?!?" you incompetent kid.

Maybe you should learn some math or WORDS before asking questions! Seems all you can say is "incompetent" and "bloated where?!?" like a broken record.


system error wrote:
Remember we haven't applied any 'calling convention' in it yet, the thing that you been trying to hide from us --> you sacred function prologue and epilogue. HAHAHA Very Happy

No, that is unrelated. Linux 64-bit ABI uses PUSH unlike MS ABI, but it also aligns the stack to 16-bytes. So it is an UNRELATED thing.

Also THAT PROLOG/EPILOG IS **ONLY** IF THE FUNCTION USES SSE. Do you understand this simple fact? It is **ONLY** for SSE.

And by SSE, I mean SSE, not vectors. Not AVX, but SSE.

I don't use SSE, sorry, I use AVX. Mad? Why must I be stuck using stupid SSE because the ABI is short-sighted?

In case you still think you know what you're talking about, show me your AVX2 function and its prolog, or shut up.

I want to see your 32-byte vectors with your MS ABI, show me how "superior" it is! On the other hand, your MS ABI *wastes* a potential 8-bytes of stack per EACH function, whether they use SSE or not!!

Remember the definition of bloat? Yeah, one of them was "increased memory use" and stack is memory.



You still haven't answered my multiple choice question. It's the easiest pop quiz question in the world. Do you have enough COMPETENCY to answer it? I don't think so. Your're such a typical 32-bit programmers who keep blaming the uneven floor for their incompetency in using low-level MS64 bit ABI correctly without INVOKE. But you're the worse. hehehe Very Happy

You have nothing else to defend here.

1) Your function prologue and epilogue are BLOATED if compared to MS64 ABI.
2) Your smart calling convention is EXTREMELY SLOW (and that's not even applied against your own prologues yet) Very Happy
3) Your disgraceful failure to comprehend the Intel/AMD technical manuals.

So take my advice. Save yourself further embarrasments while you can. Run. Hide. Burn your house. Plunge your car at the next cliff. Or become a chef. Because you're simply INCOMPETENT

Thanks Very Happy
Post 02 Apr 2017, 14:53
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
Why do you care about performance? Your CPU is shit for performance.



Oopppsss!


zhak wrote:
I'm fascinated with your dispute. Just executed your sample. My Core i7-4790K gives (for three runs)

Code:

PUSH921905920
MOV:  858874874





Coughhhh (incompetent!) Very Happy
Post 02 Apr 2017, 15:02
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
Boy, you've been PROVEN WRONG by two modern CPUs, so no I'm not going to answer your childish tantrum. Rolling Eyes

Also, I asked YOU first (beginning of previous page) to show me your AVX2 function in MS ABI. So YOU reply to me first before I will even consider yours.

In fact, I challenged you to 3 different things, yet you've ignored ALL of them.

So no, I'm definitely not going to answer your histerical monkey babbling until you do some effort to read and accept one of my 3 challenges.

We all know you ignore them on purpose because, well, you lost your credibility already.

If you aren't going to answer MY challenges, then I WILL NOT answer any retarded question you put up. I ASKED FIRST, deal with it.



system error wrote:
1) Your function prologue and epilogue are BLOATED if compared to MS64 ABI.

Show me YOUR FUNCTION IN MS ABI that uses AVX2 or AVX512 or any future vector. I ask this for the 5th time already STOP IGNORING IT, YOU DUMB TWAT. Shut the fuck up repeating same shit, I DO NOT CARE what you say UNTIL YOU SHOW ME YOUR FUCKING AVX FUNCTION GET IT?

I can copy-paste my answers too you know.

Here's MY functions prolog/epilog:

No vectors:

Code:
sub rsplocal_vars_size

; ...

add rsplocal_vars_size
ret 8*parameters_on_stack



It's only 1 byte bigger (the 'ret' instruction's immediate operand) than yours, and only once per function, and that is ONLY if the function has at least one parameter on the stack.

In which case, you lost already. Your *caller* wastes at least 4 more bytes than mine PER PARAMETER, and since mine needs at least 1 parameter on the stack to waste that extra, even with JUST ONE parameter and CALLED ONLY ONCE, you still lose by 3 bytes.

If there are zero parameters on the stack, then ret 8*0 becomes ret 0 which becomes just 'ret' (because FASM is smarter than your brain), so it is identical to yours, except mine uses rax as parameter (thus is faster) and doesn't waste 8 bytes of stack space if misaligned (less bloated).

Accept your defeat ^ that's for none vectorized functions. So I win, clearly, for non-vectorized functions, period. I win in both size and speed. Mad?


Here's my vector AVX2 function:

Code:
push rbp
mov rbprsp
and rsp, -32
; ... you get the idea for the rest ...

PS: I do NOT CODE IN SSE so I don't have any SSE functions, happy? For someone with a big mouth like yours you sure talk about "modern CPUs" a lot when you use SSE which is like 2001 lmao!!

So, use either no AVX (majority functions don't use vectors) or AVX, that's it. There's no SSE. You have functions either:

1) without vectors -- normal functions, mine are faster (rax parameter) and less bloated (smaller instruction encoding, no wasted stack space)

2) with vectors -- faster (rax parameter), exact same prolog/epilog (because we use AVX2 obviously) and smaller / less bloated (PUSH instead of MOV)


system error wrote:
2) Your smart calling convention is EXTREMELY SLOW (and that's not even applied against your own prologues yet) Very Happy

Prove it. You see me and zhak showed the exact same performance on push/mov, so shut the fuck up.

We have modern CPUs, you don't. So stay with your outdated crap, don't talk to me about CISC on modern CPUs, as you don't have one in the first place! Your histeria against answering my simple question tells me one of two things:

1) you know you lost
2) you can't code in AVX -- damn you're outdated.


system error wrote:
3) Your disgraceful failure to comprehend the Intel/AMD technical manuals.

Explain then why PUSH is faster on my CPU and same speed on zhak's, Einstein.


Intentional ignorance is just a detriment to society, you shouldn't even be allowed to roam society in freedom. Mental institution is for you.
Post 02 Apr 2017, 15:07
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
Here's my vector AVX2 function:

Code:
push rbp
mov rbprsp
and rsp, -32
; ... you get the idea for the rest ...




That's bloated. Why do you have to create a function prologue in the first place? It is SLOW and BLOATED. While in MS64 ABI, all one has to do is to SUB RSP,Size. It's the same across APIs. Your BRAIN is BLOATED or something?

The "size" is NOT part of the calling convention. It's a function thingy. Don't you get it? Do I have to to repeat myself TWICE when I stated in other posts that all MS64-bit requried are only 3.

1. Stack be aligned to 16
2. FP goes to XMM. Integers go to GPR
3. Create a stack space.

THAT ABOUT IT. The rest is up to the function body. I had stated this many times you INCOMPETENT IDIOT. Do I have to repeat it 500 times more? Do you know what a Calling Convention is?

Function prologue is SLOW. It provides a CHOKING POINT upon exit. Function epilogue is SLOW. It provides a CHOKING POINT upon entry. So your function now has TWO CHOKING POINTS. They both degrade performance by some 30-40 percent no matter how small they are in size. So if you have some highly optimized code in there, they will suffer due to those two epilogues.


Furs wrote:
PS: I do NOT CODE IN SSE so I don't have any SSE functions, happy? For someone with a big mouth like yours you sure talk about "modern CPUs" a lot when you use SSE which is like 2001 lmao!!



Why do WE CARE? We don't use your library and nobody does. Looks like you are the one with IMAGINARY LIBRARY and IMAGINARY CALLING CONVENTION.

Wake up you INCOMPETENT IDIOT and get real! Hahahaha. Calling convention MY FOOT Very Happy
Post 02 Apr 2017, 15:40
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
Furs INCOMPETENT claim:

MS64 ABI is not suitable for AVX due to different alignment requirement. So Furr's function prologue / epilogue must be used!! <------ Look at this guy! He's exposing his INCOMPETENCY out in the open without even knowing it


Code:
One_AVX_Function:
   sub rsp,48
 
   vmovdqa qqword[rsp],ymm0   ;this is vmovdqA. Look you INCOMPETENT IDIOT

   add rsp,48
   ret



Function prologue/epilogue WHERE? Very Happy
Post 02 Apr 2017, 16:11
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
lmao, your vector is misaligned Laughing

Your code:

Code:
One_AVX_Function:
   sub rsp,48
 
   vmovdqa qqword[rsp],ymm0

   add rsp,48
   ret

; let's call it, assume rsp here is 0x100010 (16-byte aligned, so we follow rules of stupid ABI!)
call One_AVX_Function

Subtract 8 from rsp (the return address pushed by call) we end up with rsp = 0x100008.

Then we have sub rsp, 48, so rsp = 0xFFFD8.

Now, 0xFFFD8 mod 32 = 24.

That's not zero you incompetent kid, your vector is misaligned, thus your program is slower (it will NOT crash because Intel removed the aligned restriction for AVX -- however misaligned vectors will be slower especially if they happen to cross a cacheline boundary).

No need to say anything else, you can't even code properly. This proves it all.

Stop wasting my time you script kiddie wannabe. Go back and play with your Java or whatever other HLL, clearly asm is too hard for you. Sad

And btw I use my calling convention all the time in my own programs -- of course, this started from a rant because MS ABI is designed like garbage and we "need" to use it if we are to interact with libraries that use it (including the Windows API).

It was a rant, I never said YOU have to use it, because frankly, you wouldn't use it anyway since you can't even code in assembly.

Program more incompetent and incorrect code please.


I guess you love that word "incompetent" since it applies to your assembly skills and experience.

BTW, just a friendly tip so you don't waste time 'adjusting' rsp in your example: if you adjust the 48 value, then it will fail if rsp is 0x100000 (which is also 16-byte aligned). You cannot make it work for both 0x100000 and 0x100010 without AND, deal with it.

You can't do alignment without AND instruction you stupid big mouthed noob.

Your code assumes the stack is misaligned (for a 32-byte alignment, assuming you "forgot" the call instruction's push, which I will forgive), but if assuming such things were easy, we wouldn't need stack alignment in the first place.

If you knew stack misalignment at all times, you could just sub rsp appropriately, not requiring any alignment whatsoever. So it is clear you're not just a clueless assembly programmer, you FAIL to understand why the MS ABI even requires alignment for SSE. You don't even understand the ABI you defend, lol.


Last edited by Furs on 02 Apr 2017, 16:40; edited 1 time in total
Post 02 Apr 2017, 16:32
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
lmao, your vector is misaligned Laughing

Your code:

Code:
One_AVX_Function:
   sub rsp,48
 
   vmovdqa qqword[rsp],ymm0

   add rsp,48
   ret

; let's call it, assume rsp here is 0x100010 (16-byte aligned, so we follow rules of stupid ABI!)
call One_AVX_Function

Subtract 8 from rsp (the return address pushed by call) we end up with rsp = 0x100008.

Then we have sub rsp, 48, so rsp = 0xFFFD8.

Now, 0xFFFD8 mod 32 = 24.

That's not zero you incompetent kid, your vector is misaligned, thus your program is slower (it will NOT crash because Intel removed the aligned restriction for AVX -- however misaligned vectors will be slower especially if they happen to cross a cacheline boundary).

No need to say anything else, you can't even code properly. This proves it all.

Stop wasting my time you script kiddie wannabe. Go back and play with your Java or whatever other HLL, clearly asm is too hard for you. Sad

And btw I use my calling convention all the time in my own programs -- of course, this started from a rant because MS ABI is designed like garbage and we "need" to use it if we are to interact with libraries that use it (including the Windows API).

It was a rant, I never said YOU have to use it, because frankly, you wouldn't use it anyway since you can't even code in assembly.

Program more incompetent and incorrect code please.


I guess you love that word "incompetent" since it applies to your assembly skills and experience.



That's intentional. I knew that it would make you explode in great joy! ;D

The challenge stands: Epilogue Where? Twisted Evil
Post 02 Apr 2017, 16:39
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
What's intentional? Your vector is misaligned.

Show me a function that will align the vector for both inputs rsp = 0x100000 and rsp = 0x100010 (which are both valid for MS ABI, 16-byte aligned).

Nothing else to say -- you can't code properly. End of story.

You don't have an epilogue because your code is wrong.

You know, I can omit the prolog/epilogue too. It will just be a slow program just like YOURS. So what do you gain compared to me exactly...? 8 bytes stack space wasted for functions that don't use vectors, that's what you "gain".
Post 02 Apr 2017, 16:41
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
What's intentional? Your vector is misaligned.

Show me a function that will align the vector for both inputs rsp = 0x100000 and rsp = 0x100010 (which are both valid for MS ABI, 16-byte aligned).

Nothing else to say -- you can't code properly. End of story.

You don't have an epilogue because your code is wrong.



Finally you learned that we don't need function prologue / epilogue even when using AVX/AVX2. See, I am a great teacher! That's all that matters Very Happy

So for all these long, your INCOMPETENCY was not becuase MS64-ABI is bad or anything, but stems from the fact that YOU DIDN"T UNDERSTAND IT in the first place So instead of barking and blaming everyone else for your own STUPIDITY, why don't u just ask nicely? Very Happy

But if you insist, the challenge stands: Function epilogue/prologue Where?

hehehehe ;D
Post 02 Apr 2017, 16:47
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
I don't know how to say this, but are you LITERALLY RETARDED?!?

I just showed you YOUR VECTOR IS MISALIGNED. This means it is SLOW. You don't need epilogue/prologue IF YOU WANT IT TO BE SLOW.

I want mine fast, else I wouldn't be using AVX in the first place, moron. I'd be using scalar x87 (not even scalar SSE) because that has the smallest instructions.

What's the point in using vector instructions if you make them slow? They have bloated code anyway, clearly not for size.

So 1) you're a moron 2) you can't even read 3) your vector is misaligned and 4) YOUR FUNCTION IS SLOWER THAN MINE and 5) you can't code in asm.
Post 02 Apr 2017, 16:54
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
I don't know how to say this, but are you LITERALLY RETARDED?!?

I just showed you YOUR VECTOR IS MISALIGNED. This means it is SLOW. You don't need epilogue/prologue IF YOU WANT IT TO BE SLOW.

I want mine fast, else I wouldn't be using AVX in the first place, moron. I'd be using scalar x87 (not even scalar SSE) because that has the smallest instructions.



It is not misaligned your INCOMPETENT IDIOT. It's the fact that you are INCOMPETENT when dealing with alignment larger than 16 when using the MS calling convention. You don't understand it in the first place. That's why I been calling you INCOMPETENT idiot since the beginning.

Here's a SCHOOLING for you:

In MS64 ABI
Everybody needs to maintains stack aligned = 16. That includes user codes, API and all other entities wishing to communicate with the APIs. so that everybody DO NOT HAVE to create a STACK FRAME each that will choking down OVERALL PERFORMANCE. This is the part that you do not understand all these long


Code:
funct_A:
      [maintained stack aligned to 16]
      call B ---> this breaks alignment due to PUSH
      ret 

funct_B:
     sub rsp,8  ---> re-align it so....
     [maintained stack aligned to 16]
     call C ---> this breaks alignment due to PUSH
     add rsp,8
     ret

func_C_AVX:
     sub rsp,40  ---> re-align it + create stack space for YMM0
     [maintained stack aligned to 16]
     add rsp,40
     ret



This is how the chained of alignment is maintained in MS64 ABI. The keyword here is CHAINED ALIGNMENT so that the entire program can AVOID the expensive stack handling (stack frame, POPs, PUSHs) which consumes more power, more microcode and degrade performance.

See INCOMPETENT IDIOT. This is the part that you been barking about with your BIG MOUTH and empty head! It's your own INCOMPETENCY in understanding the 64-bit ABI!!

So my assumption about you being "blaming that UNEVEN FLOOR" and "like 16-bit programmers blaming the 32-bit stdcall" out of IGNORANCE are true all along.

That's why we don't need full prologue and epilogue in the first place due to that CHAINED ALIGNMENT Very Happy
Post 02 Apr 2017, 17:11
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
AVX2 needs 32 bytes of alignment. Why show me 16? Fuck off.

What now? You bark, but nothing of substance comes out.

Your "function" can also be a callback, in which case you know nothing about the alignment (other than that it's 16-byte aligned, and 16 is not 32 alignment). You literally haven't said a single thing I don't already know. Not everyone is as clueless as you are, sorry. Some of us have years of experience while you have none.

The fact is, you will need the prolog/epilog if you want your AVX2 function to be fast (which you WILL want, else don't even bother using AVX).

So be quiet you got schooled.
Post 02 Apr 2017, 17:24
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
You INCOMPETENT IDIOT, looks like your INCOMPETENCY never stops. By the time it reaches funct_C_AVX, the RSP is already aligned to 32, go use a debugger you INCOMPETENT IDIOT. This address is calculated with the assumption of CHAINED ALIGNMENT. It's just math! It's your own code that will have to make sure that the local store is aligned to 32, based on that chained assumption! NOT THE CALLING CONVENTION

Hahahaha. I am so loving this! Very Happy
Post 02 Apr 2017, 17:36
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
So finally, after 3 days of BARKING and showing off his INCOMPETENCY, now it is self-revealing that Mr Furr DID NOT ACTUALLY UNDERSTAND MS64-bit ABI. He even accused it of being not future-proof, and not AVX/AVX2 compatible!

FURR's FACE now <-------------- HAHAHAHAHAHAHA ;D
Post 02 Apr 2017, 17:41
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
The fact is, you will need the prolog/epilog if you want your AVX2 function to be fast (which you WILL want, else don't even bother using AVX).



Furr's Face now <----------- HAHAHAHAHAHA! ;D
Post 02 Apr 2017, 17:47
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
WRONG!

Your code:

Code:
funct_A:
      [maintained stack aligned to 16]
      call B ---> this breaks alignment due to PUSH
      ret 

funct_B:
     sub rsp,8  ---> re-align it so....
     [maintained stack aligned to 16]
     call C ---> this breaks alignment due to PUSH
     add rsp,8
     ret

func_C_AVX:
     sub rsp,40  ---> re-align it + create stack space for YMM0
     [maintained stack aligned to 16]
     add rsp,40
     ret

Let's start with rsp = 0x100010 (16-byte aligned)

Here's the flow on top of your code:

Code:
funct_A:
      [rsp = 0x100010]
      call B ---> 0x100008
      ret 

funct_B:
     sub rsp,8  ---> 0x100000
     call C ---> 0x0FFFF8
     add rsp,8
     ret

func_C_AVX:
     sub rsp,40  ---> 0x0FFFD0
     [OOPSNOT ALIGNED TO 32FAIL!!!!]
     add rsp,40
     ret

Does this look to you 32-byte aligned? You must be literally retarded. 0x0FFFD0 is NOT 32-byte aligned even though the input was 16-byte aligned.

Relying on your debugger is an idiotic example, because it just so happened it started with a 32-byte aligned address. In other words, you got lucky.

Start with a 16-byte aligned address moron and see for yourself in your debugger (just change rsp to be 16-byte aligned BUT NOT 32-byte aligned, i.e. sub 16 from it)

I bet you're crying right now.
Post 02 Apr 2017, 17:53
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
WRONG!

Your code:

Code:
funct_A:
      [maintained stack aligned to 16]
      call B ---> this breaks alignment due to PUSH
      ret 

funct_B:
     sub rsp,8  ---> re-align it so....
     [maintained stack aligned to 16]
     call C ---> this breaks alignment due to PUSH
     add rsp,8
     ret

func_C_AVX:
     sub rsp,40  ---> re-align it + create stack space for YMM0
     [maintained stack aligned to 16]
     add rsp,40
     ret

Let's start with rsp = 0x100010 (16-byte aligned)

Here's the flow on top of your code:

Code:
funct_A:
      [rsp = 0x100010]
      call B ---> 0x100008
      ret 

funct_B:
     sub rsp,8  ---> 0x100000
     call C ---> 0x0FFFF8
     add rsp,8
     ret

func_C_AVX:
     sub rsp,40  ---> 0x0FFFD0
     [OOPSNOT ALIGNED TO 32FAIL!!!!]
     add rsp,40
     ret

Does this look to you 32-byte aligned? You must be literally retarded. FFFD0 is NOT 32-byte aligned even though the input was 16-byte aligned.

Relying on your debugger is an idiotic example, because it just so happened it started with a 32-byte aligned address.

Start with a 16-byte aligned address moron and see for yourself in your debugger (just change rsp to be 16-byte aligned BUT NOT 32-byte aligned, i.e. sub 16 from it)


I bet you're crying right now.



OMG! HAHAHAHAHA! Very Happy
Post 02 Apr 2017, 17:57
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
You should probably seek professional help, you're laughing like a guy with a mental disorder. Confused
Post 02 Apr 2017, 18:06
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
You should probably seek professional help, you're laughing like a guy with a mental disorder. Confused

It is you who need special schooling on MS64-bit ABI. HAHAHAHA Very Happy

My final advice:
MS64-bit ABI is not for everybody. It requires high technical knowledge where mostl work are done by the user codes / callers / programmers. The ABI is just a general specification. It's the tweaking part that put most 32-bit invokers off and blaming the ABI out of ignorance and incompetency. You're one classic example. I've seen a lots!

INCOMPETENT IDIOT Very Happy
Post 02 Apr 2017, 18:14
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
You got schooled, proven wrong 4 times (including on micro ops where you were flat-out WRONG, bloat, and alignment now), and you still think you're a hot shot?

Go retreat with your tail between your legs, you're like a lost puppy trying to act tough without realizing nobody cares of your wimping -- you should learn to actually program instead of talk.

You haven't even used functions with more than 4 parameters in MS ABI. Christ. You really don't know anything, do you?

You see, unlike you, I've got years of experience using this shitty MS ABI, so you'd best be quiet and start learning from people with actual knowledge.

I've probably coded more AVX functions with this shitty ABI than you have coded ALL asm functions (not just vector ones) in your life, just get lost thanks.

You know, I obviously complain because I have to actually use it. Because unlike you, some of us do code in asm.
Post 02 Apr 2017, 18:20
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  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 can 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.