Keil Logo

inline \ MACROs

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Roi T
Posted
23-Oct-2007 15:32 GMT
Toolset
C51
New! inline \ MACROs

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?

Read-Only
Author
erik malund
Posted
23-Oct-2007 15:37 GMT
Toolset
C51
New! RE: inline \ MACROs

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

Read-Only
Author
Andy Neil
Posted
23-Oct-2007 15:43 GMT
Toolset
C51
New! Does not compute

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

Read-Only
Author
Per Westermark
Posted
23-Oct-2007 16:07 GMT
Toolset
C51
New! RE: Does not compute

Called one time and called from one place can make quite a difference.

Read-Only
Author
Roi T
Posted
24-Oct-2007 15:37 GMT
Toolset
C51
New! RE: Does not compute

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.

Read-Only
Author
Andy Neil
Posted
24-Oct-2007 15:50 GMT
Toolset
C51
New! Non-arguments

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

Read-Only
Author
erik malund
Posted
24-Oct-2007 16:00 GMT
Toolset
C51
New! RE: Does not compute

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

Read-Only
Author
Drew Davis
Posted
24-Oct-2007 18:17 GMT
Toolset
C51
New! RE: Does not compute

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.

Read-Only
Author
Hans-Bernhard Broeker
Posted
24-Oct-2007 18:56 GMT
Toolset
C51
New! RE: Does not compute

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.

Read-Only
Author
erik malund
Posted
24-Oct-2007 19:18 GMT
Toolset
C51
New! you can be very modular and still totally efficient

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

Read-Only
Author
Per Westermark
Posted
24-Oct-2007 19:27 GMT
Toolset
C51
New! RE: you can be very modular and still totally efficient

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.

Read-Only
Author
erik malund
Posted
24-Oct-2007 19:30 GMT
Toolset
C51
New! RE: you can be very modular and still totally efficient

well, theoritically, an assembler 'function' can return regs8 +ac1 +b1 +dptr2 = 12 (maybe more) values.

Erik

Read-Only
Author
Andy Neil
Posted
24-Oct-2007 22:02 GMT
Toolset
None
New! Terminology - I beg to differ

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

Read-Only
Author
erik malund
Posted
24-Oct-2007 23:35 GMT
Toolset
None
New! RE: Terminology - I beg to differ

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

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.