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.
Let me tell you a story about a guy named Jed...
A long long time ago (pre-ANSI C), in a galaxy far far away I had worked for a company that had to develop internal "C" coding standards and "Jed" worked on one aspect of the standard while I worked on another. We would hold weekly meetings to reconcile our differences. In attendance, we had other professionals for simple sanity checking and to gain insights from different points of view.
Chris was one of our attendees and was a very experienced software veteran who had plenty of code in various satellite systems orbiting our planet today. By then, Chris was in upper management and graced us with his wisdom when he could.
Well during one of our weekly meetings, "Jed" and I got into a simple disagreement on a Rule about header files. We were at an impasse, so we waited for Chris to arrive and have him make the final decision: about five of us professional engineers were in the room.
When Chris arrived, he heard the arguments, and quickly announced that I was right. (Hence, Jed was wrong).
Well, Jed freaked out and wanted to take the guy outside and teach him a lesson! ... Jed was red-faced, quickly stood up, even took a step towards Chris, and said "Chris, lets just step outside and settle this! I am right and you don't know what you're talking about!" etc etc.
The other attendees and I were duly impressed over Jed's technique of handling technical disagreements. Especially with upper management.
Instead of Jed trying to learn that he *might* be wrong, Jed leaped into the confrontation method of getting his way. Bullies do this because they lack the brain-power to reason through a disagreement. It is a childish trait.
Children are at a huge disadvantage when arguing with "an adult" (or somebody who is much smarter than they are) and they will become very frustrated over their strong desire to assert themselves and their inability to win the mental sparring. They will get physical and/or verbally abusive. Some people out grow this, and some don't.
I think Jed showed his 'abilities' quite well. I find that this is true with so many people on so many subjects. I've seen this behavior many times over. I've seen it here on this forum.
When an "Original Poster", asks a question and people try to answer it (after much refinement of the OP's question) you get these side-bar posts where somebody will start attacking another poster's efforts. And I mean 'attack' and not augment or refine.
I don't have a problem with correcting or clarifying others, or even the occasional sprinkling of sarcasm, but when it is ALWAYS devolves into some vindictive vitriol between a brisling poster and the rest of 'us,' I wonder if it is out of ignorance, malice, or some twisted form of self-entertainment. All three of which are adolescent behaviors. (en.wikipedia.org/.../Adolescence)
Since the regular players here are detail oriented and thus they are savvy enough to know who I'm talking about, I don't think I have to name names.
He is critical enough to figure it out himself, so I would expect that the offender would read this and ask himself if he is demonstrating Ignorance, Malice, Entertainment, or is he being an adult and providing a constructive post before he does so.
And, I hope his "Mea Clupea" (en.wikipedia.org/.../Mea_culpa) will be a silent one, because I'm kind of tired of reading his Hostile Postings (HP).
</rant> --Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
ISO (formerly ANSI) Standard 'C' == Keil 'C'. you conveniently ignore that while "keil C" has a variable named BIT, you will not find that in the "ISO (formerly ANSI) Standard 'C'"
"Have you ever read the 'C' standard? yes (I have a K&R somewhere)
I guess that was a typo. Did you mean: "no (I have a K&R somewhere)"?" how do you know that? again you throw out accusations that you have no basis whatsoever for
It is obvious from I do not give a hoot about portability. Yes, I know you're proud of your stance on that issue. that you have no concern for readability and efficiency since 'portability' is of such paramount importance to you. And I take no pride in not giving a hoot about portability, the pride is definitely yours, since you have never argued against the fact that e.g. "a million" #if and #ifdef (to make code 'portable') will make code unreadable.
Just curious do you ever use BIT? it would make the code non-portable, so I guess you do not or, maybe, you obfusciate the code with some #if and #ifdefs.
Erik
you conveniently ignore that while "keil C" has a variable named BIT, you will not find that in the "ISO (formerly ANSI) Standard 'C'"
How do you reconcile the fact that C51 is an ANSI/ISO 'C' compiler with the existence of 'bit', I wonder?
I guess that was a typo. Did you mean: "no (I have a K&R somewhere)"?"
how do you know that? again you throw out accusations that you have no basis whatsoever for
How else should I interpret your response? You seem to be confusing K&R with the standard, and the knowledge you display of the content of the standard doesn't give any indication that you have read it.
It is obvious from I do not give a hoot about portability. Yes, I know you're proud of your stance on that issue. that you have no concern for readability and efficiency since 'portability' is of such paramount importance to you.
I have great concern for readability - it is vital for maintainability. I'd say it is probably second on my list of requirements behind correctness.
'Efficient' code - by which I assume you mean code optimised for speed rather than readability - I only use where absolutely necessary. Perhaps you could try compiling with a higher optimisation level to reduce the frequency with which you need to hand optimise code? Or would that impede your 'development by debugger' coding technique too much?
And I take no pride in not giving a hoot about portability, the pride is definitely yours, since you have never argued against the fact that e.g. "a million" #if and #ifdef (to make code 'portable') will make code unreadable.
You have some odd ideas. Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable.
How do you reconcile the fact that C51 is an ANSI/ISO 'C' compiler with the existence of 'bit', I wonder? well, I asked, why do you not answer instead of 'wonder"
'Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable. how can this be portable without preprocessor directives #if COMPILER == C51 bit47 = TRUE; #elif COMPILER == ACME bitword |= 0x04; #endif NOTE: it is, of course, possible to just use the OR and ignore the efficiency, but what if the C51 project is time critical (if you even know what that is) and the ACME project is not because it runs on a much faster processor? If the above is not "to your liking" come out of your hole and state what I suspect is your position that you do not give a hoot about efficiency.
Another query if you were to be portable between Keil and SDCC how would you manage the bit definition without preprocessor directives
In short "Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable" is contradicted by your own statements.
Jack, Erik,
I don't know how Keil handle bit fields for the C51, but for an ARM it is certainly a bad idea to use them, due to the following reasons:
* Jack must agree with me that bit fields are not really a solid part of the C standard. compilers seem to have artistic freedom when dealing with them which can yield more or less efficient code (packing of structures...). * because all ARM registers are 32 bit, 2 instructions are required to test a bit: a shift to right, then a separate instruction to test the value.
it is much faster to use a 32 bit integer as a container for your bit fields.
I wonder: what is more efficient for a C51? using a bit field or an 8 bit integer?
Tamir,
A bit in C51 is there to specifically use the bit storage area of the CPU. There is a block of 128 bits that are a little like prime real estate. They are particularly useful for boolean operations.
C51 has access to this area with a specific extension.
When considering porting, they are not such a big issue - And I see the usual stubborness being exhibited by a certain poster.
Generally, I would not consider using the bit directly within the code, but would instead use a typedef such as:
#if C51 typedef bit Flag; #else typedef unsigned char Flag; #endif
This is put into a header file with all other port related details.
So whats so difficult about it? Nothing!
well, I asked, why do you not answer instead of 'wonder"
You didn't ask anything, you made a statement to which I responded with a question. In any case, given that you treat any suggestion that you have not read the standard as a "baseless accusation" then I'm sure you'll feel insulted if I suggest that you might not know the answer to my question.
Do you still claim to have read the ISO 'C' standard?
how can this be portable without preprocessor directives #if COMPILER == C51 ....
It isn't portable. Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable.
NOTE: it is, of course, possible to just use the OR and ignore the efficiency, but what if the C51 project is time critical
I'd be unlikely to have designed my way into a situation where a bit operation rather than a byte operation would make the difference between project success and project failure. Perhaps you write the code, compile and count the clock cycles before you select the processor and oscillator?
and the ACME project is not because it runs on a much faster processor
Ah, glad to see you agree with me. Use a faster processor.
If the above is not "to your liking" come out of your hole and state what I suspect is your position that you do not give a hoot about efficiency.
I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is.
Really? Which ones?
Rob, according to whoever hides behind "Jack Sprat", you are wrong, I quote: "Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable."
evidently you are supposed to make your code portable without using "preprocessor directives"
Alas, in the real world, that is not always an option. Processors for embedded systems rarely get chosen for their ability to run 'portable' (and hence larger, slower) code - they get chosen for their ability to 'barely run the application for the lowest cost' - in this case - optimising for every last clock cycle can become an issue, especially when feature creep sets in.
Well taken to extremes, that is sheer nonsense; but I do not think (or hope) this is what is being said.
I have plenty of code that runs on different cores where the only difference is a single 'processor/core specific' header file.
At the very least, typedefs that provide specific width variables (e.g., 8, 16, 32) is nothing short of essential.
a) "I care about efficiency"
Really? Which ones? a) above for example.
I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is. translated "if cost is an issue, do not involve the person hiding behind "Jack Sprat", he cares more about his fanciful ideas"
I'd be unlikely to have designed my way into a situation where a bit operation rather than a byte operation would make the difference between project success and project failure. so would I. Confound it, can you not understand what an example is, www.merriam-webster.com/.../example see 3)
* Jack must agree with me that bit fields are not really a solid part of the C standard.
If Jack did agree with that, I'd have to disagree with Jack. Until then I'll just disagree with you.
Bit fields are quite a solid part of the C standard. Their only weak aspect lies in many people's idea of what they should be used for. Suffice it to say that, like pretty much all of C's data structures, they're intended for internal data of a C program, but not for its external interfaces.
compilers seem to have artistic freedom when dealing with them which can yield more or less efficient code (packing of structures...).
You have that backwards. Compilers have been granted all that freedom intentionally, to allow them to generate more efficient code. If you find inefficiency, blame it on the platform or the compiler.
If Jack did agree with that, I'd have to disagree with Jack. Until then I'll just disagree with you. verbiage, I think yes, bit fields are described fully in the standard, I guess whoever wrote "not really a solid part" really should have written "this is a section where almost every other word is 'implementation defined'"
The "no easy seamless portability" issues comes to a large extent from the 'implementation defined' sections of the standard. That C would have been miserable to process on some processors had these thing not been 'implementation defined' is another story.
I, for one, "have a lot of fun" processing some data which is a bunch of structures written by a processor where the byte order is "the other way around".
Well, like I just said, writing them to files is exactly what C structs are not for. Don't blame programmer's silly decisions on their tools.
Hans-Bernhard, I did not have control over this, it was so, long before I joined the company. Anyhow, without going into non-disclosure requirements, I think it is the most effective form for transferring this which hold about 75 groups of totally varying information.
Anyhow, if you have a better idea for how to transfer in one transmission about 75 groups of totally varying types of information I would love to hear it since gen 4 of this is about to be defined.
Experienced developers packs/unpacks all data themselves when sending the data on communication links or keeping non-volatile data.
This isn't a limitation of bit fields. But it is always a stupid idea to transmit raw memory structures or to to permanently store raw memory structures.
It doesn't matter if we talk about bit fields or if we talk about unions or even just an array of integers. The data should have a known format. Either pre-defined or containing flags that tells the load code which byte order to expect.
Transmitted or stored data should be described by a 100% complete document and the load/save code should make sure that the document and the reality matches.
By taking care of these issues, I don't have to worry about the next compiler changing the algorithm for packing structures or allocating bit fields from high or low bit. And if I did store the data in an internal flash sector of my ARM, I can modify the code a bit and instead write the same data to a SD memory and move that SD memory to a PC and correctly read the data. Or I can add XMODEM and transmit the saved data to a different unit using whatever processor and it will be able to process the XMODEM data and use the same code to restore the original information.