flat assembler
Message board for the users of flat assembler.

Index > Heap > Did you know this trick?

Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
A couple of minutes ago I discovered by accident a way to be sure that you are not executing a macro instruction.

Suppose you have this
Code:
macro ret arg
{
if ~arg eq
  ret word arg
else
  ret word 0
end if
}

ret    


That "ret" will obviously generate the longest encoding. The obvious way to avoid this could be defining another ret macro that does "db $C3" or purging several times "ret" to try to ensure you don't call a macro but risking the functionality of another piece of code. Of course another way is just capitalizing a letter but the author of the macro could been defined all the combinations...

The solution is this using "times 1 instruction". Doing a simple "times 1 ret" you ensure that the instruction "ret" will get assembled instead of a possible macro defined in some big package.

Well, that was the silly thing I wanted to say Razz
Post 31 May 2007, 20:31
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
nice, never realized that. I hope "times 1: ret" works same way too.

By the way, this may even be problem of FASM, not feature. If you rely on instruction being overloaded by macro, and someone uses it this way Wink
Post 31 May 2007, 20:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
haha, I never used ":" on "times" but yes, the feature works with it aswell.

Well maybe it is a desing problem of preprocessor since it only expands macroses if it is the first word on the line. However preprocessor is able to detect struc as second word but this is not enough to handle "times" properly since the preprocessor has to be able to separete the expression part from the instruction part (and be able to handle nesting as well).

The docs doesn't tell anything about this so I don't know if it is intended behavior or preprocessor's bug/unawareness.
Post 31 May 2007, 21:08
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i believe tomasz thought about this.

Problem is: how to expand macro in case of times? times can take single-line argument, and macro can produce more lines.

in theory, it could be possible to replace times by repeat, but that is somehow out of scope of preprocessor (it would have to parse expression for example).
Post 31 May 2007, 22:19
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
times and repeat are both assembler directives. To repeat a macro multiple times you could use rept, which is a preprocessor directive.
Post 31 May 2007, 22:33
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
yeah, i know. But think about it, if you were preprocessor, how would you expand this:

Code:
macro x {
db 1
db 2
}

times 5 x    
Post 31 May 2007, 23:10
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
vid wrote:
times can take single-line argument, and macro can produce more lines.

Yes, I forgot to think about it so now I'm sure that it's intended behavior.

@Goplat: Note that with "repeat" the macro gets expanded, only once though. "rept" should be used only if the macro relies on one expansion per use, otherwise "repeat" should be fine (and macroinstructions that emulates CPU instructions should not rely on "rept" IMHO).
Post 31 May 2007, 23:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.