The MASM Forum

fInt macro
  sub xsp, @WordSize                                    ;;Reserve stack place for one word
  fstcw WORD ptr [xsp]                                  ;;Store FPU control word
>>>> push QWORD ptr [xsp]                                  ;;Duplicate value
  BitSet WORD ptr [xsp], (BIT10 or BIT11)               ;;Modify the control word, int(x) = Truncate (toward 0)
  fldcw WORD ptr [xsp]                                  ;;Restore modified FPU control word
  frndint                                               ;;Round down
  fldcw WORD ptr[xsp + @WordSize]                       ;;Restore previous FPU control word
  add rsp, 2*@WordSize              <<<<<<<<                    ;;Restore stack. Don't use pop eax. We wan't destroy it
endm



Hi
Sorry for the typo. It was midnight when I wrote it  :P
Should be

  add xsp, 2*@WordSize        ;;Restore stack. Don't use pop xax. We'll not destroy it.

also correct the same way the fRndDn macro.

Biterider

It's presumed that because main development is oriented to 64bit, this little things will appear when testing in 32bit.  :t

The title reflect the fact that this things don't even allow any discussion.  :biggrin:

Demo02 don't have Shared.inc

Thanks!

Demo01b crash because ReadFile don't have storage for number of bytes readed.

Hi HSE
You are completely right. Fixed now.
Thank you  :icon14:


Biterider

Hi Biterider!

See again first post. Macros in fMath.inc are pushing QWORDs. I don't know if you maked a dual equate WORD/QWORD for 32/64 BITNESS

Hi HSE
Yes, you are right. Please try the posted file. I think I've made all necessary corrections.

Biterider

I maked a little mess with my test :biggrin:, but your file looks good  :t

Thanks.

Hi Biterider:

Nothing was working until I noted change in "m2m" macro  :biggrin: :biggrin:

I solved using old macro if BITNESS = 32. I thing that without register specification m2m have to make push and pop in 32, and use some 64 register not used in 32 (r10...r13) .

Only problem I see using AsmC are 2 or 3 ".elseif macro something" that I changed to ".elseif OA_something" (I will see again if I find where that was!)

Regards.

Quote from: HSE on February 13, 2019, 09:40:18 PMOnly problem I see using AsmC are 2 or 3 ".elseif macro something" that I changed to ".elseif OA_something"

Remember the old late expansion problem when using .elseif somemac(arg)==123

Hi HSE
It wasn't an easy decision to extend/change the way m2m works.
But it there is making some troubles, there is an easy way to overcome the issue. Other people are using a mrm macro, that explicitly uses a register to transfer the value. Since the goal was to write code that can be compiled for x86 and x64, I can do a "mass mutation" of the source code changing m2m to mrm, leaving m2m free to work like before.
Is this acceptable for you?

Like JJ said, the ".elseif macro something" is something to avoid. If you can find the code, please let me know.  :t

Biterider

Quote from: jj2007 on February 13, 2019, 10:16:23 PM
Remember the old late expansion problem when using .elseif somemac(arg)==123

Thanks JJ. It's that.

Forcing expansion solve the AsmC problem (in XMenu.inc):    % .elseif [xbx].$Obj(XMenuItem).dType == MENU_TYPE_SIDEBAR

Quote from: Biterider on February 13, 2019, 10:50:01 PM
Since the goal was to write code that can be compiled for x86 and x64

The better practice in 32 bit is to use push and pop because there is few registers (if you don't need to load a value in a register). In 64 bit you have to use a register.  The dual code have to use both, just taking care that in 64 bit registers in use are not trashed (rax,rbx,rcx,etc). 
R8 and r9 are used to pass arguments. R14 and r15 are prefered for some procedures (see Hutch code) and registers with same name have especific use in ARM. That left r10...r13 for choice...
Not very elegant, but I put in system.inc the old m2m for 32 bitness and the new for 64 but using r10 instead of rax.

Quote from: HSE on February 14, 2019, 12:22:05 AMThanks JJ. It's that.

Forcing expansion solve the AsmC problem (in XMenu.inc):

Code Select Expand

    % .elseif [xbx].$Obj(XMenuItem).dType == MENU_TYPE_SIDEBAR

Are you sure?

include \masm32\include\masm32rt.inc
.code
start:
  mov eax, 1
  .if eax==12345678h
print "never"
  % .elseif len("test")>3
print "Len gt 3"
  .else
print "you are screwed, my friend"
  .endif
  exit
end start

P.S.: Replace the mov eax, 1 with mov eax, 4 to enjoy some pleasant nights of bug chasing for Real Men^TM 8)

Quote from: jj2007 on February 14, 2019, 01:06:12 AM
Are you sure?

Yes, what is expanded is a variable name, not a function. :t

I would suggest that you test the snippet I posted above ;)

Yes JJ, I saw your snippet before to post.

Included in Demo03:
% .elseif [xbx].$Obj(XMenuItem).dType == MENU_TYPE_SEPARATOR

is expanded (in this case) to:
.elseif [ebx].OA_XMenuItem.dType == MENU_TYPE_SEPARATOR

and resulting code is:
CPU Disasm
Address   Hex dump          Command
004033CE  |> \837B 18 05    |CMP DWORD PTR DS:[EBX+18],5
004033D2  |. /0F85 82000000 |JNE 0040345A  ; almost forget this


I see. So inOnly problem I see using AsmC are 2 or 3 ".elseif macro something" that I changed to ".elseif OA_something" the OA_something is not a macro but just an equate. That is indeed different from macro expansion :t

 :biggrin:   If say macro, it's a macro:: ————————————————————————————————————————————————
; Macro:      $Obj
; Purpose:    Return the mangled object name.
; Arguments:  Arg1: Object Expression: [Namespace:]ObjectName.

$Obj macro ObjExpr:req
  PreParseExpr ObjExpr
  if $ParseObjExpr(ObjExpr) eq FALSE
    .err <$Obj - syntax error: ObjExpr>
    exitm <>
  else
    %exitm <??ObjExpr>
  endif
endm

and if say textequ or equ .. mmmh