Inline functions

[mitchi]

I use a lot of work functions in my code to improve readability.

This is a code snippet from my recent ASM CGI program

Code Select Expand

start:
Call INIT_CGI

Call PARSE_GET

Call DISPLAY_TOPIC

Call DISPLAY_FORM



In the case of DISPLAY_TOPIC and DISPLAY_FORM, they are both useful work procedures because there is a lot of code in them to work with SQLite3.
But INIT_CGI and PARSE_GET are small procedures with only a few instructions in them...  I don't want to inline these instructions myself because I want to keep the main procedure clean, if you see what I mean. I feel like I would lose this kind of readability.

CALL/RET must be fast enough to ignore all of this, but it's just the thought that C has all this for free that annoys me a bit  :green
Is there a way to inline these functions or am I supposed to encapsulate them in a macro ?

[Vortex]

I guess your only choice is to use macros to solve the problem.

[mitchi]

I see. So there's no other way. Thanks :)

[dedndave]

C has the calls - and probably saves/restores all the registers and probably sets up a stack frame, whether you need it or not
the fact that you decide whether or not you need those with ASM is half the speed advantage
the other half being faster literal code
macros is the way to fly - and for simple code, not that hard to set up
text wise, a macro doesn't really take much more typing than a proc
if you use it only a few times - or if it is really small (byes) - use a macro
if you use it over and over in places where speed is not that critical, use proc
of course, you can combine the two techniques and set up a proc that uses the macro
when speed is critical, refer to the macro
if not, refer to the proc

[hutch--]

mitchi,

Put what you are doing into context, the call/ret overhead is trivial once the instruction count goes up and in a CGI application it would be almost impossible to measure any speed gain by doing all the work to inline the code or put it in macros to inline it. Readability and maintainability are worth more than an imaginary speed gain so i would be inclined to leave it as it is.

You inline code where speed matters to save call/ret overhead which can be a significant factor on very small procedures where CGI is some powers slower than assembler instructions and any performance gain is doubtful.

[mitchi]

Yes hutch, you give good advice.
And that's what I ended up doing. I kept my code that way, it's readable and my CGI application is still very fast  :U