[bug #41435] math library functions in util/delay.h

[avrs-admin]

Sun 02 Feb 2014 05:13:34 PM CET

New version of _delay_ms (the one using __builtin_avr_delay_cycles) uses math functions fabs and ceil.

Code expects that when run on hosted and optimized compilation these calls are optimized away. As this is impossible in freestanding environment there is macro test (__STDC_HOSTED__) and code fallback to old code.

This is kind of ok, but there is possibility to make this otherwise.

Following code works in freestanding environment:

static void _delay_ms(double ms) __attribute__ ((unused));
static void _delay_ms(double ms) {
extern void __builtin_avr_delay_cycles(unsigned long);
extern double __builtin_fabs(double);
extern double __builtin_ceil(double);

double tmp = ((F_CPU) / 1e3) * ms;
uint32_t ticks_dc = (uint32_t)(__builtin_ceil(__builtin_fabs(tmp)));

__builtin_avr_delay_cycles(ticks_dc);
}

As we can see from above, we could use __builtin_fabs and __builtin_ceil in delay.h instead of expecting the compiler to use them.

I think this is better as we already use buildin_avr_delay_cycles which requires build time constant argument, thus we can use __builtin_fabs and builtin_ceil as we know their arguments are built time constant.

This issue was migrated from https://savannah.nongnu.org/bugs/?41435

[avrs-admin]

Cameron Tacklind Tue 04 Jul 2017 11:14:28 PM CEST

This caused a bunch of confusion for me until I realized that ffreestanding was causing _delay_ms to fail to compile for a ATmega32u4 device.

For reference, here are the errors I saw. It took a while to figure out that STDC_HOSTED, set by ffreestanding, was making _delay_ms use old incompatible assembly.

{standard input}: Assembler messages:
{standard input}:19: Error: constant value required
{standard input}:19: Error: register number above 15 required

The above was gcc error output from compiling this simple file:

#include <util/delay.h>
void foobar() {
_delay_ms(1);
}

For reference, this is the output if I tell g++ to just compile to assembly:

.file        "test.cpp"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.text
.global        _Z6foobarv
.type        _Z6foobarv, @function
_Z6foobarv:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(-96)
ldi r25,lo8(15)
/* #APP */
;  110 "c:\program files (x86)\avr8-gnu-toolchain\avr\include\util\delay_basic.h" 1
1: subi r24A,1
brne 1b
;  0 "" 2
/* #NOAPP */
ret
.size        _Z6foobarv, .-_Z6foobarv
.ident        "GCC: (AVR_8_bit_GNU_Toolchain_3.5.4_1709) 4.9.2"

[avrs-admin]

Georg-Johann Lay Wed 05 Jul 2017 10:35:00 PM CEST

> /* #APP */
> ;  110 "c:\program files (x86)\avr8-gnu-toolchain\avr\include\util\delay_basic.h" 1
>        1: subi r24A,1
>        brne 1b
> ;  0 "" 2
> /* #NOAPP */

By no means I can see how __STC_HOSTED__ could get you in "A" after "r24".  The revision logs of delay_basic.h and delay.h[.in] don't mention such a bug, and my builds of 4.9.2 from around that time also look sane.  Also I never came across a GCC bug which added additional "A" junk to operands.

The only issue with this is vor AVR_TINY where register class "w" is empty.

[avrs-admin]

Cameron Tacklind Wed 05 Jul 2017 10:52:03 PM CEST

My mistake. In trying to fix #36611 for myself, I accidently screwed with my delay_basic.h and forgot I had done so. That had the erroneous "A" that was causing my problems.

[sprintersb]

Implemented the proposal as https://github.com/avrdudes/avr-libc/commit/5372e83bac86261345e3a26c3076f8dbb2a2baea.