Is this a C51 / uvision bug?

Erik, you'll have to face it: what you called an "inconsistency" is not actually one. That's the whole problem. One part of the problem is that you misuse the word itself. Inconsistency as a predicate cannot be applied to a single entity. It takes two things so they can be inconsistent to each other.

I explained to you a long way upthread what the actual problem was, and that explanation can be backed up every step of the way by K&R. You posted two code snippet you believed were equivalent, and stated that Keil was wrong for giving different results for them. But in fact, strictly according to K&R, the two snippets weren't equivalent to begin with, and that's all the explanation it took to explain the difference.

So the only inconsistency anywhere around here is between your expectations and the facts. And, no matter how much that hurts your self-image, Erik, the fact remains: that's neither K&R's fault, nor Keil's. It's entirely the fault of your expectations.

The reason those expectations are at odds with the documented behaviour is because you consider yourself beyond reading manuals. The case at hand has proved you wrong on that count.

And for somebody so vociferously protesting his professionalism, your reaction to that discovery has been really rather disappointingly unprofessional. It's been mostly equivalent to that of a five-year old stomping his foot and shouting "Not so!" at the top of his lungs, mixed with rather excessive amounts of foul language. You didn't really believe that calling people "Cidiot" was going to earn credit to your side of the argument, did you?

What both of you guys really need is a cool-down. As in: no posting here at all, for at least one full week.

Erik, you'll have to face it: what you called an "inconsistency" is not actually one. That's the whole problem. One part of the problem is that you misuse the word itself. Inconsistency as a predicate cannot be applied to a single entity. It takes two things so they can be inconsistent to each other.

I explained to you a long way upthread what the actual problem was, and that explanation can be backed up every step of the way by K&R. You posted two code snippet you believed were equivalent, and stated that Keil was wrong for giving different results for them. But in fact, strictly according to K&R, the two snippets weren't equivalent to begin with, and that's all the explanation it took to explain the difference.

So the only inconsistency anywhere around here is between your expectations and the facts. And, no matter how much that hurts your self-image, Erik, the fact remains: that's neither K&R's fault, nor Keil's. It's entirely the fault of your expectations.

The reason those expectations are at odds with the documented behaviour is because you consider yourself beyond reading manuals. The case at hand has proved you wrong on that count.

And for somebody so vociferously protesting his professionalism, your reaction to that discovery has been really rather disappointingly unprofessional. It's been mostly equivalent to that of a five-year old stomping his foot and shouting "Not so!" at the top of his lungs, mixed with rather excessive amounts of foul language. You didn't really believe that calling people "Cidiot" was going to earn credit to your side of the argument, did you?

What both of you guys really need is a cool-down. As in: no posting here at all, for at least one full week.

Erik, you'll have to face it: what you called an "inconsistency" is not actually one. That's the whole problem. One part of the problem is that you misuse the word itself. Inconsistency as a predicate cannot be applied to a single entity. It takes two things so they can be inconsistent to each other.
I AM referring to two things both having a short as the result, one 'autopromotes', another does not. If two cases with the same size of the result react diffrent that IS inconsistent.

I explained to you a long way upthread what the actual problem was, and that explanation can be backed up every step of the way by K&R.
You keep harping "if it is documented, it is not inconsistent" BALONEY

And for somebody so vociferously protesting his professionalism, your reaction to that discovery has been really rather disappointingly unprofessional.
my SOLE 'reaction' has been to your REFUSAL to accept that it is inconsistent, and your eternal hammring that an inconsistencty that is 'documented' is not an inconsistency. I am aware of how it works, that it is inconsistent has nothing whatsoever to do with whatever the manual may say.

Erik

"If two cases with the same size of the result react diffrent that IS inconsistent."

Size isn't the only thing to consider.

"... that it is inconsistent has nothing whatsoever to do with whatever the manual may say."

Well, it really does because the manual tells you how operand conversion are applied, factoring in both size and sign. So if we add the detail of how C performs operand conversions to your code fragments, one can see that foo1() and foo3() below are equivalent. Comparing foo1() and foo2() below shows inequality, not inconsistency. Hopefully that has made one of the things people are arguing with you about clearer.

typedef unsigned char U8;
typedef unsigned short U16;

U8  GClwdt;
U8  GClhgt;
U16 GSloadCnt;
struct {
    U8 FSLlin;
} GX_ATT;

void foo1(void)
{
    GSloadCnt = GClwdt  * GClhgt;
    /* U16    = (int)U8 * (int)U8 */

    GSloadCnt = GSloadCnt / GX_ATT.FSLlin;
    /* U16    = U16       / (U16)U8 */

    GSloadCnt = GSloadCnt / 2;
    /* U16    = U16       / (U16)int */
}

void foo2(void)     /* "this (which is the same concatenated)".  IS IT REALLY? */
{
    GSloadCnt =      (((GClwdt  * GClhgt ) / GX_ATT.FSLlin) / 2);
    /* U16    = (U16)((((int)U8 * (int)U8) / (int)U8      ) / int); */
}

void foo3(void)
{
    GSloadCnt = ((     (GClwdt  * GClhgt ) / (U16)GX_ATT.FSLlin) / 2);
    /* U16    = (((U16)((int)U8 * (int)U8) / (U16)U8           ) / (U16)int); */
}

below shows inequality, not inconsistency

you can keep your verbiage with my blessing, just acceot that it is yours instead of insisting that i accept it. Since every statement figures out a short it is inconsistent that they do not work on the longest thing in the equation.

because the manual tells you
here we go again, documenting an inconsistency does NOT make it anything else

Erik

Oh brother! You didn't even look at the differences to see that they are flat out obviously different -- what effect the presence and absence of your single (U16) had in other subexpressions. I honestly though that boiling how the conversions are performed to a low gravy would benefit you, but you're just a hopeless case, I'm afraid -- pure and simple.

You can lead people to knowledge, but you can't make them think.

I AM referring to two things both having a short as the result, one 'autopromotes', another does not.

The fact those code samples eventually stuff the results into a short is utterly irrelevant. Intermediate results are never smaller than int, and that's what broke the supposed equivalence of your code samples. In particular, an operation on u8 values, without any casts, like in those samples, produces a result of type signed int. Not short, not unsigned: signed int. Casting one of the u8 operands to u16, i.e. unsigned int, changes that. Storing one of the intermediate results into a u16 variable is equivalent to an (u16) cast.

Consistency means that equivalent input should produce equivalent results. But your code samples are not equivalent to start with, and thus unusable in an argument over consistency.

You keep harping "if it is documented, it is not inconsistent" BALONEY
[...]your eternal hammring

Are you so deep in tantrum-throwing mode that you don't even look who wrote a posting now, Erik? Or what else gives you an excuse to call total of 2 postings by me in this entire thread, 2 weeks apart from each other, an "eternal hammering"?

Looks like I have to repeat myself: cool down, man.

GSloadCnt = (((GClwdt * GClhgt) / GX_ATT.FSLlin) / 2);
U16 U8=160 U8=16 U8=2

even if, as you say "Intermediate results are never smaller than int, and that's what broke the supposed equivalence of your code samples. In particular, an operation on u8 values, without any casts, like in those samples, produces a result of type signed int."
that should not produce a result of zero.

You keep harping "if it is documented not you, but Jack in each and every post has stated things to that effect, if not an exact quote.

Ab=nyhow, regardless of consistency, if intermidiat6e are 'signed int' the resullt should not be zero.

Erik

ou got?erik malund

somehow a partial snuck into my name, sorry

realizing I should have used 'pre' here it is again

GSloadCnt = (((GClwdt * GClhgt) / GX_ATT.FSLlin) / 2);
U16            U8=160 U  8=16      U8=2

Erik

that should not produce a result of zero.

Yes, it should.

How do I know?

I read both manuals.

Hans-Bernhard Broeker Posted
an operation on u8 values, without any casts, like in those samples, produces a result of type signed int.
by that

GSloadCnt = (((GClwdt * GClhgt) / GX_ATT.FSLlin) / 2);
U16            U8=160   U8=16      U8=2
is calculated as
GSloadCnt = (((GClwdt * GClhgt) / GX_ATT.FSLlin) / 2);
U16            S16=160  S16=16    S16=2

so, you and Hans-Bernhard evidently do not read the same book since you post:
Yes, it should.
Erik

Hans-Bernhard Broeker Posted
an operation on u8 values, without any casts, like in those samples, produces a result of type signed int.

so, you and Hans-Bernhard evidently do not read the same book since you post:
Yes, it should.

He is describing integer promotion. I am describing what happens when this is compiled with Keil.

I'm not going to spoon feed you the answer, you are going to have to read the manual if you want to understand what is happening.

Post again when you've figured it out. If you can't manage that I'll drop you another clue.

He is describing integer promotion. I am describing what happens when this is compiled with Keil.

so, are you, in effect, stating that "what happens when this is compiled with Keil" is not standard since you do not say "compiled as C" but "compiled with Keil"?

Erik

so, are you, in effect, stating that "what happens when this is compiled with Keil" is not standard since you do not say "compiled as C" but "compiled with Keil"?

Bingo!

Have you read the manual yet?

so, all this runaround has been that reading 'the manual' (K&R) would agree that there is an inconsistency; whereas 'the manual (Keil C51) would state that there is not. The Keil manual staes that INTPROMOTE enables ANSI integer promotion rules. so WHERE in the KEIL manual does it state what you claim???

Erik

The Keil manual staes that INTPROMOTE enables ANSI integer promotion rules.

I think you must have actually looked something up in the manual!

so WHERE in the KEIL manual does it state what you claim???

No, I'm sure you can work it out for yourself. Clue: you were getting very warm.

so WHERE in the KEIL manual does it state what you claim???

Have you found it yet?