[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: hutchinsonandy
Subject: Re: [avr-gcc-list] Add builtins in avr target.
Date: Thu, 17 Apr 2008 09:02:08 -0400

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?


-----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.


  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

As you consider, this builtin will be useful?


AVR-GCC-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]