Invoke macro reading prototypes

[HSE]

Hi All!

This is an update of Invoke macro for ML64 that can read prototypes to detect errors in type and number of arguments and allow or not to promotion.

H2incX @DefProto macro is used for still undeclared procs and a more simple macro @DefProtoE for procs already declared in Hutch's includes:

Code: [Select]

    @DefProtoE macro ApiQual, ProcName, CallConv, NameSuffix, Params, DecorSuffix
      ifdif <CallConv>, <vectorcall>
        ??CallConv equ <fastcall>
      else
        ??CallConv equ <&CallConv>
      endif

      ifndef __JWASM__
      ProcName&ProtoConv equ <??CallConv>
      ProcName&ProtoParams textequ <&Params>
      endif
    endm

@DefProtoE DllImport, fptoa, WIN_STD_CALL_CONV,,<:REAL8,:QWORD>
@DefProtoE DllImport, vc__i64toa, WIN_STD_CALL_CONV,, <:SQWORD, :PTR SBYTE, :SDWORD>
@DefProtoE DllImport, __imp_sprintf, WIN_STD_CALL_CONV,, <:VARARG>, 4
@DefProtoE DllImport, ExitProcess, WIN_STD_CALL_CONV,, <:UINT>, 4


You can see it's no so automatic to write proc name because can be expanded or not. Because in the example Invoke is forced to expansion vc_sprintf don't work and must be __imp_sprintf.

Variable AllowPromotions can be TRUE or FALSE and control promotions. If FALSE you have to manually convert for example a BYTE in QWORD, if function is Unprototyped or Vararg. If TRUE that is maked by Invoke macro.

Obviously is just a beginning 

First test (testxmm64) show if Invoke still work, and also VARARG. Here you can see what happen if you change AllowPromotions to FALSE.

Second test (Hutch2) show some error detections already working:

Code: [Select]

hutch2.asm(163) : error A2052:forced error :  Too many arguments (>2)

hutch2.asm(164) : error A2052:forced error : Argument for rcx is incorrect

hutch2.asm(164) : error A2052:forced error : Argument for rdx is incorrect

hutch2.asm(168) : error A2052:forced error : Argument (1) is missing


[jj2007]

Congrats, Hector

My Dual 64- and 32-bit Assembly package works, too, but I am in the process of generating the args info directly from the GCC headers, and currently a little bit stuck - too little time, too much distraction. We'll see

[HSE]

but I am in the process of generating the args info directly from the GCC headers

Another includes!   Well... Good luck 

[LiaoMi]

Congrats, Hector

My Dual 64- and 32-bit Assembly package works, too, but I am in the process of generating the args info directly from the GCC headers, and currently a little bit stuck - too little time, too much distraction. We'll see

Hi jj2007,

your experience can be transferred to the creation of UASM SDK for Linux