Hi guy's....just check this....?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just practicing some code and tried to use conditional expression...getting error....by the way i am trying this with codevision. Code is as follows:

#include 
#include 


unsigned char i;

void main(){

           int y=0;
            DDRA = 0xff;
            DDRB = 0x00;
            
            PORTA = 0x00;
            
            while(1)
            {
                         
                         
                (i<5)? y=1 : y=0;
                        
                    }
            
                PORTA = i;                


            }

and the error message is
//Error: \\Wdsharespace\nihal\AVR_high_projedata\Current_activities\Current_Projects\Covevision_projects\_Barnet_AVR & embedded c\Chapter one\Conditional_expressions\main.c(19): missing ':'//[/code]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The form is

y = (i<5) ? 1 : 0;
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks kk6gm...thanks a lot!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the future, try to line up your brackets, makes your code MUCH easier to read.

Your teacher will also appreciate it when he marks you for chapter one's conditional expressions homework :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless you deliberately edited them out, try to get into the habit of adding comments to your code as you write it. As a reader I'd like to know why DDRA is being set to output (LEDs connected?) or why DDRB is being set to all input?

By the way the optimiser in your compiler will hopefully see that 'i' is set to 0 by default (it's in .bss) and nothing can ever change it so it's always less than 5 therefore the outcome of the test is that y is always set to 1. So the code actually generated should be identical to:

            while(1) 
            { 
                PORTA = 1;                
            }

and the variable 'y' will never exist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so it's always less than 5

True, but if you add an i++ in the while loop value of y will change.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

True, but if you add an i++ in the while loop value of y will change.

Yes and if you add code to solve third order differnetial equations to main() the program will then do that too?!?

My point was that when the user builds/steps this code in the debugger they may be a little mystified as to where any reference to 'y' has gone.

(as it happens I just built it in CV and the optimiser did not remove the redundant code - not sure why - tried both "maximal" for size and speed)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(as it happens I just built it in CV and the optimiser did not remove the redundant code - not sure why - tried both "maximal" for size and speed)

Perhaps that is why this old bit-pusher feels comfortable with CV: It does what you tell it to do, no matter how idiotic.

CV is nowhere near as aggressive as GCC in "classic" compiler-writing techniques. You will not find nearly as much re-arranging and folding and elimination in CV as you will with GCC.

Thus if you want to win a round of Compiler Wars you could write a 4k program in CV that might be 400 bytes in GCC.

With decent C code the quite different code generation models seem to balance out in the general case.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Well, you get what you pay for with free tools.

So when you pay more, you get more code. I suppose when you pay the big bucks for IAR it adds useless code for you.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So when you pay more, you get more code. I suppose when you pay the big bucks for IAR it adds useless code for you.

There you go--the rule has been proven. ;) (Generally I try to >>not<< write useless code during day-to-day development. Must be a different mindset than those using other toolchains.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(as it happens I just built it in CV and the optimiser did not remove the redundant code - not sure why - tried both "maximal" for size and speed)

To Cliff (and Steve):

You guys are correct. GCC will throw away most if not all of the program posted below. CV gives the machine code shown in the second block along with warnings about code with possibly no effect.

I bring it up here as how it relates to a current "volatile" tread on the GCC forum.
https://www.avrfreaks.net/index.p...

#include 

volatile unsigned char v;
unsigned char frog;

void main(void) {
v; v; frog = v; 
   while (1) {
   }
} 
 
                 _main:
                 ; 0000 0007 v; v; frog = v;
00003d 91e0 0180 	LDS  R30,_v
00003f 91e0 0180 	LDS  R30,_v
000041 9050 0180 	LDS  R5,_v
                 ; 0000 0008    while (1) {

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee,

Can I be the first to say "Snap!" (see that other thread ;-))

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I could not resist after the other "dig" above. :twisted:

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
GCC will throw away most if not all of the program posted below.
Well, actually it does not. In fact, it keeps even more than CV. For some reason it finds it necessary to write the final result into "frog".
v; v; frog = v;
  56:	80 91 00 01 	lds	r24, 0x0100
  5a:	80 91 00 01 	lds	r24, 0x0100
  5e:	80 91 00 01 	lds	r24, 0x0100
  62:	80 93 01 01 	sts	0x0101, r24
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Well, actually it does not. In fact, it keeps even more than CV.

CV writes into "frog" as well, but it is a register variable in my fragment. And my frog isn't volatile. But as noted above CV is not as aggressive about these things as GCC. I deem it a sign of respect--the compiler respects that if I wrote that code, there must be a reason even if it is to have a Compiler Wars skirmish on AVRFreaks, and does not feel that dissing me by throwing out my code would be warranted.

I thought in the other thread you said that GCC only generates one read of "v" with the above...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I thought in the other thread you said that GCC only generates one read of "v" with the above...
No, not exactly. With the above it generates the correct code. It is when I add an extra line that accesses the volatile variable via a pointer to non-volatile, only then it seems to get confused.

The standard says "If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined." I am not sure exactly what that means. But I would think that the undefined behavior is limited only to the code that dereferences a volatile, and not extended to the entire module and all instances where that volatile is accessed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for this great ....discussion....i have learn t a lot out of this