[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Suggested improvement to <avr/pgmspace.h>
From: |
Marko Mäkelä |
Subject: |
Re: [avr-libc-dev] Suggested improvement to <avr/pgmspace.h> |
Date: |
Mon, 2 Jan 2017 19:32:56 +0200 |
User-agent: |
NeoMutt/20161126 (1.7.1) |
On Mon, Jan 02, 2017 at 05:27:19PM +0100, Georg-Johann Lay wrote:
On 02.01.2017 11:58, Marko Mäkelä wrote:
You can use the __flash address space instead of PROGMEM + pgm_read,
cf.
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
In your case, the function would read:
static void msg (const __flash char *msg)
{
char c;
while ((c = *msg++))
{
UDR0 = c;
loop_until_bit_is_set (UCSR0A, UDRE0);
}
}
The __flash address space is implemented by the compiler as a GNU
extension to the C language, and hence -std=gnu99 (or higher) is
needed.
Thank you, this is much cleaner, and like you pointed out, this allows
portable code to be written when using typedef or #define. I guess
<avr/pgmspace.h> now only exists for backward compatibility with old
code?
I would like to follow up with some avr-gcc or avr-g++ remarks (sorry
for the off-topic discussion).
It looks like avr-g++ does not accept the __flash qualifier. Are there
plans to support it?
There is no guarantee for an optimal code being generated for that
example (as applies to any other C code).
It turns out that the compiled code is identical with my asm-accelerated
version. The entry into the loop looks like this:
ae: 85 91 lpm r24, Z+
b0: 81 11 cpse r24, r1
b2: f7 cf rjmp .-18 ; 0xa2 <main+0x12>
b4: f3 cf rjmp .-26 ; 0x9c <main+0xc>
The above is also emitted for -mmcu=attiny2313. With -mmcu=at90s2313,
the "mov" from the temporary register r0 could be omitted:
48: c8 95 lpm
4a: 80 2d mov r24, r0
4c: 31 96 adiw r30, 0x01 ; 1
4e: 81 11 cpse r24, r1
50: f8 cf rjmp .-16 ; 0x42 <__SREG__+0x3>
52: f4 cf rjmp .-24 ; 0x3c <main+0x8>
Best regards,
Marko