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
Well there are a few interesting thing about people. First a person is always right in there own eyes. (this is always fun) Second a person is often blind to there own failings. (the contrapositive of the prior statement?)
This is where a saying comes from "my friend is my enemy and my enemy is my friend". Sometimes confrontational conversation allows one to see "opps that's not right is it". Hence "my enemy is my friend". However if we always say "yes", IE agree to be agreeable (smooth things over?), then "my friend is my enemy" comes into play, because our own failure, mistake or misguided choices aren't brought into light.
The problem comes in delivery and how receptive the person is to the feedback.
Without NEGATIVE feedback systems become unstable (oscillate) the same goes with people or at least that is my experience.
My 12 cents I guess.
Stephen
Since I noticed two different spellings, It was my assumption that the OP did know the correct spelling, which implies accidient or intention.
"Without NEGATIVE feedback systems become unstable (oscillate) the same goes with people or at least that is my experience."
One reason why I tell people that they should not request for email answers, is that email answers would remove the possibility of negative feedback. If I write a mail directly to someone, I can tell whatever lies and if the receiver isn't bright enough to catch it, it may cost them a lot of grief.
But the question is how negative feedback should be presented. It may be more "fun" to select a confrontational style, but it is almost always counterproductive.
It is also possible to formulate the feedback in a positive way. "Just remember that ...", "Have you thought about ...", "There is also a case where ..." Such an addendum doesn't try to force people into corners, and also invites more people to join in and in a positive way extend/correct.
"Second a person is often blind to there own failings."
My bigest failings - in my own eyes - is that I write too long posts, and that I have too short temper with people who aren't willing to spend any time on their own. This isn't helped by this forum that seems to be populated by a very large amount of trolls and fake posters. Feel free to add to the list of failings - unless I know about them, I can't do anything about them.
All spelling or grammatical errors intentionally or unintentionally added are (c) Per Westermark 2008.
So when we speak of 'portable' or 'nominal' or 'minimal' they are all subjective concepts, and we can go on-and-on-and-on refining what 'portable' means (and the derivative discussion on how to write it), but I doubt if there is going to be a clear-cut answer. To presume to hold The Answer is clearly spratter-brained. "ALL code is portable, the only difference is the amount of work involved in porting it"
so, Vince, we agree.
Erik
erik,
Yep. We agree.
"ALL code is portable, the only difference is the amount of work involved in porting it"
I guess I could have said it that way. (Its my fingers... they ramble on sometimes---at least that is what my attorney told me to say during the trial).
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Vince, What trial are referring to? You may not believe me, but my team leader ordered me to change the following function name "MachineNotSafeForActiveSpreading" into something else (I chose "MachineNotReadyForActiveSpreading") out of fear of future litigation! (you see, just reminding "safety" in source code is a risk in term of future law suits if something goes wrong, when selling something in the US market!). Was your trial related to your software career ?
As much as I would thoroughly enjoy a real trial, my remarks were just intended as houmour.
I do believe you when it comes to such minor things as 'not safe' within source code as being a liability.
Hopefully you told your team leader that the function name gets changed once it is in fact safe. But I doubt it. And even then the ambulance chasers (and all of those attorneys are) would convince a jury that the 'old' code that had the words 'not safe' buried in a comment was somehow responsible for the collapse of the Roman empire.
When we discuss the US Market, attorneys and lawsuits, we start getting into politics, and I can warn you right now, I'd win that one. (I will also not respond to any political stuff, so don't start. I pointed it out because I would LOVE to say so much about that but it is inappropriate here. But, sadly, the US Market does have that problem though)
So, no trial.
Also, I am primarily an electrical engineer and then a software engineer. (Thats what we called them back then, not "CE/CS/??"). Most of my work as been in the R&D missile & aerospace industries, so 'we' don't get sued when we put in things like:
char Totally_Unsafe_And_Known_To_Kill( short victims ) { ... }
We just get shot in a firing squad. (No, Tamir, I we don't really get shot... it was a joke).
But when it comes to Human Safety Factors, it is unsettling when you know it is your stuff that can indeed kill an innocent victim if you screw up with your electronics/software engineering. You pay 'extra' attention to those 'little details.' But that is why we have these safety review boards! Oh, and that thing people call "STANDARDS" too.
(Note: Accidental Deaths/Injuries = 0)
Vince, Don't misunderstand me, but I'd never be able to do what you do. I am convinced that the systems you work(ed) on are probably some of the most fascinating devices we can imagine from a pure technical point of view, but I would simply not be able to contribute to killing people as part of my daily job. I didn't make a fuss of that function name; hell, I changed it. Of course, that would not change the fact that the subsystem is as deadly as a guided missile if you stick a hand or a head into it...
it out because I would LOVE to say so much about that but it is inappropriate here
Vince please, you have people here hurtling at each other stuff like "blabbering idiot", "smoked sardine", "liar", "crawl back into your can" etc. and you make a fuss out of a little politics :)
"...and you make a fuss out of a little politics..."
Okay, fine. I'll keep it short, but I think this isn't exactly the correct forum or for that matter the correct thread either. This will kill two posts with one reply (and I guess I like that)...
I would simply not be able to contribute to killing people as part of my daily job.
I understand. I get that all the time. "How can you do that?"
I usually point out that the systems, at one time not too long ago, used to kill many innocent people as collateral, but now they only kill a few... the right few.
A 100 rounds/bombs/missiles to take out 'the bad guy' now takes 1. Those missed 99 rounds hit 'other stuff' which can include 'the good guys'. Also those 100 rounds cost a bundle not only in material costs but also the logistics in getting them there, so the cost of that 1 is well worth it from the bean-counter perspective. In human life, the cost savings is incalculable.
So believe it or not, I view it as saving lives. "Those bad guys are killed but they planned to suicide-bomb a playground at high-noon anyway."
The objection most people have is misplaced. The *need* to use the weapons is really at issue.
Even so, I don't have a problem with killing the enemy. I even enjoy the YouTube videos of my stuff, in action. Makes me proud.
I do believe that I am on the correct side of the war (and any war the US engages in), and with justification. I'm not building the Chest-Belt Detonator 2000 for the next hospital or marketplace suicide bombing: ONLY bad guys do that.
But Tamir, I do respect your opinion. And the many others out there who also can't/won't do this kind of work.
Vince please, you have people here hurtling at each other stuff like "smoked sardine" please note query.nytimes.com/.../abstract.html defines 'sprat' as a *** fishy thing.
and I did not come up with that monniker (Sprat)
Nice catch there.
When you browse through the "*** fishy" communications, you come away with a slimey feeling that Sprats are hostile when they are not in their native environment. Must be a defense mechanism.
"[...] 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."
Tamir: bit fields did not enter the standard because of ultimate speed - they are not intended to overlap bits in SFR - but because they allow you to trade data size for code size when you have many state variables that each requires a very limited numeric range.
I can have 256 alarm type definitions, where each definition contains a bit-field with flags for 'speech-connecting', 'requires acknowledge','number of repeats', ... Having 5 one-bit fields and one 3-bit field would save 5 bytes / alarm type definition compared to using an unsigned char for each info.
Using bit fields instead of manually performing bit operations makes the code easier to read, as you can see from the following examples. And it make it easy to change the size of the fields depending on changed requirements, without having to look into a number of helping constants or looking into the individual source lines.
The bit field will generate the same code as if I manually perform bit operations but the code will look nicer if I write:
if (alarmtype->speech_connecting) enable_speech();
than if I write:
if (alarmtype->flags & SPEECH_CONNECTING) enable_speech();
And the readability will improve even more when having bit fields of size larger than one, i.e.:
if (dial_count >= alarmtype->max_dial_count) fail_alarm();
than if I have to write:
if (dial_count >= ((alarmtype->flags >> DIAL_COUNT_SHIFT) & DIAL_COUNT_MASK)) fail_alarm();
If I really have room to store all state variables in 8, 16 or 32 bits, then I don't need bit variables.
On a PC, I might have plenty of memory. But the reduced data size from using bit fields (or manually perform the bit operations) may allow the data to fit in the data cache, resulting in faster code. And the concurrent processing of multiple instructions may hide the extra code needed for extracting the bit field.
Erik: "please define 'raw'".
My definition of raw memory structures, is to transmit or store data in the exact format that the compiler puts the data in memory. Such data will have much of it's format defined by the compiler vendor, not by you or the person responsible for the other side of a communication link. And since the compiler vendor has the full right to change that definition, you can not be in ownership of a document that correctly document the data format used.
Me: "Transmitted or stored data should be described by a 100% complete document" Erik: "it is, of course, how else could i use it?"
It can't be 100% documented if it relies on mechanisms that the compiler vendor may change between different releases of the compiler, or that are likely to fail if the source code is built with another vendors compiler.
To be 100% documented, the document must specify the actual bit location of every single bit. And the source code must make sure that the information is really placed at that bit position and doesn't just get placed there by chance because the current compiler because of some private design decision chooses that location.
There is no problem using any kind of byte order for a transmission, as long as you have a document that says that little-endian is always used, or that bit 0x40 of the third transmitted byte (before any endian byte-swappings have been performed) in message xx specifies which - of two possible - endian alternatives that is used. Just relying on memcpy() will not enforce the required endian. If you know that your processor has correct byte order memcpy() when writing may do the job, but what happens if the code is run on a different processor?
Transmitting bit fields (as oposed to manually handled flags) will always be borked since you can't write a documentation that takes into account possible future changes of a compiler.
If the other side is transmitting a raw bit-field, then you have to try to deduce the current location of these fields, while living with the knowledge that a changed compiler on the other end may require you to require your side of the communication. If the coder (or technical lead) on the other side of the communication link was a fool, you will have to suffer, since both sides will - by implication - be non-portable.
Using bit fields inside code gives cleaner code. But a lot of developers intentionally selects to manually assign the bits, just to avoid the extra work of having to write conversion functions "flags_to_native" and "native_to_flags" when they need to share information, or store he information on a medium where it may later be read by an application built with another compiler or built for another architecture.
and I doubt the endianness will change there.
and there are no bitfields, just #defines of 'masks'
Dave wrote: Whatever y'all do... please don't stop. It's always refreshing to find these lengthy discourses, and to take the time to read them. I second his post. Even the extra flaming. I have noticed when the flaming gets 'out of hand', the thread will disappear so I guess that some moderator must ocassionally look at the posts.
Erik writes:
defines 'sprat' as a *** fishy thing.
Well gents I submit this with apologies to the more erudite and entertaining suggestions/comments of this post. But I see what appears to me to be a basic problem in most posts other than lack of registration which I'm voting for adoption. Most posts suffer severely from what might be called sarchasm . Also, this apparent confusion is exaggerated by the very common dopeler effect of multiple posters. The spellings are correct in my dictionary.
Definitions: Sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it. Dopeler effect: The tendency of stupid ideas to seem smarter when they come at you rapidly from several directions. Bradford
Erik: "now I am (I confess) totally lost. if you can not use preprocessor directives to make portable, how can you then make it portable, say between little endian and big endian situations, not to mention between different length ints?"
Vince: "I don't think ANY embedded professional would expect to write in pure 'C'."
I might manage a truly magnificently portable program slightly larger than "Hello World" if I target a Posix platform.
In this case, we are arguing (at least mainly) about embedded development.
So, our programs are not portable. They can't be. But we can affect the cost and time needed to port them to another platform.
Littering the code with huge amounts of #ifdef will not help, since the cost and time needed to maintain such a monster would be gruesom. But it is a direct approach, and hence the first way a beginning developer learns how to write "portable" - or in this case compilable for multiple platforms.
A better way is to see what parts of the software that is very closely tied to the hardware, and separate this into separate files. It will not be "drivers", but it is a beginning. When speed is important, the full functionality may be moved to a target-specific file. When speed isn't as important, the code may be splitted in two layers - one that worries about the bits, and one that worries about decisions.
In some cases, you may then need a few #ifdef in one or two header files to select which set of target-specific functions to use. In some situations you may use the project manager and specify which source files to include in the build. Most often you will be stuck with something in-between.
So a "portable" program may contain #ifdef, and often have to. But the #ifdef used will not be sprinkled around. They may define a UNPACK32(p) macro that knows in which order the four bytes should be loaded, allowing the send_config()/receive_config() functions to manage without caring about the required byte order. Or, you may have buffer_target1.c, buffer_target2.c, buffer_targetx86.c, ... that contains the implementation of get_u32(ptr) functions, letting the project select the correct function for your active target.
In the end, the magical factor isn't if the code contains #ifdef, but how the code has been partitioned and how/where any #ifdef are used. The maintainance cost isn't so much affected by a target.h file containing one or a houndred #ifdef. But if I have 50 source files, each with 5-20 #ifdef, then I suddenly have a lot of source files to worry about.
you are missing the one I refer to Mr. Sprat: "Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable."
So, our programs are not portable. They can't be. But we can affect the cost and time needed to port them to another platform. BRAVO! BRAVISSIMO!
Littering the code with huge amounts of #ifdef will not help, since the cost and time needed to maintain such a monster would be gruesome. BRAVO! BRAVISSIMO!
But if I have 50 source files, each with 5-20 #ifdef, then I suddenly have a lot of source files to worry about. I inherited one of those and the only way I could get it to a level where I could maintain it was to make it far less 'portable' and, as usual, a port never was requested.
your post is even more interesting for me as I am (still) working on porting C167 code to an ARM. I can port most of the following modules without significant changes: queue(s), synchronization primitives, timers, trace buffer, scheduling logic. There are no preprocessor dependencies - all I did was to change most of the basic types used to unsigned long to get rid of some inefficient assembly. I am still struggling with the target specific features that really make the difference - interrupt handling is so different and apart from that, I just HATE making target specific modules that are a salad of many "target specific" functions.
There are no preprocessor dependencies - all I did was to change that is what has beaten a dead horse to a pulp in this thread: the contention that you can port without either having preprocessor directives or making changes.
"...I do not give a hoot about portability..."
"that is what has beaten a dead horse to a pulp in this thread"
Looking back through this thread, it would appear that YOU were the first one to mention it !!??
Why, oh why, oh why then do you insist on writing about it so much?
Before you get on that high horse (yet) again, realise that I just wrote a rhetorical question.
the correct (and complete) quote would be
all I did was to change most of the basic types used to unsigned long to get rid of some inefficient assembly
the nature of the modules that I mentioned is that they are platform independent in the sense that they are pure C implementation. I did put some effort into porting them but the implementation details did not change much. what are suggesting? that I would rewrite (and test...) then all the satisfy my crazed desire to cut off 0.5 microseconds here and there?!
Erik: "you are missing the one I refer to"
Mr. Sprat: "Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable."
No, I wasn't actually missing it. I was more pondering what to do with it. The question here is what "wrapping" means.
Use of #define in itself doesn't ruin an otherwise acceptable program. Standard guarding of header files is an example where we are "expected" to use #define statements.
Abuse of #define can on the other hand (and tend to) produce unreadable code.
The bad thing is that it can be a fine line between the two.
If kept together where I expect to find them, then I, personally, see them as useful. If spread out, I see them as evil.
Maybe Jack uses the word "wrapped" to mean "sprinkled with". Maybe his tolerance level is lower than mine. Some people are of the opinion that the preprocessor should be totally banished. enum and const declarations allows a large number of #define to be replaced with direct language constructs.
Build systems that allows different targets to have different include directories and that allows easy selection of what groups of source files that should be included in the build can remove the need for a lot of (maybe all) #ifdef.
But in the end we fall back to the problem of "portable". Exactly what is the definition of "portable" in the current context?
the contention that you can port without either having preprocessor directives or making changes.
but I did make changes! I never contended not to have made any. The code is generic enough to run reasonably well of any modern 16 bit or better processor. the fact that I don't need the preprocessor nor too extensive changes is a demonstration of portability. It was not my intention to write the best possible, most efficient code. I only wanted to reuse well tested, trusted pieces of functionality. with all due respect, if that does not fit into your perception of efficiency - than you must have a great time rewriting just about anything to win a pico-second here and there. no thanks...
View all questions in Keil forum