[avr-gcc-list] Re: avr-gcc optimisation

2009-02-28 Thread Nicholas Vinen
avr-gcc-list-requ...@nongnu.org wrote: >>> OK, I only spent a few minutes looking at old code and I found some >>> obviously sub-optimal results. It distills down to this: >>> >>> #include >>> >>> int main(void) { >>> unsigned long packet = 0; >>> >>> while(1) { >>> if( !(PINC & _BV(PC2))

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Vincent Trouilliez > Sent: Saturday, February 28, 2009 7:41 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Vincent Trouilliez
On Sat, 28 Feb 2009 19:24:38 -0700 "Weddington, Eric" wrote: > You wouldn't need *nested* ifs, but an if-else-if structure, or better yet, a > table of function pointers, also known as a dispatch table. Each method > depends on the type of data that you're switching on. I switch on an unsigned

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Vincent Trouilliez > Sent: Saturday, February 28, 2009 7:20 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Vincent Trouilliez
On Sat, 28 Feb 2009 19:09:13 -0700 "Weddington, Eric" wrote: > So in application code I tend to avoid switch statements for embedded > systems, unless I'm writing throw-away code or the application is trivial. Oh no ! ;-) I have only recently got round to using switch statements, to improve cod

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Bob Paddock > Sent: Saturday, February 28, 2009 6:40 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-li

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Bob Paddock
>  In practice, the experienced programmer can do a lot to help > the tools. avr-gcc *does* do a good job with most code - I do > much less re-structuring of my source code for avr-gcc than I do > for most other compilers (I use a lot of compilers for a lot of >different > targets). Something I a

[avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread David Brown
Georg-Johann Lay wrote: David Brown schrieb: Nicholas Vinen wrote: OK, I only spent a few minutes looking at old code and I found some obviously sub-optimal results. It distills down to this: #include int main(void) { unsigned long packet = 0; while(1) { if( !(PINC & _BV(PC2)) ) {

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Georg-Johann Lay
David Brown schrieb: Nicholas Vinen wrote: OK, I only spent a few minutes looking at old code and I found some obviously sub-optimal results. It distills down to this: #include int main(void) { unsigned long packet = 0; while(1) { if( !(PINC & _BV(PC2)) ) { packet = (packet<<

Re: [avr-gcc-list] Re: sprintf

2009-02-28 Thread David VanHorn
> > Unless your "big iron" guys are similarly inexperienced (being a beginner > is a good excuse for many mistakes), then they are incompetent. There is > *no* excuse for a knowledgeable programmer using an inefficient and unsafe > function in such a horribly unclear manner I disagree, but I'm

[avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread David Brown
Nicholas Vinen wrote: OK, I only spent a few minutes looking at old code and I found some obviously sub-optimal results. It distills down to this: #include int main(void) { unsigned long packet = 0; while(1) { if( !(PINC & _BV(PC2)) ) { packet = (packet<<1)|(((unsigned char)PIN

[avr-gcc-list] Re: sprintf

2009-02-28 Thread David Brown
David VanHorn wrote: > has exactly the same effect as: > > A_String[i] = 0xff; > A_String[i + 1] = 0x00; > delay_about_1000_processor_cycles(); > waste_about_2000_bytes_of_code_space(); ROTF ! :- As was earlier, and more gently poin

RE: [avr-gcc-list] Re: sprintf

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of David Brown > Sent: Saturday, February 28, 2009 12:49 PM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-list]

[avr-gcc-list] Re: sprintf

2009-02-28 Thread David Brown
Daniel O'Connor wrote: On Saturday 28 February 2009 09:00:50 David Kelly wrote: On Fri, Feb 27, 2009 at 10:37:30PM +0100, Vincent Trouilliez wrote: On Fri, 27 Feb 2009 22:10:16 +0100 David Brown wrote: sprintf((A_String + i), "%c", 0xff) has exactly the same effect as: A_St

Re: [avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Radoslav Kolev
Hi Eric, thanks for the extremely fast replies! On Sat, Feb 28, 2009 at 9:09 PM, Weddington, Eric wrote: > Used this command line: > avr-gcc -Os -mmcu=atmega8 -c ATmegaBOOT.c -DF_CPU=800UL -o ATmegaBOOT.o > No warnings, no errors. > Using avr-gcc 4.3.2. I have found the problem in my Makefi

RE: [avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Radoslav Kolev > Sent: Saturday, February 28, 2009 11:55 AM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-li

RE: [avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Radoslav Kolev > Sent: Saturday, February 28, 2009 11:55 AM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-li

[avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Radoslav Kolev
On Sat, Feb 28, 2009 at 8:09 PM, Weddington, Eric wrote: > Are you including or ? Yes, is included. I'm attaching the complete .c file. > And please stop using inb() and outb(). They have been removed from avr-libc > and are not necessary. Just use a regular assignment. I know. I didn't writ

RE: [avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Radoslav Kolev > Sent: Saturday, February 28, 2009 10:51 AM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-li

[avr-gcc-list] just 2 bytes allocated for uint32_t?

2009-02-28 Thread Radoslav Kolev
Hello! I wanted to rebuild the Arduino Atmega8 bootloader using avr-gcc 4.2.2, installed from the Ubuntu 8.04.1 packages. At first I run against the problem of 4.x gcc versions producing bigger code, compared to 3.x versions that doesn't fit in the 1k boot loader space. The bug report is here htt

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Saturday, February 28, 2009 10:09 AM > To: Weddington, Eric > Cc: Nicholas Vinen; avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] Re: C vs. assembly performance > > Weddington, Eric schrieb: > > BTW, is

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Georg-Johann Lay
Weddington, Eric schrieb: -Original Message- From: avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. org] On Behalf Of Georg-Johann Lay Sent: Saturday, February 28, 2009 9:00 AM To: Nicholas Vinen Cc: avr-gcc-l

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Georg-Johann Lay > Sent: Saturday, February 28, 2009 9:00 AM > To: Nicholas Vinen > Cc: avr-gcc-list@nongnu.org

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Georg-Johann Lay
Nicholas Vinen schrieb: Georg-Johann Lay wrote: If you are sure it is really some performance issue/regression and not due to some language standard implication, you can add a report to http://sourceforge.net/tracker/?group_id=68108 so that the subject won't be forgotten. Also mind http:

RE: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Nicholas Vinen > Sent: Saturday, February 28, 2009 6:21 AM > To: partha_nay...@yahoo.com > Cc: avr-gcc-list@nong

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Nicholas Vinen
Georg-Johann Lay wrote: > If you are sure it is really some performance issue/regression and not > due to some language standard implication, you can add a report to > http://sourceforge.net/tracker/?group_id=68108 > > so that the subject won't be forgotten. Also mind > http://gcc.gnu.org/b

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Nicholas Vinen
Georg-Johann Lay wrote: > compiling the following code > unsigned char sh4 (unsigned char x) > { > return x >> 4; > } > > unsigned char sh8 (unsigned short x) > { > return x >> 8; > } > > with avr-gcc 4.3.2 and -Os yields (non-code stripped) > > sh4: > swap r24 ; > andi r24,lo8(

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Nicholas Vinen
Parthasaradhi Nayani wrote: > >> From: Nicholas Vinen >> > > For example, things like "unsigned char x, y; > >> x = y>>4" could >> use the nibble swap instruction rather than four shifts, >> and things like >> > > Shifting a byte or int right or left must push in 00s from the othe

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Georg-Johann Lay
Nicholas Vinen schrieb: * On the other hand, it would be great if avr-gcc could perform some basic optimisations that even a fairly inexperienced amateur could manage. For example, things like "unsigned char x, y; x = y>>4" could use the nibble swap instruction rather than four shifts, and things

Re: [avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Parthasaradhi Nayani
> From: Nicholas Vinen For example, things like "unsigned char x, y; > x = y>>4" could > use the nibble swap instruction rather than four shifts, > and things like Shifting a byte or int right or left must push in 00s from the other side so swapping a nibble is not the right thing to do. So

[avr-gcc-list] Re: C vs. assembly performance

2009-02-28 Thread Nicholas Vinen
> If I wanted fast and small, I'd have done it in ASM. But half of the point > of this exercise was to get my feet wet with C. > So, both points accomplished. I have GCC up under AVR studio, a working > project, and I feel reasonably confident with the code. > Despite avr-gcc being fairly dim a