<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>inline \ MACROs</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/37481/inline-macros</link><description> 
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</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/135179?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 15:35:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7c898046-7948-48db-a958-9941e9e70a9d</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
OK&lt;br /&gt;
we can differ on how modular something must be to be called modular
:)&lt;/p&gt;

&lt;p&gt;
I just want to avoid that non-modular (by the &amp;#39;firm&amp;#39; definition)
becomes equalized with spaghetti.&lt;/p&gt;

&lt;p&gt;
So let us agree that you can have well organized code that is not
modular (by the &amp;#39;firm&amp;#39; definition).&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/124173?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 14:02:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a0af6113-1b24-4cb6-9311-dac643578c8c</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;A &amp;#39;clean interface&amp;#39; is not a requirement for modular
code&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
On the contrary, I think it most certainly is a requirement!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;it is only a requirement for &amp;#39;isolated module&amp;#39; code.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
To me, that is a tautology.&lt;/p&gt;

&lt;p&gt;
Think about modular hardware: to be truly &amp;quot;modular&amp;quot;, you want a
single, well-defined connector; replacing the module requires
knowledge of just that connector and its specs...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/135178?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 11:30:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b45f8f8d-5e25-4777-a778-6aeb3acad02e</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
well, theoritically, an assembler &amp;#39;function&amp;#39; can return regs8 +ac1
+b1 +dptr2 = 12 (maybe more) values.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/124174?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 11:27:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a3b5f870-14d8-4cdf-810a-9e524e84226f</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
That is a nice thing with assembly code. Calling a &amp;quot;function&amp;quot; and
have the flag in zero or carry processor flag and optionally the
character in the accumulator.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/113332?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 11:18:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:025fda77-63ef-4183-8593-60d06a6e01a4</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Those goals are ultimately in contradiction to each other.
Modularity &lt;b&gt;requires&lt;/b&gt; clean interfaces, but clean interfaces
cost CPU-cycles to set up and use.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
A &amp;quot;clean interface&amp;quot; is not a requirement for modular code, it is
only a requirement for &amp;quot;isolated module&amp;quot; code.&lt;/p&gt;

&lt;p&gt;
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&lt;/p&gt;

&lt;p&gt;
if (drain != fill)&lt;br /&gt;
{ .... = buffer[drain]; drain++;&lt;br /&gt;
}&lt;/p&gt;

&lt;p&gt;
I hate the fact that the site makes this into a crappy format
(yes, I know about &amp;#39;pre&amp;#39;)&lt;/p&gt;

&lt;p&gt;
isolated module code would, of course be&lt;br /&gt;
... = getUARTchar():&lt;/p&gt;

&lt;p&gt;
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 &lt;b&gt;making a ridiculous offering on the altar of
modularity&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
what I would do &lt;i&gt;forgive me Mr. modular&lt;/i&gt; would be&lt;br /&gt;
if (getUARTchar())&lt;br /&gt;
{ .... = global char&lt;br /&gt;
}&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/99826?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 10:56:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c64d3520-4c30-42c7-858e-f77319f5232e</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I want to keep a modular and efficient code,&lt;/i&gt;&lt;/p&gt;

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

&lt;p&gt;
You&amp;#39;ll have to decide which you prefer.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/113327?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 10:17:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9ac9aab6-bd27-4fe7-96db-28d336c0f64a</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;&lt;p&gt;
If for some reason you can&amp;#39;t live with #define&amp;#39;ing the macro,
there&amp;#39;s the brutally ugly #include method for inlining:&lt;/p&gt;

&lt;pre&gt;
MyMacro.i
--
   // I have no idea what the real code is doing
   // so here&amp;#39;s some random small calculation
   i &amp;gt;&amp;gt;= 1;
   i++;
--

Caller.c
--
   for (i = 0; i &amp;lt; A_BAZILLION; ++i)
      {
#include &amp;quot;MyMacro.i&amp;quot;
      }
--
&lt;/pre&gt;

&lt;p&gt;
The debugger should be able to step into this code. The definition
exists in only one place for maintenance.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/99817?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 08:00:16 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:de310fdd-3534-49a7-9203-3f61cfa7cafd</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;This will produce function with hundreds of lines, that is
obviously not likely.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
HUH?&lt;/p&gt;

&lt;p&gt;
I have several such.&lt;/p&gt;

&lt;p&gt;
is &amp;#39;likely&amp;#39; a language problem???? do you mean that you do not
&amp;#39;like&amp;#39; long functions?&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/99820?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 07:50:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b809fb50-7d35-4294-a31d-8f9bbf732b75</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;This will produce function with hundreds of lines, that is
obviously not likely.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
There&amp;#39;s nothing &amp;quot;unlikely&amp;quot; about it.&lt;/p&gt;

&lt;p&gt;
If execution speed is of paramount importance, then you do what is
necessary...&lt;/p&gt;

&lt;p&gt;
You can have it &amp;quot;pretty&amp;quot; &lt;i&gt;&lt;b&gt;or&lt;/b&gt;&lt;/i&gt; you can have it &amp;quot;fast&amp;quot; -
you can&amp;#39;t have your cake and eat it!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;I want to keep a modular and efficient code&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Whether you use a macro or write the code verbatim makes no
difference to either modularity or efficiency!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;think of it within a loop&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Is it in a loop? You didn&amp;#39;t state that!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/75636?ContentTypeID=1</link><pubDate>Wed, 24 Oct 2007 07:37:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:13eead50-9615-4389-8927-7f42b7e6bea8</guid><dc:creator>Roi T</dc:creator><description>&lt;p&gt;&lt;p&gt;
This will produce function with hundreds of lines, that is
obviously not likely.&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/88626?ContentTypeID=1</link><pubDate>Tue, 23 Oct 2007 08:07:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:26a84fd1-b9f5-4b38-880d-edc12de5aa6d</guid><dc:creator>Per Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Called one time and called from one place can make quite a
difference.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/48823?ContentTypeID=1</link><pubDate>Tue, 23 Oct 2007 07:43:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:538f1586-3510-4a30-b6c8-c7f4bfc78087</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;I want to avoid the CALL \ RET overhead of a certain function
which is called only once&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If it is only called once, is it really that much of an
overhead?&lt;/p&gt;

&lt;p&gt;
IF it is not called from elsewhere, why make it a separate
function anyhow?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: inline \ MACROs</title><link>https://community.arm.com/thread/51230?ContentTypeID=1</link><pubDate>Tue, 23 Oct 2007 07:37:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2282a203-39fc-471b-81ba-3757b8d3cd92</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;The problem is that uVision cannot step into macros when
debugging. Is there any good solution for this problem?&lt;/i&gt;&lt;br /&gt;
sure, insert the code in the source instead of making it a macro.
Sometimes you can not see the forest for the trees.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>