News:

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

Main Menu

Static RSP built in JWasm

Started by habran, June 14, 2013, 03:39:17 PM

Previous topic - Next topic

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

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!!! :bgrin:

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

here are some examples:


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

johnsa

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

habran

#2
thanks johnsa :biggrin:
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
Cod-Father

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 :biggrin:
Cod-Father

habran

#4
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
Cod-Father

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

habran

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

Cod-Father

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 :biggrin:

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 
Quote from: japheth on June 29, 2013, 02:26:14 PM
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 :bgrin:
Cod-Father

japheth

Quote from: habran on June 29, 2013, 02:57:24 PM
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.

Quote
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 :biggrin:

QuoteI 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 :biggrin:

 
Cod-Father

japheth

Quote from: habran on June 29, 2013, 07:43:17 PM
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 :biggrin:

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 :(
Cod-Father

sinsi

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

:biggrin:

habran

what about you sinsi, Amberman?
do you know care what we're talking about? :biggrin:
Cod-Father