Re: [avr-gcc-list] Don't use gcc 3.4.4, use 4.0.1
E. Weddington [EMAIL PROTECTED] writes: Andy Warner wrote: E. Weddington wrote: [...] I'd like some other issues in GCC 4.x to be cleaned up for the AVR port before including it in WinAVR, especially DWARF2 issues. Here is a list of known AVR GCC bugs: http://rtems.org/phpwiki/index.php/GCCAVRBugs As a Linux-hosted user, is 4.0.1 stable enough for me to spend some time getting to know it ? I'm running 3.4.3 right now, and am very happy with it - but smaller/faster code is always welcome. I'm cool building it all from source. Personally I would still hesitate to use it in any type of production environment because of these two GCC bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21107 Bug #21990 is a wrong code type bug and was submitted by Björn Haase. He stated in the beginning: I have observed a wrong code bug that I judge to be so serious that IMHO one should discourage use of the avr port for 4.x.x until it is resolved. I can't reproduce this bug with current mainline. Denis. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Generating code using sbis, sbic
Hi,
Yes, I understand about integer promotion (although I have never been clear
on all the cases when it applies). However, as far as I understand it,
there is nothing in the C standard that says you *actually* have to promote
to integer - just that the code should work as though it had been promoted.
If all the C code that handles the results of this function only look at the
low byte, then the high byte can be ignored. I'm sure it's possible to
write some horrible code that actually relies on char - int promotion
occuring in a function result, but I don't think it would be a problem for
most sane code. A compiler flag to turn off integer promotion on the AVR
port would be a definite boost to code quality (on 16-bit and 32-bit
targets, however, it could well be a net loss - it would only help on a
target which can't work with integers properly). I guess the other trick,
especially on a Tiny (using no library function), would be to compile
with -mint8.
Anyway, even with the integer promotion, the code is not optimal - is there
no peephole optimisation that would move the ldi r25, hi8(1) above the
test? Better code would be:
test2:
clr r25// If ANSI insists...
clr r24
sbic 54-0x20,1
inc r24
ret
Using c++ like this is an interesting idea - I haven't tried c++ on the AVR
as yet. I guess if you collect some useful little classes like this in a
single header (with the member functions inlined), it should be quite
efficient.
But my real gripe is not so much the code generated for test2 (not optimal,
but not too bad), but with the code generated for test1, which is a complete
mess.
Regards,
David
- Original Message -
From: Haase Bjoern (PT-BEU/EMT) * [EMAIL PROTECTED]
To: David Brown [EMAIL PROTECTED]; avr-gcc-list@nongnu.org
Sent: Thursday, August 18, 2005 7:17 PM
Subject: AW: [avr-gcc-list] Generating code using sbis, sbic
David Brown wrote
But the generated code for test2 itself is:
test2:
sbis 54-0x20,1
rjmp .L9
ldi r24, lo8(1)
ldi r25, hi8(1)
ret
.L9:
ldi r24, lo8(0)
ldi r25, hi8(0)
ret
Hardly optimal (does the result really have to be promoted to an
integer?),
but not bad. The generated code for test1 is extraordinary:
Unfortunately: This integer promotion is prescribed by the c standard.
If you are using c++ you could overcome it by defining a class uint8_c
and by
Specifying this type as return parameter:
#include inttypes.h
class uint8_c {
public:
uint8_c (uint8_t initval)
{
value = initval;
};
uint8_c
operator= (uint8_t initval)
{
value = initval;
return *this;
};
operator uint8_t (void)
{
return value;
};
private:
uint8_t value;
};
uint8_c
test (void)
{
return 1;
}
uint8_t
Test (void)
{
return 1;
}
Yields:
.type _Z4testv, @function
_Z4testv:
ldi r24,lo8(1)
ret
.size _Z4testv, .-_Z4testv
.global _Z5test2v
.type _Z5test2v, @function
_Z5test2v:
ldi r24,lo8(1)
ldi r25,hi8(1)
ret
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Saving space in interrupt handler prologues
I don't know if this has been covered already, but noe way to save space in interrupt handlers is to inline all the functions they call. Obviously is it not always practical, but if the functions are split out mainly for clarity this can be a big win. The main reason is that if the interrupt handler doesn't call *any* other functions it isn't obligated to save the caller-saves registers if it doesn't use them. Also, I think someone else wanted to know why things sometimes did/did not get inlined. gcc tries to be clever about this, so if you want the final say, try this: #define NOINLINE __attribute__ ((__noinline__)) #define YESINLINE inline __attribute__ ((__always_inline__)) Make sure to declare the YESINLINE functions static if you don't want a callable copy for external references. Also, as far a general prologue bloat goes: I may have mentioned this before, but I think a lot of it comes from the fact that AVR GCC generates 16 and 32 bit math in parallel instead of series. For example, something like: int32 a, b, c; a = b | c; becomes: lds r24,b lds r25,(b)+1 lds r26,(b)+2 lds r27,(b)+3 lds r18,c lds r19,(c)+1 lds r20,(c)+2 lds r21,(c)+3 or r24,r18 or r25,r19 or r26,r20 or r27,r21 sts a,r24 sts (a)+1,r25 sts (a)+2,r26 sts (a)+3,r27 when it could be: lds r24,b lds r25,c or r24,r25 sts a,r24 ... using only 2 registers instead of 8. None of the load/store instructions set flag bits, so even math with carry can be done this way. I don't think it's a legitimate peephole optimization (though I haven't pondered it deeply) since qualifiers like 'volatile' would prevent the re-ordering of the memory accesses. -- Ben Jackson [EMAIL PROTECTED] http://www.ben.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Generating code using sbis, sbic
As Haase Bjoern (PT-BEU/EMT) * wrote: IIUC 4.x.x does very much the same as 3.x.x . There is one single place pointed out by Paul Schlie some time ago where you could switch of the promotion rules, however. I didn't mean the promotion rules but the abysmal code generation that occasionally happens when returning a literal 0. See here: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=30960 -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] global variables
Hi!
I have a problem with global variables in my project.
The problem is:
I have file system.c
byte proc_tbl[MAX_PROCESS]; //it's global variable in system.c
void System_Init(void){
int i;
for (i = 0;i MAX_PROCESS; i++)
proc_tbl[i] = NOT_USED;
}
and function
byte Create_Process(void){
int i;
for (i=0; i MAX_PROCESS; i++)
if (proc_tbl[i] == NOT_USED){
proc_tbl[i] = USED;
return(OK);
}
return(ERROR);
}
It's a simplified example, but doesn't work too.
If I call these functions in main.c
System_Init();
Create_Process();
function Create_Process return ERROR permanently.
If global variable proc_tbl is static, it's work fine.
And If I change sequence of linking obj files, system.o is first, It's
work fine too.
Compiling and linking : example for all files
main.o : main.c
$(CC) $(CFLAGS) -Os -c main.c
main.out: main.o all obj files
$(CC) $(CFLAGS) -o main.out main.o all obj files
main_eeprom.hex: main.out
$(OBJCOPY) -j .eeprom -O ihex main.out main_eeprom.hex
main_flash.hex: main.out
$(OBJCOPY) -R .eeprom -O ihex main.out main_flash.hex
CFLAGS=-g -mmcu=$(MCU) -DF_CPU=14.7456E6 -Wstrict-prototypes
-Wunknown-pragmas -O0 -mcall-prologues
and avr-gcc for linux
I don't know what's wrong. Maybe some error with memory.
Do you have ideas?
Thanks.
Tom
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] global variables
Hi!
I have a problem with global variables in my project.
The problem is:
I have file system.c
byte proc_tbl[MAX_PROCESS]; //it's global variable in system.c
void System_Init(void){
int i;
for (i = 0;i MAX_PROCESS; i++)
proc_tbl[i] = NOT_USED;
}
and function
byte Create_Process(void){
int i;
for (i=0; i MAX_PROCESS; i++)
if (proc_tbl[i] == NOT_USED){
proc_tbl[i] = USED;
return(OK);
}
return(ERROR);
}
It's a simplified example, but doesn't work too.
If I call these functions in main.c
System_Init();
Create_Process();
function Create_Process return ERROR permanently.
If global variable proc_tbl is static, it's work fine.
And If I change sequence of linking obj files, system.o is first, It's
work fine too.
Compiling and linking : example for all files
main.o : main.c
$(CC) $(CFLAGS) -Os -c main.c
main.out: main.o all obj files
$(CC) $(CFLAGS) -o main.out main.o all obj files
main_eeprom.hex: main.out
$(OBJCOPY) -j .eeprom -O ihex main.out main_eeprom.hex
main_flash.hex: main.out
$(OBJCOPY) -R .eeprom -O ihex main.out main_flash.hex
I don't know what's wrong. Maybe some error with memory.
Do you have ideas?
Thanks.
Tom
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
