Re: [avr-gcc-list] Add builtins in avr target.
Hi.
__builtin_return_address is extremely useful for target error reporting.
e.g. a function can be called(or trapped) to report error in another
part of program. This allows such routines to determine the address of
the caller without using naked asm functions.
You are correct, that return address will only give 16bit pointer. But
that covers most uses.
It would seem easier to implement than create documents and disable all
current and future testcases that use it. That would seem to be
confirmed by the fact that bug reports have been outstanding since 2005.
Of course, Eric and other AVR users may disagree.
Word or byte address return __builtin_return_address?
I consider that, it will be better that it returned the word address.
For those architectures where it cannot return the correct address, the
__builtin_return_address should be disabled.
+static void avr_init_builtins (void);
+#undef TARGET_INIT_BUILTINS
+#define TARGET_INIT_BUILTINS avr_init_builtins
+void
+avr_init_builtins (void)
+{
+ if (AVR_HAVE_EIJMP_EICALL) // if __builtin_return_address return word
address.
+{
+ disable_builtin_function (return_address);
+}
+}
Anatoly.
___
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.
As before I disagree.
But let Eric and users decide:
1) Should __builtin_return_address() be disable for 256K device. Since
it will only return word not 3 bytes.
2) Should function pointer arithmetic be disabled for 256K device -
since it will only operate on word address.
I think answer should be no. But there should be documented restrictions.
Andy
Anatoly Sokolov wrote:
Hi.
__builtin_return_address is extremely useful for target error reporting.
e.g. a function can be called(or trapped) to report error in another
part of program. This allows such routines to determine the address of
the caller without using naked asm functions.
You are correct, that return address will only give 16bit pointer. But
that covers most uses.
It would seem easier to implement than create documents and disable all
current and future testcases that use it. That would seem to be
confirmed by the fact that bug reports have been outstanding since 2005.
Of course, Eric and other AVR users may disagree.
Word or byte address return __builtin_return_address?
I consider that, it will be better that it returned the word address.
For those architectures where it cannot return the correct address, the
__builtin_return_address should be disabled.
+static void avr_init_builtins (void);
+#undef TARGET_INIT_BUILTINS
+#define TARGET_INIT_BUILTINS avr_init_builtins
+void
+avr_init_builtins (void)
+{
+ if (AVR_HAVE_EIJMP_EICALL) // if __builtin_return_address return word
address.
+{
+ disable_builtin_function (return_address);
+}
+}
Anatoly.
___
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
Re: [avr-gcc-list] Add builtins in avr target.
Anatoly Sokolov schreef: Hello. I have considered all proposals on changing '__builtin_avr_delay_cycles' builtin. Also has added '__builtin_avr_fmul*' builtins. There is one thing that crosses my mind. A user would not only want a voidinterrupt_enable (void) uint8_t interrupt_disable (void) but also a void interrupt_restore (uint8_t) In 99% of the cases interrupt_disable would be used, the user needs an option to restore the interrupt flag to it's previous state. This feature would also make the atomic access builtin set of GCC functions reachable. See http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Atomic-Builtins.html#Atomic-Builtins for more detail. HTH Wouter ___ 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.
Anatoly Sokolov schrieb: Hi. Why can not this be done with library/inline functions? I consider that use builtins allows to realize universal delay function easier. Also use builtins will allow to the same delay funcianality it ADA language. I have no problem in Ada calling inline assembler functions for exactly this purpose. I expect to have a hard time, however, to figure out how to call the builtin function from the Ada front end. I really don't see the benefit of the builtins, neither for C nor for Ada. Rolf ___ 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.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Rolf Ebert Sent: Monday, April 21, 2008 10:24 AM To: Anatoly Sokolov Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Add builtins in avr target. Anatoly Sokolov schrieb: Hi. Why can not this be done with library/inline functions? I consider that use builtins allows to realize universal delay function easier. Also use builtins will allow to the same delay funcianality it ADA language. I have no problem in Ada calling inline assembler functions for exactly this purpose. I expect to have a hard time, however, to figure out how to call the builtin function from the Ada front end. I really don't see the benefit of the builtins, neither for C nor for Ada. If I understand the internals correctly, if we move code from avr-libc inline assembly macros to GCC builtins, then *eventually* the avr back end could call these builtins in code generation as needed. So, in general, I support the idea of having these builtin functions in the avr port at some point. ___ 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] Add builtins in avr target.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Dmitry K. Sent: Thursday, April 17, 2008 9:24 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Add builtins in avr target. On Friday 18 April 2008 12:56, Weddington, Eric wrote: 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. AFAIK, linker relaxation will do JMP-RJMP transformations only. Going the other way is not a size optimization. Alas, not only. Linker relaxation replaces the (R)CALL,RET sequence into (R)JMP,RET. I'm confused. I thought we were talking about constructs like: 3 cycles: rjmp . nop Tail call optimization transforms (R)CALL,RET - (R)JMP,RET as you mentioned above. But again it would not affect the rjmp . as above. Only RCALL. Eric ___ 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.
Hi. Why can not this be done with library/inline functions? I consider that use builtins allows to realize universal delay function easier. Also use builtins will allow to the same delay funcianality it ADA language. Why does delay always have to be constant? If to allow input parameter to be a variable then it will be necessary to perform division in run-time. It to add a unpredictable delay. How do we document functionality - for example resolution limitations? The '__builtin_avr_delay_cycles (unsigneg long __n)' perform a delay of minimum __n cycles. How is this different from IAR? I do not know. Im don't have IAR C installed. Anatoly.___ 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.
Hi. I wish to add: .. 3. builtin similarly to IAR '__delay_cycles'; .. This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin to the avr backend. The 'delay' parameter should be constant. If 'delay' is 1 or 2 then one or two 'nop' instructions is generated. If 'delay' is from 3 to 756 then code: ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. For 'delay' from 757 to 196605 loop is: 1:sbiw Rx,1 brne 1b For 'delay' from 196606 to 83886075 loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 brne 1b And for 'delay' from 83886076 to 0x loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 sbci %D0,0 brne 1b Adding '__builtin_avr_delay_cycles' builtin will allow to remove restrictions on max possible values of parameter for '_delay_us' macro and reduce code size for long delay of '_delay_ms' macro. Also it will simplify porting code from IAR C, if define '__delay_cycles' as '__builtin_avr_delay_cycles'. As you consider, this builtin will be useful? Anatoly.___ 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.
I wish to add:
..
3. builtin similarly to IAR '__delay_cycles';
..
This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin
to the avr backend. The 'delay' parameter should be constant.
The patch attached.
Anatoly.Index: gcc/config/avr/avr.md
===
--- gcc/config/avr/avr.md (revision 134368)
+++ gcc/config/avr/avr.md (working copy)
@@ -52,12 +52,25 @@
(UNSPEC_STRLEN 0)
(UNSPEC_INDEX_JMP 1)
- (UNSPEC_SEI 2)
- (UNSPEC_CLI 3)
+ (UNSPEC_SWAP2)
+ (UNSPEC_FMUL3)
+ (UNSPEC_FMULU 4)
+ (UNSPEC_FMULSU 5)
(UNSPECV_PROLOGUE_SAVES 0)
- (UNSPECV_EPILOGUE_RESTORES 1)])
+ (UNSPECV_EPILOGUE_RESTORES 1)
+ (UNSPECV_SEI2)
+ (UNSPECV_CLI3)
+ (UNSPECV_NOP4)
+ (UNSPECV_SLEEP 5)
+ (UNSPECV_WDR6)
+ (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)
@@ -2751,7 +2764,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 +2773,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 +2873,158 @@
expand_epilogue ();
DONE;
})
+
+;;delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay
+;; delay_cycles
+
+(define_expand delay_cycles
+ [(set (match_operand:SI 0 register_operand =r)
+ (unspec_volatile:SI [(match_operand:SI 1 immediate_operand i)]
+UNSPECV_DELAY_CYCLES))]
+
+
+ rtx loop_reg;
+
+ if (0 == (INTVAL (operands[1])))
+{
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 1, 2))
+{
+ emit_insn (gen_nop ());
+ if (2 == (INTVAL (operands[1])))
+ emit_insn (gen_nop ());
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 3, 756))
+{
+
+ loop_reg =
+ copy_to_mode_reg (QImode,
+gen_int_mode (INTVAL (operands[1]) / 3, QImode));
+ emit_insn (gen_delay_cycles_1 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 757, 196605))
+{
+ loop_reg =
+copy_to_mode_reg (HImode,
+ gen_int_mode (INTVAL (operands[1]) / 3, HImode));
+ emit_insn (gen_delay_cycles_2 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 196606, 83886075))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode (INTVAL (operands[1]) / 5, SImode));
+ emit_insn (gen_delay_cycles_3 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 83886076, 0x))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode (INTVAL (operands[1]) / 6, SImode));
+ emit_insn (gen_delay_cycles_4 (loop_reg));
+
+ DONE;
+}
+ )
+
+(define_insn delay_cycles_1
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES)
+ (match_operand:QI 0 register_operand r)
+ (clobber (match_dup 0))]
+
+ 1:dec %0\;brne 1b
+ [(set_attr length 2)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_2
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_2)
+ (match_operand:HI 0 register_operand w)
+ (clobber (match_dup 0))]
+
+ 1:sbiw %0,1\;brne 1b
+ [(set_attr length 2)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_3
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_3)
+ (match_operand:SI 0 register_operand d)
+ (clobber (match_dup 0))]
+
+ 1:subi %0,1\;sbci %B0,0\;sbci %C0,0\;brne 1b
+ [(set_attr length 4)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_4
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_4)
+ (match_operand:SI 0 register_operand d)
+ (clobber (match_dup 0))]
+
+ 1:subi %0,1\;sbci %B0,0\;sbci %C0,0\;sbci %D0,0\;brne 1b
+ [(set_attr length 5)
+ (set_attr cc clobber)])
+
+;; CPU instructions
+
+;; NOP
+;(define_insn nop
+; [(unspec_volatile [(const_int 0)] UNSPECV_NOP)]
+;
+; nop
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
+;; SEI, Enable Interrupts
+;(define_insn enable_interrupt
+; [(unspec_volatile [(const_int 0)] UNSPECV_SEI)]
+;
+; sei
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
+;; CLI, Disable Interrupts
+;(define_insn disable_interrupt
+; [(unspec_volatile [(const_int 0)] UNSPECV_CLI)]
+;
+; cli
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
Re: [avr-gcc-list] Add builtins in avr target.
Anatoly Sokolov schreef: Hi. I wish to add: .. 3. builtin similarly to IAR '__delay_cycles'; .. This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin to the avr backend. The 'delay' parameter should be constant. If 'delay' is 1 or 2 then one or two 'nop' instructions is generated. For a 2 cycles delays an rjmp can be used. Saves an instruction! If 'delay' is from 3 to 756 then code: ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. For 'delay' from 757 to 196605 loop is: 1:sbiw Rx,1 brne 1b For 'delay' from 196606 to 83886075 loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 brne 1b And for 'delay' from 83886076 to 0x loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 sbci %D0,0 brne 1b That is a high registers usage. 4 register used just for burning cycles? On the other hand burning cycles this way will probably never be used in real code. Adding '__builtin_avr_delay_cycles' builtin will allow to remove restrictions on max possible values of parameter for '_delay_us' macro and reduce code size for long delay of '_delay_ms' macro. Also it will simplify porting code from IAR C, if define '__delay_cycles' as '__builtin_avr_delay_cycles'. As you consider, this builtin will be useful? Yes it is useful, especially the really short ones. Wouter ___ 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.
2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop 4 cycles: rjmp . rjmp . 5 cycles: rjmp . rjmp . nop 6 cycles: rjmp . rjmp . rjmp . All code portions use no more program words than delay loop and not use any register. 7 cycles delay requires four instructions and delay loop is more efficient in code size: If 'delay' is from 3 to 756 then code: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay -- wbr, ReAl ___ 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.
2008/4/17, Oleksandr Redchuk [EMAIL PROTECTED]: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay May be ldi rX, ((delay+1)/3) will be better for small delays -- wbr, ReAl ___ 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.
Hi. 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. 7 cycles delay requires four instructions and delay loop is more efficient in code size: If 'delay' is from 3 to 756 then code: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay Ok. I shall check it. Anatoly.___ 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.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Thursday, April 17, 2008 3:44 PM To: Oleksandr Redchuk; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Add builtins in avr target. Hi. 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. AFAIK, linker relaxation will do JMP-RJMP transformations only. Going the other way is not a size optimization. ___ 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.
On Friday 18 April 2008 12:56, Weddington, Eric wrote: 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. AFAIK, linker relaxation will do JMP-RJMP transformations only. Going the other way is not a size optimization. Alas, not only. Linker relaxation replaces the (R)CALL,RET sequence into (R)JMP,RET. Note, the linker does not differ the C and ASM functions and can spoil the delay routine like: long_delay: rcall . middle_delay: rcall . short_delay: ret or may destroy the program where the 'return to next level' trik is used, like Avr-libc's old (1.4 and early) float library. The Binutils-2.17 makes such replacement unconditionally. The 2.18 has an option to disable it: '--no-call-ret-replacement'. IMHO, such replacement must be disabled by default. Note, GCC for some targets can itself optimize tailing call. This is better, as the second instruction (RET) is deleted. 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] Add builtins in avr target.
Hi. My patch adds avr specific builtins, and has no attitude to GCC standard builtins. See GCC bug #21080: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080 Andy Hutchinson wrote a patch (attached to bug report) to fix this bug which adds support for __builtin_return_address. As far as I can tell, __builtin_return_address is used entirely for tracing, profiling, and error reporting. And practically it is not useful for AVR target. More, this function returns the pointer which is 16-bits on AVR target, hence its value for devices with more than 64KB FLASH will be incorrect. The only practical advantage of this patch to remove 2-3 FALL in GCC testsuite. To make truly a working '__builtin_return_address' now it is not possible. Easier to document '__builtin_return_address' as not supported feature and disable this testcases in GGG testsuite. And to not complicate AVR backend. Anatoly.___ 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.
Anatoly, __builtin_return_address is extremely useful for target error reporting. e.g. a function can be called(or trapped) to report error in another part of program. This allows such routines to determine the address of the caller without using naked asm functions. You are correct, that return address will only give 16bit pointer. But that covers most uses. It would seem easier to implement than create documents and disable all current and future testcases that use it. That would seem to be confirmed by the fact that bug reports have been outstanding since 2005. Of course, Eric and other AVR users may disagree. Andy ___ 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.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Friday, April 04, 2008 2:51 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Add builtins in avr target. Hello. This patch add '__builtin_avr_swap', '__builtin_avr_sei' and '__builtin_avr_cli' builtins in avr backend. It will allow to use 'SWAP', 'SEI' and 'CLI' instructions, without use inline assembly. I wish to add: 1. builtins for 'SLEEP' and 'WDR' instructions; 2. builtins for 'FMUL*' instructions; 3. builtin similarly to IAR '__delay_cycles'; 4. builtin for 'DES' xmega instruction. Your suggestions? See GCC bug #21080: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080 Andy Hutchinson wrote a patch (attached to bug report) to fix this bug which adds support for __builtin_return_address. BTW, Andy has a *lot* of outstanding patches that needs review and possible commit to AVR port. He has been fixing a lot of bugs. I have a list if you need it. Eric Weddington ___ 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.
Unless the builtins expose more information to gcc, I cannot see any benefit from the addins - with the possible exception of FMUL. The result will be the same. No better code, no fewer bugs. Yes there are lots of outstanding patches that fix real bugs. It would seem to me that these are more critical. Andy Weddington, Eric wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Friday, April 04, 2008 2:51 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Add builtins in avr target. Hello. This patch add '__builtin_avr_swap', '__builtin_avr_sei' and '__builtin_avr_cli' builtins in avr backend. It will allow to use 'SWAP', 'SEI' and 'CLI' instructions, without use inline assembly. I wish to add: 1. builtins for 'SLEEP' and 'WDR' instructions; 2. builtins for 'FMUL*' instructions; 3. builtin similarly to IAR '__delay_cycles'; 4. builtin for 'DES' xmega instruction. Your suggestions? See GCC bug #21080: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080 Andy Hutchinson wrote a patch (attached to bug report) to fix this bug which adds support for __builtin_return_address. BTW, Andy has a *lot* of outstanding patches that needs review and possible commit to AVR port. He has been fixing a lot of bugs. I have a list if you need it. Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
