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

good code bad answer

my code is 110% correct; eg no errors and runs properly. see.

int _val;

int myfunc2(int val)
{
  _val = val;
   return _val;
};

int Bar(int val)
{
  return _val + val + 1;
};

void myfunc1(int val)
{
  _val += Bar(val);
};

etc
etc
etc

it doesnt give me the right answer sometime.

HEEEEEEEELLLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

Parents
  • "That code does work in its original surroundings. It works by coincidence rather than by design, but still..."

    not sure about that. sounds like 1) whether it had worked had nothing to do with a) cpu frequencies; b) peripheral speeds; or c) external devices, and 2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.

    that contradicts the notion that the bug is the result of a) cpu frequencies; b) peripheral speeds; or c) external devices.

    "The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then."

    that's irrelevant to this discussion, had the cpu worked as described in the datasheet. so the bug here is really the hardware bug, not a software one, except that the moronic programmer couldn't realize it.

Reply
  • "That code does work in its original surroundings. It works by coincidence rather than by design, but still..."

    not sure about that. sounds like 1) whether it had worked had nothing to do with a) cpu frequencies; b) peripheral speeds; or c) external devices, and 2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.

    that contradicts the notion that the bug is the result of a) cpu frequencies; b) peripheral speeds; or c) external devices.

    "The CPU was, in fact, so slow that even a read "immediately" after pulling down the clock was still happening long enough after the clock edge that valid data was available by then."

    that's irrelevant to this discussion, had the cpu worked as described in the datasheet. so the bug here is really the hardware bug, not a software one, except that the moronic programmer couldn't realize it.

Children
  • the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.

    What on earth are you talking about?
    Hans-Bernhard Broeker presented a perfectly logical explanation for the observed behavior.

  • except that the moronic programmer couldn't realize it.

    Such mistakes are rarely related to one being a moron.
    Everybody makes mistakes, and as specified already- sometimes it the environment, not the code itself!

  • On the contrary - it is entirely pertinent!

    It is actually quite a common type of mistake - especially when using a "slow" CPU with a "fast" peripheral.

    And it is exactly the type of problem that can give the situation of the OP; viz, the code builds fine, works most of the time - but occasionally fails.

    It's even likely that the code would work fine in an instruction set simulator like the one in uVision.

  • 2) the only reason it worked is that the cpu was NOT functioning as it should per the datasheet.

    Interesting how you assume to know whether or not my CPU here was functioning acccording to its data sheet. Particularly since you certainly don't have the slightest which CPU that might even was.

    that contradicts the notion

    The "that" you're referring is pure speculation on your part, so there's no way it can contradict anything.