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

Why does the Keil compiler generate bad code for the DS400C80?

Barry Gaiman

The following code:
fwsUniChar c;
fwsUniChar *temp;

temp=p->inPtr;
c = *temp;
temp++;
p->inPtr = temp;
correctly increments the pointer p by 0x01


instead of
fwsUniChar c = p->inPtr++;
which incorrectly increments the pointer p by 0x101
This code compiles and runs correctly with ANSI C compilers



Also
routine1() reentrant
{
enum ElementTagType type;

routine2(&type);
}

routine2(enum ElementTagType *type)
{
type = START_TAG;
}


does not work (i.e. type in routine1 is not set to START_TAG after calling routine 2.

There is a default XBPSTACK

Any Ideas

Thanks

Barry

Parents
  • 0 in reply to Dan Henry

    Sorry, bad example use of the ubiquitous name p in this case, since your parameter is also named p. Using your specific example, you would look at the memory allocated to p->inPtr and verify that the 3-byte generic pointer inPtr member changed (or not) as I described.

Reply
  • 0 in reply to Dan Henry

    Sorry, bad example use of the ubiquitous name p in this case, since your parameter is also named p. Using your specific example, you would look at the memory allocated to p->inPtr and verify that the 3-byte generic pointer inPtr member changed (or not) as I described.

Children
No data