News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

OPTION STACKBASE also broken in x64

Started by aw27, March 21, 2017, 07:58:08 PM

Previous topic - Next topic

jj2007

Quote from: habran on March 22, 2017, 08:21:20 AM
aw27, your 64 bit example is a mirror of your programming skills.

Quote from: aw27 on March 22, 2017, 09:01:04 AMI have not seen any evidence so far that you know how to program. You are just unable to cope with any issue.  :badgrin:

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)
Cod-Father

habran

Hi jj2007 :biggrin:
Thank you for the flowers  :bgrin:
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.



Cod-Father

aw27

Quote from: habran on March 22, 2017, 02:08:40 PM
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

Quote from: hutch-- on March 22, 2017, 07:02:19 PM
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--

 :biggrin:

> 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

Quote from: hutch-- on March 22, 2017, 08:42:39 PM
:biggrin:

> 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




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

Quote from: johnsa on March 23, 2017, 10:00:22 PM
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.