Terraspace / UASM

UASM - Macro Assembler
http://www.terraspace.co.uk/uasm.html
Other
220 stars 49 forks source link

INVOKE outside PROC reserves stack #105

Closed vid512 closed 4 years ago

vid512 commented 5 years ago

Current situation, as I understand it (correct me if wrong): When 'OPTION WIN64' is not set, the default behavior of INVOKE is to always reserve and release needed stack space for every call. When any flag of 'OPTION WIN64' is set, INVOKE no longer does this. With 'OPTION WIN64', if INVOKE is used inside PROC, the stack is reserved automatically in prologue/epilogue, but if INVOKE is used outside any PROC, the code has to reserve stack for the INVOKE manually.

It would seem to me useful, to have ability for INVOKE to still keep reserving stack, when it is used outside PROC. It could be a new 'OPTION WIN64' flag, which would enable this behavior. With such flag enabled, it would mean that INVOKE would be always "safe" to use without having to worry about stack, both inside and outside of PROC.

john-terraspace commented 5 years ago

I wouldn't recommend having any code NOT inside a proc as its the most reliable way of ensuring proper stack alignment at all times. In 32bit code startup would often just start at an entry point label IE: entry:

However for 64bit code you should use a Main proc / CrtStartup type proc and use that as the entry point. Any other method can lead to unpredictable situations with stack.

If you really know what you're doing and want to achieve this you can always wrap the specific INVOKEs outside of PROCS with different options.

vid512 commented 5 years ago

However for 64bit code you should use a Main proc / CrtStartup type proc and use that as the entry point. Any other method can lead to unpredictable situations with stack.

Do you mean that I should use the highlevel PROC directive, or that my code should conform to ABI expected fom entry point function? The second claim is obviously correct, but the first IMO shouldn't be required. I should have option to write my entry point function without the highlevel directives, even if I am using PROC (with OPTION win64) elsewhere.

And in such case, it would be nice, to have the ability to still use the INVOKE same way as when 'option win64' is not set. It's not just about entry point function, it's about possibility to use INVOKE with automatic stack allocation in any code outside of PROC (for example callback with custom ABI).

If you really know what you're doing and want to achieve this you can always wrap the specific INVOKEs outside of PROCS with different options.

Can this be done in a macro wrapper for INVOKE, which would work both inside and outside of PROC? In other words, is it possible to discover at compile-time, whether code is inside PROC or outside it, and conditionally compile options controlling behavior of INVOKE?

john-terraspace commented 5 years ago

There is a built-in variable @ProcName

This should tell you the last PROC to be parsed, and there is also @ProcLine

Which should == 0 outside of any proc.

So it should be possible to use that in a macro to achieve any sort of combination of invoke modes for in vs. out of a proc.

From: vid512 notifications@github.com Sent: 18 June 2019 16:08 To: Terraspace/UASM UASM@noreply.github.com Cc: John Hankinson john@terraspace.co.uk; Comment comment@noreply.github.com Subject: Re: [Terraspace/UASM] INVOKE outside PROC reserves stack (#105)

However for 64bit code you should use a Main proc / CrtStartup type proc and use that as the entry point. Any other method can lead to unpredictable situations with stack.

Do you mean that I should use the highlevel PROC directive, or that my code should conform to ABI expected fom entry point function? The second claim is obviously correct, but the first IMO shouldn't be required. I should have option to write my entry point function without the highlevel directives, even if I am using PROC (with OPTION win64) elsewhere.

And in such case, it would be nice, to have the ability to still use the INVOKE same way as when 'option win64' is not set. It's not just about entry point function, it's about possibility to use INVOKE with automatic stack allocation in any code outside of PROC (for example callback with custom ABI).

If you really know what you're doing and want to achieve this you can always wrap the specific INVOKEs outside of PROCS with different options.

Can this be done in a macro wrapper for INVOKE, which would work both inside and outside of PROC? In other words, is it possible to discover at compile-time, whether code is inside PROC or outside it, and conditionally compile options controlling behavior of INVOKE?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Terraspace/UASM/issues/105?email_source=notifications&email_token=AEAZAVEYGW53TV2OPUN4F2DP3D24NA5CNFSM4HHV2OY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX66K5Y#issuecomment-503178615 , or mute the thread https://github.com/notifications/unsubscribe-auth/AEAZAVC4Y5SBDSGQONWDRD3P3D24NANCNFSM4HHV2OYQ .

vid512 commented 5 years ago

Allright, if that works, it should be enough. Thanks.

john-terraspace commented 5 years ago

Let me know how you get on with that, it would be good for us to make a test case for it. If it needs a tweak we can do that asap now for 2.49 release which will be ready soon.

From: vid512 notifications@github.com Sent: 18 June 2019 22:27 To: Terraspace/UASM UASM@noreply.github.com Cc: John Hankinson john@terraspace.co.uk; Comment comment@noreply.github.com Subject: Re: [Terraspace/UASM] INVOKE outside PROC reserves stack (#105)

Allright, if that works, it should be enough. Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Terraspace/UASM/issues/105?email_source=notifications&email_token=AEAZAVBXQCFOJ25RWGQHHDTP3FHJLA5CNFSM4HHV2OY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAAPHI#issuecomment-503318429 , or mute the thread https://github.com/notifications/unsubscribe-auth/AEAZAVEX2WR77A7JEXUI6U3P3FHJLANCNFSM4HHV2OYQ .

john-terraspace commented 5 years ago

2.49 is up, please test and let me know if this idea works and I can close this issue.

vid512 commented 5 years ago

I won't get to testing until at least a week, sorry. When I test this, I'll reply here.