Static RSP built in JWasm

[habran]

I am back as I promissed 8)

I have succeeded to build in JWasm STATIC RSP and it works fine
how it works?
use these options

Code Select Expand


option win64:7
option frame:auto


why all this?

because RSP is static we can calculate params and locals from RSP register, rather than use RBP
and we get awarded with free to use RBP register!!!

In the attached folder are changed sources and 64 bit JWasm.exe

here are some examples:

Code Select Expand



testproc4 PROC FRAME
LOCAL z:DWORD   
   
mov eax,22 
mov z,eax
ret
testproc4 endp

000000013F02116E  sub         rsp,8 
000000013F021172  mov         eax,16h 
000000013F021177  mov         dword ptr [rsp],eax 
000000013F02117A  add         rsp,8 
000000013F02117E  ret


[johnsa]

Nice work! :) Another register back helps given how many 64bit fastcall abi is trashing all over the place.

[habran]

thanks johnsa
with this we are getting not only RBP back but code are more compact because of using the home space to store
registers

I have to remind you that RBP register is saved by default and is ready to use any time (that helps for the stack alignment)

I am working on another version where RBP will not be saved
It is working already but there is still some problem not solved

the JWasm version in a folder goes together with the .FOR feature

this is now most advanced assembler in the Universe :t

[habran]

I succeeded to build the version without pushing RBP which is more similar to C prologue :t
I will just test it a little bit before I post it here

[habran]

here it is 8)

johnsa worked together with me on debug info and Japheth gave some hints how to make debug to work :t

now both versions work correctly with debug info for locals and params

for now only MSVC12 understand debug info

I have replaced the folder at the top with the new version with a debug working

[habran]

there was some problem with pushed rbp version to read locals correctly :icon_redface:
both version had a problem with a second RET in a function because of:
      CurrProc->e.procinfo->stored_reg=0;
      CurrProc->e.procinfo->pushed_reg=0;
when I removed it everything worked fine
I have fixed it and replaced both versions 8)
now both version are working beautifully :t 

[habran]

this last version with no RBP saved is now OK :t
there was still necessary some tweaking
please test it

[japheth]

Cool!

However, if a "frame pointer omission" feature is to be added to jwasm, it should be implemented for 32-bit as well.

This makes the user interface of this implementation a bit unfortunate, because the flags in OPTION:WIN64 are intended for the Win64 ABI only.

[habran]

thanks japheth for flowers

I am still working on debug info for different debuggers
I just figured out how to make it for MSVC 2005
but I would like to do that for WinDbg 6.11 and 6.12
I am planing to make switches for different debuggers 

However, if a "frame pointer omission" feature is to be added to jwasm, it should be implemented for 32-bit as well.

I am a little bit skeptic about 32 bit "frame pointer omission" because
people who have already written and tested programs in 32 bit will not
go through all of they program to get read of push/pop commands
and for writing new programs it would be like going in the past
IMO new programs should be written in 64 bit where ever possible

however, if people think that it is good idea it will be no big dill to tweak a bit all together

anyway, thank you japheth for taking time to go through source :t

I am pretty happy how it all together works

[japheth]

because people who have already written and tested programs in 32 bit will not
go through all of they program to get rid of push/pop commands

It's a matter of course that a frame pointer omission feature for 32-bit must be able to allow PUSH and POP instructions.

That's not impossible, but requires a bit more work. Evidently, since the assembler itself cannot reliably track PUSH and POP inside a procedure, it's the programmer's duty to do this - all the assembler can do is to "assist".

The preferred approach is a new option that will allow a more comprehensive control of how stack variables are accessed.  Additionally a few macros that track the current value of ESP by renaming a few instructions with OPTION RENAMEKEYWORD.

IMO new programs should be written in 64 bit where ever possible

I still prefer my good, old 32-bit XP.  :icon_cool:

[habran]

OPTION RENAMEKEYWORD is good idea :idea:
I agree with you that it would be possible to make it work
and it would be more sophisticated than 64 bit
however, you are on holidays from JWasm, remember ;)

perhaps, because this version is dedicated to Margaret Thatcher
you don't want to "thatch" it any more

I still prefer my good, old 32-bit XP. :icon_cool:

I still love Commodore 64, unfortunately it is obsolete now :(

I will suggest a proposal here:

If at least five members from this forum vote for 32 bit "static stack", than it is worth to build it in JWasm 
than we will talk about who will implement it

 

[japheth]

If at least five members from this forum vote for 32 bit "static stack", than it is worth to build it in JWasm 
than we will talk about who will implement it

I'm afraid there aren't five members here who know what we're talking about.

[habran]

you are exaggerating :shock:

If so, why would we go through the trouble to build it :(

[sinsi]

I'm afraid there aren't five members here who know care what we're talking about.

[habran]

what about you sinsi, Amberman?
do you know care what we're talking about?