Dear all,

again I'm wondering a little about my compiler's behaviour.
(ICC430 V2.21B)


An expression like                             evaluates to
 if (P1IN & 0x02)                           BIT.B  #0x02, &P1IN

This is what I like.     ;-)


But... if I'm going to write the program a little more
modular and rely on inlining to shrink the code...

static int function(void)
{
   return ( P1IN & 0x02 );
}

if ( function() )


what I get looks a little different ...

MOV.B  &P1IN, R14
AND.B  #0x02, R14


Of course, this works with the same result.  But what I don't like
is that it unnecessarily wastes 2 Byte of memory.

And more annoying to me:  I don't see an obvious reason for this.

a) There is something in the function declaration that I'm missing?
(Which again forces the compiler to do so.)
b) The compiler is "only human" and makes things sub-optimal.
c) I don't know?

:-)
Looking forward to your comments...

Dirk

Dirk,

When you have the expression inside the if condition the compilier knows
that only a Boolean result is needed.  However when you make it a function
that returns an int result the compilier is forced to produce the code to
generate the int value that you have asked for.  It's possible that an
optimizer might reduce this to only the Boolean that you need but then again
it might not.  Maybe you would be better to use a macro.

Gary.

----- Original Message -----
From: "Dirk Reymann" <d.reymann@d.re...>
To: <msp430@msp4...>
Sent: Wednesday, April 28, 2004 6:28 AM
Subject: [msp430] IAR-Compiler: A little ineffective inlining ?!?


> Dear all,
>
> again I'm wondering a little about my compiler's behaviour.
> (ICC430 V2.21B)
>
>
> An expression like                             evaluates to
>  if (P1IN & 0x02)                           BIT.B  #0x02, &P1IN
>
> This is what I like.     ;-)
>
>
> But... if I'm going to write the program a little more
> modular and rely on inlining to shrink the code...
>
> static int function(void)
> {
>    return ( P1IN & 0x02 );
> }
>
> if ( function() )
>
>
> what I get looks a little different ...
>
> MOV.B  &P1IN, R14
> AND.B  #0x02, R14
>
>
> Of course, this works with the same result.  But what I don't like
> is that it unnecessarily wastes 2 Byte of memory.
>
> And more annoying to me:  I don't see an obvious reason for this.
>
> a) There is something in the function declaration that I'm missing?
> (Which again forces the compiler to do so.)
> b) The compiler is "only human" and makes things sub-optimal.
> c) I don't know?
>
> :-)
> Looking forward to your comments...
>
> Dirk
>
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

Gary,

The compiler is not forced to generate a bool for the if statement, just
test the expression to be non-zero.

I believe it's simply an artifact of the internal expansion of the
expression into the if context--perhaps it's an EDG front end issue?
Inlining is difficult, however hard you wave your hands and brush stuff
under the carpet.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

> -----Original Message-----
> From: Gary Anderson [mailto:gary.anderson@gary...] 
> Sent: 27 April 2004 22:38
> To: msp430@msp4...
> Subject: Re: [msp430] IAR-Compiler: A little ineffective inlining ?!?
> 
> 
> Dirk,
> 
> When you have the expression inside the if condition the 
> compilier knows that only a Boolean result is needed.  
> However when you make it a function that returns an int 
> result the compilier is forced to produce the code to 
> generate the int value that you have asked for.  It's 
> possible that an optimizer might reduce this to only the 
> Boolean that you need but then again it might not.  Maybe you 
> would be better to use a macro.
> 
> Gary.
> 
> ----- Original Message -----
> From: "Dirk Reymann" <d.reymann@d.re...>
> To: <msp430@msp4...>
> Sent: Wednesday, April 28, 2004 6:28 AM
> Subject: [msp430] IAR-Compiler: A little ineffective inlining ?!?
> 
> 
> > Dear all,
> >
> > again I'm wondering a little about my compiler's behaviour.
(ICC430 
> > V2.21B)
> >
> >
> > An expression like                             evaluates to
> >  if (P1IN & 0x02)                           BIT.B  #0x02,
&P1IN
> >
> > This is what I like.     ;-)
> >
> >
> > But... if I'm going to write the program a little more modular
and 
> > rely on inlining to shrink the code...
> >
> > static int function(void)
> > {
> >    return ( P1IN & 0x02 );
> > }
> >
> > if ( function() )
> >
> >
> > what I get looks a little different ...
> >
> > MOV.B  &P1IN, R14
> > AND.B  #0x02, R14
> >
> >
> > Of course, this works with the same result.  But what I 
> don't like is 
> > that it unnecessarily wastes 2 Byte of memory.
> >
> > And more annoying to me:  I don't see an obvious reason for this.
> >
> > a) There is something in the function declaration that I'm
missing? 
> > (Which again forces the compiler to do so.)
> > b) The compiler is "only human" and makes things
sub-optimal.
> > c) I don't know?
> >
> > :-)
> > Looking forward to your comments...
> >
> > Dirk
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~--> Buy Ink Cartridges or Refill Kits 
> for your HP, Epson, Canon or Lexmark Printer at MyInks.com.  
> Free s/h on orders $50 or more to the US & Canada. 
http://www.c1tracking.com/l.asp?cidU11
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/CFFolB/TM
---------------------------------~->

.

 
Yahoo! Groups Links



 

> An expression like                             evaluates to
>  if (P1IN & 0x02)                          
BIT.B  #0x02, &P1IN
>
> This is what I like.     ;-)
>
> But... if I'm going to write the program a little more modular
> and rely on inlining to shrink the code...
>
> static int function(void)
> {
>    return ( P1IN & 0x02 );
> }
>
> if ( function() )
>
> what I get looks a little different ...
>
> MOV.B  &P1IN, R14
> AND.B  #0x02, R14


Hi Paul, Dirk!

The first statement is a test for a certain bit in P2IN and the result 
is the setting of a flag upon which there will be a conditional jump 
executed.
The second is a function that has to return a value of type int. Thus 
the compiler has to use a register to return the integer in which is 
commonly R14 and R15 I believe. So the assembler for your second 
example is the shortest possible already, simply because both tasks 
are not the same.
Of course, to you the tasks may be the same as you will probably be 
using the integer as a boolean, but the compiler was told to deliver 
an integer. :-)

Regards,
-Jean-

Jean,

As a compiler implementor, I'd expect an inline function as originally
presented to be expanded inline and deliver the same code as the textual
replacement.

However, compilers are complex beasts and be greateful for what you
get...  ;-)

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

> -----Original Message-----
> From: jean_randhah [mailto:jean@jean...] 
> Sent: 28 April 2004 16:28
> To: msp430@msp4...
> Subject: [msp430] Re: IAR-Compiler: A little ineffective inlining ?!?
> 
> 
> > An expression like                             evaluates to
> >  if (P1IN & 0x02)                           BIT.B  #0x02,
&P1IN
> >
> > This is what I like.     ;-)
> >
> > But... if I'm going to write the program a little more modular
and 
> > rely on inlining to shrink the code...
> >
> > static int function(void)
> > {
> >    return ( P1IN & 0x02 );
> > }
> >
> > if ( function() )
> >
> > what I get looks a little different ...
> >
> > MOV.B  &P1IN, R14
> > AND.B  #0x02, R14
> 
> 
> Hi Paul, Dirk!
> 
> The first statement is a test for a certain bit in P2IN and 
> the result 
> is the setting of a flag upon which there will be a conditional jump 
> executed.
> The second is a function that has to return a value of type int. Thus 
> the compiler has to use a register to return the integer in which is 
> commonly R14 and R15 I believe. So the assembler for your second 
> example is the shortest possible already, simply because both tasks 
> are not the same.
> Of course, to you the tasks may be the same as you will probably be 
> using the integer as a boolean, but the compiler was told to deliver 
> an integer. :-)
> 
> Regards,
> -Jean-
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~--> Buy Ink Cartridges or Refill Kits 
> for your HP, Epson, Canon or Lexmark Printer at MyInks.com.  
> Free s/h on orders $50 or more to the US & Canada. 
http://www.c1tracking.com/l.asp?cidU11
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/CFFolB/TM
---------------------------------~->

.

 
Yahoo! Groups Links