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 1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 477
Now this is better. Asking for help to learn the very basics but asks it to be conducted in EXPERT MODE (no printf to verify and to practice, jumping right to questions related to Chapter 4 of the book, etc).

Let's see how far this fakery can go.
Post 30 Mar 2017, 11:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14797
Location: Lost in translation

system error wrote:
Let's see how far this fakery can go.

My mother used to say to me: "Say something nice or say nothing at all".
Post 30 Mar 2017, 11:54
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

revolution wrote:

system error wrote:
Let's see how far this fakery can go.

My mother used to say to me: "Say something nice or say nothing at all".



Wiseman says otherwise: Attack fakeries before they consume everybody else's resources, wasting people's time, money and efforts.

No I don't see any genuine newbies questions from the way he's asking them. I told him twice in the last thread about "backdown to basics a little bit" but he refused to listen. And now the first question that came out in this thread is about a PUSH instruction, which is very clear from the same reference book he's using that it is a CHAPTER 4 thingy! Does it sound like a "back down to basics" to you?

No. He just want to play his little trolling game. Just wanna see how far he can go. It will be fun to see him toying you guys around.

Good luck Very Happy
Post 30 Mar 2017, 12:29
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
At least he knows [rsp+8*4] is 32 bytes above rsp unlike certain other ppl.
Post 30 Mar 2017, 12:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14797
Location: Lost in translation
Furs & system error: If you want to have an argument take it to PM please.
Post 30 Mar 2017, 12:42
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
At least he knows [rsp+8*4] is 32 bytes above rsp unlike certain other ppl.



Fur, are you referring to revolution's? This is her code


Code:
sub rsp,6*8 ;make space for all six arguments 
mov [rsp+5*8],arg6 
mov [rsp+4*8],arg5 
mov r9,arg4 
mov r8,arg3 
mov rdx,arg2 
mov rcx,arg1 
call function



See, we save volatiles **** BEFORE **** entering the function in 64-bit ABI. And it's completely optional too.

Seems like there's no end in your INCOMPETENCY when dealing with 64-bit ABI and calling convention!

OMG, I am so loving this. If it wasn't unethical, I'd love to bring all your PM's to the open thread to let people see how INCOMPETENT you are in interpreting 64-bit ABI!

You're a BIG JOKE! Hahahaha Very Happy
Post 30 Mar 2017, 13:00
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
Ok, I am out of here. HAHAHAHA Very Happy
Post 30 Mar 2017, 13:01
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361

revolution wrote:
Furs & system error: If you want to have an argument take it to PM please.

Well it was in PM, and he doesn't get it that [rsp+8*4] is a parameter on the stack (he thinks it is "volatile memory" aka shadow space). I said it cause I saw him arguing with you (the "he" was referring to you, certain other ppl was him) off topic stuff in this thread so... nevermind then. I guess he reads it as [rsp+8] and then something with *4 does idk what.

I saw him troll in this thread so I was trolling the troll with a one-liner. Forget it Razz
Post 30 Mar 2017, 14:30
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:

revolution wrote:
Furs & system error: If you want to have an argument take it to PM please.

Well it was in PM, and he doesn't get it that [rsp+8*4] is a parameter on the stack (he thinks it is "volatile memory" aka shadow space). I said it cause I saw him arguing with you (the "he" was referring to you, certain other ppl was him) off topic stuff in this thread so... nevermind then. I guess he reads it as [rsp+8] and then something with *4 does idk what.

I saw him troll in this thread so I was trolling the troll with a one-liner. Forget it Razz



What do you mean? It shows a lot of your INCOMPETENCY in understanding the technicalities of MS64 ABI. That's all. I was talking about the volatile registers RCX-r9, which in MS64 ABI is optional and up to the user codes whether to save them or not.

It started from YOUR INCOMPETENT CLAIM that MS64 ABI is bloated against your sacred stdcall. Well, I asked you to have a look at this code below and asking what did you mean by bloated?


Code:
func_fastcall:
    sub rsp,8
    ...
    add rsp,8
    ret 



vs your INCOMPETENT code


Code:
 func_BLOATED:
    push rbp
    mov rbp,rsp
    sub rsp,INCOMPETENT LOCALS
    and rsp,-16
    ... DO you INCOMPETENT THINGS
    mov rsp,rbp
    pop rbp
    ret 8INCOMPETENT BRAIN



My question: BLOATED WHERE?

Now let the people here see you INCOMPETENT brain trying to interpret the MS64 ABI. You know that you must back up your claim right? Very Happy
Post 30 Mar 2017, 22:04
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 7272
Location: 22° 15' N | 114° 10' E

revolution wrote:

system error wrote:
Let's see how far this fakery can go.

My mother used to say to me: "Say something nice or say nothing at all".

I wish that your mother could also tell you:

"Offer genuine help or don't offer help at all. Never trick other forum members into visiting a fake website!"

Wink
Post 31 Mar 2017, 06:38
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: 14797
Location: Lost in translation

YONG wrote:
"Offer genuine help or don't offer help at all. Never trick other forum members into visiting a fake website!"

I'm glad you are not my mother. Evil or Very Mad
Post 31 Mar 2017, 08:16
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361

system error wrote:
My question: BLOATED WHERE?

Sigh.

Instead of talking sense into you because you are clearly blind, let's do a small contest to prove you wrong. Whoever gets less stack use/binary size (smaller instructions) wins.

Show me a function that takes 10 parameters in MS ABI, and I will show you a better ABI for the same function, period.

Maybe this way you'll understand how stupid you look with such ignorance.

Rules and method to judge other than resulting bloat:

1) The function's prototype in C just takes 10 integer parameters, nothing special/magical, i.e.:

Code:
int func(int p1int p2int p3int p4int p5int p6int p7int p8int p9int p10);

2) You call the function at least 2 times. (which is acceptable since that's the purpose of functions after all, to be re-useable)

3) Passing parameters in registers is better than on the stack, according to you. (too bad you will lose this one since you must pass only 4 in MS ABI, haha)

4) All parameters that you pass come from global variables, for example, for 'p1' in MS ABI you would do this:

Code:
mov rcx, [var1]

(this is to prevent "smart ass code" to not make it a fully generic example.

5) You must provide the ret instruction in your function at least (1 byte, this is because my callee cleans the stack so mine is 2 bytes, you win 1 byte here!)


The reason for these rules are to: prevent smartass "optimizations" for special cases (remember, an ABI is fully GENERAL CASE). So all parameters are OPAQUE and taken from a global variable to ease example.



Here's my well-designed ABI, beat it: (this is a FULL example, two function calls, no memory leaks or stack leaks)

Code:
use64
; this is to make vars resolved for this example (not real)
rept 10 n { var#n: }

mov rax, [var1]
mov rcx, [var2]
mov rdx, [var3]
mov r8, [var4]
mov r9, [var5]
push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
call func

mov rax, [var1]
mov rcx, [var2]
mov rdx, [var3]
mov r8, [var4]
mov r9, [var5]
push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
call func


func:
push rbp
mov rbprsp
and rsp, -16

mov rsprbp
pop rbp
ret 8*5  ; 5 parameters on the stack

155 bytes and that is only if "func" uses SSE. If "func" does not use SSE, I win a potential 8 bytes of stack space (let's say half of functions, on average, will not have to align the stack, thus I gain 4 bytes on average).

Plus if it does not use SSE, there's no alignment of stack, saving more bytes: 143 bytes

So my ABI in this case is: 155 bytes if func uses SSE, 143 bytes + 4 saved stack space if it doesn't use SSE. So technically the latter should be counted as 139 bytes.

My ABI here is not "made for this example". It is the same as MS ABI minus my complaints about it. It is fully general-purpose ABI. Thus it passes extra parameter on register (rax) (which is unused in MS ABI), and has no shadow space (so you can PUSH parameters). Also, the callee cleans the stack. (the function cleans it)

Also, it has no alignment requirement on the stack (well it has 8-bytes requirement but that's "natural").

So I'm willing to see your lack of bloat Wink Let's see how big your skills are compared to your mouth.



BTW I can do a way without "global variables" if you want -- say, if all parameters are in registers and you have to push them. That's fine, too.

If you fail, then you can shut up already.

My ABI should have been the MS ABI. The end.




EDIT: Keep one thing in mind. If the function uses AVX (not SSE, but AVX), then YOU have to realign the stack too. So your stupid ABI isn't even future-proof. How do you feel now? Wink

If you want, I can make another challenge where the "func" uses AVX, to see how wonderful use you make of that stupid 16-byte alignment. (if you have any misaligned variables, you LOSE btw).

I guess for people like you, english can't be used to talk sense into them. You have to code it yourself to realize using AVX forces you to realign the stack if you want your vars aligned properly. Yes, even in your shitty MS ABI. So I will win by a very wide margin if the code uses AVX. I will also win by a wide margin if the code doesn't use SSE.

If the func uses SSE only, I still win, because the bloat of MS ABI is just too large.
Post 31 Mar 2017, 11:49
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:

bla blah blah my ABI better that MS and SystemV ABI! It is being used by millions of users because I am offering them lots of compatible library too! So yeah, I am INCOMPETENT!



I don't know what exactly you're trying to prove here. I asked you to show me where MS ABI 64 is bloated if compared to your sacred stdcall conventions. I am not asking for a custom CC that only you're the only human being using it because
every single one on this board can create a custom Calling Conventions that can take 10 or 50000 parameters if they wished to. There's nothing new.

Do you think people like Tomasz Gryzstar cannot make up his own calling convention as the extension to his FASM and Macro Engine? Are you trying to look smart or just made up a 'quick' calling convention after such humiliation? Very Happy

There's some things that you as INCOMPETENT IDIOT never knew of:

1) PUSH, POP are legacy instructions that everybody is trying to avoid due to its CISC nature that don't work quite well on RISC-friendly modern processors. The same reason AMD never implemented PUSHAQ/POPAQ variants of PUSHAD/POPAD. You got that BOY? Do you have any idea how PUSH and POP behave under the hood? I guess you never knew that because your technical knowledge on CPU is SHALLOW and INCOMPETENT. Not to mention that 2 or more successive POPs or PUSHs introduced unnecassary CHAIN DEPENDENCIES of compared to SUB/MOV combo.

Let me draw you a Elementary school drawing;


Code:
    push rcx  
    push rdx       ;i need to wait for the above to finish calculating RSP
    push r8        ; me two!! 
    push r9        ;I am waiting too! There's now BUBBLE in the pipeline!



If compared to this


Code:
    sub rsp,32
    mov [rsp],rcx  ;no waiting. 
    mov [rsp+8],rdx ; no waiting either. 
    mov [rsp+16],r8 ; nope. Just as smooth.
    mov [rsp+24],r9 ; ayyy! no bubble in pipeline!



How's that feel. Even your CPU is calling you INCOMPETENT! Hahahaha Very Happy

2) Now what you 'smart' CC (which you copied directly from MS64-bit ABI) is suggesting is the use of full function prologue and epilogue which will provide 2 CHOKING POINTS for fast code it is hosting. They do degrade speed by 20-30% AND since they are CISC instructions, they commit more microcode under the hood! While you SHALLOW INCOMPETENT MINDED see a POP as 1 byte convenience, it is exactly performing this type of extra micro-ops implementations:


Code:
POP Instruction
PRETECTED MODE COMPATIBILITY MODE;
IF SS is loaded;
POP—Pop a Value from the Stack
THEN
IF segment selector is NULL
THEN #GP(0);
FI;
IF segment selector index is outside descriptor table limits
or segment selector's RPL  CPL
or segment is not a writable data segment
or DPL  CPL
THEN #GP(selector);
FI;
IF segment not marked present
THEN #SS(selector);
ELSE
SS  segment selector;
SS  segment descriptor;
FI;
FI;
IF DSESFSor GS is loaded with non-NULL selector;
THEN
IF segment selector index is outside descriptor table limits
or segment is not a data or readable code segment
or ((segment is a data or nonconforming code segment)
and (both RPL and CPL > DPL))
THEN #GP(selector);
FI;
IF segment not marked present
THEN #NP(selector);
ELSE
SegmentRegister  segment selector;
SegmentRegister  segment descriptor;
 FI;
FI;
IF DSESFSor GS is loaded with a NULL selector
THEN
SegmentRegister  segment selector;
SegmentRegister  segment descriptor;
FI;



That's CISC / complex / High-level instruction you can find in Intel/AMD manuals. Do have enough COMPETENCY to read that technical details?

Now compare that to simple RISC combo for POP;


Code:
mov [rsp],rcx
add rsp,8



Which one do you think is more bloated? YOUR INCOMPETENT BRAIN? Hahaha Very Happy

3) With more microcode, more POWER CONSUMPTION, hence the very reason why people are avoiding CISC-style instructions. Optimizing for power consumption is just as important for CC as speed and size. Even more important on mobile devices.
So MS64-bit ABI is a CC designed to be more POWER-FRIENDLY as well and not just for speed!

Now idiot, do you understand now why I am calling you INCOMPETENT?

So back to my ORIGINAL CHALLENGE:


Code:
func_fastcall
    sub rsp,8 
    ... 
    add rsp,8 
    ret




vs your INCOMPETENT code



Code:

 func_BLOATED
    push rbp 
    mov rbp,rsp 
    sub rsp,INCOMPETENT LOCALS 
    and rsp,-16 
    ... DO you INCOMPETENT THINGS 
    mov rsp,rbp 
    pop rbp 
    ret 8INCOMPETENT BRAIN




My question: BLOATED WHERE? Twisted Evil
Post 31 Mar 2017, 14:21
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
Are you fucking retarded? I GAVE YOU A LINK THAT PUSH IS ****FASTER**** THAN MOV because of newer processors implementing a proper stack machine.

I get it, you probably use a CPU from 2003 that's why you don't even understand why the ABI is so shit. You have no idea what AVX is because of your shit CPU, so you don't understand why the ABI is total trash even for vectors above SSE.

What the fuck do you want other than 3rd party proof? Pathetic kid.

See: http://stackoverflow.com/questions/36631576/what-is-the-stack-engine-in-the-sandybridge-microarchitecture

Show me proof of your bullshit about MOV being faster than PUSH for any CPU that supports AVX, or stop dodging with excuses like a retard.

It doesn't matter how you THINK the CPU works. Push is faster than mov, and that's a fact you gotta deal with.



Oh and btw, stdcall has the same size as my code (or even smaller), point...? It's even smaller in few cases, means even LESS bloat. Not that I ever said stdcall is "the best" calling convention -- I simply said it's better than MS ABI. That's not difficult, because MS ABI is garbage.

Though, I did specifically say that the MS ABI is designed like trash, not that stdcall is "the best". I can provide quotes for you if you are so inclined, but I doubt it matters, since you seem to ignore any proof.

Being "better" than the MS ABI doesn't really make a calling convention godly. Because it's not a feat at all to be above garbage.


BTW if you don't accept my challenge then I can only assume I've won the "bloated" debate, so get schooled.


Last edited by Furs on 31 Mar 2017, 15:12; edited 1 time in total
Post 31 Mar 2017, 15:08
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
Are you fucking retarded? I GAVE YOU A LINK THAT PUSH IS ****FASTER**** THAN MOV because of newer processors implementing a proper stack machine.

I get it, you probably use a CPU from 2003 that's why you don't even understand why the ABI is so shit. You have no idea what AVX is because of your shit CPU, so you don't understand why the ABI is total trash even for vectors above SSE.

What the fuck do you want other than 3rd party proof? Pathetic kid.

See: http://stackoverflow.com/questions/36631576/what-is-the-stack-engine-in-the-sandybridge-microarchitecture

Show me proof of your bullshit about MOV being faster than PUSH for any CPU that supports AVX, or GET THE FUCK LOST BITCH.

Oh and btw, stdcall has the same size as my code (or even smaller), point...? It's even smaller in few cases, means even LESS bloat.

Though, I did specifically say that the MS ABI is designed like trash, not that stdcall is "the best".

Being "better" than the MS ABI doesn't really make a calling convention godly. Because it's not a feat at all to be above garbage.



oouuuchhh, touchy! ;D

I am asking a BLOATED question. Not speed. I am saving speed for your next humiliation.

Calm your tits down. This is not a barking competition Very Happy

My Challenge stands: Bloated, where?
Post 31 Mar 2017, 15:12
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
hihihi. Someone is burning down his entire house tonight! ;D
Post 31 Mar 2017, 15:16
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
> Bloated where?
* In instruction encoding/size/executable size/RAM use.
* In stack space use (8 bytes wasted if not aligned, even if function doesn't use SSE).

Need more?

Since you refuse to add your own code, here's my MS ABI attempt:


Code:
use64
; this is to make vars resolved for this example (not real)
rept 10 n { var#n: }

mov rcx, [var1]
mov rdx, [var2]
mov r8, [var3]
mov r9, [var4]
mov rax, [var10]
mov [rsp+8*4+8*5], rax
mov rax, [var9]
mov [rsp+8*4+8*4], rax
mov rax, [var8]
mov [rsp+8*4+8*3], rax
mov rax, [var7]
mov [rsp+8*4+8*2], rax
mov rax, [var6]
mov [rsp+8*4+8], rax
mov rax, [var5]
mov [rsp+8*4], rax
call func

mov rcx, [var1]
mov rdx, [var2]
mov r8, [var3]
mov r9, [var4]
mov rax, [var10]
mov [rsp+8*4+8*5], rax
mov rax, [var9]
mov [rsp+8*4+8*4], rax
mov rax, [var8]
mov [rsp+8*4+8*3], rax
mov rax, [var7]
mov [rsp+8*4+8*2], rax
mov rax, [var6]
mov [rsp+8*4+8], rax
mov rax, [var5]
mov [rsp+8*4], rax
call func


func:
ret

211 bytes, it lost, IT IS MORE BLOATED.

Feel free to improve it (not my fault you refuse a challenge you know it's lost) but remember: it has to use less stack than mine and compile to less bytes, or it is more bloated!!!


BTW here's stdcall:


Code:
 use64
; this is to make vars resolved for this example (not real)
rept 10 n { var#n: }

push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
push qword [var5]
push qword [var4]
push qword [var3]
push qword [var2]
push qword [var1]
call func

push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
push qword [var5]
push qword [var4]
push qword [var3]
push qword [var2]
push qword [var1]
call func


func:
ret 8*10

133 bytes, the LEAST bloated (so why even bring it up? to get owned even more?!?)

Now, IF and ONLY IF "func" uses SSE, then it becomes 145 bytes. Still way less than 211 bytes, don't you think so?

You lost.


Bloated where? 211 bytes versus 145 is not bloated? And it only becomes worse the more times you call this function. Idiot.


EDIT: Oops I messed up argument on MS ABI, it's even worse! 211 bytes not 187.
Post 31 Mar 2017, 15:19
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477

Furs wrote:
> Bloated where?
* In instruction encoding/size/executable size/RAM use.
* In stack space use (8 bytes wasted if not aligned, even if function doesn't use SSE).

Need more?

Since you refuse to add your own code, here's my MS ABI attempt:


Code:
use64
; this is to make vars resolved for this example (not real)
rept 10 n { var#n: }

mov rcx, [var1]
mov rdx, [var2]
mov r8, [var3]
mov r9, [var4]
mov rax, [var10]
mov [rsp+8*4+8*5], rax
mov rax, [var9]
mov [rsp+8*4+8*4], rax
mov rax, [var8]
mov [rsp+8*4+8*3], rax
mov rax, [var7]
mov [rsp+8*4+8*2], rax
mov rax, [var6]
mov [rsp+8*4+8], rax
mov rax, [var5]
mov [rsp+8*4], rax
call func

mov rcx, [var1]
mov rdx, [var2]
mov r8, [var3]
mov r9, [var4]
mov rax, [var10]
mov [rsp+8*4+8*5], rax
mov rax, [var9]
mov [rsp+8*4+8*4], rax
mov rax, [var8]
mov [rsp+8*4+8*3], rax
mov rax, [var7]
mov [rsp+8*4+8*2], rax
mov rax, [var6]
mov [rsp+8*4+8], rax
mov rax, [var5]
mov [rsp+8*4], rax
call func


func:
ret

211 bytes, it lost, IT IS MORE BLOATED.

Feel free to improve it (not my fault you refuse a challenge you know it's lost) but remember: it has to use less stack than mine and compile to less bytes, or it is more bloated!!!


BTW here's stdcall:


Code:
 use64
; this is to make vars resolved for this example (not real)
rept 10 n { var#n: }

push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
push qword [var5]
push qword [var4]
push qword [var3]
push qword [var2]
push qword [var1]
call func

push qword [var10]
push qword [var9]
push qword [var8]
push qword [var7]
push qword [var6]
push qword [var5]
push qword [var4]
push qword [var3]
push qword [var2]
push qword [var1]
call func


func:
ret 8*10

133 bytes, the LEAST bloated (so why even bring it up? to get owned even more?!?)

Now, IF and ONLY IF "func" uses SSE, then it becomes 145 bytes. Still way less than 211 bytes, don't you think so?

You lost.


Bloated where? 211 bytes versus 145 is not bloated? And it only becomes worse the more times you call this function. Idiot.


EDIT: Oops I messed up argument on MS ABI, it's even worse! 211 bytes not 187.



No you INCOMPETENT idiot! The requirement for MS64-bit ABI is only 3;

1. Stack must be aligned to 16.
2. Create shadow space
3. FP data goes to XMM. Integers go to GPR.

That's it. If you want to save 10_000_000H, It's your choice!

See, I told you many times that you are INCOMPETENT. Now everybody is laughing at you!
Laughing

EDIT: 10_000_000H data and variables! ;D
Post 31 Mar 2017, 15:31
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 361
Excuse me, what? I really don't understand what you are saying.

Straight from the horse's mouth, so to speak: https://msdn.microsoft.com/en-us/library/ms235286.aspx

Any parameters beyond the first four must be stored on the stack, above the shadow store for the first four, prior to the call.

That's what Microsoft says, you know, the designers of the ABI. I'm not sure what you're getting at, but you obviously are beyond clueless and have never programmed in asm (or at least used a function with more than 4 parameters).

At this point, it is clear you've:

1) Never programmed asm and are just a script kid.
2) Never used a function with more than 4 parameters in 64-bit (lol at schooling me!!! hilarious), in which case you have NEVER EVEN USED THE MS ABI TO ITS FULL DESCRIPTION. YOU CANNOT JUDGE IT if you haven't even used its BAD PARTS. Let the judging for people who have a clue and experience, and stay with your toys.

I'm done wasting time with a script kid. This is an asm forum, I assumed people here are at least smart and know assembly + try to either code for performance or size. Else they'd just use HLLs. Guess I was wrong about that one.
Post 31 Mar 2017, 15:35
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 477
Furs, so called smart calling convention:


Code:
push qword [var10
push qword [var9
push qword [var8
push qword [var7
push qword [var6
push qword [var5
push qword [var4
push qword [var3
push qword [var2
push qword [var1]



Which in CISC definitions, translate to this MAMMOTH, SUPERBLOATED micro-ops, just like his brain! ;D


Code:
 ;PUSH R10
IF StackAddrSize = 64
THEN
IF OperandSize = 64
THEN
RSP  RSP  8;
Memory[SS:RSP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
RSP  RSP  4;
Memory[SS:RSP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
RSP  RSP  2;
Memory[SS:RSP SRC; (* push word *)
FI;
ELSE IF StackAddrSize = 32
THEN
IF OperandSize = 64
THEN
ESP  ESP  8;
Memory[SS:ESP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
ESP  ESP  4;
Memory[SS:ESP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
ESP  ESP  2;
Memory[SS:ESP SRC; (* push word *)
FI;
ELSE (* StackAddrSize = 16 *)
PUSH—Push WordDoubleword or Quadword Onto the Stack
INSTRUCTION SET REFERENCEM-U
Vol. 2B 4-513
IF OperandSize = 32
THEN
SP  SP  4;
Memory[SS:SP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
SP  SP  2;
Memory[SS:SP SRC; (* push word *)
FI;
FI;

;PUSH R11
IF StackAddrSize = 64
THEN
IF OperandSize = 64
THEN
RSP  RSP  8;
Memory[SS:RSP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
RSP  RSP  4;
Memory[SS:RSP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
RSP  RSP  2;
Memory[SS:RSP SRC; (* push word *)
FI;
ELSE IF StackAddrSize = 32
THEN
IF OperandSize = 64
THEN
ESP  ESP  8;
Memory[SS:ESP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
ESP  ESP  4;
Memory[SS:ESP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
ESP  ESP  2;
Memory[SS:ESP SRC; (* push word *)
FI;
ELSE (* StackAddrSize = 16 *)
PUSH—Push WordDoubleword or Quadword Onto the Stack
INSTRUCTION SET REFERENCEM-U
Vol. 2B 4-513
IF OperandSize = 32
THEN
SP  SP  4;
Memory[SS:SP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
SP  SP  2;
Memory[SS:SP SRC; (* push word *)
FI;
FI;

;PUSH R9
IF StackAddrSize = 64
THEN
IF OperandSize = 64
THEN
RSP  RSP  8;
Memory[SS:RSP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
RSP  RSP  4;
Memory[SS:RSP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
RSP  RSP  2;
Memory[SS:RSP SRC; (* push word *)
FI;
ELSE IF StackAddrSize = 32
THEN
IF OperandSize = 64
THEN
ESP  ESP  8;
Memory[SS:ESP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
ESP  ESP  4;
Memory[SS:ESP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
ESP  ESP  2;
Memory[SS:ESP SRC; (* push word *)
FI;
ELSE (* StackAddrSize = 16 *)
PUSH—Push WordDoubleword or Quadword Onto the Stack
INSTRUCTION SET REFERENCEM-U
Vol. 2B 4-513
IF OperandSize = 32
THEN
SP  SP  4;
Memory[SS:SP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
SP  SP  2;
Memory[SS:SP SRC; (* push word *)
FI;
FI;

;PUSH R8
IF StackAddrSize = 64
THEN
IF OperandSize = 64
THEN
RSP  RSP  8;
Memory[SS:RSP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
RSP  RSP  4;
Memory[SS:RSP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
RSP  RSP  2;
Memory[SS:RSP SRC; (* push word *)
FI;
ELSE IF StackAddrSize = 32
THEN
IF OperandSize = 64
THEN
ESP  ESP  8;
Memory[SS:ESP SRC; (* push quadword *)
ELSE IF OperandSize = 32
THEN
ESP  ESP  4;
Memory[SS:ESP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
ESP  ESP  2;
Memory[SS:ESP SRC; (* push word *)
FI;
ELSE (* StackAddrSize = 16 *)
PUSH—Push WordDoubleword or Quadword Onto the Stack
INSTRUCTION SET REFERENCEM-U
Vol. 2B 4-513
IF OperandSize = 32
THEN
SP  SP  4;
Memory[SS:SP SRC; (* push dword *)
ELSE (* OperandSize = 16 *)
SP  SP  2;
Memory[SS:SP SRC; (* push word *)
FI;
FI;

6 more BLOATS to go

== snipped out of respect to board owner ==




Enjoy!! And have a good day!

Don't use Furs calling convention, people! ;D
Post 31 Mar 2017, 15:44
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 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.