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

    I wouldn't class it as a bug - you want the compiler to optimise the use of variables - in your instance you need to give it some clues to tell it your memory address is NOT memory so it can do what you require. In the case where it is memory - I would curse the compiler if it loaded the dptr, write the value, then load the dptr again and read the same location. The optimiser's job is to identify such things and streamline the code.

    In this instance we have a 'design feature'!

Reply
  • 0 in reply to Julian Cox

    I wouldn't class it as a bug - you want the compiler to optimise the use of variables - in your instance you need to give it some clues to tell it your memory address is NOT memory so it can do what you require. In the case where it is memory - I would curse the compiler if it loaded the dptr, write the value, then load the dptr again and read the same location. The optimiser's job is to identify such things and streamline the code.

    In this instance we have a 'design feature'!

Children
No data