flat assembler
Message board for the users of flat assembler.

Index > Main > How many instructions endorse the definition of a function

Author
Thread Post new topic Reply to topic
pete



Joined: 20 Apr 2009
Posts: 110
pete 16 Apr 2010, 07:53
Hello ladies'n'gentlemen'n'borgs!

During the last days i kept asking myself how many instructions endorse the definition of a function or the usage of a macro instead. Does anyone of you has a rule-of-thumb? Please let me know!

Thanks in advance.
Post 16 Apr 2010, 07:53
View user's profile Send private message Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433 16 Apr 2010, 09:18
number of instructions isnt property of function/macro.
so it can be infinite, and 0.
Post 16 Apr 2010, 09:18
View user's profile Send private message Reply with quote
pete



Joined: 20 Apr 2009
Posts: 110
pete 16 Apr 2010, 09:35
Probably my question was unclear. If, for instance i have a set of instructions that get repeatedly executed through the runtime of a program, i want to optimize the program to store the same set of instructions as seldom as possible. This forces me to use functions or procedures. But of course i want the program to run as fast as possible. So when i call a procedure inside my program very often, but this procedure consists of only four instructions, i am thinking of converting this procedure into a macro instead, because the jumping around in the memory that comes with procedures probably isn't worth the four instructions.
So what i am interested in is, how many instructions should a procedure at least consist of, so that the memory jumps (through call and return) are endorsed?
Post 16 Apr 2010, 09:35
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 16 Apr 2010, 10:43
4 instructions? ok, lets go for a function, then, you will have many more flexibility during software evolution.

i have a fucntion with 4 instructions, including ret.

Code:
asm:
.call=0
.func=4
.op1=8
.op2=12
.op3=16
.op4=20
.op5=24
.op6=28
.op7=32
.op8=36
        cmp dword[esi+.func],0
        je @f
        call near[esi+.func]
@@:
        ret           
    
Post 16 Apr 2010, 10:43
View user's profile Send private message Visit poster's website Reply with quote
pete



Joined: 20 Apr 2009
Posts: 110
pete 16 Apr 2010, 11:22
Thanks for the example edfed, but why do i gain flexibility during software evolution with a function?
Post 16 Apr 2010, 11:22
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4353
Location: Now
edfed 16 Apr 2010, 11:51
simple to explain.

a function, for example, put a picture.

instead of puting pixel inside the picture function, you use putpixel subfunction, then, you just give X,Y and color to putpixel.
then, if you change screen mode (320*200*8bpp to 1280*1024*32bpp), only putpixel function will change.
if you want to draw line, you will use the same putpixcel function, draw a rectangle, draw a circle, draw a triangle, put text, etc... and all will use only one putpixel fucntion, then, mode switch will be easy.


and if one day you use hardware acceleration, some complex putpixel queue will be good, or something like that.



there are many other examples where a function is good.

a function that have only 4 instruction can easy become fat, adding security tests, particular case, etc..
Post 16 Apr 2010, 11:51
View user's profile Send private message Visit poster's website Reply with quote
pete



Joined: 20 Apr 2009
Posts: 110
pete 16 Apr 2010, 12:05
Well, thanks!
Post 16 Apr 2010, 12:05
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 cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.