• State Not Answered
  • Locked Locked
  • Replies 45 replies
  • Subscribers 21 subscribers
  • Views 8335 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with optimisation of volatiles

Richard Roebuck

Hi there All,

I have a problem which seemed to be defying explanation, but I have come up with a theory. Could I possibly have some feedback on whether the following is likely, plausible, possible, untrue or downright rubbish?

If one reads the contents of a CAN or ADC chip register at a particular address, then the label volatile is placed upon that address to prevent the compiler optimising out repeat readings of the address. If one reads the contents of the address into a variable, then the compiler would automatically treat the contents of this variable with similar care.

Is it possible that there has been an oversight with statements where the contents of a variable depend on the contents of a volatile by way of an if statement, ie...

normal_var=volatile_var;

...is correctly optimised, but...

normal_var=voltile_var;
if (normal_var=0x00)
   {
   another_normal_var+=1;
   }

...is not correctly optimised all of the time, dependant on the surrounding code, unless normal_var itself is declared to be volatile?

For info - am using optimisation level...

OPTIMIZE(3,SPEED)

...and am using version...

C166 COMPILER V4.11

Any thoughts, or is any or all of the above thoughts and understanding way off the mark?


Yours (grateful for any input),


Richard.

Parents
  • 0 in reply to Richard Roebuck

    Well, I can't really see what you mean. Give us a piece of code in C with a real-world example of whatever undesirable optimizations you think the compiler could apply, and we can discuss that. Because in my example I can't see what optimization with side effects the compiler could apply to the i variable, apart from replacing maltiplication with shift, but that has nothing to do with volatile, of course.

    - mike

Reply
  • 0 in reply to Richard Roebuck

    Well, I can't really see what you mean. Give us a piece of code in C with a real-world example of whatever undesirable optimizations you think the compiler could apply, and we can discuss that. Because in my example I can't see what optimization with side effects the compiler could apply to the i variable, apart from replacing maltiplication with shift, but that has nothing to do with volatile, of course.

    - mike

Children
  • 0 in reply to Mik Kleshov

    Volatility is not contagious. A variable not explicitly declared as volatile will be treated however the optimizer treats it, regardless of where its value came from.

    (This is a good thing, as it allows you to sample a volatile register into a variable, and then carry that one sample around without having to worry that it will be re-read.)

  • 0 in reply to Mik Kleshov

    Hi there Mike,

    Cheers for your patience.

    Stripping out all the unnecesary stuff, the code which I am working with is as shown below.

    Note that it is for testing for successful transmission and reception of CAN messages. The aim being to pass one of four suitable values to a set of lights on the CAN card to set them green or red to say if CAN messages are being successfully sent of received...

    //define the addresses on the CAN chip containing the send and receive flags
#define TransmitA  (*((volatile unsigned char far*)0x200008))
#define TransmitB  (*((volatile unsigned char far*)0x200009))
#define ReceiveA   (*((volatile unsigned char far*)0x200004))
#define ReceiveB   (*((volatile unsigned char far*)0x200005))

// define the address which governs the CAN card LED's and the values which could be assigned to it.
#define CAN_board_LEDs  (*((volatile unsigned char far*)0x20002E))

#define Transmit_OK 0x05
#define Receive_OK  0x0A
#define RESET       0x00

//define the variables
unsigned char CAN_LED_status;
unsigned char temp_a;
unsigned char temp_b;
unsigned char test;

//piece of code located in the main function
Start_timing();
TransmitB=0x47;
TransmitA=0xff;
ReceiveB=0;
ReceiveA=0;
Timing_pause(); \\waits for end of 100Hz cycle time to be flagged

test=0x00;
while (test!=0xb8)//test for at least one CAN message being received
   {
   Read_signals();//fills CAN message registers with fresh data from ADC's
   temp_b=TransmitB;
   temp_a=TransmitA;
   TransmitB=0x47;
   TransmitA=0xff;
   CAN_LED_status=RESET;
   if ((temp_a==0x00)&&(temp_b==0x00))
      {
      CAN_LED_status+=Transmit_OK;
      }
   temp_b=ReceiveB;
   temp_a=ReceiveA;
   ReceiveB=0;
   ReceiveA=0;
   if ((temp_a==0x00)&&(temp_b==0xb8))
      {
      CAN_LED_status+=Receive_OK;
      }
   CAN_board_LEDs=CAN_LED_status;
   test=temp_b;
   Watchdog();
   Timing_pause();
   }

    ...by applying tests to the system (like flashing LED's using lines from the C165 processor) I am sure that I am stuck in this loop. (Note that I disconnect from the CANbus so both transmissions and receives will fail).

    The problem is that if I define all four of my variables as given, then I the code performs the lines...

    CAN_LED_status+=Transmit_OK;
CAN_LED_status+=Receive_OK;

    ...and both my LED's go green (suggesting successful transmission and reception) BUT stays in the loop indicating not one CAN message received(which seems to contradict the logic)!!!

    If define all four of my variables as volatile, then the code correctly doesn't perform the two lines...

    CAN_LED_status+=Transmit_OK;
CAN_LED_status+=Receive_OK;

    ...my LED's stay red, and I stay in the loop, which is all corrrect.

    BUT indicating the unpredictability of the situation, if I add the lines...

    while(1)
   {
   Watchdog();
   }

    ...after the above code, and don't define my variables as volatile, then the code works again.

    This is my problem. I have carefully checked the symptoms carefully and feel that I have ruled out anything other than the optimisation of the code with the variables which have been loaded with values from the volatile addresses, which is why I am asking the list.

    Any further thoughts on this would be appreciated.


    Yours,


    Richard.

  • 0 in reply to Richard Roebuck

    PS I ought to add about this piece of code, that if the loop to detect if any CAN messages are received is repeated further down the piece of code. If these further repeats are removed (by for example the use of the lines...

    while(1)
   {
   Watchdog();
   }

    ...before the repeat (which the compilers optimiser should hopefully then regard as dead code and ignore it) or by just deleting it, then the problem goes away.

    To my mind this suggests that perhaps when the optimiser is picking up on repeat code, it is only placing it once in the final code, but making two calls to it, and that it is somewhere in this attempt to optimise that the difference in interpretation of my code is occuring.

    Yours,

    Rich.

  • 0 in reply to Richard Roebuck

    Hi Richard,

    That's more like it. When discussing anything to do with C, I much prefer C code to abstract words :-)
    It sounds like you don't have an in-circuit debugger set up... Anyway, there is no need to try and guess how the compiler optimized your code when you can actually see the generated code. Print out the disassembly of your code and the questions will go away. If you are not familiar with the C166 instruction set, it wouldn't be too dificult to learn. After all, C166 is a RISC-like architecture, there are not that many instructions.
    I would suggest posting compiler listing here if there wasn't that much code.

    Regards,
    - mike

  • 0 in reply to Mik Kleshov

    Hi Mike,

    Cheers for this suggestion, it looks like it is bearing fruit.

    Looking at the Main.LST file, the differences seem to be
    in the interpretation of the lines...

    CAN_LED_status=RESET;
if ((temp_a==0x00)&&(temp_b==0x00))
   CAN_LED_status+=Transmit_OK;
temp_b=ReceiveB;
temp_a=ReceiveA;
ReceiveB=0;
ReceiveA=0;
if ((temp_a==0x00)&&(temp_b==0xb8))
   CAN_LED_status+=Receive_OK;
CAN_board_LEDs=CAN_LED_status;

    Without declaring the variables here as volatiles
    (when the code fails to 'work properly'), the
    assembler looks like...

    2A6C E00E          MOV       R14,#00H
2A6E F480DC00      MOVB      RL4,[R0+#0DCH]; temp_a
2A72 3D04          JMPR      cc_NZ,?C0236
2A74 F480DE00      MOVB      RL4,[R0+#0DEH]; temp_b
2A78 3D01          JMPR      cc_NZ,?C0236
2A7A 08E5          ADD       R14,#05H
2A7C         ?C0236:
2A7C D7408000      EXTP      #080H,#01H
2A80 F3F80500      MOVB      RL4,05H
2A84 E480DE00      MOVB      [R0+#0DEH],RL4; temp_b
2A88 D7408000      EXTP      #080H,#01H
2A8C F3F80400      MOVB      RL4,04H
2A90 E480DC00      MOVB      [R0+#0DCH],RL4; temp_a
2A94 E108          MOVB      RL4,#00H
2A96 D7408000      EXTP      #080H,#01H
2A9A F7F80500      MOVB      05H,RL4
2A9E E108          MOVB      RL4,#00H
2AA0 D7408000      EXTP      #080H,#01H
2AA4 F7F80400      MOVB      04H,RL4
2AA8 F480DC00      MOVB      RL4,[R0+#0DCH]; temp_a
2AAC 3D07          JMPR      cc_NZ,?C0237
2AAE F480DE00      MOVB      RL4,[R0+#0DEH]; temp_b
2AB2 47F8B800      CMPB      RL4,#0B8H
2AB6 3D02          JMPR      cc_NZ,?C0237
2AB8 06FE0A00      ADD       R14,#0AH
2ABC         ?C0237:
2ABC F04E          MOV       R4,R14
2ABE D7408000      EXTP      #080H,#01H
2AC2 F7F82E00      MOVB      02EH,RL4

    If I declare the four variables as volatile (which makes
    the code do exactly what I want of it), the assembler looks
    like...

    2A82 E108          MOVB      RL4,#00H
2A84 E480DA00      MOVB      [R0+#0DAH],RL4; CAN_LED_status
2A88 F480DC00      MOVB      RL4,[R0+#0DCH]; temp_a
2A8C 3D08          JMPR      cc_NZ,?C0236
2A8E F480DE00      MOVB      RL4,[R0+#0DEH]; temp_b
2A92 3D05          JMPR      cc_NZ,?C0236
2A94 F480DA00      MOVB      RL4,[R0+#0DAH]; CAN_LED_status
2A98 0985          ADDB      RL4,#05H
2A9A E480DA00      MOVB      [R0+#0DAH],RL4; CAN_LED_status
2A9E         ?C0236:
2A9E D7408000      EXTP      #080H,#01H
2AA2 F3F80500      MOVB      RL4,05H
2AA6 E480DE00      MOVB      [R0+#0DEH],RL4; temp_b
2AAA D7408000      EXTP      #080H,#01H
2AAE F3F80400      MOVB      RL4,04H
2AB2 E480DC00      MOVB      [R0+#0DCH],RL4; temp_a
2AB6 E108          MOVB      RL4,#00H
2AB8 D7408000      EXTP      #080H,#01H
2ABC F7F80500      MOVB      05H,RL4
2AC0 E108          MOVB      RL4,#00H
2AC2 D7408000      EXTP      #080H,#01H
2AC6 F7F80400      MOVB      04H,RL4
2ACA F480DC00      MOVB      RL4,[R0+#0DCH]; temp_a
2ACE 3D0B          JMPR      cc_NZ,?C0237
2AD0 F480DE00      MOVB      RL4,[R0+#0DEH]; temp_b
2AD4 47F8B800      CMPB      RL4,#0B8H
2AD8 3D06          JMPR      cc_NZ,?C0237
2ADA F480DA00      MOVB      RL4,[R0+#0DAH]; CAN_LED_status
2ADE 07F80A00      ADDB      RL4,#0AH
2AE2 E480DA00      MOVB      [R0+#0DAH],RL4; CAN_LED_status
2AE6         ?C0237:
2AE6 F480DA00      MOVB      RL4,[R0+#0DAH]; CAN_LED_status
2AEA D7408000      EXTP      #080H,#01H
2AEE F7F82E00      MOVB      02EH,RL4

    If I include my infinite loop immediately after the troublesome
    loop, but don't declare the variables as volatile (which also
    makes the code do exactly what I want), then I get the following
    assembler...

    2A22 E108          MOVB      RL4,#00H
2A24 E480D600      MOVB      [R0+#0D6H],RL4; CAN_LED_status
2A28 F480D800      MOVB      RL4,[R0+#0D8H]; temp_a
2A2C 3D08          JMPR      cc_NZ,?C0236
2A2E F480DA00      MOVB      RL4,[R0+#0DAH]; temp_b
2A32 3D05          JMPR      cc_NZ,?C0236
2A34 F480D600      MOVB      RL4,[R0+#0D6H]; CAN_LED_status
2A38 0985          ADDB      RL4,#05H
2A3A E480D600      MOVB      [R0+#0D6H],RL4; CAN_LED_status
2A3E         ?C0236:
2A3E D7408000      EXTP      #080H,#01H
2A42 F3F80500      MOVB      RL4,05H
2A46 E480DA00      MOVB      [R0+#0DAH],RL4; temp_b
2A4A D7408000      EXTP      #080H,#01H
2A4E F3F80400      MOVB      RL4,04H
2A52 E480D800      MOVB      [R0+#0D8H],RL4; temp_a
2A56 E108          MOVB      RL4,#00H
2A58 D7408000      EXTP      #080H,#01H
2A5C F7F80500      MOVB      05H,RL4
2A60 E108          MOVB      RL4,#00H
2A62 D7408000      EXTP      #080H,#01H
2A66 F7F80400      MOVB      04H,RL4
2A6A F480D800      MOVB      RL4,[R0+#0D8H]; temp_a
2A6E 3D0B          JMPR      cc_NZ,?C0237
2A70 F480DA00      MOVB      RL4,[R0+#0DAH]; temp_b
2A74 47F8B800      CMPB      RL4,#0B8H
2A78 3D06          JMPR      cc_NZ,?C0237
2A7A F480D600      MOVB      RL4,[R0+#0D6H]; CAN_LED_status
2A7E 07F80A00      ADDB      RL4,#0AH
2A82 E480D600      MOVB      [R0+#0D6H],RL4; CAN_LED_status
2A86         ?C0237:
2A86 F480D600      MOVB      RL4,[R0+#0D6H]; CAN_LED_status
2A8A D7408000      EXTP      #080H,#01H
2A8E F7F82E00      MOVB      02EH,RL4

    Slightly rusty on my Z80, and 6800 assembler, I'll have a
    stab at working out what's going on. But if this prompts
    any thoughts, then it'd be much appreciated.


    Yours,

    Richard.

  • 0 in reply to Richard Roebuck

    The only difference I see is that in the 'broken' code one of the variables (CAN_LED_status) is placed in the register R14. All the other veriables are placed on the user stack. Of course, this is perfectly legal and the compiler generated correct code.
    There can be all sorts of reasons why the code fails: changed execution speed, corruption of registers by interrupt service routines we don't know of, plain bug in the code (so it works accidentally sometimes) and so on.

    Best of luck!
    - mike

  • 0 in reply to Mik Kleshov

    I'll second Mike's observation. There's absolutely no change at all between the three assembly outputs you show, as far as accesses to your CAN registers are concerned. They're those EXTB+MOVB pairs. Which means that whatever the real bug is, it's not in the piece of assembly code you did show. It's elsewhere.

    One thing I'm worried about is that I don't see any remains of the most significan byte actual addresses of your CAN registers (0x20) in any of the quoted code. Now, I don't do 166's at all, but this does feel fishy.

    Are you sure this code succeeds in accessing your CAN hardware registers at all, in the first place?

    You really should trace through this in some simulator or emulator to see what actually happens.

  • 0 in reply to HansBernhard Broeker

    One thing I'm worried about is that I don't see any remains of the most significan byte actual addresses of your CAN registers (0x20) in any of the quoted code.

    It's those EXTP instructions. EXTP #080H,#01H is pretty much the same as EXTS #020H,#01H, which wouldn't alarm you. For some reason the C166 compiler prefers EXTP to EXTS, but that doesn't do any harm.

    - mike