HPs

 HPs

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. (http://en.wikipedia.org/wiki/Adolescence#Psychology)

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" (http://en.wikipedia.org/wiki/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

 RE: HPs

There are postings that are hostile and/or argumentative (I have part of the guilt here) however I, for one do not see the need to hide behind a monniker. I know I should just ignore the smoked sardine and the bratwurst but it is darn tough when they attack my abilities/professionalism.
if they would move ther personal attacks to e-mail, this would be a much more peaceful place.
comments like
But - they won't study program design, they'll only read a 'C' book as a last resort, they learn by trying things to see if they appear to work, if they do - fine, job done. The attitude is so different than the one they take with hardware design, its weird.

So - you're not alone. But you won't be missed by those who have to pick up the pieces when you're gone.

have no merit in the forum and should be relegated to e-mail
I post under my REAL name and if anyone want to write me directly go to http://www.8052.com and use the e-mail gateway there.

Erik Malund

 RE: HPs

I know I should just ignore the smoked sardine and the bratwurst but it is darn tough when they attack my abilities/professionalism.

You can't expect to post whatever you like in a public forum and have it quietly ignored.

if they would move ther personal attacks to e-mail, this would be a much more peaceful place.

Why do you view any disagreement as a 'personal attack'? If you're prepared to expose yourself in public you really must expect responses in public.

comments like [quote] have no merit in the forum and should be relegated to e-mail

Based on what you post that quote seems an accurate reflection of your working practices. Have you ever read the 'C' standard? Would you use a chip without reading the datasheet?

 RE: HPs

Why do you view any disagreement as a 'personal attack'? If you're prepared to expose yourself in public you really must expect responses in public.
I do not wiev disagreements as 'personal attacks' by no means; however phrases like "I am sure your code is not mainatainable" are very personal attacks for two reasons a) you can not possibly know if it is and b) that has nothing to do with the subject of the thread. Thus, since it has nothing to do with the thread it can not be anything but a personal attack.

Based on what you post that quote seems an accurate reflection of your working practices.
The very point showing that what you post is personal.

An impersonal attack would be based on facts, not what something seems to be to you.

Erik

 RE: HPs

An impersonal attack would be based on facts, not what something seems to be to you.

Ok, let's establish some facts:

Have you ever read the 'C' standard?

Would you use a chip without reading the datasheet?

 RE: HPs

Have you ever read the 'C' standard?

Would you use a chip without reading the datasheet?

yes (I have a K&R somewhere) and no, of course not (it would be impossible)

That I am much more concerned with "Keil '51 C" than the utterly stupid concept of insisting on "Real C" on a '51 is another thing.
If, in Keil C, a 'for' was called a 'because' I would not have a problem, (you would have cow, I'm sure) that to me would just be "Keil '51 C" and that it was not "real C" would be no concern of mine.
I work with the tool I have, and know that tool, I could not care less what other similar tools do.

Erik

PS I do not give a hoot about portability, that would come under the heading "real C", not "Keil '51 C"

 RE: HPs

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)"?

and no, of course not (it would be impossible)

Why the difference?

That I am much more concerned with "Keil '51 C" than the utterly stupid concept of insisting on "Real C" on a '51 is another thing.

Maybe pseudocode will help:

ISO (formerly ANSI) Standard 'C' == Keil 'C'.

I know you don't like it, but you will have to accept it. Quite what you mean by 'Real C' I've no idea.

If, in Keil C, a 'for' was called a 'because' I would not have a problem

Again, ISO (formerly ANSI) Standard 'C' == Keil 'C' so that is not a possibility.

(you would have cow, I'm sure)

Er, what?

that to me would just be "Keil '51 C" and that it was not "real C" would be no concern of mine.

Again, ISO (formerly ANSI) Standard 'C' == Keil 'C'.

I work with the tool I have, and know that tool, I could not care less what other similar tools do.

Unfortunately you don't seem to even know what the tool is. Again, ISO (formerly ANSI) Standard 'C' == Keil 'C'.

PS I do not give a hoot about portability

Yes, I know you're proud of your stance on that issue.

that would come under the heading "real C", not "Keil '51 C"

Again, ISO (formerly ANSI) Standard 'C' == Keil 'C'. That is real 'C'.

 you conveniently ignore

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

 RE: you conveniently ignore

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?

"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

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.

 RE: you conveniently ignore

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.

Erik

 RE: you conveniently ignore

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?

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.

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.

Really? Which ones?

 RE: you conveniently ignore

Ah, glad to see you agree with me. Use a faster processor.

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.

 RE: you conveniently ignore

a) "I care about efficiency"

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.

Really? Which ones? a) above for example.

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.
translated "if cost is an issue, do not involve the person hiding behind "Jack Sprat", he cares more about his fanciful ideas"

Erik

 RE: you conveniently ignore

Really? Which ones? a) above for example.

You seem to be saying that my statement:

"I care about efficiency <snip>"

Contricts my other statement:

"Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable"

You are very confused.

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"

Sensible design isn't a fanciful idea.

Oh, have you decided yet whether my assertion that you haven't read the 'C' standard remains baseless?

 RE: you conveniently ignore

Really? Which ones? a) above for example.

You seem to be saying that my statement:

"I care about efficiency <snip>"

Contricts my other statement:

"Wrapping code in preprocessor directives doesn't make it portable - in fact, it makes it clear that it is non-portable"
if you do not "Wrap code in preprocessor directives" it can never be portable by the "sardine standard" and efficient. e.g. if you do not have a preprocessor directive for using 'bit' when running on a '51 your code is not efficient. Did that bend it in neon so you can see it? One one hand you claim the efficiency is not important, on the other you calim that the "sardine standard code" is not inefficient

You are very confused.
here you go again making statements about me that you have no background for making.

I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is.
so, "sensible design" makes effciency irrelevant. I have always thought that "sensible design" was efficient desitgn.

Sensible design isn't a fanciful idea.
by most peoples definition no, by yours yes

Erik

 RE: you conveniently ignore

if you do not "Wrap code in preprocessor directives" it can never be portable by the "sardine standard"

No. I said that wrapping code in preprocessor directives indicates that it is not portable. The preprocessor directives do not make non-portable code portable. Please try to understand this.

One one hand you claim the efficiency is not important, on the other you calim that the "sardine standard code" is not inefficient

No. Please re-read my comments on efficiency. The world is not black and white - there is only worth in making code efficient if it needs to be efficient, otherwise it is better to write it with portability and clarity as the foremost priorities. If you want to consider this further please take a look at my response to your comments about malloc() further down this thread.

I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is.

so, "sensible design" makes effciency irrelevant. I have always thought that "sensible design" was efficient desitgn.

There are many factors to consider in a sensible design - development cost, maintainability, reliability to name but a few. Perhaps you could do with broadening your horizons a little?

 RE: you conveniently ignore

WOW, only a small insult at the end, I think this one deserves a civil answer.
if you do not "Wrap code in preprocessor directives" it can never be portable by the "sardine standard"

No. I said that wrapping code in preprocessor directives indicates that it is not portable. The preprocessor directives do not make non-portable code portable. Please try to understand this.
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?

Please re-read my comments on efficiency. The world is not black and white - there is only worth in making code efficient if it needs to be efficient, otherwise it is better to write it with portability and clarity as the foremost priorities.
even in a situation where code does not need to be efficient I would go, at least, half the way in making it efficient. I have had to do an almost total rewrite of an inherited project that was "efficient enough" till an added beature was requested. I do disagree with your implication that efficient code can not be reasonably portable and fully maintainable.

I care about efficiency where efficiency is the most important factor. With sensible design, however, it rarely is.

so, "sensible design" makes effciency irrelevant. I have always thought that "sensible design" was efficient desitgn.

There are many factors to consider in a sensible design - development cost, maintainability, reliability to name but a few. Perhaps you could do with broadening your horizons a little?
in addition to what I replied to the previous quote which applies here as well: re "development cost, maintainability, reliability", again, you make the asssumption that because I mention one point, I am ignorant of the remaining. I do my utmost to make what leaves my desk or my lab efficient, maintainable and reliable. As far as development cost, that is a function of anticipated production volume. I hope with the above to have clarified that I do not need "broadening your horizons a little". If you still ASS U ME so, that will be your problem.

Erik (real name)

 RE: you conveniently ignore

You are very confused.

here you go again making statements about me that you have no background for making.

Well, either you are confused or are deliberately misunderstanding a quite simple point.

Any more thoughts on whether my apparently baseless assertion about your knowledge of the 'C' standard remains baseless?

 it is baseless

Any more thoughts on whether my apparently baseless assertion about your knowledge of the 'C' standard remains baseless?
1) it is baseless if you mean 'none' not if you mean "can be recited completely without the document".
2) what concern of yours is it whether I read the C standard as my bedside litterature or use it as a reference?
3) 'assertion', I appreciate your choice of word http://www.thefreedictionary.com/assertion "a positive statement, usually made without evidence" however, some of your statements in this regard have bee quite a bit more than 'assertions'

Erik

 RE: it is baseless

'assertion', I appreciate your choice of word

Sorry, I was actually trying to quote you. I meant to say 'baseless accusation':

Any more thoughts on whether my apparently baseless accusation about your knowledge of the 'C' standard remains baseless?

 RE: you conveniently ignore

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, http://www.merriam-webster.com/dictionary/example see 3)

Erik

 RE: you conveniently ignore

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, http://www.merriam-webster.com/dictionary/example see 3)

Gosh, I had 5 definitions to choose from! Ok, but you think number 3 might suit your purpose:

"one (as an item or incident) that is representative of all of a group or type"

Here we go:

I'd be unlikely to have designed my way into a situation where anything of the group or type represented by a bit operation rather than a byte operation would make the difference between project success and project failure.

 OH BOY,

OH BOY, after posting that 'bit' is but an example, you write:
I'd be unlikely to have designed my way into a situation where anything of the group or type represented by a bit operation rather than a byte operation would make the difference between project success and project failure.
I stated (clearly to all but you) that using 'bit' was an example of where adapting code to a particular processor/compiler would affect efficiency.
I am not going to waste my time on listing other examples if you do not know what they (or, at least, most of them) are, you will be lost anyhow. Then on the other hand since you state that efficiency is unimportant what would you care. I am sure the processor makers love you for buying a more expensive (faster, bigger) derivative than anyone else would need, just to make the code fit the "sardine standard"

Erik

PS do you do CAN

 RE: OH BOY,

I stated (clearly to all but you) that using 'bit' was an example of where adapting code to a particular processor/compiler would affect efficiency.

An example, according to your favoured definition, is representative of a group or type. You are now arguing that what you presented as an example is not representative of what you meant. This makes no sense.

 bit and the ARM

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?

 RE: bit and the ARM

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!

 RE: bit and the ARM

#if C51
  typedef bit Flag;
#else
  typedef unsigned char Flag;
#endif

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"

Erik

 RE: bit and the ARM

evidently you are supposed to make your code portable without using "preprocessor directives"

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.

 RE: bit and the ARM

* 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.

 verbiage

* 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.
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".

Erik

 RE: verbiage

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.

 RE: verbiage

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.

Erik

 RE: verbiage

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.

 easy when you control both ends

Experienced developers packs/unpacks all data themselves when sending the data on communication links or keeping non-volatile data.
easy when you control both ends, I do not.
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.
please define 'raw' ?
Transmitted or stored data should be described by a 100% complete document
it is, of course, how else could i use it?

erik

 Forced to disagree

Vince,
To me, the only criterion here is whether the "offending" posts are of value in terms of their informative content. Yes, some heated debated resulted in insults exchanged, but if that is how the untainted truth is brought to the surface, so be it! Indeed, it is sometimes more pleasant to be part of a relaxed academic discussion, but I think that the colourful figures in this forum add a lot to it beyond professional authority.

 RE: Forced to disagree

But it doesn't change the fact that in a full-out war, there will only be loosers.

Focusing posts on attacking other people is so very counter-productive. Just about every outsider will hate both sides for making trouble.

 RE: Forced to disagree

Tamir,
After posting it, I was starting to think the same thing... it does provide some color (not colour, as only retards like yourself write it that way---get the ironic humor there?), to the forum. I just don't like wasting my time reading stupid things. I know it sounds odd since I write the long 'novelistic' posts. But when that person writes these lame barbs at you guys, while providing very little value to the discussion at hand, it takes its toll. I guess if *that* person had some worth-while nuggets of wisdom, I wouldn't have been irritated enough to make this thread. So, that gets most of you guys off the hook when taking jabs at each other.

I guess I just rewrote what you just posted... I could have just said "Agreed" but I have a hard time keeping things terse.

Oh, and Per,
"Agreed"

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 spelling

color (not colour, as only retards like yourself write it that way ---get the ironic humor there?)

Appreciate the "ironic humor" however you do (humourously) make all Brits retards

Thus when you have a flat in England, you better ask someone to get the spare tyre out of the boot or your face will achieve a red colour because nobody will understand you otherwise.

Erik

 RE: nobody will understand you

Oh, we will understand - and pity you...!

;-)

 RE: nobody will understand you

...you do (humorously) make all Brits retards...
Correction erik... All those Brits did that themselves: I didn't make them become that way.

;-)

And thanks for the pity... I need it.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

Well during one of our weekly meetings, "Jed" and I got into a simple disagreement on a Rule about header files.

Go on then - what was the disagreement?

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.

Unfortunately some respondents habitually reply with posts which are rude, unhelpful, opinionated, inaccurate or even downright misleading. If I can correct some of this I will.

I'm amused by the mental picture you've developed of me but I will have to dissapoint you somewhat - you're well off the mark in most respects.

I've justified myself at length in the past - please search my posting history to learn more.

Tell me - do you think software should be treated as an engineering discipline? Do you think software writers should properly learn to use their tools? Would you expect them to be apparently proud of not doing so?

And, I hope his "Mea Clupea" (http://en.wikipedia.org/wiki/Mea_culpa) will be a silent one

If you're going to try chucking bits of Latin in for effect it's best try and spell them correctly.

 talking about yourself now again?

Unfortunately some respondents habitually reply with posts which are rude, unhelpful, opinionated

Erik Malund (who do not hide who he is, because he is willing to stand by what he writes as opposed to some others)

 And my 10 cents worth

"Unfortunately some respondents habitually reply with posts which are rude, unhelpful, opinionated"

As someone who listens to posts on this forum rather than one who normally posts, I see an interesting picture from the text of a few profligate posters.

There certainly are a few posters who undoubtedly have strong egos and there is at least one that appears to post in the manner of "I do it this way and it is the right way and any other way is wrong".

So what if one certain person "is willing to stand by what he writes as opposed to some others". That style alone cannot make the person right and nor does the fact that the same person makes frequent posts.

The style has the effect of making that person appear to be authoritative to some others - Oddly, it would appear to have this effect on fellow posters that clearly have equal and probably better knowledge.

Don't get me wrong, the person in question obviously has some experience and he does occasionally impart it in a sensible manner; but it frequently goes too far and ends up with personal views being expressed in a way that makes them sound factual.

I, for one, am glad that some people stand up to obviously biassed, misleading and incorrect responses.

 RE: HPs

what was the disagreement?

It was a simple 'rule' ... I said "header files shall contain no executable code" He said otherwise. (He was also a MACRO freak too... I was the one who insisted that we needed coding standards because of his odd coding styles).

Engineering Discipline? Yes, it should. Codemonkeys knowing their tools? Yes, they should. Proud of ignorance? No, they shouldn't.

I'm glad you can correct some of the 'misleading' unhelpful, opinionated, etc, posts. Let me check on that 'rudeness' factor now... "chucking bits of Latin for effect..." I think it had its intended effect.

Misspelling occurs all of the time on forums, and most of us will excuse it. Some people will pick at it as if it will score them points for 'correctness.' Others will poke fun at it, without malice. But indeed, it was kind of you to point 'it' out.

Are you absolutely sure I misspelled it? Do your research, and get back to me. We wouldn't want our readers to think that you haven't done your homework before making a jab at my spelling in an attempt to "one-up" me on a 'spelling error.'

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

I said "header files shall contain no executable code" He said otherwise.

Can you guess which side of that particular fence I live on?

Let me check on that 'rudeness' factor now... "chucking bits of Latin for effect..."

Did you think that was rude? I apologise. It was a bit off the cuff.

I think it had its intended effect.

I assumed it was intended to add a little gravitas to your apparent wish that I should not reply to your post.

Misspelling occurs all of the time on forums, and most of us will excuse it.

Yes, I ignore English misspellings unless I cannot make sense of what the poster is trying to say.

Are you absolutely sure I misspelled it? Do your research, and get back to me.

Is this a serious question, or ar you herring me on?

We wouldn't want our readers to think that you haven't done your homework before making a jab at my spelling in an attempt to "one-up" me on a 'spelling error.'

Given the context it seemed fair game.

 RE: HPs

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

 RE: HPs

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.

 your biggest failing is your biggest contribution!

Please do keep on posting the same long, elaborate, detailed, knowledgeable and enlightening posts!

 RE: HPs

Both 'brisling' vs 'bristling' and 'clupea' vs 'culpa' were non-accidents. I was going out of my way in not directly naming the poster.

I figured that the savvy regulars would see it as you did Per. And that this particular person would get it too, and silently take heed, or possibly admit fault (hence, mea culpa)... but I was hoping for both.

This way I would not be in a position to do what he often does, and start some flame-war. Uhm, about spelling I guess. Oh, the irony! (note the difference between humorous and bits of Latin... git it?)

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

Both 'brisling' vs 'bristling' and 'clupea' vs 'culpa' were non-accidents.

I didn't credit you with that level of subtlety. Mostly I find myself struggling to read the lines round here rather than read between them.

I was going out of my way in not directly naming the poster.

I think any regular reader, savvy or not, would know who you were talking about without spotting the fishy references.

This way I would not be in a position to do what he often does, and start some flame-war.

Throwing out bait like that is a pretty standard way of trying to start a flame war...

 RE: HPs

Right, right my little droog. Sounds like its a wrap then.

(and BTW, I enjoyed your last two posts)

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 vindication of free speech

This is an open forum, which bared a certain cost. People can and do occasionally post mistakes (me included) and personal opinions are sometimes introduced as facts. These can be attributed to the shortcomings of people in general and software developers in particular. So, I am big supporter of the freedom of expression here, even by trolls (excluding really annoying people that hijack posts and the like). So I don't think that Jack Sprat is a troll. Not at all. The fact that he posts contentions opinions certainly contributes to the level of the technical debates here, as far as I can judge!

 Off-topic header (ab)uses

"I said 'header files shall contain no executable code'"

Before C++ templates, I would (almost) have agreed with this one. But the C++ standard have more or less forced this issue - any template function must have the implementation visible to the compiler by at least one source file that is making use of the function with the specific template parameters.

The end result is that STL has huge amounts of code in the header files. Not nice, but needed.

Besides the C++ template functions, there could still be advantageous to declare a number of small inline functions in a header file. I prefer inline functions instead of #defined code expansions.

If often create an inline_<target>.h file with a number of tiny helper functions to make my code less bound to the hardware.

 RE: HPs

Right, right my little droog.

Dream on.

--Cpt. Vince Foster

Why the military affectation, I wonder? Ego trouble?

 RE: HPs

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 often email my peers with links to these threads, and we relish reading them. If nothing else, they're often a great source of entertainment. So easy to find too... just look for the huge number of replies.

Of course, I sometimes learn things from them too, or am prompted to do some relevant independant study.

Whoever said engineers were boring...? Flame on!

 RE: HPs

I often create an inline_<target>.h file

Per, you wanna step outside and settle this?!

The catch-all escape-clause for all of those rules was to have the Project Manager sign off on any waivers to The Standard. So in your case, it would have required you to fill out forms MS-1781, SE-0112, and then of course ECR-100.

After a review of your peers, an ECO may have been signed and then it would have generated an ECN. Only then could you include your in_line.h file. And after that, an NCAR form would have been written to satisfy the team of 'inspectors.' (Basically, I made it hard to deviate from the standard... most likely due to my huge ego troubles)

Dream on

*sniff* You are a meanie.
(Ref: http://www.keil.com/forum/docs/thread12822.asp)

Ego trouble?

Yes.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

But at least I have a computer - you can't catch me at a late stage of my application process by noting that my triplicates are not enough. Life must have been a real bitch when you had to fight with huge sets of carbon paper duplicates ;)

Somewhere in the process there might be a bean counter that I can swing over on my side by claiming 'saved money', 'unchanged code run on multiple hardware platforms (possibly the next that hasn't had the money granted yet)', 'faster time-to-market by testing substantial parts of the code on off-the-shelf hw'.

If I can't produce selling (and hopefully believable) arguments, then I can't have spent enough time pondering the need/advantages of an inline_<target>.h file, and should obviously have my application rejected. This world has already seen enough code produced "just because", with no real thought behind.

When we know that well-designed software regularly fail, it's a wonder that we survive all the crappy code out there. Space avionics may seem like the ultimate challenge but a single little bad line of code in an ABS system may quickly destroy an otherwise perfect day. Or my mobile phone, that managed to move a meating to an earlier date, but kept the alarm reminder...

 is that "meeting in the slaughterhouse" :

meating
Not critisizing you, just found it funny :)

Erik

 RE: is that "meeting in the slaughterhouse" :

No, luckily for me I noticed the missing alarm, but even if I would have missed the meeting I think I would have survived with just a brief comment from the CEO about the value of meeting discipline. Threatening with "meating" me would probably not help me meat my deadlines ;)

 RE: HPs

"That I am much more concerned with "Keil '51 C" than the utterly stupid concept of insisting on "Real C" on a '51 is another thing."

That is a bit dangerous. Keil has made some deviations (because of puny stack and no real 16-bit support in the chip) and some extensions (because of need for different processor instructions to address different blocks of memory and because of bit variables etc).

But besides that, Keil is a C compiler, which means that Keil to the best of their knowledge tries to follow the C standard. If you have grown used to how it works, and a bug is found where the compiler unintentionally deviates from the standard, then it is likely that a new version of the compiler will correct this bug.

If you assumed that the previous version of the compiler was "the reference" and continues to write software based on how you learned that the Keil compiler worked, then your new and old code can suddenly fail.

If you knew the language standard by heart, you would not have been caught off-guard, because you would be able to notice if the compiler did deviate from the standard in a way that Keil hasn't explicitly documented. Before coding for this behaviour, you would be able to contact Keil and ask them why the compiler does something unexpected.

Right now, you think that your C51 is wonderful. But if there is suddenly a need to create a product with a different processor architecture, your knowledge about the specific Keil C51 deviations would be worth zero. If you are not aware about exactly how the standard requires signed and unsigned variables to be treated, you may create the nastiest of bugs if/when you have to develop for a general-purpose 16-bit or 32-bit chip.

When mixing signed and unsigned variables and working with sub-int variable types, it is absolutely vital to know the difference between what the compiler does and what the standard required.

 different tools, different rules

But if there is suddenly a need to create a product with a different processor architecture, your knowledge about the specific Keil C51 deviations would be worth zero.
different tools, different rules.
the point is that if Keil had a 'because' instead of a 'for' (deliberately chosen ridiculous difference) then when you work with Keil, you use 'because' whatever the standard states.
If you use a different compiler, you work with the rules for that compiler. all the wunnerful stuff about "the C standard" is fine and dandy, the point is that what you should work with is how your tool behaves, not with some 'standard' that might and might not apply.

An I saying that knowing the standard is worthless, by no means, just that whining about nonstandard 'features' or 'differences' implemented to match the processor you happen to use is ridiculous. Also, ignoring an extermely useful feature (e.g. Keil '51 BIT) for the sake of "the standard" is going around designing the project the wrong way.

Erik

PS I have worked (succesfully) with, at least, 5 different compilers and, at least 4 different processor architectures, and, in all cases, applied the "it is better to work with your tool than some 'standard' that might and might not apply.

 RE: different tools, different rules

Erik,

Don't you think that if tool vendors would have had this slogan ticking in their head...

the point is that what you should work with is how your tool behaves, not with some 'standard' that might and might not apply.

our industry would have never reach ANY coding standards whatsoever?

 you totally misunderstand

the point is that what you should work with is how your tool behaves, not with some 'standard' that might and might not apply.

our industry would have never reach ANY coding standards whatsoever?
of course, any tool should adhere to existing stndards as far as possible/practical but here are a couple of examples of what I mean:
For the benefit of "PC programmers" Keil '51 can do malloc() ARGH, have you seen how it works in the little resource starved '51?
To make use of the unique facilities of the '51 Keil has introduced the BIT variable type.

fully adhering to the standard you would use malloc() and never use BIT which would be plain unadulterated stupidity.

Erik

 RE: you totally misunderstand

For the benefit of "PC programmers" Keil '51 can do malloc() ARGH, have you seen how it works in the little resource starved '51?

not for the C51, but for the C166. It looked like world war three!

 RE: you totally misunderstand

For the benefit of "PC programmers" Keil '51 can do malloc() ARGH, have you seen how it works in the little resource starved '51?

Let's take two programs that perform the same job exactly as per the project requirements. The one that uses malloc() is more readable, easier and quicker to write, less prone to suffering subtle bugs and easier to maintain.

Which is better?

fully adhering to the standard you would use malloc() and never use BIT which would be plain unadulterated stupidity.

The standard doesn't require you to use malloc(). It doesn't even require malloc() to be implemented. Oh, and it doesn't prevent you from using 'bit'.

 RE: HPs

Life must have been a real bitch when you had to fight with huge sets of carbon paper duplicates ;)

The real problem was that this "Jed" guy wrote such horrendous code that I had refused to work with him until we had standards. Management agreed, and in an effort to corral him until the project was done, we implemented the draconian policies. As soon as the project was done, "Jed" no longer reported to work... for some reason. (He made it past his 'outburst' by a few months)

This world has already seen enough code produced "just because", with no real thought behind.

Human Safety Factors are always paramount, and once you have gone down that road (either from military, aerospace, medical, automotive, or industrial equipment projects), those habits might help you when you code-up that "My Little Notes" iPhone application. Hopefully that code won't lose the medical records that customers like to carry around with them to their trip to Mozambique ... and hence, that non-Human Safety Factored project became life-saving app. Or not.

And yes, we are now way off topic. We must think of Dave Sudolcan and his Keil Thread Worshipers. They might become irritated and become a whole school of smoked sardines. And we all know how those sprats like to communicate:

http://www.newscientist.com/article.ns?id=dn4343&print=true

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

Erik: Once, many years ago, I worked with C. Or C++. K&R designed something called C. Bjarne Stroustrup played with something called C++. There was even the old cfront program that converted C++ to C, just since many architectures had good (or at least existing) C compilers.

My language reference was to a large part the Borland Turbo C/Turbo C++ manuals, or whatever information I could bring up about the early GNU C compiler (run on a Sun).

I didn't mind that Turbo C and gcc differed a bit. I could live with that, and whenever code for some strange reason failed to compile, or did produce unexpected results, I could figure out why or how to get around it.

Writing code for segmented 16-bit processors or a 32-bit linear address spaces wasn't so much different, after I realized that a 'bus error' meant 'me bad' (for people who don't like latin terms :p ).

ANSI C felt like some dusty work by some abstract people I didn't much cared about. As long as I could learn how to get code through both Turbo C and gcc and get them to print similar results, I was happy.

I had mostly left C and where busy with C++ (or working with old C compilers) when ISO/IEC 9899 was adopted. But by that time, a lot had happened with C++. We got exceptions, RTTI etc. Initially, I felt that the changed scope rule for "for" statements was the most compatibility-breaking change. And all compilers where in a big flux either trying to catch up, or already having implemented most of the features based on preliminary suggestions (possibly incompatible with the finally accepted definitions). It really became important to look into the ISO C++ standard, since it's the official map for all the compiler vendors.

After starting to read the standards, it suddenly became clear that the standards are not strange beasts living their own lifes. The used language is quite clear. And they have a level of detail that the compiler vendor manuals are not even close to reach, and couldn't/shouln't try to match.

Just as the datasheets for hw components, they represent the ultimate description about the tools we are using. You not only get information about the "what", but from the text you can deduce _why_ the standard requirements looks as they do.

When you see a hw question here, you may think that the OP is a fool for not being able to pick up the answer from the datasheet within seconds to minutes. But with experience, you have learned to master datasheets and know what to look for, and where to look. But have you spent the same time getting comfortable with the _real_ datasheet for your compiler?

The standards do know about architectural differences. They do know that C and C++ compilers may need extra data types or extra attributes (such as xdata) added to variable declarations.

So how do you know if your compiler vendor is well-versed in the standard? Hint: If your code suddenly breaks or you get release notes claiming that such a compiler-specific attribute suddenly binds in a different way in comparison to a previous version of the compiler.

Turbo C had far, near and huge pointers. That was specific to the x86 architecture, but not much have changed. If the compiler vendor knows the standard, they can add an xdata attribute and you will know if you should write the word first on the line, or before the star, or after the star or after the variable name. The far, near and huge attributes has survived the x86 era. Some compilers may have far, some compilers may have _far, and some may have __far. But the declaration still looks the same.

To you, xdata is a violation of the C standard, and a reason to ignore the standard. To me, the standard has already told Keil how to implement the xdata extension in a way that I will understand if it binds to the left or to the right.

(to be continued)

 RE: HPs

(continued)

The standard is not about forcing a compiler vendor into producing carbon-copy products, all being "exactly" identical and totally limited by hard rules. It is about making sure that all common parts of the different compilers behaves exactly as you expect they should. And the standard makes sure that extensions are added in a way that makes the extensions logical super-sets of the language.

Do get the C standard. It isn't expensive. Whenever you see a thread discussing syntax problems - pick up the standard and try to find the relevant sections. If you do, then you will notice that the answers are clearly writen and easy to find.

And that any such thread could actually be summed up as a RTFM, just as questions about "how do I initialize my watchdog?". If RTFM is a good answer is a separate issue, but the reason people ask questions is because they haven't read the correct documentation. If it us because they don't know what to read, doesn't understand the language or are lazy is a separate issue. But for anyone to be able to answer (knowing the answer and not just assuming they know the answer), some people really must have spent the time reading the ultimate datasheet.

A huge number of questions to this forum is because people haven't spent time with the documentation. But whenever people gets links to the Keil documentation, it is important to note that the Keil documentation isn't complete. It is just an addendum to read as follow-up to the ISO C standard.

When I initially coded C, everything was obvious. A + B could only mean one thing. But that isn't true. If you look at the standard, it spends a lot of paragraphs on explaining what the compiler must do to make sure that you don't get surprised when you try A + B. The standard worries about A being signed and B being unsigned, or A and B having different sizes. And it worries about the case when you assign the answer to a variable of different size. There are so many small details needed to get C to look obvious and generate "obvious" results.

Whenever the compiler vendor miss-reads the standard, you as the end user will get a big nose-bleed. If you know the standard, you know where the compiler vendor has erred. If you don't know the standard, you may assume that you did something wrong.

All changes Keil has made to their C51 compiler are so very tiny compared to the language standard, that it is more or less a non-issue. If you throw away the actual declaration and just look at the code using the sbin data type, it will look like standard C. It will almost fully behave as standard C. It will almost be portable. That the data type is sbit doesn't mean much for portability since the real portability issue isn't the sbit type but how another processor controls a port pin.

Following the standard isn't a question about allowing sbit or not. The most important part when it comes to the standard is if sbit is signed or not, and what happens if you try to assign -1, 0, 1 or 2 to it, i.e. if the behaviour follows the behaviour of the rest of the language, just as it is important to know what result you get (or if it will be undefined) if you assign a value from an int or unsigned int into a signed or unsigned char.

It isn't really the C standard that controls how portable a program is. It is more a question about how you access the actual hardware, or how you handle your variables. A program can be highly portable, while being written for a specific architecture if 95% of the source is generic and located in one set of files, and the last 5% is target-specific and located in different files. And the code can be very efficient. Or it can be portable by using #define blocks (but I don't much like #define blocks because of readability issues).

On the other hand, you can write code where every single line of code is intentionally written for the target architecture. But the code can still be very inefficient.

Portable and efficient are not mutually exclusive. In some cases you can have both. In some cases you can't.

For me, portable is to a large part how easy you can move the code to a different target, and how easy can you make sure that the ported code will produce the same results.

Your design controls how easy you can adapt the code for a different target. Your understanding of the C/C++ standards and "standard" portability issues such as size of an int, or byte order, affects how hard it will be to get the expected results out of the ported code.

Your projects may be so special that you have made the decision that you don't have to spend any time on making the design portable, and instead spend any design time into managing to get the hw to dance for you. But you should still spend time on the language side of portability, since that very much defines how portable _you_ are. Can _you_ be moved to a different architecture, and after reading the datasheets for the new processor start to produce working code? And will the code work because _you know_ that it will work, or because you run it an saw the result you hoped to see?

 RE: HPs

Per, Excellent post. Well said, well thought-out, and well executed.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: HPs

Your projects may be so special that you have made the decision that you don't have to spend any time on making the design portable, and instead spend any design time into managing to get the hw to dance for you. But you should still spend time on the language side of portability, since that very much defines how portable _you_ are. Can _you_ be moved to a different architecture, and after reading the datasheets for the new processor start to produce working code?

Per, anything will be more or less portable. I have reused code across platforms and will state as I have before "to port non-portable code is less effort than making the original code portable", not the least because at the time you write the original code, you usually do not know what it might be ported to some day. As an example if you write some code in C51 should you make the effort of making it portable to SDCC.

And will the code work because _you know_ that it will work, or because you run it an saw the result you hoped to see?
as far as I am concerned if it works for any reason except "the code work because _I know_ that it will work" it does not work whatever the result of a 'test' might show. The internet is flooded wirh 'working' code that only works under the exact same circumstances as those of the original 'developer'.

Erik

PS vocabulary
portable: code that without any change will compile and work when compiled by C51 SDCC and GNU
non-portable: code that require nominal changes tto work when compiled by C51 SDCC or GNU

 RE: HPs

On this whole portability thing, I'm glad erik provided the glossary of terms, because when erik points out that portable code is rare, he is right in his definition of terms. I don't think ANY embedded professional would expect to write in pure "C". It would be simply smashing if they do.

All processor variants and their cohorts in the IDE business will have special options for squeezing every last performance drop out of the final executable code.

Be it speed or space, the need to optimize your code is driven by us, the customer. Imagine a pure "C" compiler (no deviations from the standard at all) for the 8051. To eek core performance out of it, we would complain about the gyrations we would need to go through to achieve 'assembly level' performance, and if they (Keil) would only provided a "C" variant extension called 'bit' or 'xdata' or 'data' like their competitor does, we'd be happy. We would be able to eek that performance out and be happy.

So they do. And so does their competition, etc. But as Per points out, at least these deviations are only a stones throw away from the main road/path that The Standard has carved out. And of course going from one processor to the next are still only a stones throw way from each other on the "C" level. Without knowledge of The Standard, how can any embedded professional determine if that stone was thrown, or shot out of a Howitzer?

I prefer to know my tools well, but at the same time, I don't want to NEED to know the tool in order to complete a task or project. If that Howitzer deviation must be taken, then I get a bit aggravated. Especially when I want my code to last years, and not be boxed into a corner due to a highly specific compiler path that cannot be logically reworked for a new or different compiler or even a new or different processor.

I consider it portable if there is 'minimal' impact on the code and 'minimal' impact on the coder to go from one platform to another. Centralizing the non-portables or high-risk code helps, and trying to write the code closer to the 'pure' C environment aids in making code portable.

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.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 as I said in an earlier thread

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

 RE: as I said in an earlier thread

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

 trials and future litigation

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 ?

 RE: trials and future litigation

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)

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: trials and future litigation

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...

 RE: trials and future litigation

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 :)

 RE: trials and future litigation

"...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.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 RE: trials and future litigation

Also, I am primarily an electrical engineer and then a software engineer.

That was already clear from code you posted in another thread and your descriptions of your development technique.

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.

Scary.

I do believe that I am on the correct side of the war (and any war the US engages in)

Er...

and with justification.

Oh well, that's ok then.

 origin

Vince please, you have people here hurtling at each other stuff like "smoked sardine"
please note
http://query.nytimes.com/gst/abstract.html?res=9F02E1DF153DE633A25757C1A96E9C94669ED7CF
defines 'sprat' as a queer fishy thing.

Erik

 added

and I did not come up with that monniker (Sprat)

 RE: added

erik,

Nice catch there.

When you browse through the "queer 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.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

 bit fields slow

"[...] 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.

 RE: bit fields slow

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.

 the origin is x86 i.e. a PC

and I doubt the endianness will change there.

and there are no bitfields, just #defines of 'masks'

Erik

 RE: HPs

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 queer fishy th