News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

MASM64 problem with if macro

Started by C3, October 22, 2022, 07:37:37 AM

Previous topic - Next topic

hutch--

 :biggrin:

Or a high efficiency variation.

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

switchtst proc num1:QWORD

    cmp num1, 0
    jne @F
    rcall MessageBox,0,str$(num1),"Zero",MB_OK
    ret
  @@:
    cmp num1, 1
    jne @F
    rcall MessageBox,0,str$(num1),"One",MB_OK
    ret
  @@:
    cmp num1, 2
    jne @F
    rcall MessageBox,0,str$(num1),"One",MB_OK
    ret
  @@:
    ret

switchtst endp

; «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»

C3

Hi,

The solution to the problem is what I tought. The 64-bit wParam uses only high word and low word (low 32bits) for the messages. So I changed that "C syntax" code wParam+4 to wParam+2. So it uses high word to do logic if its for Menu or for the Accelerator.
Code might not be elegant still, I have to check what I can optimize for reducing instructions or improve use of the registers.

  .case WM_COMMAND
    .if ((wParam+2)==0)
      .switch wParam
        .case ID_FILE_EXIT
          rcall SendMessage,hWnd,WM_CLOSE,0,0
        .case ID_HELP_ABOUT
          invoke DialogBoxParam,hInstance,IDD_DIALOG1,hWnd,ADDR HelpAboutDialog,NULL
      .endsw
    .elseif ((wParam+2)==1)
      mov dx,WORD PTR wParam
      .if dx==ID_FILE_EXIT
        rcall SendMessage,hWnd,WM_CLOSE,0,0
      .elseif  dx==ID_HELP_ABOUT
        rcall SendMessage,hWnd,WM_COMMAND,ID_HELP_ABOUT,0
      .endif
    .else
      nop
  .endif


Petter

jj2007

Petter, please read the doc carefully. There is wParam, and there is lParam.
wParam+4 Is lParam in 32-bit code. It Is meaningless in 64-bit code.
What you really want Is
Word ptr wParam
Word ptr wParam+2

C3

#18
I have moved from 32-bit MASM mainly to 64-bit MASM. As I have read manuals CPU is byte addressed, so if I can address wParam as I did previously, it works.

EDIT: JJ, you might have a point ;)


C3

Well this is last post today. Thats how I modified WM_COMMAND to use wParam to choose is the message for Menu, Accelerator or Control-item.

.case WM_COMMAND
    .if ((WORD PTR wParam+2)==0)
        .switch wParam
            .case ID_FILE_OPEN
                mov ofn.Flags,OFN_FILEMUSTEXIST or OFN_PATHMUSTEXIST or OFN_LONGNAMES or OFN_EXPLORER or OFN_HIDEREADONLY
                mov ofn.lpstrTitle,ptr$(FileExplorerTitleOpen)
                invoke GetOpenFileName,ADDR ofn
            .case ID_FILE_SAVE
                mov ofn.Flags,OFN_PATHMUSTEXIST or OFN_LONGNAMES or OFN_EXPLORER
                mov ofn.lpstrTitle,ptr$(FileExplorerTitleSave)
                invoke GetSaveFileName,ADDR ofn
            .case ID_FILE_EXIT
                rcall SendMessage,hWnd,WM_CLOSE,0,0
            .case ID_HELP_ABOUT
                invoke DialogBoxParam,hInstance,IDD_DIALOG1,hWnd,ADDR HelpAboutDialog,NULL
        .endsw
    .elseif ((WORD PTR wParam+2)==1)
            mov dx,word ptr wParam
            .if dx==ID_FILE_OPEN
                rcall SendMessage,hWnd,WM_COMMAND,ID_FILE_OPEN,0
            .elseif dx==ID_FILE_SAVE
                rcall SendMessage,hWnd,WM_COMMAND,ID_FILE_SAVE,0
            .elseif dx==ID_FILE_EXIT
                rcall SendMessage,hWnd,WM_CLOSE,0,0
            .elseif dx==ID_HELP_ABOUT
                rcall SendMessage,hWnd,WM_COMMAND,ID_HELP_ABOUT,0
            .endif
    .else
            .if ((WORD PTR wParam+2)==BN_CLICKED)
                mov rax,wParam
                .if (ax==WORD PTR IDC_CUSTOM_BUTTON)
                    invoke MessageBox,hWnd,"TEST","TEST",MB_OK
                .endif
            .endif
    .endif

NoCforMe

Quote from: zedd151 on October 22, 2022, 05:38:37 PM
Quote from: NoCforMe on October 22, 2022, 05:03:09 PM
I think they're talking about Win64 programming, not the OS.
Um 64 bit programs require a 64 bit OS to run.  :tongue:  No sense in writing for 64 bit unless you can also run and test it.  :biggrin:

I was simply pointing out that even if you use a 64-bit OS, you can still program in 32-bit, which is what I do (Win7/64 here). (And it won't cause any of the problems that the OP is experiencing, which have nothing at all to do with the OS and everything to do with misunderstanding 64-bit programming.) I've never used 64-bit MASM, probably never will; to me, it's total overkill for any of the applications I've seen here on this board, apart from a few performance-critical ones.

I'd be interested to know why folks here do use MASM 64. If the answer is "because it's cool" or "because I'm curious about it", that's a plenty good enough reason. But I doubt if many of us actually need to use it ...
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: NoCforMe on October 23, 2022, 07:32:50 AMI'd be interested to know why folks here do use MASM 64.

Because "it's the future" :cool:

If I were 20 years old, I would jump on the 64-bit train. But I'm 66 :biggrin:

Going from 16 to 32 bits was a huge step, with lots of advantages.
Going from 32 to 64 bits allows to address more than 3GB, and that's the one and only advantage. If I ever see a need to address more than 3GB, I might look into 64-bit programming.

NoCforMe

Quote from: jj2007 on October 23, 2022, 08:22:24 AM
Going from 32 to 64 bits allows to address more than 3GB, and that's the one and only advantage.

This bears repeating and remembering.
Assembly language programming should be fun. That's why I do it.

jj2007

But I admit I had some fun when I wrote the jinvoke macro :biggrin:

Quote from: jj2007 on September 12, 2022, 06:39:55 PM
Quote from: hutch-- on September 12, 2022, 11:50:59 AMthe traditional "invoke" notation in 32 bit MASM had arg count checking which helped a lot of people catch errors in their code. Traditionally, assemblers never needed such things (real men[tm] etc ....)

Real Men[tm] know how to write macros that are understood even by ML64:

mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance) ; one less
mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance, NULL)
mov hEdit, rv(CreateWindowEx, 0, Chr$("RichEdit20A"), NULL, reStyle, 0, 0, 1, 1, hWnd, ID_EDIT, wcx.hInstance, NULL, 123) ; one more


*** Assemble using ml64  ***
Assembling: tmp_file.asm
** 64-bit assembly **
## line 32: not enough arguments for CreateWindowExA ##
## line 34: too many arguments for CreateWindowExA ##


hutch--

Why migrate to 64 bit MASM ?

Twice as many registers, massive memory, 64 bit operations, later faster stack design etc etc etc ....

The arguments to stay with 32 bit are the same that was used to stay with 16 bit and before that the arguments to stay with MS-DOS.

32 bit works fine but its not going anywhere but the 16 bit worked fine and it has not gone anywhere for a very long time and as for MS-DOS, are you old enough to remember ?  :tongue:

C3

Go to the 64-bit, there are no reasons not to go. I know, I have started with Commodore 64, then Amiga and then IBM compatibles.

I know its nice to do stuff with DOS and maybe Windows 95. But 64-bit is today and its still tomorrow. It's no such a giant leap for mankind, but its best what you can do today.

jj2007

Going from 16 to 32 bits made your code a factor 5-10 faster :thumbsup:
Going from 32 to 64 bits makes your code bloated and a bit slower :sad:

hutch--

> Going from 32 to 64 bits makes your code bloated and a bit slower

Nah, just write it correctly.  :biggrin:

HSE

Quote from: jj2007 on October 24, 2022, 02:54:12 AM
Going from 32 to 64 bits makes your code bloated and a bit slower :sad:

:biggrin: Perhaps Wow64 optimize your 32 bit code!
Equations in Assembly: SmplMath