The MASM Forum

jj2007,
HJWasm is smart and you don't need to use OPTION PROLOGUE, OPTION EPILOGUE, it will decide if it is necessary or not to write it, however, you can use it if you insist.
So, if you have locals or/and push registers, it will create PROLOGUE and EPILOGUE, otherwise it will just skip it.
You just need to write Someproc PROC FRAME  :biggrin:

HJWasm does so much, much, much more than any other assembler, especially ML64 (it still wears diapers, long time not changed) :P 

There are 2 issues at play here, ML64 is a crude pig but it has this advantage, by the time you get to fly it, you will understand why it is like that and that is more use to you that having it spoon fed to you while covering up the underlying yukkies. It is also "blessed" with appallingly bad documentation and lack of viable examples that mean you must learn it by test piece but it depends what you want, the "Visual Basic" approach of catering for idiots or the low level approach to know why something works.

Long ago when Iczelion and I were working on the early forms of MASM32 it was even worse, the documentation was garbage, Microsoft were telling everyone that you never need assembler any longer and every idiot and their dog though they could tell you something with the C compilers. We changed all of that reasonably quickly and they shut their mouths.

I think you are doing well with your re-write of JWASM and it is looking like a good tool but it will not teach you the yukkies underlying win64, that you have to do the hard way.

ML64 was basically designed to write procedures for VC and its OK in that area, expanding it to a general purpose assembler for making EXE and DLL files is another matter. Its never going to be fun but you will learn much on the way.

With other words more is less and good is actually bad :biggrin:
Reminds me on my school time when I was told: you can't get an A, your knowledge is to wide :lol:

Microsoft probably see it differently, it already does the job they need it for, essentially procedures for 64 bit C compilers that don't have an inline assembler. There are two classes of people in terms of learning Win64, those who want to know how it works and those who prefer to try and keep it a secret, I opt for the former. I have yet to see what your contribution is to ML64, I am more or less immune to other people's opinions when they don't contribute to what is being done. I hope you finish the development of HJWASM but it has little to do with what I am doing with ML64.

BTW you can use H/JWasm in "low-level" mode also, if you don't want the automatic stack frame features. Previously, just don't set the advanced options; maybe now you have to tell it option:0 or something. And of course you can override the 'invoke" keyword if you want to roll your own. That way it's exactly compatible with ML64, concerning those features. There are more little differences, like ML doesn't do "assume" command. Again, just don't use those commands / abilities. In this way ML code more or less always works in H/JWasm ... except for a couple very minor things I don't remember exactly, like maybe macro nesting levels and line continuations. Going the other way, of course, is no good. If you use H/JWasm features freely, many don't work in ML64, and it will take a lot of work to convert. And, of course, you need two assemblers with ML, one for 32 and one for 64. I think it's still true that's not the case with H/JWasm, all versions (?) do both 32 and 64.

None of my posted code used the stack frame features, and I usually use my own invoke macros, but even so there are many convenient things like "assume" in it which makes it hard converting to ML64. Basically the code needs to be "crippled" in a dozen little ways. That's why I just can't get interested in converting it all to work with ML. Also why I took months wondering whether to use those H/JWasm features, I knew I was cutting myself off from easy ML64 compatibility. Decided I couldn't stand to deliberately use such an inferior program. Like shooting yourself in the foot just to make life more challenging.

QuoteLike shooting yourself in the foot just to make life more challenging.

Nice comparison, I totally agree with you. :t
There is one more thing: Potentially write something for commercial use, can we do that with ML.exe or ML64.exe?

Quote from: rrr314159 on July 04, 2016, 08:27:35 AMI knew I was cutting myself off from easy ML64 compatibility. Decided I couldn't stand to deliberately use such an inferior program. Like shooting yourself in the foot just to make life more challenging.

It is not an easy decision. My macros work with ml, (h)jwasm and asmc, and it was hard to achieve that, a bit masochistic indeed. But it was worth the effort because a) everybody uses ML and b) many use JWxxx and AsmC because they are better.

The situation with ML64 is different: Microsoft has decided to cripple this software, so that it's only useful for compilers. So be it :t

When I saw OPTION DOTNAME in Vasily's files, I knew awkward things were ahead, but really, .if MACRO ::) ::) ::)

Hutch, I know this hurts your feelings, but ML64 is not a serious option. Let's get over it, and concentrate on a good set of includes and macros that work with HJWasm and Nidud's AsmC, without having to set a bunch of idiosyncratic options that require a user's manual.

Halle*ucke*lujah jj2007  :t

Hallo,

healthy competition is very good, I love the assembly language, so I try to write in this language, but if the task becomes easier, then I find it easier to program in assembler. It is worth remembering that changes in macro assembler, have been made due to the change of the structure of the C compiler. And as we develop programming in assembly language, then HJwasm decision is the logical continuation of the disconnect assembly from the C language.

Regards

Very logical conclusion 8)

JJ,

Quote
Hutch, I know this hurts your feelings, but ML64 is not a serious option. Let's get over it, and concentrate on a good set of includes and macros that work with HJWasm and Nidud's AsmC, without having to set a bunch of idiosyncratic options that require a user's manual.

Not at all, I pursue what I am doing for good reasons and while no-one seems to have a clue as to what needs to be done with ML64 so I will just continue to work on it as I slowly quantify bit by bit.

Everybody has a clue what needs to be done with ML64 - same thing MS decided to do with it - trash it ;)

I don't care for .if macro either. Instead of that I would just stop using .if (etc) entirely.

It's important to note that it would be a very different situation if ML64 retained the ML 32-bit capabilities (like invoke and assume, etc); and HJwasm had new better features. Then it would be similar to GoAsm, Sol assembler, MasmBasic, and other systems that their users love. One could still say you're "shooting yourself in the foot" by not using (for instance) RadAsm, ObjAsm, or EasyCode, but these involve new features one has to learn, and figure out the quirks. I don't blame anyone for sticking with what they're used to and not bothering with these types of systems, even though they may be more powerful.

But in this situation, HJwasm is the "good old" assembler. ML64 is deliberately crippled. So not only you have to learn new ways of doing things, it's a big step back. HJwasm does have some new stuff, but even the stack frame option is an attempt to make it as similar to masm32 as possible. You can really tell the difference when you convert old 32-bit code. With ML64 it often requires major surgery, whereas with HJwasm it's as smooth a transition as possible.

Note, I'm not considering logistical meta-issues like licensing, support in the future, Open Source code, and so forth, because I know next to nothing about them. I'm only talking about the programming tool. If such issues force someone to use ML64, so be it; I'm glad they don't affect me.

 :biggrin:

I take the comment about trashing ML64 as a verification of not having a clue about how to use it. Its a little before your time here but in about 2006 we had a member from the Microsoft development team, Kang Su Gatlin who asked questions about what form a 64 bit version should take and the advice he was given was to leave ML alone and produce a stand alone 64 bit version. At that time M$ had been using NASM and YASM for writing small bits of 64 bit assembler and when they produced their own, ML64, it was about as bare bones as the former because it only needed to be able to do what they needed. Fortunately it retained the old MASM macro system which was familiar to a wide range of people.

Comments like "ML64 is deliberately crippled" are simply nonsense, Microsoft do not spend development money were they don't need to so it has never been developed as a consumer friendly easy to use toy. Its main curse is almost non existent documentation and the little they keep on MSDN would have to be described as obscure at best. Now the interesting part is that nobody has been willing to get off their arse and produce a viable set of include files, libraries and examples for most of what has been peddled as 64 bit assemblers, POASM is under documented, ML64 is little better, JWASM was a flop that was abandoned by its author with little useful support and even HJWASM has little support.

Contrast this with the work that Vasily has done and the range of examples done by Mikl__ and while my Russian is not up to scratch, at least the work has been done. Its worth noting that there are other 64 bit assemblers available, FASM has been up and going for years and Bogdan has produced his own assembler as well and of course if you like bare bones assemblers, the GNU "as" assembler (GAS) separates the men from the boys.  :P

Quote from: hutch-- on July 05, 2016, 11:05:42 AMComments like "ML64 is deliberately crippled" are simply nonsense

My take on this was a nuance softer:

Quote from: jj2007 on July 04, 2016, 05:05:19 PMMicrosoft has decided to cripple this software, so that it's only useful for compilers. So be it :t

When I saw OPTION DOTNAME in Vasily's files, ...

One can argue about "deliberately", but crippled it is. If Habran and Nidud can produce an assembler that knows about .if and .endif, how much time and money would it have taken for that team of software heros in Redmond???

I fear that you might succeed: To my great surprise, the 30-year-old OPTION DOTNAME did so far not break my MasmBasic sources. But it's disgusting to be forced to accept a .if macro just because M$ thinks that assembly programmers should go to hell. Besides, we have two members, Habran and Nidud, who have control over the source of powerful 64-bit assemblers - why that desperate attempt to be friends with Micros**t? Do I have to remind you about slickhuh.asm, Hutch?

 :biggrin:

Problem is you are not preaching to the converted, there are plenty of assemblers out there and I am not particularly committed to any of them in 64 bit.

> Besides, we have two members, Habran and Nidud, who have control over the source of powerful 64-bit assemblers

And Japheth before them. I archived his last work for any who wanted it.

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

My real beef in 64 bit Windows is with Microsoft with very poor specs of the low level aspects of calling API code.

Quote from: hutch-- on July 05, 2016, 07:26:42 PMRE: 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,
  .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.

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


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


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. (http://masm32.com/board/index.php?topic=5465.0) I attach it to make sure we are talking about the same macros. Is this the fn64 you are using?
    fn64 MACRO func,args:VARARG
      sub rsp, 40
      invoke func,args
      add rsp, 40
    ENDM

 :biggrin:

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.

Quote from: hutch-- on July 05, 2016, 11:05:42 AM
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.

Quote from: hutchnobody 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.

Quote from: hutch-- on July 06, 2016, 12:07:17 AMFor 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
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


Quote from: rrr314159 on July 06, 2016, 12:14:27 AM
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

Quote
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.

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.


    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


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

Quote from: hutch-- on July 06, 2016, 10:54:54 AM
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
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

Quote from: fearless on July 06, 2016, 07:34:59 AMi 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