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.
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"
The majority of the document covers the standard library. Give me a list of thing in "the standard library" that it handled efficiently in '51 C
Erik
You need to offer some sort of explanation as to how I have proved your point.
Give me a list of thing in "the standard library" that it handled efficiently in '51 C
Why?
obvious answer when you cant, because there aren't any.
The very mention of the 'importance' of the standard C libraries, when discussing the '51.
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.
I wanted to know why you were asking the question, not what you think the answer is.
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.