• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 21 subscribers
  • Views 786 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

over ambitious code optimisation

Julian Cox

I have a memory mapped A/D converter (with a conversion time << one machine cycle, therefore no need to check for End of Conversion). The following code was written to explain the problem: -

xdata unsigned char A_D _at_ 0xE000;
//this is the address of the A/D converter
unsigned char x,y;

main()
{
A_D = 0;
//start conversion by doing a "dummy write"
x = A_D;     // read the value from the A/D
}
This all looks fine, but when I look at the assembly code: -

     CLR A
     MOV DPTR,#A_D(E000)
     MOVX @DPTR,A
     MOV x(0x80),A
the "dummy write" is OK but we obviously DO NOT read from XDATA address 0xE000. The only way to "FIX" the problem is to insert some code between the write and read operations that make use of the accumulator.
Clearly, this will be a problem where a write only device and a read only device share the same address, as is the case with many programmeable peripheral devices.

Parents
  • 0 in reply to Julian Cox

    "However, the question remains - why should I need to do anything at all?"

    If you look up 'volatile' in a decent 'C' book you'll realise that the optimisation you're seeing is exactly what 'C' compilers are expected to do. In embedded stuff you'll find yourself using volatile quite a bit to suppress this when dealing with memory mapped peripherals and interrupt service routines.

Reply
  • 0 in reply to Julian Cox

    "However, the question remains - why should I need to do anything at all?"

    If you look up 'volatile' in a decent 'C' book you'll realise that the optimisation you're seeing is exactly what 'C' compilers are expected to do. In embedded stuff you'll find yourself using volatile quite a bit to suppress this when dealing with memory mapped peripherals and interrupt service routines.

Children
No data