Thread: C 89 Implementation-Defined Behavior?

I am trying not to assume anything as I have stated a couple of times I really don't know at all what the CPU designers have to work with. That being said I guess I do have some assumptions as to how I think things should work based on the arithmetic that I have been taught so far.

Based on what you were saying about the C89 standard though and how it was more flexible with different CPUs and such... in the example of 5 % 2 if there was a CPU that decided that 5 / 2 was 3 rather than 2 then the MOD answer would be -1 rather than 1 which I would deem 1 the correct answer and -1 to be wrong. I would also suggest that this is one of the reasons that the C99 group decided to implement the round towards 0 rather than allow for two competing standards.

As I stated in an earlier post I always viewed math as being "fairly" static in that 2 + 2 is always 4 not 5 and I would view the above MOD the same way. I understand in higher level math you can get multiple answers but again you would always get the "same" multiple answers. I totally get what you are saying about the "trade offs" they make when designing. Is there a way to code in c89 to make sure that you ALWAYS get the "usual" or "expected" answer? I am sure that there will be things in C99 that seem this way to me as well....

Here is my question though...say you make a C99 compiled program and it runs on one of those CPUs that they chose to round away from 0 contrary to the C99 standard what would happen?

Thanks,
Bill

Originally Posted by grumpy

I said no such thing. What you are not realising is that microprocessor design involves trade-offs between competing requirements. Mathematical fidelity of basic operations (eg integer division rounding to nearest, rather than up or down) is not a primary design constraint in microprocessor design.

You are assuming there are no trade-offs in microprocessor design. In reality, repeatability of microprocessor behaviour is statistical: there is a likelihood that any operation will not behave correctly, because (in modern processors) effects like voltage variations within a circuit and other random effects. The speed of an instruction tends to go down as the number of circuit elements (resistors, capacitors, transistors, etc) used to implement that instruction goes up. The number of components needed to implement a "round up" or "round down" integer division circuit is much less than the number needed to implement a "round to nearest" circuit.

Because of things like this, even in modern microprocessor design, basic operations tend to be implemented in as simple a form as possible to maximise performance. Techniques are also used that reduce likelihood of a circuit being subjected to some variation that causes it to produce erroneous results. Those sorts of trade-offs tend to discourage hardware designers from implementing operations (eg integer division) in a more costly (i.e. demanding more physical circuit components) manner.


It offers consistency. However, it also broke one of the mandatory design constraints that guided development of the 1989 C standard. A requirement of the 1989 C standard was that any given operation could be implemented in a way that was most efficient on all possible hardware platforms. That meant that simple operations (eg integer division) could be implemented in few machine instruction. That meant allowing use of native instructions.

Some microprocessors in 1989 supported "round up" integer division when given negative operands. Some others supported "round down". Very few - none as far as I know - supported "round to nearest". The 1989 C standard had to allow "implementation defined" in order to allow maximum efficiency on all possible hardware.

Originally Posted by billhavens

Based on what you were saying about the C89 standard though and how it was more flexible with different CPUs and such... in the example of 5 % 2 if there was a CPU that decided that 5 / 2 was 3 rather than 2 then the MOD answer would be -1 rather than 1 which I would deem 1 the correct answer and -1 to be wrong. I would also suggest that this is one of the reasons that the C99 group decided to implement the round towards 0 rather than allow for two competing standards.

C89 did not allow for such flexibility. You had two choices: always round down, or always truncate. For positive values, these two give the same answer. Round to nearest was never an option.

Originally Posted by billhavens

Here is my question though...say you make a C99 compiled program and it runs on one of those CPUs that they chose to round away from 0 contrary to the C99 standard what would happen?

Thanks,
Bill

If a system is developed for a CPU with native division that rounds down instead of truncates, then the C99 compiler must not generate code that uses that native instruction (unless it can guarantee the values are positive), but must instead do the division "manually" (i.e., generate code to do the "proper" division itself, rather than using the built-in).