Hi all Below is the result of some debugging. I have isolated some code from a bigger project and have put it into a stand-alone project.
I basically don't understand why I can do right bit-shifting and AND'ing on single line, when I can't do left bit-shifting and AND'ing on single line.
If it isn't a bug, then what have I missed?
I have included many comments to describe my problem
#include <ADUC832.H> #include <string.h> void main(void) { char ascii[] = "MC"; unsigned char pdu[3]; int w=0, r=0, len; char ch1, ch2, rr, rl; /* This is what I want to do: while-loop run 1: 1: Assign to var 'ch1': ch1 = 'M' (= 0x4D = 0100 1101) 2: Assign to var 'ch2': ch2 = 'C' (= 0x43 = 0100 0011) 3: Assign to var 'w' : w = 0 4: OR together the following: ((ch1 >>(w%7))&0x7F) | ((ch2 <<(7-(w%7)))&0xFF); <=> 0100 1101 | 1000 0000 <=> 1100 1101 <=> 0xCD while-loop run 2: 1: Assign to var 'ch1': ch1 = 'C' (= 0x43 = 0100 0011) 2: Assign to var 'ch2': ch2 = 0x00 3: Assign to var 'w' : w = 1 4: OR together the following: ((ch1 >>(w%7))&0x7F) | ((ch2 <<(7-(w%7)))&0xFF); <=> 0010 0001 | 0000 0000 <=> 0010 0001 <=> 0x21 */ len=strlen(ascii); while (r<len) { // ------ First OR-part ----------------------- // -------Both versions below are OK ---------- // -- VER 1: OK // ch1 = ascii[r]; // rr = (w%7); // ch1 = (ch1 >> rr) & 0x7F; // -- VER 2: OK ch1 = (ascii[r] >> (w%7)) & 0x7F; // Bit-shifting and AND'ing // may be done in one line // ------ Second OR-part ----------------------------- //------- Both versions below are NOT OK ?? ---------- // -- VER 1: OK ch2 = ascii[r+1]; rl = (7-(w%7)); ch2 = (ch2 << rl) & ((char)0xFF); // Bit shift and AND'ing can be // done in one line, IF type cast // is used - why? // ch2 = ch2 & 0xFF; // If splitting into new line // type cast is not required? // -- VER 2: NOT OK // ch2 = (ascii[r+1] << (7-(w%7))) & 0xFF; // type cast doesn't help // ch2 = ch2 & 0xFF; // AND'ing must be on seperate line ? //---------------------------------------------------------------- // IS THIS A BUG ?? //---------------------------------------------------------------- // Why can we bit-shift and do the AND'ing in a single line // for the first OR-part above, but cannot do it for the second // OR-part where bit-shifting and AND'ing must be on two seperate // lines ??? //---------------------------------------------------------------- // ------ Do the actual OR'ing ------- pdu[w]= (ch1 | ch2) ; if ((w%7)==6) r++; r++; w++; } pdu[w]=0; // terminator //---------------------------------------------------------------- // Run to here in debugger and look at content of // local variable 'pdu'. // When using 'NOT OK' versions from above // pdu will contain {0x4D, 0x21, 0x00} // and not {0xCD, 0x21, 0x00} as the 'OK' versions // produce. //---------------------------------------------------------------- while(1); }
you just proved my point: "you may very7 well be more 'competent' than me in the finer nuances of C but I will bet that compared to me you are GROSSLY 'incompetent' in '51 C"
You need to offer some sort of explanation as to how I have proved your point.
The very mention of the 'importance' of the standard C libraries, when discussing the '51.
Erik
Yours is the only use of the word 'importance' in this thread.
I mentioned the standard 'C' library exactly twice:
The majority of the document covers the standard library. You've made it pretty clear you use very little (if any) of the standard library hence the parts of the 'C' language you actually use are covered by quite a small subset of the document.
You seem to be up to your old tricks of false attribution. Please desist.
You seem to be up to your old tricks
well, what about your "old tricks" of not answering.
I just read through this exchange and did not find one single place where you instead of discussing "the gospel of C" discussed "C as applied to the '51".
You have totally ignored every single reference I have made to "C as applied to the '51".
Of course, if your basis for discussing is "the gospel of C' and the '51, to you, is a abnomiation because it is not an ideal C machine. that would explain it.
If you review the thread you will find that I have addressed a far greater number of your points than you have of mine.
I don't discuss the 'gospel of C' (I'm not even certain what you mean by that). I discuss writing correct 'C' as documented in the language definition. 'C' as applied to the 8051 is not relevant to the example you posted (the example showed a lack of understanding of integer arithmetic which would be equally applicable on any platform).
I have explained above why I have not been drawn into platform specific discussions irrelevant to my original point.
I read Toolset C51
you post 'C' as applied to the 8051 is not relevant
how does that jive?
of course you do not, you have no friggin idea of what C does to the '51.
I would much rather have doubts about 'integer promotion' than about the efficiency of a switch statement in C51.
I am quite aware of the general principles of integer promotion, just the fact that when the result is a short there is no 'internal' promotion seems very inconsistent to me. If something seems very inconsistent to me I do not immediately think that the inconsistency is 'designed in', but your excellent familiarity with the gospel of C of course makes looking for an inconsistency as 'the standard' natural.
Ah, another of the tricks you use when you have no rational argument left: snip the quote to change its meaning. Let's look at what I actually said:
'C' as applied to the 8051 is not relevant to the example you posted
Do you notice the extra 5 words?
Oh dear, more vulgarity.
I have every idea what 'C' does to the 8051. Why you think that having actually read the manual precludes that I don't know.
I am quite aware of the general principles of integer promotion, just the fact that when the result is a short there is no 'internal' promotion seems very inconsistent to me.
Why don't you read the manual and find out how it works?
If something seems very inconsistent to me I do not immediately think that the inconsistency is 'designed in'
You only think it is inconsistent because you haven't read the manual.
but your excellent familiarity with the gospel of C
I'm familiar with the 'C' language. Any 'gospel' is entirely in your imagination.
of course makes looking for an inconsistency as 'the standard' natural.
Once again you only think the behaviour is 'inconsistent' because you don't understand how it works.
Try taking a step back, calming yourself down and reading the thread slowly from start to finish. If you can manage that you'll realise that the thrust of my comments throughout have been nothing more than an encouragement to you to read the manual and learn how 'C' works. If you do that you'll be a better programmer, if you don't you'll still be 'solving' problems that don't exist in another 15 years time.
You'll also realise that your desperate attempts to berate me and pigeon hole me as someone who codes with no consideration for the underlying platform are unfounded.
I have every idea what 'C' does to the 8051. Why you think that having actually read the manual precludes that I don't know. the fact you refuse to discuss it. The fact that you as I "have actually read the manual" has nothing to do with that statement. The issue is put emphasis where emphasis belong. What is more important: to have to 'figure out' a calculation that the debugger show has the wrong result (2 minutes) or fighting timing issue because of "fully using" C (days)?
Why don't you read the manual and find out how it works? already answered in my above post.
If something seems very inconsistent to me I do not immediately think that the inconsistency is 'designed in' You only think it is inconsistent because you haven't read the manual. can't you READ, I wrote "inconsistent to me"
Once again you only think the behaviour is 'inconsistent' because you don't understand how it works. as stated in the manual the driver side window of my car roll fully down when the button is pressed, the others do not I find that VERY INCONSISTENT. How would 'reading the manual' change my opinion of what is isncosistent and what is not?
If you can manage that you'll realise that the thrust of my comments throughout have been nothing more than an encouragement to you to read the manual and learn how 'C' works. I KNOW HOW C WORKS CONFOUND IT!!!!!!!!! that you may have a more detailled knowledge of the finer details does not make me an imbecile.
You'll also realise that your desperate attempts to berate me WHO started the 'berating'?
C'mon guys... take a break, cool off, and drop it. Do you think you might be doing more harm than good?
I'll gladly stop, if that's OK with Jack. but when he calls me incompetent or similar, I must respond.
"Do you think you might be doing more harm than good?"
There is some value to this discussion/argument and those we've read here in the past -- interview test cases. Some employment candidates have many years of experience and claim to know C. We have taken the basis of many of these arguments and test candidates on the root issue, looking for "Cignorance" and "Cidiocy" (to expand on Erik's vernacular). Since we develop deeply embedded systems, we don't test much related to the C libraries, but do test for core language competency.
That said, if a veteran has some weaknesses in C, but is good in other areas, as long as they have not isolated themselves from education and still have an eagerness to (re)learn and improve themselves, we'll take 'em. Test for knowledge and attitude.
the fact you refuse to discuss it.
It isn't relevant to the point we are discussing. I realise you would prefer to try and steer the discussion onto another topic but I'd prefer to stick with the existing one.
What is more important: to have to 'figure out' a calculation that the debugger show has the wrong result (2 minutes) or fighting timing issue because of "fully using" C (days)?
The most important thing is to try and write correct, bug free code in the first place. In order to do this it is necessary to know how to use the tools (in this case the 'C' language). That is best achieved by consulting the manual when you come across something you don't understand. If you often spent days fighting timing issues I'd suggest that a little more planning before you start coding would be in order.
already answered in my above post.
I couldn't see your answer. Could you repeat it for me?
can't you READ, I wrote "inconsistent to me"
Yes, I can read. I'll rephrase if you prefer, although I don't think there's much semantic difference:
It only seems inconsistent to you because you haven't read the manual.
as stated in the manual the driver side window of my car roll fully down when the button is pressed, the others do not I find that VERY INCONSISTENT. How would 'reading the manual' change my opinion of what is isncosistent and what is not?
Our discussion is about one programming language for which there is one defining manual. No inconsistency. Two cars == two manuals == inconsistency.
I KNOW HOW C WORKS CONFOUND IT!!!!!!!!!
I'm afraid your posts tell a different story.
that you may have a more detailled knowledge of the finer details does not make me an imbecile.
I just read the manual. It's not difficult.
You'll also realise that your desperate attempts to berate me
WHO started the 'berating'?
I berated you for refusing to read the manual, something that you do to other posters on this forum with monotonous regularity.
... and still have an eagerness to (re)learn and improve themselves ...
Quite.
Reading back through the thread it's interesting to note that I have not described you as incompetent or anything similar, whereas you have described me as 'grossly incompetent' amongst other things.
Oh, weel, I offered to stop, but here we go again
"What is more important: to have to 'figure out' a calculation that the debugger show has the wrong result (2 minutes) or fighting timing issue because of "fully using" C (days)?" The most important thing is to try and write correct, bug free code in the first place. In order to do this it is necessary to know how to use the tools (in this case the 'C' language). That is best achieved by consulting the manual when you come across something you don't understand. Rephrasing your answer (The most important thing is to try and write correct, bug free code), by that you state that designing the program well is TOTALLY IRRELEVANT if your code is 'correct'. Some write "write correct, bug free code" that is so badly designed that it is a miracle it woeks, yet it 'correct'. Try adding a feature to such code and see it fall apart.
If you often spent days fighting timing issues I'd suggest that a little more planning before you start coding would be in order. and now you contradict what you said before. This could be my advice to someone else.
Why don't you read the manual and find out how it works? already answered in my above post. I couldn't see your answer. Could you repeat it for me? you state "if something is inconsistent to you, assume it is the compiler that is designed inconsistent - I make no such assumption.
It only seems inconsistent to you because you haven't read the manual. as stated in the manual the driver side window of my car roll fully down when the button is pressed, the others do not I find that VERY INCONSISTENT. How would 'reading the manual' change my opinion of what is isncosistent and what is not? Our discussion is about one programming language for which there is one defining manual. No inconsistency. Two cars == two manuals == inconsistency. No two cars, no two manuals, 4 windows in the same car BULLSHIT, the inconsitency may be 'documented' but it is STILL an inconsistency. If I document that you are dead, will that kill you?
I KNOW HOW C WORKS CONFOUND IT!!!!!!!!! I'm afraid your posts tell a different story. that you may have a more detailled knowledge of the finer details does not make me an imbecile. I just read the manual. It's not difficult. No, it is not, and I am friggin IMPRESSED that you can retain all the info in it. Then, of course when your only interest is the programming language and not its appplication, that will make it easier.
erik
You offered me a choice of two things:
The first one is an example of how *not* to fix a problem caused by lack of knowledge of the programming language, the second is an example of how to fix a problem caused by poor program design.
You then asked me to choose which is more important. Well, the important thing is to avoid getting into these sort of situations in the first place. Try taking a disciplined engineering approach to design and development instead.
Rephrasing your answer
Changing it to something completely different that suits you better would be a more accurate description...
(The most important thing is to try and write correct, bug free code), by that you state that designing the program well is TOTALLY IRRELEVANT if your code is 'correct'.
No, I don't state that.
If you often spent days fighting timing issues I'd suggest that a little more planning before you start coding would be in order.
and now you contradict what you said before. This could be my advice to someone else.
No, I don't contradict what I said before.
Will you please stop attributing false quotations? You've taken a statement I made, invented an alternative completely different statement, and then tell me I'm contradicting myself when in fact you have invented the statement I'm supposed to be contradicting? Grow up.
already answered in my above post. I couldn't see your answer. Could you repeat it for me?
you state "if something is inconsistent to you, assume it is the compiler that is designed inconsistent - I make no such assumption.
Ok, I asked you to state your answer to the question:
"Why don't you read the manual and find out how it works?"
You have answered with yet another quotation from me that *you have modified to change the meaning*.
No two cars, no two manuals, 4 windows in the same car
I misunderstood. I thought you meant two or more cars.
BULLSHIT
No, it is not, and I am friggin IMPRESSED that you can retain all the info in it.
Oh dear, more vulgarity. Incidentally, I can't retain all the information. That's why I read the manual.
Then, of course when your only interest is the programming language and not its appplication, that will make it easier.
Once again, no matter how convenient the contrary would be for your argument, I *am* interested in both the programming language and its application. I also find that I can apply it much more effectively by reading the manual.
It would save a lot of bandwidth if you would please refrain from these rather pathetic tactics of fabricating false quotations or 'adjusting' real ones.
I give up
Jack, you go read your manual. I will write some quality code, that may not be 'intricate' but will be fully functional with much concern for not overloading the processor by "fully using the C language'.
If you want to, go ahead and tell another outright lie, re my porogramming skills, which you have absolutely no idea about - that one intricacy of C to you is consistent and to me not, does not make you any better, just makes you a gospel reader.
You keep on, there is evidently no other way to shut you up than ignoring you.