Re: [avr-gcc-list] Add builtins in avr target.

[hutchinsonandy]

Why can not this be done with library/inline functions?

Why does delay always have to be constant?

How do we document functionality - for example resolution limitations?

How is this different from IAR?

Andy



-----Original Message-----
From: Anatoly Sokolov <address@hidden>
To: Weddington, Eric <address@hidden>; 
address@hidden
Cc: Andrew Hutchinson <address@hidden>
Sent: Thu, 17 Apr 2008 2:50 am
Subject: 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 0xFFFFFFFF 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list