inline \ MACROs

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!

This will produce function with hundreds of lines, that is obviously not likely.

HUH?

I have several such.

is 'likely' a language problem???? do you mean that you do not 'like' long functions?

Erik

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.

Those goals are ultimately in contradiction to each other. Modularity requires clean interfaces, but clean interfaces cost CPU-cycles to set up and use.

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
}

Erik

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.

Erik

"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.

Erik