News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

mov or muv

Started by usingMasm, September 07, 2010, 10:05:54 AM

Previous topic - Next topic

usingMasm


Hi,
I am looking to optimize the following macro. Basically it is a mov instruction with some additional goodies.

   muv macro arg1:req,arg2:=<eax> ;assume eax if arg2 is blank
   ifndef arg1                                  ;inline declaring of variable if not already declared
   ife (OPATTR(arg1)) and 2         ;don't declare things like [edi+esi]
   .data?
   arg1 dword ?
   .code
   endif
   endif
   if ((OPATTR(arg1)) and 16) or ((OPATTR(arg2)) and 20) ;if arg1 is a register or arg2 is a register or constant
   mov arg1,arg2                                                             ;simply mov
   else
   push arg2                                                                    ;otherwise it is memory to memory and push pop
   pop arg1
   endif   
   endm

now muv hWnd will generate a variable called hWnd and mov eax into it.

if you like it, post comments.



frktons

Quote from: usingMasm on September 07, 2010, 10:05:54 AM
Hi,
I am looking to optimize the following macro. Basically it is a mov instruction with some additional goodies.

   muv macro arg1:req,arg2:=<eax> ;assume eax if arg2 is blank
   ifndef arg1                                  ;inline declaring of variable if not already declared
   ife (OPATTR(arg1)) and 2         ;don't declare things like [edi+esi]
   .data?
   arg1 dword ?
   .code
   endif
   endif
   if ((OPATTR(arg1)) and 16) or ((OPATTR(arg2)) and 20) ;if arg1 is a register or arg2 is a register or constant
   mov arg1,arg2                                                             ;simply mov
   else
   push arg2                                                                    ;otherwise it is memory to memory and push pop
   pop arg1
   endif   
   endm

now muv hWnd will generate a variable called hWnd and mov eax into it.

if you like it, post comments.

Hi usingMasm.

I'm going to like MACRO as soon as I understand them  :P

I'll give it a look next week, back to my pc, and I'll tell you
how useful it could be.  :U

Frank
Mind is like a parachute. You know what to do in order to use it :-)

usingMasm

So, I took out one if block and it still seems to be working

   muv macro arg1:req,arg2:=<eax>
     ife ((OPATTR(arg1)) and 50)
   .data?
   arg1 dword ?
   .code
   endif
   if ((OPATTR(arg1)) and 16) or ((OPATTR(arg2)) and 20)
   mov arg1,arg2
   else
   push arg2
   pop arg1
   endif   
   endm

  I'll do some more testing though

Rockoon

I suggest you nix the magic numbers, replacing them with named constants.. when the code is more readable, it will be easier to reason about it.
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

usingMasm

Quote from: Rockoon on September 07, 2010, 03:49:53 PM
I suggest you nix the magic numbers, replacing them with named constants.. when the code is more readable, it will be easier to reason about it.

How do you mean it?

Rockoon

50, 16, and 20 appear to have magical properties not explained by the source code.
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

usingMasm

Quote from: Rockoon on September 07, 2010, 06:18:32 PM
50, 16, and 20 appear to have magical properties not explained by the source code.

The OPATTR operator returns a one-word constant defining the mode and scope of expression. If <expression> is not valid or is forward- referenced, OPATTR returns a 0. If <expression> is valid, a nonrelocatable word is returned. The .TYPE operator returns only the low byte (bits 0-7) of the OPATTR operator and is included for compatibility with previous versions of the assembler.

Bit Set If
Position <expression>


0 References a code label
1 Is a memory expression or has a relocatable data
label
2 Is an immediate expression
3 Uses direct memory addressing
4 Is a register expression
5 References no undefined symbols and is without error
6 Is an SS-relative memory expression
7 References an external label
8-10 Language type:


therefore:
16 is bit 4 which is a register
20 is 16 or ed with 4 which os a constant

50 is bit 5 or ed with bit 1 and 4

hope that explains it.


Rockoon

Quote from: usingMasm on September 07, 2010, 07:15:09 PM
The OPATTR operator returns a one-word constant ....

I know this. That doesnt fix the problem that the source code is using magic numbers.

Do you understand that the magic number 50 requires me to LOOK UP what the magic number 50 relates to in order to figure out what your macro is doing?

While you are at it... name your macro MYMACRO1, and your next macro MYMACRO2, etc, and so on....

Why did you choose to name your macro descriptively but did not choose to name your constants descriptively?
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

usingMasm

Quote from: Rockoon on September 08, 2010, 12:19:39 AM
Quote from: usingMasm on September 07, 2010, 07:15:09 PM
The OPATTR operator returns a one-word constant ....

I know this. That doesnt fix the problem that the source code is using magic numbers.

Do you understand that the magic number 50 requires me to LOOK UP what the magic number 50 relates to in order to figure out what your macro is doing?

While you are at it... name your macro MYMACRO1, and your next macro MYMACRO2, etc, and so on....

Why did you choose to name your macro descriptively but did not choose to name your constants descriptively?


Stop kidding  :dazzled:
if you got some ideas let's have them.

Tedd

I'd recommend against having such a macro.
While creating variables on-the-fly may seem convenient, one simple typo can lead to very difficult to spot problems - since you think you're accessing one variable, but you've actually just created one and are accessing that. The assembler will show no error for this, whereas it would for an undefined variable.

(Yes, scripting languages generally allow this and the same applies, though in a more limited way because they can check that access pattern; this macro can not.)
No snowflake in an avalanche feels responsible.

usingMasm

Quote from: Tedd on September 08, 2010, 02:30:02 PM
I'd recommend against having such a macro.
While creating variables on-the-fly may seem convenient, one simple typo can lead to very difficult to spot problems - since you think you're accessing one variable, but you've actually just created one and are accessing that. The assembler will show no error for this, whereas it would for an undefined variable.

(Yes, scripting languages generally allow this and the same applies, though in a more limited way because they can check that access pattern; this macro can not.)


Well observed.

I thought of that too. could cause hard to detect bugs.

usingMasm


   muv macro arg1 :req,arg2:=<eax>
   i equ <arg1>
   ife ((OPATTR (i)) and 32)
   i  substr <arg1>,1,1
   ifidn i,<->
   i substr <arg1>,2
   .data?
   i dword ?
   .code
   endif
   endif
   if ((OPATTR(i)) and 16) or ((OPATTR(arg2)) and 20)
   mov i,arg2
   else
   push arg2
   pop i
   endif   
   endm

       I tried to somehow make it foolproof. so that the generated variable MUST be preceded by "-", whereas accessing it is done without it.
       
       muv -hWnd will now generate a variable called hWnd. now when accessing the variable you mistype hwnd you get an error because code does not     generate variables without - at the beginning.

Critical ideas are welcome.

Neo

Quote from: usingMasm on September 08, 2010, 09:17:36 AM
Quote from: Rockoon on September 08, 2010, 12:19:39 AM
Quote from: usingMasm on September 07, 2010, 07:15:09 PM
The OPATTR operator returns a one-word constant ....

I know this. That doesnt fix the problem that the source code is using magic numbers.

Do you understand that the magic number 50 requires me to LOOK UP what the magic number 50 relates to in order to figure out what your macro is doing?

While you are at it... name your macro MYMACRO1, and your next macro MYMACRO2, etc, and so on....

Why did you choose to name your macro descriptively but did not choose to name your constants descriptively?


Stop kidding  :dazzled:
if you got some ideas let's have them.
He wasn't kidding about naming your constants; that's a rather important idea.  You shouldn't have non-arbitrary numbers whose meaning is not clear from the code.  I don't know what the constants 32, 16, and 20 mean in your code, and I shouldn't have to look them up to know what they mean.  I know this may be a fairly minor piece of code, and I don't always hold myself to the same standard, but you did post it for commentary.

usingMasm

Quote from: Neo on September 09, 2010, 06:46:04 AM
Quote from: usingMasm on September 08, 2010, 09:17:36 AM
Quote from: Rockoon on September 08, 2010, 12:19:39 AM
Quote from: usingMasm on September 07, 2010, 07:15:09 PM
The OPATTR operator returns a one-word constant ....

I know this. That doesnt fix the problem that the source code is using magic numbers.

Do you understand that the magic number 50 requires me to LOOK UP what the magic number 50 relates to in order to figure out what your macro is doing?

While you are at it... name your macro MYMACRO1, and your next macro MYMACRO2, etc, and so on....

Why did you choose to name your macro descriptively but did not choose to name your constants descriptively?


Stop kidding  :dazzled:
if you got some ideas let's have them.
He wasn't kidding about naming your constants; that's a rather important idea.  You shouldn't have non-arbitrary numbers whose meaning is not clear from the code.  I don't know what the constants 32, 16, and 20 mean in your code, and I shouldn't have to look them up to know what they mean.  I know this may be a fairly minor piece of code, and I don't always hold myself to the same standard, but you did post it for commentary.

I get it. You are right. I think he should be more concerned with variables. Constants could get boring at times.

Tedd

I'd go with '_' in preference to '-' as it doesn't already have a meaning.

Also, be careful you're not trying to patch it up to the point where it becomes just as much 'trouble' to use as simply defining your own variables anyway.
No snowflake in an avalanche feels responsible.