Faster for() loops?

I'm going to make one and only one attempt to make this clear to you. It's arguably more than you deserve, but if you improve your posting habits it will benefit all of us. If not, we can achieve the same benefit by killfiling you -- which I'm sure many people already have.

We don't discourage top-posting because we like to enforce arbitrary rules. We do so because top-posting makes articles more difficult to read, especially in an environment like this one where bottom-posting is a long-standing tradition. (In other words, top-posting in an environment where it's commonly accepted is ok; top-posting where it's not commonly accepted makes *your* article more difficult to read because we have to make an extra effort to read a different format.)

Usenet is an asynchronous medium. Parent articles can arrive after followups, or not arrive at all. It's important for each individual article to be readable by itself, from top to bottom, providing as much context as necessary from previous articles. It's not reasonable to expect your readers to jump around within your article to understand what you're talking about.

Quoting one of CBFalconer's sig quotes:

A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

See also .

I'm giving you good advice. You can believe me and follow it, or you can ignore it and never be taken seriously here again. It's your call.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  
San Diego Supercomputer Center               
We must do something.  This is something.  Therefore, we must do this.

Well, one thing you seem to have learned is how to avoid getting help when you want it. The convention of bottom posting has been established for a long time and the reasons for it have been discussed here and else where on many occasions, so I'm not going to debate them. Had you taken not of the practices of this group you would have known this.

--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

If saving 50 or even 100 machine code instructions saves you 10% of memory then you only have space for 1000 instructions and would, in my opinion, be better off programming in assembler where you actually have control over what happens. Otherwise you might well find changes in the compiler and library from version to version are more significant.

I would refer you to the above, but based on your response to Brian I'm guessing that you have no consideration for other users of this group. Don't be surprised if this leaves you with only the ignorant to talk to.

--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

If you are working with just 512 bytes of program memory, then you probably should not be writing in C. C as a programming language makes no attempt to mimimize code space. And though it is a matter outside of the standards, most compilers prefer to trade off space for increased speed.

--
These .signatures are sold by volume, and not by weight.

Where is the context? You've got me all twisted up.

I'm reading Usenet articles at the moment. "Depends what..." That's what I am doing. What...?

cache.

OK, I am not doing that at this particular moment. Why are you advising me on my disposition to go for large chunks? I do sometimes "swing the other way" after all. You may hate me, but don't judge me!

I do it all the time. I'm bad, I know, but had to be told. Shame on me.

-- Dan Henry

See

as well.

Thanks,

Al

Oops. I can't spell.

Make that

Al

To Flash and Walter,

Maybe 10% saved for a 1k memory was a bit of an exageration on my part.

I'm currently working with some inhereted AVR GNU that was incomplete, by quite some margin, yet close to the preferred memory limit with decent debug info, and too big to feel comfortable without the debug. Checking out the size differences resulting from alternative ways of writing the same code has resulted in a worthwhile amount of memory being recovered (I believe) - i.e. I'm more relaxed about the situation now. I'm telling the compiler to optimise for size, since speed is not a problem. Of course, if things won't fit at the end, then I'll have to look for other optimisations, such as the assembler suggested. It's unlikely that I'll be forced to switch to a different version of the compiler or libs. Changing the code's architecture and data structures results in bigger savings - I'm almost thru doing that (for other reasons) and it looks like I'll recover over 1k of mem (out of

8k). and the resulting code is cleaner and easier to understand too.

You both probably know this through experience, but one trick I've found of simply making a local copy of a global variable, that is used a fair bit in a function, and then coping it back to the global afterwards saves a reasonable amount of code size, over the more obvious code, that it makes this particular trick worth knowing/trying when things do get tight - it's obviously (to me now) a bigger saving if the global happens to be volatile as well.

I have no personal problem trying these things out if it helps me to understand what the compiler is likely to do with new code that I author (afterall, it takes about 6 minutes to try a little trick out, which means that it'll take about an hour to know 10 new things about the behaviour of the compiler and to recognise oportunities, etc. in the future.) Perhaps at the end of the project, I would have had plenty of room anyway, but, as I said things were tight, I was feeling uneasy, and every time I wanted more debug info, it meant choosing something else for temporary culling which was beginning to make things thorougly difficult.

Things seem to be going 'swimmingly' now - I hope that holds up to the end.

can

Afterall, 50

I'm

found it

Snipping attributions is considered rude. The quoted material starting with "I'm going to make one and only one attempt" is mine. I don't remember who write the line above that.

There is one valid point in the referenced web page (titled "In Defence of Top Posting"):

Bottom posting without snipping irrelevant pats is at least as annoying as a top-post.

Which is why nobody recommends bottom-posting without snipping irrelevant parts.

Apart from that, the argument seems to be based on assumptions about the software people use to read Usenet, and the environment in which it runs.

Once again: Usenet is an asynchronous medium. The parent article may not have arrived yet. It may have expired. It may never arrive at all. I may have read it a week ago and forgotten it, and I very like have my newsreader configured not to display articles I've already read.

A simple command to jump to the parent article is a useful feature in a newsreader, and one that exists in the one I use. I have no idea which other newsreaders have such a command. That's why I try to make each article readable by itself.

Perhaps the most telling point in the web page is:

A Threaded newsreader. These days, pretty much every PC has one.

Not everyone reads Usenet on a PC.

I realize this is cross-posted to comp.lang.c and comp.arch.embedded. Perhaps top-posting is tolerated in comp.arch.embedded. In comp.lang.c, we've reached a general consensus that top-posting is discouraged, for perfectly valid reasons. And even if I *liked* top-posting, I wouldn't do it in comp.lang.c; consistency is even more important than the arguments in favor of a given style.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  
San Diego Supercomputer Center               
We must do something.  This is something.  Therefore, we must do this.

Top-posting is strongly discouraged in comp.arch.embedded as well. It's not as bad as google groups posts that fail to include any context, however, which seems to be considered the worst sin at the moment (I'm not sure where posting in html ranks these days - I haven't seen any html posts here for a while).

David.

If it's less then it is even less worth while.

Which just goes to show that you should concentrate on high level optimisations not micro-optimisations.

I've used processors where it would be one instruction to set up the offset then another to read/write the value for a local as compared to in the worst case a single instruction the same size as that pair of instructions for a global. Of course, the compiler optimisations make this irrelevant with most compilers since they will keep it in a register if it is used much.

If it is volatile you are significantly changing the semantics, so either the original code was wrong or your "optimised" code is wrong.

All that you learn about micro-optimisation on one system you have to forget on the next where your "optimisations" actually make it worse. Also, if your optimisations make the code harder to read you have just increased the cost to the company of maintenance, and since maintenance is often a major part of the cost of SW over its lifetime this is not good.

It would almost certainly have saved you time and effort to restructure the code and optimise the algorithms first (which you say you are doing) since then you would not have found the need for "temporary culling" because you have already admitted that it is saving you a significant amount.

Not really. You included in your message that restructuring is saving you a vast amount of space which is further evidence that you should always start at the algorithm and work down, not start with micro-optimisation.

For continual refusal to post properly despite being informed that top posting is not accepted here...

*PLONK*

--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

If you say so. It seems to me that I've just given myself a bit more memory to play with in a tight situation.

architecture

that

of

Yes, that's correct. It does not mean, so-called micro-optimisations should not be attempted.

of

in

Well, in my case, GNU didn't seem to choose this optimisation - so, the trick saved some bytes - that's indisputable, and as far as I can see, odd that you'd want to dismiss the idea.

it's

volatile

I don't think so. The code is in an ISR. While the ISR is running, the global won't be changed externally. The little trick saved something like

28 bytes and yet the global was only touched twice, if I remember correctly.

However, if someone has a counter example, I would be interested in knowing.

means

of

Perhaps. Yet, for very little effort, I have given myself more room to play with in the current system, I've got a better feeling for the compiler's quirks, and have saved (with just a few micro-optimisations) about 250-bytes (out of 8k) - that's plenty more to extend an existing parameter look up table built into the system in both directions (thus increasing the versitility of the system), or to include more human-readable debug output and even to use more sophisticated code for some other operations that are yet to be written. So, as far as I can see, I've gained by this exercise. I've given myself an advantage, and you are still telling me it was next to worthless because it comes under the lable 'micro-optimisation' or 'premature optimisation' - to me, it's just an achieved gain.

good.

Errm, in this case, I don't think the code is harder to read - it's straighforward C-code - nothing particularly difficult. There are ample comments documenting reasons for some of the slightly none-obvious ways of doing something, along with the 'obvious' code snippet for ready-reference. The code will go into a mass-produced product that is to be thorougly tested before release - maintenance is not an option.

I

more

was

I can't see this. I've positively gained thru this exercise. I have not lost anything.

end.

It looks like I will save about 1k with the restructure (but I cannot tell for sure until I get the full re-structure into the embedded compiler - I'm currently writing and testing the restructured part under Windows). So, the 'micro-optimisations' would amount to another 25% on top of that - hardly a worthless effort, wouln't you say.

It amazes me how some people can claim to speak for the whole group with no documentation at all. I, for one, appreciate top-posting when it is appropriate. At least I won't claim to speak for a whole group who did not elect me to represent them.

-Robert Scott Ypsilanti, Michigan

I don't like top posting.

--
pete

*plonk*

Brian

For the record, I simply don't care. I'm happy to make allowances for all kinds. Life's too short.

Steve

Are you clinically thick? You're /still/ top posting. In CLC thats the height of rudeness. Stop it.

-- Mark McIntyre CLC FAQ CLC readme:

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----

The #1 Newsgroup Service in the World! 120,000+ Newsgroups

----= East and West-Coast Server Farms - Total Privacy via Encryption =----

For what its worth, arguments based on threading are bunk. Thread members arrive out-of-order, not at all, and disappear from servers.

And arguments based on catering for cretinous users who're too thick to snip are hardly likely to impress smart people...

I slightly agree with your conclusions tho. I'd modify (1) and (2) as follows

1) Top Post (and totally remove the old message) if you are only making 1 brief point which has no relation to any of the old message. And then ask yourself why the hell you're replying to this post with an irrelevant remark. 2) otherwise middle post

--
Mark McIntyre
CLC FAQ 
CLC readme: 

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

A little alarm goes off in my brain every time I see an arithmetic variable (bit_ctr) used as the parameter of a logical expression (while).

The following line better expresses what I think you mean: while (--bit_ctr != 0);

The compiler optimizer may well deliver the same machine code for both methods.

And please don't let me get started with the use of NULL pointers in similar situations.