RE: [avr-gcc-list] Illegal opcode errors building gcc-4.2.3
-Oorspronkelijk bericht- Van: Rick Mann [mailto:[EMAIL PROTECTED] Verzonden: zaterdag 19 april 2008 19:49 Aan: Wouter van Gulik Onderwerp: Re: [avr-gcc-list] Illegal opcode errors building gcc-4.2.3 On Apr 19, 2008, at 7:28 AM, Wouter van Gulik wrote: This is because binutils 2.18 does not support avr architecture 35. Use binutils 2.18.5 or more recent. Search the gcc mailing list for some more info. If your are building for linux maybe you should take a look at the linux build scripts sticky post on http://www.avrfreaks.net/index.php? name=PNphpBB2file=viewtopict=42631 You need to be logged in to actually download the scripts. These script are for 4.2.2 I finally realized I had to be logged in to find those. I build for Mac OS X, using a script I made myself, but it does not apply patches (it makes the mistaken assumption that recent GCC versions actually work out-of-the-box for AVR). My script also builds GDB and AVaRICE. I don't see a binutils-2.18.5 where I normally look: http://ftp.gnu.org/gnu/binutils/ Is there another place I should be looking? ftp://sourceware.org/pub/binutils/snapshots It is the snapshot. I do not know if the current version is broken for the AVR. I finally used your scripts and got a toolchain working that supports the ATmega324P (the need that triggered all this). Thank you for those. The scripts are not mine. That would be to much credit. But it is good to know your setup works. HTH, Wouter Ps please use reply-all next time, so it gets to the list, just in case someone else has the same problem. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Latest working versions (ATmega324p)?
On Apr 18, 2008, at 1:29 PM, Weddington, Eric wrote: FSF stock 4.3.0 is broken for the AVR port. You have to have a slew of patches to get code generation right. See the patches (gcc, binutils, others) that come with the WinAVR 20080411 package. Thanks. Maybe the right question to ask is, which GCC supports atmega324p? avarice 2.7 knows this part number, but GCC 4.1.2 does not. Thanks! -- Rick ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] winavr 20080411 and atmega324p
Does the latest winavr work with the mega324p right out of the box? I saw there are patches in the source folder - do they have to be installed? If so, which patches in order to make the 324p work? I install those patches with patch patchname right? I tried that and I get error messages that the target file can not be found. I googled this and it seems there are no instructions on how to do that exactly on winavr, also the manual does not mention anything about it. Maybe I do not have to install any patches to make it work? I tried some code on the mega324p and it seems to be broken. I tried with a friend but we couldn't get any code run properly on that mcu with the latest winavr yet. thanks ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Upgraded and re-compiled a current project and a function was converted to in-line and a function.
Hi. I just installed WinAvr-20080411 and re-compiled a recent project (lab4a). I was surprised that the code increased by almost 400 bytes (lab4b). Looking into the reason I see that the compiler generated my EEPROM_read function and then started generating the function in-line in all of the places I called it. Any reason for this? Use '--param inline-call-cost=2' the GCC switch. Without 'inline-call-cost': $ avr-size main.elf textdata bss dec hex filename 1756 260 1342150 866 main.elf With 'inline-call-cost': $ avr-size main.elf textdata bss dec hex filename 1370 260 1341764 6e4 main.elf Anatoly.___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Optimizer appears broken in WinAVR-20080411
Wouter van Gulik wrote: -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:avr-gcc- [EMAIL PROTECTED] Namens Ray Hurst Verzonden: zondag 20 april 2008 2:07 Aan: avr-gcc-list@nongnu.org Onderwerp: [avr-gcc-list] Optimizer appears broken in WinAVR-20080411 I recompiled a recent project with the latest WinAVR and was surprised that the code uncreased by almosy\t 400 bytes. Upon investigation as to why I releaized the compile was in-lining my functions instead of calling them. Project attached Any reason for this? The optimizer is inlining to strong like you said. I don't know why. I have experienced the same problem. My bootloader size almost doubled because of this :(. For some quick solution I use the tips found here: http://lists.gnu.org/archive/html/avr-gcc-list/2008-04/msg00081.html For me the size went back to usable again. HTH, Wouter Thanks, -fno-inline-small-functions did the trick. Looks like the optimizer is a little better. Ray ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
Hello.
I have considered all proposals on changing '__builtin_avr_delay_cycles'
builtin. Also has added '__builtin_avr_fmul*' builtins.
Anatoly.Index: gcc/config/avr/predicates.md
===
--- gcc/config/avr/predicates.md(revision 134489)
+++ gcc/config/avr/predicates.md(working copy)
@@ -27,6 +27,11 @@
(and (match_code reg)
(match_test REGNO (op) = 16 REGNO (op) = 31)))
+;; Registers from r16 to 24.
+(define_predicate fmul_register_operand
+ (and (match_code reg)
+ (match_test REGNO (op) = 16 REGNO (op) = 24)))
+
(define_predicate even_register_operand
(and (match_code reg)
(and (match_test REGNO (op) = 31)
Index: gcc/config/avr/avr.md
===
--- gcc/config/avr/avr.md (revision 134489)
+++ gcc/config/avr/avr.md (working copy)
@@ -52,12 +52,26 @@
(UNSPEC_STRLEN 0)
(UNSPEC_INDEX_JMP 1)
- (UNSPEC_SEI 2)
- (UNSPEC_CLI 3)
+ (UNSPEC_SWAP2)
+ (UNSPEC_FMUL3)
+ (UNSPEC_FMULS 4)
+ (UNSPEC_FMULSU 5)
(UNSPECV_PROLOGUE_SAVES 0)
- (UNSPECV_EPILOGUE_RESTORES 1)])
+ (UNSPECV_EPILOGUE_RESTORES 1)
+ (UNSPECV_SEI2)
+ (UNSPECV_CLI3)
+ (UNSPECV_NOP4)
+ (UNSPECV_NOP2 5)
+ (UNSPECV_SLEEP 6)
+ (UNSPECV_WDR7)
+ (UNSPECV_DELAY_CYCLES 100)
+ (UNSPECV_DELAY_CYCLES_1 101)
+ (UNSPECV_DELAY_CYCLES_2 102)
+ (UNSPECV_DELAY_CYCLES_3 103)
+ (UNSPECV_DELAY_CYCLES_4 104)])
+
(include predicates.md)
(include constraints.md)
@@ -2367,13 +2381,6 @@
(const_int 1))
(const_int 3)])])
-(define_insn nop
- [(const_int 0)]
-
- nop
- [(set_attr cc none)
- (set_attr length 1)])
-
; indirect jump
(define_insn indirect_jump
[(set (pc) (match_operand:HI 0 register_operand !z,*r))]
@@ -2751,7 +2758,7 @@
;; Enable Interrupts
(define_insn enable_interrupt
- [(unspec [(const_int 0)] UNSPEC_SEI)]
+ [(unspec_volatile [(const_int 0)] UNSPECV_SEI)]
sei
[(set_attr length 1)
@@ -2760,7 +2767,7 @@
;; Disable Interrupts
(define_insn disable_interrupt
- [(unspec [(const_int 0)] UNSPEC_CLI)]
+ [(unspec_volatile [(const_int 0)] UNSPECV_CLI)]
cli
[(set_attr length 1)
@@ -2860,3 +2867,230 @@
expand_epilogue ();
DONE;
})
+
+;;delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay
+;; delay_cycles
+
+(define_expand delay_cycles
+ [(unspec_volatile [(match_operand:SI 0 const_int_operand i)]
+ UNSPECV_DELAY_CYCLES)]
+
+
+ rtx loop_reg;
+
+ if (IN_RANGE((INTVAL (operands[0])), 0, 6))
+{
+ switch (INTVAL (operands[0]))
+{
+case 0:
+ break;
+case 1:
+ emit_insn (gen_nop ());
+ break;
+case 2:
+ emit_insn (gen_nop2 ());
+ break;
+case 3:
+ emit_insn (gen_nop ());
+ emit_insn (gen_nop2 ());
+ break;
+case 4:
+ emit_insn (gen_nop2 ());
+ emit_insn (gen_nop2 ());
+ break;
+case 5:
+ emit_insn (gen_nop ());
+ emit_insn (gen_nop2 ());
+ emit_insn (gen_nop2 ());
+ break;
+case 6:
+ emit_insn (gen_nop2 ());
+ emit_insn (gen_nop2 ());
+ emit_insn (gen_nop2 ());
+ break;
+}
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[0])), 7, 765))
+{
+
+ loop_reg =
+ copy_to_mode_reg (QImode,
+gen_int_mode ((INTVAL (operands[0]) + 2) / 3,
+ QImode));
+ emit_insn (gen_delay_cycles_1 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[0])), 767, 196605))
+{
+ loop_reg =
+copy_to_mode_reg (HImode,
+ gen_int_mode ((INTVAL (operands[0]) + 2) / 3,
+ HImode));
+ emit_insn (gen_delay_cycles_2 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[0])), 196606, 83886075))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode ((INTVAL (operands[1]) + 4) / 5,
+ SImode));
+ emit_insn (gen_delay_cycles_3 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[0])), 83886076, 0x))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode ((INTVAL (operands[0]) + 5) / 6,
+ SImode));
+ emit_insn (gen_delay_cycles_4 (loop_reg));
+
+ DONE;
+}
+ )
+
+(define_insn delay_cycles_1
+ [(unspec_volatile
Re: [avr-gcc-list] the framepointer
On Saturday 19 April 2008 23:26, you wrote: The save around call will not use R18 upwards, as these are call clobbered. You'r right. Without studying source and compiler RTL and optimisation level used I cannot say why it did not use a lower register. It may be the cost assumptions are not quite right for a low number of slots compared to reg push/pops.. Maybe this is a little dumb, but i asked the compiler with -fomit-frame-pointer explicitly to not use the frame pointers if avoidable. Then it should not weight any costs, it should simply do push/pop for one variable (or use a lower register). Even if it is much more expensive. Only when it is not avoidable it should use framepointers, but if you do not explictly alloc some space and your functions are not to complex/long this should be rare. Thus, in my view this is not a matter of optimization. My knowledge of the gcc internals is near to zero so i have a hard time finding the right spots to analyze this. Any comments appreciated. The reason you don't have RTL prolog/epilog is that it takes forever to get patches approved. I think I wrote it in 2005 for 4.1 ! Argh! And i thought our goverment was slow greetings Ruud. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Illegal opcode errors building gcc-4.2.3
On Sunday 20 April 2008 01:28, Wouter van Gulik wrote:
[...]
../../gcc/config/avr/libgcc.S:280: Error: illegal opcode movw for mcu
avr3
[...]
This is because binutils 2.18 does not support avr architecture 35.
Use binutils 2.18.5 or more recent.
More exactly: this is because binutils 2.18 does not support
the MOVW instruction with architecture 3.
The simplest workaround (if you are not happy to install new
binutils) is to add '-mall-opcodes':
Replace into 'config/avr/avr.h' the string:
#define ASM_SPEC %{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}
to:
#define ASM_SPEC %{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3 -mall-opcodes;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}
Regards,
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Illegal opcode errors building gcc-4.2.3
On Apr 20, 2008, at 2:29 PM, Dmitry K. wrote:
More exactly: this is because binutils 2.18 does not support
the MOVW instruction with architecture 3.
The simplest workaround (if you are not happy to install new
binutils) is to add '-mall-opcodes':
Replace into 'config/avr/avr.h' the string:
#define ASM_SPEC %{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}
to:
#define ASM_SPEC %{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3 -mall-opcodes;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}
Thank you for the suggestion.
Would you mind giving me a little lesson in how that ASM_SPEC works?
(I'm trying to learn more about GCC in general).
Also, how can I find out which patches need to be added to a given GCC
release? For example, 4.3.0 is out, and if I wanted to make that work,
how would I find out if it works for AVR and if not, are there are
patches for it?
Thanks again!
--
Rick
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
