Comments on: Efficient C Tips #3 – Avoiding post increment / decrement http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/ Thoughts on embedded systems by Nigel Jones Fri, 10 Feb 2012 14:37:44 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Raul http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-13483 Raul Wed, 25 Jan 2012 13:59:27 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-13483 Thank you! Thank you!

]]> By: Nigel Jones http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-13462 Nigel Jones Wed, 25 Jan 2012 00:19:10 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-13462 IAR seems to have removed the original article. I have replaced the link with another one that gives a better explanation (also from IAR :-)) IAR seems to have removed the original article. I have replaced the link with another one that gives a better explanation (also from IAR :-) )

]]> By: Raul http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-13449 Raul Tue, 24 Jan 2012 16:56:50 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-13449 Hi, Thank you for your great articles! The link to IAR website is broken. Can you fix it please? Thanks again. Hi,

Thank you for your great articles!

The link to IAR website is broken. Can you fix it please? Thanks again.

]]> By: Lundin http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-2818 Lundin Wed, 01 Dec 2010 07:46:56 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-2818 I can't recall a CPU where this would actually matter for efficiency reasons. The real issue here is that *ptr++ may be hard to read. C's operator precedence rules are far from obvious, and that's the main reason you should avoid it. There's also the issue with order of evaluation: if you write *ptr++, then you might be tempted to write the classic C bug *ptr = *ptr++, which relies on the implementation-defined order of evaluation (and is banned by MISRA-C). For this reason, professional programmers never use the ++ operator together with other operators ever. I can’t recall a CPU where this would actually matter for efficiency reasons. The real issue here is that *ptr++ may be hard to read. C’s operator precedence rules are far from obvious, and that’s the main reason you should avoid it.

There’s also the issue with order of evaluation: if you write *ptr++, then you might be tempted to write the classic C bug *ptr = *ptr++, which relies on the implementation-defined order of evaluation (and is banned by MISRA-C). For this reason, professional programmers never use the ++ operator together with other operators ever.

]]> By: Nigel Jones http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-2811 Nigel Jones Tue, 30 Nov 2010 16:42:50 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-2811 Thanks for the information Mark - I was not aware of this. Thanks for the information Mark – I was not aware of this.

]]> By: MarkM http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-2810 MarkM Tue, 30 Nov 2010 16:39:56 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-2810 PowerPC specifically has instructions that support an addressing mode (the "U" instructions) where pre-increment/pre-decrement is provided for free in the load/store instruction itself. There is no equivalent post-increment/post-decrement instruction. PowerPC specifically has instructions that support an addressing mode (the “U” instructions) where pre-increment/pre-decrement is provided for free in the load/store instruction itself. There is no equivalent post-increment/post-decrement instruction.

]]> By: Murray http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-52 Murray Wed, 27 Jan 2010 19:39:17 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-52 On GCC with an ARM7tdmi it seems to make no difference at all. However, if you use "uint32_t i;" or "register uint32_t i;" for your local variable declaration, you see a significant size reduction and a speed increase. On GCC with an ARM7tdmi it seems to make no difference at all. However, if you use "uint32_t i;" or "register uint32_t i;" for your local variable declaration, you see a significant size reduction and a speed increase.

]]> By: Mike Layton http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-51 Mike Layton Tue, 26 Jan 2010 09:39:39 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-51 If you read K&R (the original C) you find that they were motivated to make the language as terse as possible--as I recall, to allow transmission at eg. 300 baud. I don't recall hearing a case where terse code is more optimal for space or speed (with or without optimization). Most of the time I'm adding code to insure optimization. If you read K&R (the original C) you find that they were motivated to make the language as terse as possible–as I recall, to allow transmission at eg. 300 baud. I don't recall hearing a case where terse code is more optimal for space or speed (with or without optimization). Most of the time I'm adding code to insure optimization.

]]> By: ashleigh http://embeddedgurus.com/stack-overflow/2008/08/efficient-c-tips-3-avoiding-post-increment-decrement/comment-page-1/#comment-50 ashleigh Tue, 26 Jan 2010 00:53:49 +0000 http://www.gfcdev.org/test-stack/2008/08/01/efficient-c-tips-3-avoiding-post-increment-decrement/#comment-50 I've had many long arguments with C programmers who insist that *ptr++ WILL ALWAYS be better / faster / whatever. And I've never come across a case yet where it unambiguously is so.Check the generated code!Avoiding these operators also makes the code much more readable. I've had many long arguments with C programmers who insist that *ptr++ WILL ALWAYS be better / faster / whatever. And I've never come across a case yet where it unambiguously is so.Check the generated code!Avoiding these operators also makes the code much more readable.

]]>