News:

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

Main Menu

Assembly error A2048

Started by pgw001, April 08, 2014, 09:13:21 PM

Previous topic - Next topic

pgw001

Peoples,

The procedure DoPageSU (see below) is called by previous WndProc processing.

When I try to assemble the program using the Visual Studio IDE I get A2048 errors (see following) on all
'mov' statements involving psd.rtMargin[]

I have tried changing the move to mov eax, psd.rtMargin[0] but I guess its
another case of me not grasping the fundamental problem - this is complicated
by the fact that the program appears to assemble without error using qeditor

Any pointers or suggested code changes would be much appreciated

Thanks


;=========================================================================
;* Page Setup Dialog Procedure                                           *
;=========================================================================
DoPageSU PROC
         mov     psd.lStructSize, sizeof psd
        push     hWnd
         pop     psd.hwndOwner
        push     hInst
         pop     psd.hInstance
         mov     psd.Flags, PSD_MARGINS or PSD_INTHOUSANDTHSOFINCHES or PSD_DISABLEPAPER or PSD_DISABLEPRINTER
      INVOKE     PageSetupDlg, offset psd
         cmp     eax,0
          jz     NSU
       finit
         mov     al, psd.rtMargin[0]                               <<<<<<<<<<<<<<<<<<Error   1   error A2048: Operands must be the same size: 1 - 16

         mov     ah, psd.rtMargin[1]                             ******************Error   1   error A2048: Operands must be the same size: 1 - 16
         and     eax, 0000ffffh
         mov     w1, eax
         fld     RTwips1000
        fild     w1
        fmul     ST(0), ST(1)
       fistp     mL
         mov     al, psd.rtMargin[4]
         mov     ah, psd.rtMargin[5]
         and     eax, 0000ffffh
         mov     w1, eax
         fld     RTwips1000
        fild     w1
        fmul     ST(0), ST(1)
       fistp     mT
         mov     al, psd.rtMargin[8]
         mov     ah, psd.rtMargin[9]
         and     eax, 0000ffffh
         mov     w1, eax
         fld     RTwips1000
        fild     w1
        fmul     ST(0), ST(1)
       fistp     mR
         mov     al, psd.rtMargin[12]
         mov     ah, psd.rtMargin[13]
         and     eax, 0000ffffh
         mov     w1, eax
         fld     RTwips1000
        fild     w1
        fmul     ST(0), ST(1)
       fistp     mB
         sub     mL, 360
         sub     mT, 360
         sub     mR, 360
         sub     mB, 302
NSU:
         ret
DoPageSU ENDP

jj2007

In VS, you are using ML version 10.0 or even 11.0, in qEditor it's ML 6.14

Unfortunately, the later versions are a bit stupid, and don't realise that al and ah cannot load other sizes than 8 bit.

There is a simple workaround, though: be explicit...

mov al, byte ptr psd.rtMargin[4]

pgw001

jj2007 - many thanks, the explicit remedy worked fine - not sure how
long it would have taken me to deduce that..

As for the ML versions - price of progress doesn't ring too true..

Best,

qWord

Quote from: jj2007 on April 08, 2014, 10:23:25 PMUnfortunately, the later versions are a bit stupid, and don't realise that al and ah cannot load other sizes than 8 bit.
yea, warning about a type conflict is really stupid...
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Quote from: qWord on April 09, 2014, 02:10:47 AM
Quote from: jj2007 on April 08, 2014, 10:23:25 PMUnfortunately, the later versions are a bit stupid, and don't realise that al and ah cannot load other sizes than 8 bit.
yea, warning about a type conflict is really stupid...

Warning would be intelligent, but throwing an error is stupid.

qWord

Quote from: jj2007 on April 09, 2014, 02:47:28 AMWarning would be intelligent, but throwing an error is stupid.
An error can't be ignored and a type conflict is a potential bug.
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Quote from: qWord on April 09, 2014, 02:57:03 AMAn error can't be ignored and a type conflict is a potential bug.

Amen 8)

OP: There is a much shorter way to achieve this:

mov al, psd.rtMargin[4]   ; 5 bytes
mov ah, psd.rtMargin[5]   ; 6
and eax, 0000ffffh   ; 5
nop
movzx eax, word ptr psd.rtMargin[4]   ; 7


16 bytes vs 7 ;-)

qWord

Quote from: jj2007 on April 09, 2014, 03:20:03 AMAmen 8)
So I'm not allowed to post my opinion, but you are allowed to frivolously use the word "stupid"?
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Quote from: qWord on April 09, 2014, 03:41:18 AM
Quote from: jj2007 on April 09, 2014, 03:20:03 AMAmen 8)
So I'm not allowed to post my opinion, but you are allowed to frivolously use the word "stupid"?

You are certainly free to post your opinion, qWord. In fact, I always read your posts carefully, because you are a very knowledgeable person from whom I have learnt a lot.

qWord

Sorry jj, I'm sometimes startled about myself  :t
MREAL macros - when you need floating point arithmetic while assembling!

Will

My MASM (version 6) Programmer's Guide says this about error A2048:

nondigit in number

A number contained a character that was not in the set of characters used by the current radix (base).

The error can occur if a B or D radix specifier is used when the default radix is one that includes that letter as a valid digit.

______________________________________________________________________________________

I think MicroSoft made a mistake and it should say "doesn't include that letter" instead of includes that letter.

radix is defined as, "The base of a number system. The default radix for MASM and CodeView is 10."

Probably the compiler is expecting a BASE 10 (decimal) number when you are using BASE 16 (Hexadecimal).

Hope this helps you!

Will