habran on other assemblers.

[jj2007]

RE: SlickHuh, look at POASM1k, there is a difference between bad code and low level. All assembler used to look like that once.  :P

And Tin Lizzy was the best car ever. Btw,

Code: [Select]

  .if eax
invoke MessageBox, 0, addr txText, addr txTitle, MB_OK
  .endif
works great in PoAsm but ML64 is just too dumb for such advanced code.

[hutch--]

I confess I have done few macros in ML64 yet but what you have posted is trivial.

Code: [Select]

fn64 MessageBox,hWin,txt("Example with icon and menu."),txt("About ML64 Example"),0


[jj2007]

Attention, you might have used by accident another assembler! ML64 gives error A2008:syntax error : invoke
 fn64(2) :(

( using the macros64.inc attached to http://masm32.com/board/index.php?topic=5462.0 )

P.S.: Now this is odd - I see you have a new version of Macros64.inc in Memory benchmark with some new macros. I attach it to make sure we are talking about the same macros. Is this the fn64 you are using?

Code: [Select]

    fn64 MACRO func,args:VARARG
      sub rsp, 40
      invoke func,args
      add rsp, 40
    ENDM

[hutch--]

 

Was using. I have a nicer one now. Note that the code I am posting is experimental and will keep changing but I am coming closer to knowing what works in win64. ML64 uses close enough to normal ML macros so fiddling bits and pieces is pretty normal for someone who has a background in MASM.

This is the current replacement I am using.


    function MACRO func:REQ,arg1,arg2,arg3,arg4
      IFNB <arg1>
        mov rcx, arg1
      ENDIF
      IFNB <arg2>
        mov rdx, arg2
      ENDIF
      IFNB <arg3>
        mov r8, arg3
      ENDIF
      IFNB <arg4>
        mov r9, arg4
      ENDIF
      call func
    ENDM


For functions with more than 4 arguments I am using Vasily's "invoke" macro as I don't yet understand how it works.

[rrr314159]

Comments like "ML64 is deliberately crippled" are simply nonsense,

AFAIK they don't intend it for stand-alone but only to use with VS so removed invoke, the "end" label, assume, and similar that aren't used in VS but "cripple" it for stand-alone.

nobody has been willing to get off their arse and produce a viable set of include files, libraries and examples

Includes and libraries are all available from WinInc and, I was told, Pelles C. They are a complete set AFAIK, I used them with no trouble. If you need to know how to get them I'll find my previous post where I went over all that. AFAIK the Russians' libs and includes are equally good but may not be entirely compatible; at least, they're organized very differently.

As for examples, Iczelion's all work with little modification (except for one or two hiccups, like "tooltips"). Re. macros, most / all of macros.asm convert over with no trouble. I could find my posts where I provided quite a few of these before, including the basics like print (with c format codes). Plus I made a lot of new ones for math functions, timing, and stuff, which may be useful to others. But they have little documentation, and often use my special stack macros. If there was any interest I could polish them a bit. When I was doing it no one seemed interested so I didn't bother.

[jj2007]

For functions with more than 4 arguments I am using Vasily's "invoke" macro as I don't yet understand how it works.

Sometimes it gives me problems. For example, this one causes an exception:

Code: [Select]

.code
main proc
    sub    rsp,28h      ; shadow space, aligns stack
    invoke MessageBox,0,txt("Example with icon and menu."),txt("About ML64 Example"), 0, MB_OK
    call ExitProcess
    ret
main endp

end


[fearless]

Includes and libraries are all available from WinInc and, I was told, Pelles C.

Yes, i agree. Also i put together a list of common tools found with various microsoft development packages and .net downloads, that people may already have on there machines. I did test out the 32bit and 64bit versions of those tools and tried out the libraries from various sources.

http://masm32.com/board/index.php?topic=4162.0

64bit Libraries

The following sources seem to work when compiling with JWasm64 (copying them directly into \JWasm\Lib)

• WinInc v2.08 Lib64 (build libraries with POLIB, see intructions)
• PellesC libraries from Lib\Win64
• \Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64
• \Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64
• \Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
• \Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64

Obviously I didnt package them up into one download, much as i might have liked to, as i wouldnt have the rights to distribute most of the tools and other bits and pieces.

From my own experiences with 64bit assembler, limited as it is, i found using jwasm/hjwasm very easy to use, and converting x86 source to x64 mostly a simple search and replace for registers (ecx->rcx etc) and the addition of FRAME keyword in the procedures (PROC) , and a line or two at the start for the options: option win64 : 11, option frame : auto and option stackbase : rsp

Since i use RadASM as my IDE, i also created the additional files for the JWasm in Radasm addin - which also works with HJWasm (found here http://masm32.com/board/index.php?topic=4162.0) to further help in creating x64 programs.

The only issue i came across is the includes from WinInc - couple of definitions i had to modify, and it doesnt pair up with the library you are including, this is presumably due to the original source being the sdk header files, so some libraries and bits and pieces are mashed together or use different filenames that are not the same as the library you are including. Not hugely an issue, but it would be nicer and easier to use if they where named similar to the masm32 package include files.

It might be handy for those looking to develop x64 if there was a one stop package to download everything. The lib files possibly could be sourced from Pelle, assuming he is ok for someone to take them and package them up - which requires someone to ask him if that would be ok. Or perhaps there is already a way to include those libs from somewhere already (assuming there is no issues redistributing them)

I dont know the status of redistributing ML64, so would require someone to check that - i suspect its only to be distributed as part of the Visual Studio and its service packs - and similarly with the linker, library manager and all the dlls that are required for those tools. cvtres seems to be included with a lot of .net packages, but on its own taken from them, can it be distributed? i dont know. Assuming there was a way, that would be handy to include all those in one package.

Including HJWasm would be handy as well, but that would be up to Habran and John to decide if thats cool.

Then that leaves who is to be the curator who can collate all these separate bits and pieces into a package, and where it might be stored.

Lots of questions, not so many answers, but hopefully there is a way to make this happen - fingers crossed. I fear the biggest issue / stumbling block is the redistribution of the ms stuff tho.

[hutch--]

JJ,

Try this. So far this use of Vasily's prologue and epilogue requires at least 1 local variable. Note though that so far using the macros with a stack frame eliminates the need to manually fiddle RSP.

Code: [Select]

    OPTION DOTNAME
    option casemap:none

    include \masm64\include\temphls.inc
    include \masm64\include\win64.inc
    include \masm64\include\kernel32.inc
    include \masm64\include\user32.inc

    includelib \masm64\lib\kernel32.lib
    includelib \masm64\lib\user32.lib

    OPTION PROLOGUE:rbpFramePrologue
    OPTION EPILOGUE:rbpFrameEpilogue

    include macros64.inc

.code

main proc

    LOCAL dummy[1]:BYTE

    invoke MessageBox,0,txt("Example with icon and menu."),txt("About ML64 Example"), MB_OK
    function ExitProcess, 0

    ret

main endp

end


[mineiro]

You can build libraries on the fly sir fearless :icon_eek:, well, you don't need libraries  :shock:

Don't need insert /entry and import macro will not work to all functions, some of them don't have '__imp_'. This way object files are little and library too.

If you use 'org' to put a label on specific address and label that address with function name you don't need library, I forgot now but you can use '/base' on command line I suppose.

;edited
added zip file

[jj2007]

JJ,

Try this. So far this use of Vasily's prologue and epilogue requires at least 1 local variable. Note though that so far using the macros with a stack frame eliminates the need to manually fiddle RSP.

Yes, that's right - one local, and no more sub rsp, 28h. Besides, you can then freely choose how many args to pass with invoke:

Code: [Select]

.code
main proc
if 1 ; both work
local somevar
else ; but only this one causes an exception if the number of MessageBox parameters is wrong
sub    rsp,28h      ; shadow space, aligns stack
endif
    invoke MessageBox,0,txt("Example with icon and menu."),txt("About ML64 Example"), 100, 200, 300, 400, MB_OK
    call ExitProcess
main endp :t

[jj2007]

i found using jwasm/hjwasm very easy to use, and converting x86 source to x64 mostly a simple search and replace for registers (ecx->rcx etc) and the addition of FRAME keyword in the procedures (PROC) , and a line or two at the start for the options: option win64 : 11, option frame : auto and option stackbase : rsp
..
I fear the biggest issue / stumbling block is the redistribution of the ms stuff tho.

You shouldn't fear that, fearless :icon_mrgreen:

There might be an unorthodox workaround: No static API libs. LoadLibrary and GetProcAddress require only knowing the number and type of parameters...

Btw very informative post, thanks a lot :t