The MASM Forum

General => The Workshop => Topic started by: hutch-- on August 24, 2017, 11:18:57 AM

Title: Decyphering notation in JWASM.
Post by: hutch-- on August 24, 2017, 11:18:57 AM
I have been using the following code for a tool I have made and its working OK but even after climbing through Japheth's old help file I cannot find any information on "option win64:3" as far as the trailing "3" is concerned.

    .x64
    .model  flat, fastcall
    option casemap:none
    option win64:3

Does anyone know how this works or have any documentation on it ?
Title: Re: Decyphering notation in JWASM.
Post by: TWell on August 24, 2017, 11:27:15 AM
3.9 Directive OPTION WIN64

Store Register Arguments [ bit 0 ]:
INVOKE Stack Space Reservation [bit 1]:
16-byte Alignment for Local Stack Variables [bit 2]:

3 = 11h
Title: Re: Decyphering notation in JWASM.
Post by: habran on August 24, 2017, 01:03:58 PM
Hi hutch, here is the best info for that:

/* flags for win64_flags */
enum win64_flag_values {
    W64F_SAVEREGPARAMS = 0x01, /* 1=save register params in shadow space on proc entry */
    W64F_AUTOSTACKSP   = 0x02, /* 1=calculate required stack space for arguments of INVOKE */
    W64F_STACKALIGN16  = 0x04, /* 1=stack variables are 16-byte aligned; added in v2.12 */
    W64F_SMART         = 0x08, /* 1=takes care of everything */
    W64F_HABRAN = W64F_SAVEREGPARAMS | W64F_AUTOSTACKSP | W64F_SMART,
    W64F_ALL = W64F_SAVEREGPARAMS | W64F_AUTOSTACKSP | W64F_STACKALIGN16 | W64F_SMART, /* all valid flags */
};


JWasm will save all 4 registers in the shadow space, regardless if ussed or not  while UASM saves only registers in the function which shadow space was used:

   164: subproc1  PROC myvar1:QWORD,  myvar2:QWORD
00007ff69fea1080 48 89 4C 24 08                   mov qword ptr [rsp+0x8], rcx 
   165: mov rax,myvar1
00007ff69fea1085 48 8B 44 24 08                   mov rax, qword ptr [rsp+0x8] 
   166: mov rdx,rax
00007ff69fea108a 48 8B D0                         mov rdx, rax 
   167: mov eax,1
00007ff69fea108d B8 01 00 00 00                   mov eax, 0x1 
   168: ret
00007ff69fea1092 C3                               ret 




Title: Re: Decyphering notation in JWASM.
Post by: hutch-- on August 24, 2017, 07:02:23 PM
Hi habran,

Thanks for the info, if I have it right this data is for one of your early versions of HJWASM ? I have the source for version 2.11s and have it buildable and what I am using it for is the -bin option to output direct binary code which I then read back into DB notation so the binary data can be written to disk where needed. I built the version with MSVCRT to get its size down then stuffed it through an EXE compressor to get it even smaller as I embed the file into the application that uses it so that it always finds the assembler.

I need the tool to be stand alone and while I can do what I need using 64 bit MASM, that technique needs the full assembler and linker to make the exe that the binary code is extracted from which means I cannot distribute it.
Title: Re: Decyphering notation in JWASM.
Post by: habran on August 24, 2017, 07:58:33 PM
first 3 rows are the same for JWasm :

    W64F_SAVEREGPARAMS = 0x01, /* 1=save register params in shadow space on proc entry */
    W64F_AUTOSTACKSP   = 0x02, /* 1=calculate required stack space for arguments of INVOKE */
    W64F_STACKALIGN16  = 0x04, /* 1=stack variables are 16-byte aligned; added in v2.12 */

If you don't want to use any of this above, you don't have to, it will still create 64 bit
you can use something like this:

    .x64                ; -pe requires to set cpu, model & language
    option casemap:none
    option frame:auto   ; generate SEH-compatible prologues and epilogues


or you can use your own prologue and epilogue

BTW the latest version of UASM can do the same job, as well much more advanced than that :biggrin:

Title: Re: Decyphering notation in JWASM.
Post by: hutch-- on August 24, 2017, 09:33:58 PM
Is the prologue/Epilogue code the same from MASM ? If so I have a very reliable one to try it with.
Title: Re: Decyphering notation in JWASM.
Post by: habran on August 24, 2017, 10:56:58 PM
I believe so 8)