OPTION STACKBASE also broken in x64

[jj2007]

aw27, your 64 bit example is a mirror of your programming skills.

I have not seen any evidence so far that you know how to program. You are just unable to cope with any issue. 

Folks,

You are both lightyears ahead of the average programmer (same for John & Steve, of course). You are working in an extremely tricky language, in an area that is so far badly explored. It is understandable that in certain moments the stress takes over and lets you write such things, but don't forget that you have a common goal: The best assembler in 64-bit land. You are damn close to that goal, don't spoil the party :icon14:

P.S.: I've great sympathy for Hutch' proposal to reduce the options, or at least to make them secret and officially undocumented. Frameless is pretty useless IMHO, no need to save ebp, as you have a bunch of new registers in 64-bit land. And it was never significantly faster.

[habran]

HI hutch--,
now you are talking... thank you for confirming our thoughts :t
We'll do exactly that 8)

[habran]

Hi jj2007
Thank you for the flowers 
Long time ago I've learned in my life that to give choice to people is a big mistake, because they will always chose the worst option,
so, you do that only if you don't care about them.

So, we will probable give 3 options. My proposal is:
  win64:11                     ;we will force it and you will not need to declare it
  OPTION STACKBASE     ;this one will go together with x64

  for 32 bit we will leave that choice of OPTION STACKBASE
 and if not declared it will be normal 32 bit compatible with masm

If someone want to do on they own, they can still use:
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

I'll just see with Johnsa if he agrees about it.


 

[aw27]

Long time ago I've learned in my life that to give choice to people is a big mistake, because they will always chose the worst option,

Rush forwarding was never a solution for anything.
The truth is, your win64:11 is broken as well as I demonstrated easily. While I recognize Johnsa is trying to save the ship you are doing exactly the inverse.  :(

[hutch--]

aw27,

Just keep in mind that these guys are doing a massive amount of work getting this assembler up and going and on the way through there will be bits and pieces that need to be fixed. Bug reports are useful to the extent that it helps in the development but that does not translate into telling them what to do. Design decisions are the choice of the authors, not the testers and while its fair to make suggestions, the final decisions must be left to them.

[aw27]

aw27,
the final decisions must be left to them.

Always! And you know as well that products done against the market expectancies go down the toilet.

[hutch--]

 

> Always! And you know as well that products done against the market expectancies go down the toilet.

The simple solution is to write your own.

[aw27]

> Always! And you know as well that products done against the market expectancies go down the toilet.

The simple solution is to write your own.

Things don't work like that in real life.

[johnsa]

Hi,

After investigating this one I can confirm that Visual (C++) is NOT aligning the stack to 16.

I've setup test C++ and ASM project and I've saved a screen-shot here:

www.terraspace.co.uk/stack.png

C++ will align RSP to 16 in it's own prologue to keep locals etc. aligned, but it doesn't do this up-front accounting for the call's 8byte return, hence the wrong alignment once into the ASM proc.

[coder]

I think it's the same with GCC. It's the library functions (paticularly the WinAPI) that require stack alignment, not the main or the entire program. You should have known this long ago.

[coder]

Also you guys should take into account the linker's own requirements. Some linkers do align the stack for your code while others don't.

 

[johnsa]

I can confirm that using FRAME (as intended) does counter the mis-alignment by 8 and ensures the stack is aligned to 16 on entry.

I've linked to the C++ project with assembler module, simply decorate the PROCs with "FRAME" and everything will be good to go! :)

http://www.terraspace.co.uk/testapp.zip

Code: [Select]



option casemap : none
option frame : auto
option win64: 11
OPTION STACKBASE : RSP

.code

sub1 proc private frame dest : ptr, src : ptr, val1 : qword, val2 : qword
mov dest, rcx
mov src, rdx
mov val1, r8
mov val2, r9
mov rax, qword ptr[rdx]
add rax, val1
add rax, val2
mov qword ptr[rcx], rax

ret
sub1 endp

getSum proc public frame dest:ptr, src : ptr, val1 : qword, val2 : qword
mov dest, rcx
mov src, rdx
mov val1, r8
mov val2, r9
INVOKE sub1, dest, src, val1, val2
ret
getSum endp

end



[coder]

johnsa

It's good to know that everything is turning out just fine for you guys.

Keep up the good work and get some sleep.

[johnsa]

Thanks.. :) I think 2.22 has some great fixes and new features!

Time to take a nap/break though ;)

[aw27]

After investigating this one I can confirm that Visual (C++) is NOT aligning the stack to 16.

Of course not and does not have to. What is required is to align the stack "before" the call is made. How is it possible to have simultaneously the stack aligned before the call and immediately after the call?
I give up. It is too much nonsense for me.