Hi, I want to avoid the CALL \ RET overhead of a certain function which is called only once in my program.
I understand the uVision compiler does not support the inline keyword (http://www.keil.com/support/docs/1755.htm), and I should use macros instead. The problem is that uVision cannot step into macros when debugging.
Is there any good solution for this problem?
The problem is that uVision cannot step into macros when debugging. Is there any good solution for this problem? sure, insert the code in the source instead of making it a macro. Sometimes you can not see the forest for the trees.
Erik
"I want to avoid the CALL \ RET overhead of a certain function which is called only once"
If it is only called once, is it really that much of an overhead?
IF it is not called from elsewhere, why make it a separate function anyhow?
Called one time and called from one place can make quite a difference.
This will produce function with hundreds of lines, that is obviously not likely.
I want to keep a modular and efficient code, and calling a function takes more than 10 clocks (think of it within a loop), not speaking when it takes a few variables.
"This will produce function with hundreds of lines, that is obviously not likely."
There's nothing "unlikely" about it.
If execution speed is of paramount importance, then you do what is necessary...
You can have it "pretty" or you can have it "fast" - you can't have your cake and eat it!
"I want to keep a modular and efficient code"
Whether you use a macro or write the code verbatim makes no difference to either modularity or efficiency!
"think of it within a loop"
Is it in a loop? You didn't state that!
HUH?
I have several such.
is 'likely' a language problem???? do you mean that you do not 'like' long functions?
If for some reason you can't live with #define'ing the macro, there's the brutally ugly #include method for inlining:
MyMacro.i -- // I have no idea what the real code is doing // so here's some random small calculation i >>= 1; i++; -- Caller.c -- for (i = 0; i < A_BAZILLION; ++i) { #include "MyMacro.i" } --
The debugger should be able to step into this code. The definition exists in only one place for maintenance.
I want to keep a modular and efficient code,
Those goals are ultimately in contradiction to each other. Modularity requires clean interfaces, but clean interfaces cost CPU-cycles to set up and use.
You'll have to decide which you prefer.
A "clean interface" is not a requirement for modular code, it is only a requirement for "isolated module" code.
If you have all code related to stuffing and draining the UART in one module; I would still call the code modular even if another module had
if (drain != fill) { .... = buffer[drain]; drain++; }
I hate the fact that the site makes this into a crappy format (yes, I know about 'pre')
isolated module code would, of course be ... = getUARTchar():
Actually this is one case where I see the modularity prophets going overboard. You need to have getUARTchar() return an int which you then have to split into flags and (possible) received char which lead to making a ridiculous offering on the altar of modularity
what I would do forgive me Mr. modular would be if (getUARTchar()) { .... = global char }
That is a nice thing with assembly code. Calling a "function" and have the flag in zero or carry processor flag and optionally the character in the accumulator.
well, theoritically, an assembler 'function' can return regs8 +ac1 +b1 +dptr2 = 12 (maybe more) values.
"A 'clean interface' is not a requirement for modular code"
On the contrary, I think it most certainly is a requirement!
"it is only a requirement for 'isolated module' code."
To me, that is a tautology.
Think about modular hardware: to be truly "modular", you want a single, well-defined connector; replacing the module requires knowledge of just that connector and its specs...
OK we can differ on how modular something must be to be called modular :)
I just want to avoid that non-modular (by the 'firm' definition) becomes equalized with spaghetti.
So let us agree that you can have well organized code that is not modular (by the 'firm' definition).
I have seen truly modular code and I have seen code that made me call for tomato sauce, and then I have seen well organized code.