Author Topic: Difference between jwasm and uasm  (Read 794 times)

AW

  • Member
  • *****
  • Posts: 2243
  • Let's Make ASM Great Again!
Re: Difference between jwasm and uasm
« Reply #30 on: August 31, 2019, 10:00:28 AM »
Obviously, there are no restriction in the way one function can call another function in Assembly language, it should even be possible (but strangely is not) for Assemblers to have some way to make a custom calling convention using rules from a template available to users, unfortunately they don't (Something like IDA has).
I am not sure how ASMC deals in 64-bit with the traditional 32-bit calling conventions, but I don't think JWASM does it the same way.
In addition, I don't think JWASM supports the SystemV calling convention in any way, let alone aliasing traditional 32-bit calling conventions to SystemV or implementing it behind the scenes. If it does, Japheth never noticed that:  :badgrin:
https://sourceforge.net/p/jwasm/feature-requests/27/

jj2007

  • Member
  • *****
  • Posts: 9644
  • Assembler is fun ;-)
    • MasmBasic
Re: Difference between jwasm and uasm
« Reply #31 on: August 31, 2019, 05:06:14 PM »
it should even be possible (but strangely is not) for Assemblers to have some way to make a custom calling convention using rules from a template available to users

This is what prologue/epilogue macros do.

AW

  • Member
  • *****
  • Posts: 2243
  • Let's Make ASM Great Again!
Re: Difference between jwasm and uasm
« Reply #32 on: August 31, 2019, 09:25:21 PM »
@jj2007,
I don't think so, although Microsoft used macros for prologue/epilogue in 32-bit MASM ages ago and, of course, Hutch managed to produce a working solution for the Windows 64-bit ABI. However, macros are cumbersome by their own nature. For example, I can't figure out a way to produce the vectorcall convention using macros.
But there is an opportunity for assemblers, like those hosted in this website, to fill in the blanks left behind by Masm and gain popularity doing so. This was actually what gave recognition to Jwasm years ago and lots of people still believe it is worthwhile to build using Jwasm despite it being dead and buried deep since long.

nidud

  • Member
  • *****
  • Posts: 1717
    • https://github.com/nidud/asmc
Re: Difference between jwasm and uasm
« Reply #33 on: September 01, 2019, 12:45:04 AM »
I am not sure how ASMC deals in 64-bit with the traditional 32-bit calling conventions, but I don't think JWASM does it the same way.

The assumption in 64-bit is a fixed global scope based on syscall or fastcall as oppose to 32-bit where you have a mixed bag of calling conventions interacting with each other. The former is the base of the assembler and thus more sophisticated then the latter which was introduced in Jwasm more or less as a hack.

This means the 32-bit version use the individual proc definition to render a call:
Code: [Select]
    .486
    .model flat
    .code

p1  proc syscall a:ptr
    inc a
    ret
p1  endp

p2  proc stdcall a:ptr
    invoke p1,a
    ret
p2  endp

p3  proc c a:ptr
    invoke p2,a
    ret
p3  endp

    end

Code: [Select]
public p1
public _p2@4
public _p3

p1      PROC NEAR
        push    ebp
        mov     ebp, esp
        inc     dword ptr [ebp+8H]
        pop     ebp               
        ret                       
p1      ENDP

_p2@4   PROC NEAR
        push    ebp     
        mov     ebp, esp
        push    dword ptr [ebp+8H]
        call    p1               
        add     esp, 4
        pop     ebp   
        ret     4     
_p2@4   ENDP

_p3     PROC NEAR
        push    ebp   
        mov     ebp, esp           
        push    dword ptr [ebp+8H]
        call    _p2@4             
        pop     ebp               
        ret                       
_p3     ENDP

When you then add a new calling convention (vectorcall in this case) you have to apply the same logic for this to work but this is not done in Uasm. This means you have to have a global calling convention defined to assemble mixed code so this will fail in Uasm:
Code: [Select]
    .x64
    .model flat
    .code

p1  proc vectorcall a:ptr
    inc a
    ret
p1  endp

p2  proc fastcall a:ptr
    invoke p1,a
    ret
p2  endp

    end

test.asm(11) : Error A2178: Too many arguments to INVOKE
test.asm: 15 lines, 1 passes, 8 ms, 0 warnings, 1 errors


However, this will assemble but still fail:
Code: [Select]
    .x64
    .model flat, fastcall
    .code

p1  proc vectorcall a:ptr
    inc a
    ret
p1  endp

p2  proc a:ptr
    invoke p1,a
    ret
p2  endp

    end

The problem is that it uses the global definition (fastcall) to render the call to p1:
Code: [Select]
        sub     rsp, 32
        mov     rcx, qword ptr [rbp+10H]
        call    p1@@8       
        add     rsp, 32     

Another hack done in Jwasm is the use of SYSCALL which is a calling convention in 32-bit, but given this was not implemented in 64-bit it was renamed to SYSCALL_ as it is both an instruction and a calling convention in 64-bit. This is removed in Asmc so you may use the same keyword for both.

strlen proto syscall :ptr ; same for 32 and 64-bit
foo proc syscall
    syscall
    ret
foo endp

So this is the main difference between Asmc and Uasm where the same logic apply for both 32 and 64-bit in this regard. This then related to adding vector and sys-call to 64-bit. As for using STDCALL and other conventions in 64-bit this has not been an issue but given the current implementation this should also be possible.

AW

  • Member
  • *****
  • Posts: 2243
  • Let's Make ASM Great Again!
Re: Difference between jwasm and uasm
« Reply #34 on: September 01, 2019, 03:35:02 AM »

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6589
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Difference between jwasm and uasm
« Reply #35 on: September 01, 2019, 04:16:22 AM »
In Win64 you can do anything you like as long as you understand what registers to preserve and what alignment is necessary if you make any system calls at all. Get it wrong and it just won't start and you get no analysis about why. With the number of available registers in Win64 I wonder why you would bother to use other than FASTCALL at all. The main reason why I use LOCAL variables is for higher level code, mainly API code and here you need the stack frame.

The risk with non standard calling methods is messing up the stack where the FASTCALL technique comfortably handle BYTE to QWORD in the same stack locations. JWASM did win32 reasonably well but it was not properly Win64 ABI compliant and is best left to the dustbin of history.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

tastewar

  • Regular Member
  • *
  • Posts: 12
Re: Difference between jwasm and uasm
« Reply #36 on: September 06, 2019, 09:50:59 PM »
Thanks for the help! We are getting closer to some solutions.

The current challenge is that we are looking for a means of defining a proc that would use traditional stack based parameters. I understand, this is not "the" approved calling convention in x64, but we have scads of code that compiles today with jwasm on x64, which you are free to tell me is broken, but which works with our code when defining our internal functions as stdcall