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.
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
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
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.
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?
50, 16, and 20 appear to have magical properties not explained by the source code.
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.
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?
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.
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.)
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.
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.
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.
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.
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.
Quote from: usingMasm on September 09, 2010, 08:33:07 AM
I get it. You are right. I think he should be more concerned with variables. Constants could get boring at times.
First it was "stop kidding" and then it was "constants could get boring" ...
Whats next? "the names are longer than the values" ?
You have spent more time defending the use of magic numbers than it would have taken to not use them. You posted the macro up for review and while I immediately had a good idea of what you were trying to do, I could not be sure about the veracity or accuracy of the code itself because I did not know from memory (nor does anyones else) what those magic numbers actually were.
In short, I wouldn't review your macro beyond the magic number issue BECAUSE I WASN'T BORED ENOUGH TO LOOK UP THOSE CLEARLY NOT-INTERESTING MAGIC NUMBERS.
If the magic numbers had been something interesting, like say the fixed point representation of 1/10th, then I might not have cared. But they werent interesting at all, and still arent. They are just there making it hard to read for no good reason.
Quote from: Tedd on September 09, 2010, 09:58:25 AM
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.
I am getting unmatched block nesting error when arg1 is like [edi] with the following code:
muv macro arg1:req,arg2:=<eax>
i equ <arg1>
ife (OPATTR (arg1)) and 32
i substr <arg1>,1,1
ifidn i,<->
i substr <arg1>,2
.data?
i dword ?
.code
endif
endif
Quote from: Rockoon on September 09, 2010, 10:35:03 AM
Quote from: usingMasm on September 09, 2010, 08:33:07 AM
I get it. You are right. I think he should be more concerned with variables. Constants could get boring at times.
First it was "stop kidding" and then it was "constants could get boring" ...
Whats next? "the names are longer than the values" ?
You have spent more time defending the use of magic numbers than it would have taken to not use them. You posted the macro up for review and while I immediately had a good idea of what you were trying to do, I could not be sure about the veracity or accuracy of the code itself because I did not know from memory (nor does anyones else) what those magic numbers actually were.
In short, I wouldn't review your macro beyond the magic number issue BECAUSE I WASN'T BORED ENOUGH TO LOOK UP THOSE CLEARLY NOT-INTERESTING MAGIC NUMBERS.
If the magic numbers had been something interesting, like say the fixed point representation of 1/10th, then I might not have cared. But they werent interesting at all, and still arent. They are just there making it hard to read for no good reason.
I love you
Quote from: usingMasm on September 09, 2010, 12:22:59 PM
Quote from: Tedd on September 09, 2010, 09:58:25 AM
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.
I am getting unmatched block nesting error when arg1 is like [edi] with the following code:
muv macro arg1:req,arg2:=<eax>
i equ <arg1>
ife (OPATTR (arg1)) and 32
i substr <arg1>,1,1
ifidn i,<->
i substr <arg1>,2
.data?
i dword ?
.code
endif
endif
Solved- "LOCAL i" had to be declared
:U
Here is the finished code. You can use it free of charge at my expense. All rights reserved. :lol
muv macro arg1:req,arg2:=<eax>
LOCAL i
i equ <arg1>
ife (OPATTR (arg1)) and 32
i substr <arg1>,1,1
ifidn i,<->
i substr <arg1>,2
.data?
i dword ?
.code
else
.err <Unknown argument: arg1>
endif
endif
if ((OPATTR(i)) and 16) or ((OPATTR(arg2)) and 20)
mov i,arg2
else
push arg2
pop i
endif
endm
Thanks to everyone for comments. Particularly Rockoon. :naughty:
You should indeed thank Rockoon, he is perfectly right. Try using this set, for use with e.g.
oa = (opattr(arg)) AND 127; Bit Set If...
; 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, i.e. is an absolute memory reference
; 4 Is a register expression
; 5 References no undefined symbols and is without error
; 6 References a stack location (usually a LOCAL variable or parameter)
; 7 References an external label
; 8-10 Language type (0=no type)
; 76543210
atMemory = 34 ; 00100010
atImmediate = 36 ; 00100100
atLabel = 37 ; 10100101
atGlobal = 42 ; 10101010
atRegister = 48 ; 00110000
atLocal = 98 ; 01100010
Using one-letter expressions as in i equ <arg1> is not a good idea, either.
Note that there is a small difference between Masm and JWasm:
mov eax, (opattr([eax+4*eax+20])) and 127
print str$(eax), 13, 10
Result is 34 for JWasm but 42 for Masm (6.15, 9.0 tested).
Quote from: jj2007 on September 14, 2010, 08:30:26 AM
You should indeed thank Rockoon, he is perfectly right. Try using this set, for use with e.g. oa = (opattr(arg)) AND 127
; Bit Set If...
; 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, i.e. is an absolute memory reference
; 4 Is a register expression
; 5 References no undefined symbols and is without error
; 6 References a stack location (usually a LOCAL variable or parameter)
; 7 References an external label
; 8-10 Language type (0=no type)
; 76543210
atMemory = 34 ; 00100010
atImmediate = 36 ; 00100100
atLabel = 37 ; 10100101
atGlobal = 42 ; 10101010
atRegister = 48 ; 00110000
atLocal = 98 ; 01100010
Using one-letter expressions as in i equ <arg1> is not a good idea, either.
Note that there is a small difference between Masm and JWasm:
mov eax, (opattr([eax+4*eax+20])) and 127
print str$(eax), 13, 10
Result is 34 for JWasm but 42 for Masm (6.15, 9.0 tested).
If you guys are able to get over this constant stuff, I wouldn't mind working a bit more on this macro and adding some more features to it so as to put the x86 architecture to shame. If you ask for explanation of something obvious then you are a geek. I am not. I just do it for fun. I explained thoroughly three times the meaning of every MAGICAL number used, but he refused completely to move a single step towards the actual purpose of the thread. Telling me to rename the macro to mymacro1 and at the same time noting it is named descriptively. I can write a book on how geeky that was. anyone ..........naf said.
By the way I haver slightly modified the macro. No, Not renamed it to mymacro1
muv macro arg1:req,arg2:=<eax>
LOCAL macroarg1
macroarg1 equ <arg1>
ife (OPATTR (arg1)) and 32
ifidn @SubStr (arg1,1,1),<->
macroarg1 substr <arg1>,2
.data?
align 4
macroarg1 dword ?
.code
else
.err <"&arg1&" is either a typo or you forgot the leading dash.>
exitm
endif
endif
if ((OPATTR(macroarg1)) and 16) or ((OPATTR(arg2)) and 20)
mov macroarg1,arg2
else
push arg2
pop macroarg1
endif
endm
Quote from: usingMasm on September 14, 2010, 11:33:50 AM
If you guys are able to get over this constant stuff, I wouldn't mind working a bit more on this macro and adding some more features to it so as to put the x86 architecture to shame.
...or you could simply make your code more readable and thus maintainable, debuggable, and extendable.. by using named constants.
Even with a reference right next to me, I need to look at the reference, instead of the code... which means that I cannot fluently grok the code.. which means that its a CHORE to do any reasoning about it.
You are insisting that your code be difficult to read, and are then expecting others to WORK HARD in order to review it. Well I say bullshit. I dont come here to work hard, especially not needlessly on the whim of a programmer too stubborn to do the obviously simple, even trivial, effort to make it far less like work for me and others.
Quote from: usingMasm on September 14, 2010, 11:33:50 AM
If you ask for explanation of something obvious then you are a geek. I am not.
Nobody asked for an explanation. I really dont understand why you dont get it. It isnt that the numbers are hard to look up, its that we shouldn't have to under these circumstances. There are cases where magic numbers are appropriate but this case doesn't even come close. In this case, your stubbornness on the issue is like saying "screw you guys.. I'm making hard, on purpose, and tough shit for you.. and BTW I'm going to call you names now too... you people are geeks"
Quote from: Rockoon on September 14, 2010, 11:55:14 AM
Quote from: usingMasm on September 14, 2010, 11:33:50 AM
If you guys are able to get over this constant stuff, I wouldn't mind working a bit more on this macro and adding some more features to it so as to put the x86 architecture to shame.
...or you could simply make your code more readable and thus maintainable, debuggable, and extendable.. by using named constants.
Even with a reference right next to me, I need to look at the reference, instead of the code... which means that I cannot fluently grok the code.. which means that its a CHORE to do any reasoning about it.
You are insisting that your code be difficult to read, and are then expecting others to WORK HARD in order to review it. Well I say bullshit. I dont come here to work hard, especially not needlessly on the whim of a programmer too stubborn to do the obviously simple, even trivial, effort to make it far less like work for me and others.
Quote from: usingMasm on September 14, 2010, 11:33:50 AM
If you ask for explanation of something obvious then you are a geek. I am not.
Nobody asked for an explanation. I really dont understand why you dont get it. It isnt that the numbers are hard to look up, its that we shouldn't have to under these circumstances. There are cases where magic numbers are appropriate but this case doesn't even come close. In this case, your stubbornness on the issue is like saying "screw you guys.. I'm making hard, on purpose, and tough shit for you.. and BTW I'm going to call you names now too... you people are geeks"
:bg :bg :bg :bg
did I mention how much I love you?
OK. once this thing is over and you come up with some good suggestions, so that any doubts on your mastery are removed, I will take your advice.
Quote from: usingMasm on September 14, 2010, 12:45:10 PM
OK. once this thing is over and you come up with some good suggestions, so that any doubts on your mastery are removed, I will take your advice.
I gave the most masterful suggestion so far, and you have refused to take that advice.
I fear that you are too inexperienced to realize that us "geeks" as you call us, actually know exactly what we are talking about. You want to continue to clumsily mess around with hard to maintain code when it would take you only a few minutes to make it easy to maintain code that isnt clumsy to work with, with NO SACRIFICES WHAT-SO-EVER unless you consider "clear and concise code" to be a sacrifice over that hack-job you have now.
Quote from: Rockoon on September 14, 2010, 01:00:25 PM
Quote from: usingMasm on September 14, 2010, 12:45:10 PM
OK. once this thing is over and you come up with some good suggestions, so that any doubts on your mastery are removed, I will take your advice.
I gave the most masterful suggestion so far, and you have refused to take that advice.
I fear that you are too inexperienced to realize that us "geeks" as you call us, actually know exactly what we are talking about. You want to continue to clumsily mess around with hard to maintain code when it would take you only a few minutes to make it easy to maintain code that isnt clumsy to work with, with NO SACRIFICES WHAT-SO-EVER unless you consider "clear and concise code" to be a sacrifice over that hack-job you have now.
You first.
Hi,
I am finally quite happy with the macro. Freedom of movement. use it and forget all the restrictions of the mov instruction.
Advantages:
1 - Automatic detection and handling of memory to memory mov instructions
2 - Inline variable generation
syntax muv .var,anything Generates a variable called var and moves anything into it.
3 - Inline byte array generation
syntax muv .var,"this is a silly text" generates a byte array and moves it's offset into the newly generated variable. You may need to reference the string later. No problem. just add a name for your string at the end. muv .var,"this is a silly text"silly . now you can reference the text with the name silly.
This macro uses two sub macros which should also be included.
for bugs xor suggestions post here.
enjoy!
muv macro arg1:req,arg2:=<eax>
ifdif @SubStr (arg2,1,1),<">
ifidn @SubStr (arg1,1,1),<.>
if ((OPATTR(arg2)) and 20)
mov setdword (@SubStr (arg1,2)),arg2
else
push arg2
pop setdword (@SubStr (arg1,2))
endif
elseif ((OPATTR(arg1)) and 16) or ((OPATTR(arg2)) and 20)
mov arg1,arg2
else
push arg2
pop arg1
endif
else
ifidn @SubStr (arg1,1,1),<.>
mov setdword (@SubStr (arg1,2)),(setstr (arg2))
else
mov arg1,(setstr (arg2))
endif
endif
endm
setstr macro arg
LOCAL closing_quot,var_name,quoted_text
quoted_text equ <arg>
closing_quot instr 2,<arg>,<">
ifdif %(@SizeStr (arg)),%closing_quot
var_name substr <arg>,closing_quot+1
quoted_text substr <arg>,1,closing_quot
endif
.data
align 4
var_name byte quoted_text,0
.code
exitm <offset var_name>
endm
setdword macro arg
.data?
align 4
arg dword ?
.code
exitm <arg>
endm