if parmbytes ¦ localbytes    

Why would the stack need aligned?

Most structures are aligned to their natural alignment. The primary exceptions are the stack pointer and malloc or alloca memory, which are aligned to 16 byte, in order to aid performance.

Borsuc: Actually, I think the new way is much smarter than stdcall, considering that 99.99% of code is generated by compiler. And of course, good asm coder can do it same way. Try disassembling some fastcall64 code, maybe you will change opinion

vid wrote:

Borsuc: Actually, I think the new way is much smarter than stdcall, considering that 99.99% of code is generated by compiler. And of course, good asm coder can do it same way. Try disassembling some fastcall64 code, maybe you will change opinion

I on the other side consider that this fastcall64 is stupid, wrong and pathetic.

An expression of people that do not know or understand ASM and CPU anymore and apply childish academic concepts. A copy paste from RISC wrong concepts.

This was bound to happen sooner or later because new people have lost the knowledge.

This is in fact a revert to dark ages of programing.

The funny part it that someday in "the future" they will re-invent STDCALL ... if they ever evolve back towards intelligence that is ... )

Until then (if ever) of course we do have to use it as it is (with help from macros probably). There is no purpose in fighting against what is.

First of all, you can see the problem with that last statement of yours.

NOTE: I'm NOT against using registers as parameters AT ALL. I'm against the stupidity of reserving STATIC stack space even for the registers. I mean I just dropped my jaw when I read it!

@vid: I dunno & don't care, I'm programming software, not cracking

How can you program using the windows API without disassembling it a little first? The MSDN documentation is shit!

Azu wrote:

How can you program using the windows API without disassembling it a little first? The MSDN documentation is shit!

Wow I always followed it when programming in Windows, I thought system APIs are kinda complex for user-mode apps understanding to be honest, so that's why I never bothered.

Plus, the documentation says how you should write even if your version of Windows doesn't have all functionality, like the crappy but so frequently found Microsoft "reserved" parameters -- ironically which almost never get used (but crash if you use them).

What's wrong with using registers intead of stack? Most 64-bit CPUs can move things into and out of the registers much faster than stack..

Azu wrote:

What's wrong with using registers intead of stack? Most 64-bit CPUs can move things into and out of the registers much faster than stack..

If you have experience in programming you could not ask such a stupid question!

Here are a few answers so you can meditate upon:

1) Sending parameters by registers is a primitive method from DOS era

2) It is faster but only for leaf functions and in heavy optimized functions. For general functions that call other functions that call other functions it is a huge mistake. And guess what this kind of functions are 90% of OS and applications body.

For your example you do need to "spill" those registers anyway in most scenarios beacuse you usually NEED arguments further in your code and you can not preserve (and thus loose) 4 registers.

The argument that you already have many registers and you can waste some of them is never valid. No matter how many registers you have you always need more

3)You need the stack anyway for more than 4 parameters

4) You need the stack for recursion.

Recursion is an fundamental programming concept. You can not do it with registers.

5) Writing to stack is NOT faster than PUSH. or it should not be. Of course you can make a CPU where this is as you wish it but conceptually the PUSH is always faster... mov [esp+48h],xxx and mov [esp+40h],yyy is not faster to be computed than an implicit and fixed mov [esp],xxx and add esp,8... This is basic CPU logic.

6)Stdcall is uniform and can be unwinded easy. Uniformity and ease of understanding and debugging is very important. It also scales nicely to any number of parameters.

have you noticed the .pdata structures and the fixation of valid prologues and epilogues that are needed now in order to unwind stack and to provide exception handling?

This is the result of stupidity. They have to patch holes up in very complex and pathetic ways.

Think Occam's razor: when a solution is complex then it is wrong. There is no beauty in complexity and no simplicity inside complexity

Complex = stupid.

7) It is NOT a new improved concept.

It results in larger code and more complex code with no speed increase what so ever.

On inner loops an leaf functions ASM programmers did a lot of tricks and handcrafted optimizations anyway. You do not use STDCALL there.

If parameters are passed via varargs (for example, ellipsis arguments), then essentially the normal parameter passing applies including spilling the fifth and subsequent arguments. It is again the callee's responsibility to dump arguments that have their address taken. For floating-point values only, both the integer and the floating-point register will contain the float value in case the callee expects the value in the integer registers.

So is the use of pointers, and strings, and integers. All of those are very old things that were around way back in DOS. But you use them, don't you?

So you are a hypocrite.

Outside of heavy optimization, in functions that call many other functions (which is a design flaw most of the time), the performance of needing to save those args isn't going to matter either way.

Um.. this is what they use that extra space you reserve for them. I think it's really stupid that they don't do it themselves as local variables though.

Actually, the fastcall way is to move them into the registers themselves, not to use the register as a pointer to a memory location and move the values there.

As does fastcall. o_o

I don't know. I use a flat programming model (no .rdata, .pdata, .reloc, .resource, etc, just one section).

Their own fault for implementing it in a crappy way >_>

x86-64 is not for you, then. It's a very CISCy (complex) instruction set overall.

Bug testing isn't a new improved concept. Do you not bug test?

bogdanontanu wrote:

It results in larger code and more complex code with no speed increase what so ever.

Weird. What processor did you time this on?

On the E8400, it is much faster to move a bunch of values into some registers than it is to push them onto the stack.

And they don't need popped off (since they are in registers already), so less code is needed.

I thought we were talking about function calls. It would definitely be bad to put pushes and pops inside a tight inner loop unless absolutely necessary.

I'm really sleepy sorry, I'll reply to the rest of your post tomorrow. Unless somebody else already has.

Um.. this is what they use that extra space you reserve for them. I think it's really stupid that they don't do it themselves as local variables though.

Code 1: pushes on stack

push [eax]
call SomeFunction

SomeFunction:
...
; do something
...

;finally use the pushed value
add ebx, [esp+4]  ; assuming no other local variables

...
; do some more
...
ret 4    

mov eax, [eax]
call SomeFunction

SomeFunction:
mov [esp+4], eax

...
; do something
...

;finally use the pushed value
add ebx, [esp+4]  ; assuming no other local variables

...
; do some more
...
ret    

Azu wrote:

So is the use of pointers, and strings, and integers. All of those are very old things that were around way back in DOS. But you use them, don't you?

I am not against OLD things if they are correct.

I am against using primitive things. Primitive= suboptimal solutions used only because at the time you can not or can not understand how to do better.

Like using a wooden blade instead of an steel blade for a weapon.

Pointers are not primitive.

They are an fundamental element of programming. You can hide them in HLL and pretend that you do not use them but they are there behind the scenes.

However sending arguments to a function via registers is primitive.

Quote:

So you are a hypocrite.

I am in fact much more that that.

Quote:

Outside of heavy optimization, in functions that call many other functions (which is a design flaw most of the time), the performance of needing to save those args isn't going to matter either way.

Organizing and wrapping code correctly in hierarchical layers is NOT a design flaw. It is needed for large and real life projects.

It helps browsing, managing, understanding, debugging, porting and expanding the code base.

It is an intelligent solution. That is why FASM can run on multiple OS targets because it has such a minimal layer at least in some of its interfaces.

That is why my own assembler Sol_Asm can run on multiple OS targets and it is so easy for me to debug and maintain it as a huge ASM project.

Quote:

Um.. this is what they use that extra space you reserve for them. I think it's really stupid that they don't do it themselves as local variables though.

Priceless

Quote:

Actually, the fastcall way is to move them into the registers themselves, not to use the register as a pointer to a memory location and move the values there.

I never said that somebody is using a register as a pointer. I know how win64 fastcall works.

You move the values to registers but only for the first 4 parameters the rest are moved to stack ... and it uses up 4 registers that you will have to move to memory sooner or later.

For the rest of the parameters (and many functions have more than 4) you will have to move them to the memory / stack somehow. The PUSH is much harder to be done in this context (stack alignment issues and stack reuse) and compilers usually end up moving them as I have shown : mov [esp + 40h],argument[n]

This puts a problem if argument[n] is in fact a memory location because you can not move memory to memory ... unlike push where you can do: push [memory]

The fact that you do not understand this kind of things (the need for spill also) makes me believe that you have not studied this seriously and made up your mind from "hear say"

Quote:

As does fastcall. o_o

The essence of it is sending parameters via registers. This DOES NOT scale nicely because registers are a limited resource. They have to use a surrogate of STDCALL for more than 4 parameters anyway...

And about "unwinding" I think you have to study more again ....

Quote:

I don't know. I use a flat programming model (no .rdata, .pdata, .reloc, .resource, etc, just one section).

As I have said above you need to study more. Those sections serve a purpose... ".pdata" is relevant in this unwinding and exception handling discussion for win64 calling convention. It can not be ignored for long.

Quote:

Their own fault for implementing it in a crappy way >_>

Maybe... but this is the logical result of sending parameters in registers.... then adding rest on stack, then trying to align the stack before the call to have parameters aligned ...

In such a way one decision leads to another mistake and another mistake and then "shit happens" because your are trying to optimize at the expense of simplicity.

Quote:

x86-64 is not for you, then. It's a very CISCy (complex) instruction set overall.

I think they made some mistakes with x86-64 design but not many under the circumstances.

When I will design my own CPU I will make it more simple inside but still x-86 like IMHO. RISC CPU is a huge error but more easy to produce than CISC.

I do like x86 architecture hence it is for me. But I will not consider it's mistakes to be good things just because I like and use it. I am not lying myself.

I think the term CISC is designed by RISC zealots to be an insult for x-86 architecture.

I guess that x-86 is complex inside when compared with a RISC ... BUT it is SIMPLE to use outside from an ASM programmer's point of view and this is what I need.

I would have been better it this external simplicity of x86 architecture was obtained with more simplicity inside but you have to understand that simplicity dos not have to be implemented at all costs.


This is the only limitation to simplicity: not simpler than what is needed to get the job done. A RISC CPU is sub-optimal.


Anyway what we speak here is a software calling convention choice not a hardware choice. There is nothing in the x-86 hardware to requires or advocates such a calling convention as win64 fastcall.

It is a choice of some humans that made a mistake. A mistake we have to live with for a very long time but we do not have to "make believe" it is a good thing.

Such is life.

Quote:

Bug testing isn't a new improved concept. Do you not bug test?

I do unit testing, functional testing, fuzzy testing... almost every day at work as a programmer.

I am not against "old" I am against presenting "old" as "new" and "bad" as "better" when in fact they are not.

I also do not change things when there is no need to. When ther is no clear improvement. When new things are more complex and provide only doubtful benefits.

That is what I say: this change was not needed, it provides doubtful benefits, it is complex for no reasons other than to cover up conceptual mistakes and it is a copy cat from other architecture and older concepts.

Quote:

bogdanontanu wrote:

It results in larger code and more complex code with no speed increase what so ever.

Weird. What processor did you time this on?

Intel Core 2 Duo at 2Ghz.

Quote:

On the E8400, it is much faster to move a bunch of values into some registers than it is to push them onto the stack.

Of course it is. But this in NOT what I say. I say that to use registers for ARGUMENTS in the context of win64 fastcall convetion results in larger code, more complex code with no speed increase overall.

Why?
a) Because you will most likely spill the arguments.
b) Because you need to move on the stack the "other" arguments by not using PUSH and this is slower and it generates more code with memory arguments and it is bigger overall.
c) because you need to align the stack additionally

Quote:

And they don't need popped off (since they are in registers already), so less code is needed.

Who pops arguments?

Quote:

I thought we were talking about function calls. It would definitely be bad to put pushes and pops inside a tight inner loop unless absolutely necessary.

Yes of course. What I was trying to present is that nobody uses STDCALL inside heavy optimized inner loops. There you CAN and you SHOULD use registers at maximum...

Quote:

I'm really sleepy sorry, I'll reply to the rest of your post tomorrow. Unless somebody else already has.

Have a nice sleep.

It takes time and experience to understand those kind of things don not worry too much about them. Sleep is of the essence.


I think I have presented my available logical arguments and debating this further is not going to offer more logical arguments from my side.... hence I will rest my case and not debate it anymore.

I guess it is ok to "love" and "believe" in win64 fast call convention.

Just keep an open mind and an eye open for the alternatives and possible mistakes.

Azu, the stack isn't slow at all because it's mostly in L1 cache so it is probably the same as registers.

Azu wrote:

Um.. this is what they use that extra space you reserve for them. I think it's really stupid that they don't do it themselves as local variables though.

This is the biggest stupidity. What sense does it make to take registers are parameters only for the function to save them later on the stack? Why not just PUSH the values DIRECTLY on the stack? It avoids the "mov register, value".

For example:

Code:

Code 1: pushes on stack

push [eax]
call SomeFunction

SomeFunction:
...
; do something
...

;finally use the pushed value
add ebx, [esp+4]  ; assuming no other local variables

...
; do some more
...
ret 4    

Compared with:

Code:

mov eax, [eax]
call SomeFunction

SomeFunction:
mov [esp+4], eax

...
; do something
...

;finally use the pushed value
add ebx, [esp+4]  ; assuming no other local variables

...
; do some more
...
ret    

I count one more "mov eax, [eax]" than before (assuming "mov [esp+4], eax" is the same as "push [eax]" which IT IS NOT since it's BIGGER).

this is why fastcall64 is a stupidity. total FAIL.

What I do hate very much is how varargs were implemented:

Varargs wrote:

If parameters are passed via varargs (for example, ellipsis arguments), then essentially the normal parameter passing applies including spilling the fifth and subsequent arguments. It is again the callee's responsibility to dump arguments that have their address taken. For floating-point values only, both the integer and the floating-point register will contain the float value in case the callee expects the value in the integer registers.

I think they should have used a stack-only approach for them. It is also interesting that you are required to pass the floating point values twice... (if them are between the firsts four parameters)