Re: About the clang/llvm tool chain for AVR

[Georg-Johann Lay]

I am current maintainer of the llvm-avr backend, and I would like to ask
for your feedback on my work. My final goal is making
clang-llvm-lld-compiler_rt chain fully functional, and let AVR program
developers get rid of the GNU tool chain. So any complain/concern/report
is welcome.


As you are asking for feedback, here are my 4 points:

1. As far as I know, clang is using (parts of) avr-gcc installations.
When clang/llvm want to stand on its own feet, the tools should be
self-containing instead of parasitic.

2. There is no equivalent of attribute progmem.  You may argue that
clang has attribute address_space which is superior to progmem.
This is true but misses the point:  When users are supposed to
switch tool chains, then the transition should be as seamless
as possible.  Just replacing progmem with address_space will raise
hundreds of warnings per project for thousands of developers.
I'd rather be not the one facing the storm which that would raise.

3. There are still lots of bugs, in particular at the low end (asm).
My impression is that the clang developers are not eating their own
dog food.  On the upside, bug are fixed in a timely manner, much faster
than the average avr-gcc bug.  But I have to admit that after a dozen
or so inline asm bugs, I lost interest in supporting or even just
bench-marking clang in projects.

4. AFAIK, clang cannot be used to build AVR-LibC.  How is that supposed
to work if clang wants to replace gcc, I don't see.

Finally, when clang is mature enough, it could be an IDE option for
users to pick, stay or revert as they please.  So IDE maintainers are
the right address, IMO.

Johann

Re: ATmega3208

[Georg-Johann Lay]

Hi, I think this has been applied a week ago or so:

https://github.com/avrdudes/avr-libc/commit/afb1ffdb8e35065f7fb5317bb6693311f5eec7a5

Johann


Am 06.02.24 um 13:46 schrieb Jürgen Appel via Discussion of avr-libc 
development:

Hej,

Some time last fall I had trouble using my atmega3208 and traced this back to
a series of typos in devtools/gen-avr-lib-tree.sh and but had no time to
submit this patch upstream.

Now that my hotfix got overwritten with a faulty package from my distributor
again, I think it's more than due time to write to you in the hope that this
helps others to solve the same problem:


--- doc/api/Makefile.old2023-09-12 13:47:58.776696628 +0200
+++ doc/api/Makefile.am 2023-09-12 13:48:11.936871715 +0200
@@ -68,7 +68,7 @@
  
  USER_MANUAL  = @AVR_LIBC_USER_MANUAL@
  
-DEMO_LIBS= $(shell cd $(top_srcdir) && find `pwd` \( -name

crtm8.o -o -name exit.o \) -print | grep avr4)
+DEMO_LIBS= $(shell cd $(top_srcdir) && find `pwd` \( -name
crtm8.o -o -name exit.o \) -print | grep avr4/)
  # As avr-gcc must have been installed already, we can reference its
  # library by a -l option.
  DEMO_LIBS+= -lgcc
--- devtools/gen-avr-lib-tree.old   2023-09-12 17:54:40.974963202 +0200
+++ devtools/gen-avr-lib-tree.sh2023-09-12 17:57:32.977116083 +0200
@@ -351,12 +351,12 @@
  attiny3224:crttn3224.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
  attiny3226:crttn3226.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
  attiny3227:crttn3227.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny1608:crtm1608.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny1609:crtm1609.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny3208:crtm3208.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny3209:crtm3209.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny4808:crtm4808.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
-attiny4809:crtm4809.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS}\
+atmega1608:crtm1608.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+atmega1609:crtm1609.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+atmega3208:crtm3208.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+atmega3209:crtm3209.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+atmega4808:crtm4808.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+atmega4809:crtm4809.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS}\
  "
  
  AVRXMEGA4_DEV_INFO="\



Cheers,
Jürgen

Re: About the clang/llvm tool chain for AVR

[Georg-Johann Lay]

Am 15.01.24 um 04:53 schrieb Ben Shi via Discussion of avr-libc development:

Dear AVR-libc developers,

I am current maintainer of the llvm-avr backend, and I would like to ask for 
your feedback on my work. My final goal is making clang-llvm-lld-compiler_rt 
chain fully functional, and let AVR program developers get rid of the GNU tool 
chain. So any complain/concern/report is welcome.


Is it possible to build AVR-LibC with clang?

Johann



Current known issues:

1. The clang frontend still does not support float-64 type and int24 type.
2. The clang frontend does not support virtual functions in C++ classes.
3. The 32-bit mul/div are not supported in compiler-rt, though 8-bit/16-bit 
ones are supported.
4. The lld should have support all functionality compared to GNU-ld. (There may 
be bugs, but it should be quite stable.)
5. The lld accepts all syntax of GNU linker script, except 
'KEEP(SORT(*)(.ctors))', so you need to do a little modification to the linker 
scripts distributed within avr-gcc, and use lld style syntax.
6. There are still some minor bugs in the llvm backend. 
(https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+label%3Abackend%3AAVR)

Generally speaking I have written some simple test programs with the 
clang/llvm/lld chain on Arduino boards, which are stable. So I would ask for 
more tests and reports by you. You can specify lld with command line option 
'-fuse-ld=lld'.

You are appreciated to report issues to me 
athttps://github.com/llvm/llvm-project/issues, and do not forget to set 
the issue's label to 'backend:avr'.

I hope my work can be fully accepted by the aruidno community and finally 
replace the GNU toolchain in its package releases in the future.

Best regards,

Ben Shi

Running the AVR-LibC test suite

[Georg-Johann Lay]

Trying to run the AVR-LibC test suite, I came across some
problems and have some questions.

tests/simulate/runtest.sh sets libs as follows:

  libs="$AVRDIR/avr/lib/$multilibdir/libc.a\
$AVRDIR/avr/lib/$multilibdir/libm.a \
$AVRDIR/avr/lib/$multilibdir/$2/lib$2.a -lgcc"

but then lib.a is not found.  Changing it to

  libs="...
$AVRDIR/avr/devices/$2/lib$2.a -lgcc"

fixes that problem, presumably some fallout from the
multilib changes in 
https://github.com/avrdudes/avr-libc/commit/f4ec4b741bc608f0afc471734afa097e905fed9b#diff-d1b54ff37e1aefa0d1f6b269aa0d859981cac6ce7cf3be4c88d00c770807599e


When I runhest.sh with that change, I am getting the output below.

~/gnu/build/avr-libc-v13 is an AVR-LibC build dir.

$ ./runtest.sh  -g avr-gcc-13 -a ~/gnu/build/avr-libc-v13 -s -v
...
+ CPPFLAGS=-Wundef -I.
+ CFLAGS=-gdwarf-4 -W -Wall -pipe -Os -Wno-array-bounds -Werror
...
Simulate: time/aux.c + echo -n atmega128 ...
atmega128 ... + Compile time/aux.c atmega128 aux.elf PR_STD
+ local crt=
+ local libs=
+ local flags=
+ [ -z /home/john/gnu/build/avr-libc-v13 ]
+ avr-gcc-13 -mmcu=atmega128 -print-multi-directory
+ local multilibdir=avr51
+ crt=crtatmega128.o
+ flags=-isystem /home/john/gnu/build/avr-libc-v13/include -nostdlib
+ head -1
+ find /home/john/gnu/build/avr-libc-v13/avr/lib -name crtatmega128.o -print
+ crt=
+ libs=/home/john/gnu/build/avr-libc-v13/avr/lib/avr51/libc.a	 
 /home/john/gnu/build/avr-libc-v13/avr/lib/avr51/libm.a 
/home/john/gnu/build/avr-libc-v13/avr/devices/atmega128/libatmega128.a -lgcc

+ basename time/aux.c
+ flags=-isystem /home/john/gnu/build/avr-libc-v13/include -nostdlib 
-std=gnu99
+ avr-gcc-13 -Wundef -I. -gdwarf-4 -W -Wall -pipe -Os -Wno-array-bounds 
-Werror -isystem /home/john/gnu/build/avr-libc-v13/include -nostdlib 
-std=gnu99 -mmcu=atmega128 -o aux.elf time/aux.c 
/home/john/gnu/build/avr-libc-v13/avr/lib/avr51/libc.a 
/home/john/gnu/build/avr-libc-v13/avr/lib/avr51/libm.a 
/home/john/gnu/build/avr-libc-v13/avr/devices/atmega128/libatmega128.a -lgcc

+ [ -z ]
+ Simulate aux.elf atmega128
+ rm -f core_avr_dump.core
+ simulavr -d atmega128 -T+ grep ERROR:
 __stop_program -f aux.elf -C core_avr_dump.core -m 600
+ [ -e core_avr_dump.core ]
+ echo Core dump is not created
Core dump is not created
+ RETVAL=-1
+ [ -1 -eq 0 ]
+ Err_echo simulate failed: -1
+ echo *** simulate failed: -1
*** simulate failed: -1
+ [ 1 ]
+ Errx Stop
+ echo ./runtest.sh: Stop
./runtest.sh: Stop
+ exit 1

So this test is failing for some reason, which is

$ avr-objdump -d aux.elf | head

aux.elf: file format elf32-avr

Disassembly of section .text:

 :
   0:   62 30   cpi r22, 0x02   ; 2
   2:   21 f4   brne.+8 ; 0xc <.L2>
   4:   0e 94 0d 00 call0x1a; 0x1a 


Any ideas?

Johann

Why is AVR-LibC still using -fno-jump-tables?

[Georg-Johann Lay]

In devtools/gen-avr-lib-tree.sh we have

CFLAGS_BIG_MEMORY='-Os $(FNO_JUMP_TABLES)'

where FNO_JUMP_TABLES is resolved to -fno-jump-tables by configure.

CFLAGS_BIG_MEMORY is then used as build flags for cores and devices with 
more than 64 KiB of program memory (i.e. with 3-byte PC i.e. that have 
ELPM) with the exceptions of ATmega128RFR2 and ATmega1284RFR2.



Is there any benefit of still using that flag?


To all of my knowledge, -fno-jump-tables was used because avr-gcc 
assumed that jump tables reside in the lower 64 KiB of flash (.progmem), 
but that restriction was resolved with https://gcc.gnu.org/PR63223 which 
applies to avr-gcc v4.9.2+.


PR63223 removes assumptions on the placement of jump tables altogether, 
in particular there is no more the requirement that they reside in 
.progmem.  Jump tables are now placed in .jumptables which the linker 
script locates after ordinary .text sections (even after .progmemx), and 
the code in libgcc takes care of that by using the full address width 
including RAMPZ as needed.



Johann

[patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #29, patch #9543 (project avr-libc):

This patch is best integrated after the changes from


https://savannah.nongnu.org/bugs/?49567

and

https://savannah.nongnu.org/bugs/?57071

which will greatly reduce the number of conflicts. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: can't reproduce documented overflow behavior of _delay_ms()

[Georg-Johann Lay]

Am 04.02.20 um 23:05 schrieb Joerg Wunsch:

As Georg-Johann Lay wrote:


hmmm.  So there is more work to do for double support?  We definitely do not
want double here but float instead...


I disagree.

This is all just happening in temporary variables inside of "static
inline" functions, and thus completely optimized away by the compiler.
Thus, the actual argument type doesn't really matter.


As yes, of course.


With optimizations turned off, all bets for the various _delay*
functions are gone anyway.


Johann

Re: can't reproduce documented overflow behavior of _delay_ms()

[Georg-Johann Lay]

Joerg Wunsch schrieb:
 > No, obviously, the documentation is wrong, and the delay functions

clip the delay value at a __builtin_avr_delay_cycles() value of
UINT_MAX rather than setting it to 0.

However, I just revisited the C standard on this.  All this is simply
undefined behaviour: the internal calculation is performed with a
"double" argument type, which is eventually then converted to
uint32_t, thereby overflowing the uint32_t domain.


hmmm.  So there is more word to do for double support?  We definitely do 
not want double here but float instead...


Johann

Re: can't reproduce documented overflow behavior of _delay_ms()

[Georg-Johann Lay]

Am 23.01.20 um 23:57 schrieb Britton Kerin:

On a 16 MHz Arduino Mega 256, this code:

   __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
   debug_led_on ();
   _delay_ms (29.0);
   debug_led_off ();
   assert (0);

leaves the debug led on for about 269 s.  Same for larger arguments to
_delay_ms (e.g. 35.0).  This is different from what this
documentation implies will happen:

   If the avr-gcc toolchain has __builtin_avr_delay_cycles() support,
maximal possible delay is
   4294967.295 ms/ F_CPU in MHz. For values greater than the maximal
possible delay,
   overflows results in no delay i.e., 0ms.

It looks like the result is now the maximum delay, rather than 0ms.
Perhaps __builtin_avr_delay_cycles() has changed?


No, the code is still from the initial commit

https://gcc.gnu.org/r172416

The code is still the same today:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.md?annotate=28
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.c?annotate=28

That's from just prior to the SVN->GIT transition.
(I found no way for a similar neat view with gitweb.  The transition was 
3 weeks ago, and since then that code did not change either.)


https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=tree;f=gcc/config/avr;hb=HEAD

Johann



Also, the documentation for _delay_us() also contains this:

   If the user requests a delay greater than the maximal possible one,
_delay_us() will
   automatically call _delay_ms() instead. The user will not be
informed about this case.

   If the avr-gcc toolchain has __builtin_avr_delay_cycles() support,
maximal possible delay is
   4294967.295 us/ F_CPU in MHz. For values greater than the maximal
possible delay, overflow
   results in no delay i.e., 0us.

This looks suspicious because if _delay_us() calls _delay_ms() for
longer delays, one would
expect the same maximum low-resolution delay as for _delay_ms().  And
in fact this code
behaves as expected (gives 10 seconds with LED on):

   __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
   debug_led_on ();
   _delay_us (1000.0);   // 10 s in us
   debug_led_off ();
   assert (0);

but this code delays for only 269s:

   __builtin_avr_delay_cycles (100.0);   // Compiles, so we apparently have it
   debug_led_on ();
   _delay_us (29000.0);   // 290 s in us
   debug_led_off ();
   assert (0);

So it looks like with recent avr gcc at least my suspicion is correct.

If it would get applied I could prepare a documentation patch for
these issues, but I don't know when the __builtin_avr_delay_cycles()
behavior changed (assuming that's the cause of the above problem).

Britton

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #13, bug #57071 (project avr-libc):


[comment #12 comment #12:]
> Here is a small addendum which fixes some problems that I ran into when
building avr-libc with avr-gcc v3.4.6:

Note: Just the fact that current avr-libc can be built with avr-gcc v3.4.6
does not mean the result is usable in any way.  Modern avr-libc drags device
properties from avr-gcc's built-in macros like __AVR_HAVE_JMP_CALL__ which
archaic avr-gcc does not define.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #12, bug #57071 (project avr-libc):

Here is a small addendum which fixes some problems that I ran into when
building avr-libc with avr-gcc v3.4.6:

1) The compiler might not recognize -Wno-sign-compare or
-Wno-maybe-uninitialized which are used to silence some build warnings.

2) Old GCC does not built-in define __SIZEOF_DOUBLE__ and
__SIZEOF_LONG_DOUBLE__, hence do it by hand.



(file #48240)
___

Additional Item Attachment:

File name: math64-addend1.diffSize:2 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

[Georg-Johann Lay]

Follow-up Comment #2, bug #49567 (project avr-libc):

Attached a new proposal mlib-gen-3.diff that has some minor simplifications
and fixes typos in comments.

Apart from that, we should remove ./devtools/make-binary-dist.sh as it makes
no more sense to have binary distributions because the binary will depend on
the compiler used at configure time.  As make-binary-dist.sh invokes
configure, that script is obsolete and should be removed so that nobody is
misled by the existence of such a script.

Similar for ./avr-lib.spec[.in] which was supposed to build a RPM file.  The
contents of that file are outdated, anyway.

(file #48085)
___

Additional Item Attachment:

File name: mlib-gen-3.diffSize:76 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

[Georg-Johann Lay]

Additional Item Attachment, bug #49567 (project avr-libc):

File name: mlib-gen-2.diffSize:75 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

[Georg-Johann Lay]

Follow-up Comment #1, bug #49567 (project avr-libc):

Attached a first draft version.

The $(srcdir)/avr tree is now generated by a new Python script mlib-gen.py
which should work with Python v2.7 and v3.  Which parts of that tree will we
used (and how) is determined by configure using -print-multi-lib and
-print-multi-directory.

mlib-gen.py generates 4 files from the device-info still held in
gen-avr-lib-tree.sh which are included by configure.ac.

There is still some build-in knowledge about avr-gcc multilib layout, for
example about orthogonality of -mdouble=64 etc and which devices are
asm-only.


* configure.ac (asm_only): New var.
(CHECK_AVR_DEVICE): Rewrite.
(CHECK_MULTI_OPTION, CHECK_MULTI_VARIANT): New AC_DEFUNs.
(CHECK_MULTI_OPTION) <-mdouble=32, -mlong-double=32>: New tests.
(CHECK_MULTI_OPTION) <-mdouble=64, -mlong-double=64>: New tests.
(devices.m4, devlist.m4, multilib.m4, files.m4): New m4_include's.
(CHECK_AVR_DEVICE()): Remove all of them.
(AM_CONDITIONAL(HAS_)): Same.
(AC_CONFIG_FILES) : Remove.
(AC_CONFIG_FILES) : Remove all of them.
devtools/
* Avr.am: Remove file.
* Lib.am: Remove file.
* mlib-gen.py: New Python script.
* Makefile.am (EXTRA_DIST): Adjust to added / removed files.
* gen-avr-lib-tree.sh: Let mlib-gen.py build $(srcdir)/avr.
Clean up code.
(CFLAGS_TINY_STACK): Remove.
(CFLAGS_SHORT_CALLS): Remove.
(AVR12_DEV_INFO): Assimilate AVR12TS_DEV_INFO.
(AVR25_DEV_INFO): Assimilate AVR25TS_DEV_INFO.
(AVRXMEGA3SC_DEV_INFO): Remove.
(AVR_ARH_INFO): Remove assimilated entries.
* Device.am (AVR_INSTALL_DIR): Set to $(MULTIDIR_<>).
(if HAS_<>): Remove.
* Architecture.am (SUBDIRS): Remove.
(AVRLIB_DEVLIST) [!HAS_DEV_LIB]: Init from $(DEVLIST_<>).
(AVRLIB_CFLAGS, AVRLIB_ASFLAGS) <-mmcu=$(AVR_TARGET)>: Remove option.
(avrD32) [HAS_double32]: New secondary.
(avrD64) [HAS_double64]: New secondary.
(avrL32) [HAS_long_double32]: New secondary.
(avrL64) [HAS_long_double64]: New secondary.
(avrD64) [HAS_double64]: New secondary.
(if HAS_<>): Remove.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: support for atmega4809 family?

[Georg-Johann Lay]

Am 08.12.19 um 21:10 schrieb Britton Kerin:

I notice there are official arduinos (arduino nano every and variants)
which use the 4809 now so there's presumably some support for this
chip somewhere. Is it going to show up in my beloved avr-libc?


The common approach is to fiddle with device packs provided by 
Microchip.  They contain, amongst other stuff, io*.h, crt*.o, specs-* 
and lib*.a for the devices.


There are also patches for avr-libc floating around, and there is a fork 
that tries to supply all that


https://github.com/stevenj/avr-libc3/

I cannot say anything about how reliable that is (with respect to (long 
term) support, bug-fixing, running test suites before integrating, 
sanity checking, ...)


However, in order to make the patches for the 0-series devices to have 
any effect, the compiler must support these devices, which will be in 
v10 for 0-series, cf.


http://gcc.gnu.org/PR92545

This support is not needed if you are using device packs (the rationale 
behind them is that you can generate code for a device without native 
support from the compiler).



If there's work to be done I'd be interested in helping with this
though I haven't done any avr-libc work before.  I saw some email


The tedious work is checking coding rules, writing ChangeLogs, running 
tests, integrating the stuff, reviewing if it might conflict with 
anything, it it's appropriate, etc.  For many of the issues there are 
patches available, but someone would have to integrate them (which is 
much more wirk than just pressing some "merge" button).



mentioning it as well

https://lists.nongnu.org/archive/html/avr-libc-dev/2019-11/msg2.html


This is the support for the multilib variants so that libm.a and libc.a 
are generated as needed.  This is the minimum that's required to make 
device-packs for avrxmega3 devices work (without multilib support you 
will get linker errors even if your lib.a, ioxxx.h, 
crt.o and specs- are in the right place).  However you 
could use the existing avrxmega2 with some performance penalty.


Johann


so maybe it's already done, but would be lovely if it showed up in a
release of course.

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #11, bug #57071 (project avr-libc):

Hi, here is an updated version of the patch.  Compared to the patch proposed
in comment #10, it fixes the vfprintf issues:

* Treat %f like %lf, same for other float printers.  If double is 64 bits, it
will only print "?".

* Support %Lf for long double, same for other float printers.  If long double
is 64 bits, it will only print "?".

(file #48029)
___

Additional Item Attachment:

File name: math64-3.diff  Size:72 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #10, bug #57071 (project avr-libc):

Here is an updated version of the patch with the following changes:

* It also defines alias symbols for long double provided long double = float.
* It provides long double prototypes in math.h.
* Adds a new file common/alias.h which defines layout-dependent alias macros
(C + Asm).
* Turns double into float in the C-part of the lib (dtostr[ef], vfprintf,
atof, ...).
* vfprintf depends on sizeof ([long] double) and distinguishes between %lf and
%f if their layouts differ.  However, we are running out of flags (which are
currently 8 at most).
* It fixes abs / labs implementation so they do no more conflict with
stdlib.h. 
* Fixes a bunch of unrelated build warnings so it can be built with
CFLAGS=-Werror


(file #47938)
___

Additional Item Attachment:

File name: math64-2.diff  Size:71 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #21, patch #9543 (project avr-libc):

FYI, support for devices from the 0-series like ATmega4808 (also filed under
avrxmega3) has been added to avr-gcc:

https://gcc.gnu.org/PR92545

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #9, bug #57071 (project avr-libc):

The GCC feature is upstream: https://gcc.gnu.org/r277908

The new configure options are:


--with-double={32|64|32,64|64,32}
--with-long-double={32|64|32,64|64,32|double}


For a documentation, see

https://gcc.gnu.org/install/configure.html#avr

Only 14 of the 20 combinations are valid, resulting in 12 different
configurations total.  Depending on the configuration, there will be up to 57
= 3*19 multilib variants.

The new compiler options are:


-mdouble={32|64}
-mlong-double={32|64}


For a documentation, see

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#index-mdouble

To display the mapping between option sets and multilib variants, use


avr-gcc -print-multi-lib


To show which multilib variant is actually picked for a specific set of
options, use


avr-gcc -print-multi-directory 


To factor out different floating-point layouts in a target program, you can
use -- like always -- the built-in defines


__SIZEOF_DOUBLE__
__SIZEOF_LONG_DOUBLE__


The libgcc build just copies the double64 and long-double64 multilib variants
from the vanilla one so that the build times won't go through the roof --
these variants would not contain any differences to the vanilla version,
anyway.

There is also the (undocumented, avr) configure option --with-fixed-point=no
which skips the build of the thousands of libgcc fixed-point modules.  You can
use this during development for sane build times.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #8, bug #57071 (project avr-libc):

FYI, there is the according GCC issue + patch

http://gcc.gnu.org/PR92055

>From the doc of
https://gcc.gnu.org/bugzilla/attachment.cgi?id=47114=diff


+@item -mdouble=@var{bits}
+@opindex mdouble
+Set the size (in bits) of the @code{double} type.  Valid values for
+@var{bits} are 32 and 64. This option is only available if the compiler
+is configured with @code{--with-double=32} or with @code{--with-double=64},
+and the argument of @code{--with-double=} specifies the default layout of
+@code{double}.
+
+@item -mlong-double=@var{bits}
+@opindex mlong-double
+Set the size (in bits) of the @code{long double} type.  Valid values for
+@var{bits} are 32 and 64. This option is only available if the compiler
+is configured with @code{--with-long-double=32} or with
+@code{--with-long-double=64}, and the argument of @code{--with-long-double=}
+specifies the default layout of @code{long double}.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57114] Do not #define abs / labs

[Georg-Johann Lay]

URL:
  

 Summary: Do not #define abs / labs
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Fri 25 Oct 2019 08:42:00 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.0.0
   Fixed Release: None

___

Details:

#define'ing abs is evil, in particular together with C++ when there are
methods called abs or there is abs polymorphism.

Same for labs.

The patch provides proper functions (kind of) without introducing overhead.

* include/stdlib.h (__ATTR_ALWAYS_INLINE__): New macro.
(abs): Provide in such a way that we get a prototype.
(labs): Same.




___

File Attachments:


---
Date: Fri 25 Oct 2019 08:42:00 AM UTC  Name: stdlib-abs.diff  Size: 1KiB   By:
gjlayde



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #7, bug #57071 (project avr-libc):


[comment #6 comment #6:]
> The current patch is supposed to be a no-op, so that
> no observable effect should occur.

There are observable effects actually:  The patch should also result in the
resolution of bug #49984.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #6, bug #57071 (project avr-libc):

[comment #5 comment #5:]
> Thanks for the explanation.
> 
> I think I'll apply the patch then as is by now, and we might
> add some words about the usage later on, when the configuration
> is settled.

Great.  The current patch is supposed to be a no-op, so that no observable
effect should occur.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #2, bug #57071 (project avr-libc):

Here is a version without __asm(symbol) that defines a symbol for double only
if sizeof(double) == sizeof(float).


* include/math.h
(cosf, sinf, tanf, fmodf, modff, sqrtf, cbrtf, hypotf, squaref)
(floorf, ceilf, frexpf, ldexpf, expf, coshf, sinhf, tanhf, asinf)
(acosf, atanf, atan2f, logf, log10f, powf, isnanf, isinff)
(signbitf, fdimf, fmaf, fmaxf, fmin, truncf, roundf, lroundf)
(lrintf): Turn from macro to proper prototype.
(fabs, fabsf, isfinite, isfinitef, copysign, copysignf): Implement.

* libm/fplib/asmdef.h (ALIAS_ENTRY): Remove.
(ENTRY_DOUBLE32): New .macro that only defines the symbol
if __SIZEOF_DOUBLE__ == __SIZEOF_FLOAT__.
* libm/fplib/acos.S: Use correct names for functions that deal
with float, e.g. acosf instead of acos.  Provide double symbol
only if __SIZEOF_DOUBLE__ == __SIZEOF_FLOAT__.
* libm/fplib/asin.S: Same.
* libm/fplib/atan.S: Same.
* libm/fplib/atan2.S: Same.
* libm/fplib/cbrt.S: Same.
* libm/fplib/ceil.S: Same.
* libm/fplib/copysign.S: Same.
* libm/fplib/cos.S: Same.
* libm/fplib/cosh.S: Same.
* libm/fplib/exp.S: Same.
* libm/fplib/fdim.S: Same.
* libm/fplib/floor.S: Same.
* libm/fplib/fma.S: Same.
* libm/fplib/fmax.S: Same.
* libm/fplib/fmin.S: Same.
* libm/fplib/fmod.S: Same.
* libm/fplib/fp_arccos.S: Same.
* libm/fplib/frexp.S: Same.
* libm/fplib/hypot.S: Same.
* libm/fplib/isfinite.S: Same.
* libm/fplib/isinf.S: Same.
* libm/fplib/isnan.S: Same.
* libm/fplib/ldexp.S: Same.
* libm/fplib/log.S: Same.
* libm/fplib/log10.S: Same.
* libm/fplib/lrint.S: Same.
* libm/fplib/lround.S: Same.
* libm/fplib/modf.S: Same.
* libm/fplib/pow.S: Same.
* libm/fplib/round.S: Same.
* libm/fplib/signbit.S: Same.
* libm/fplib/sin.S: Same.
* libm/fplib/sinh.S: Same.
* libm/fplib/sqrt.S: Same.
* libm/fplib/square.S: Same.
* libm/fplib/tan.S: Same.
* libm/fplib/tanh.S: Same.
* libm/fplib/trunc.S: Same.


(file #47711)
___

Additional Item Attachment:

File name: math64-syms.diff   Size:52 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9864] Use proper float function names and prototypes.

[Georg-Johann Lay]

URL:
  

 Summary: Use proper float function names and prototypes.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Thu 17 Oct 2019 08:27:15 AM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:


* include/math.h
(cos, sin, tan, fmod, modf, sqrt, cbrt, hypot, square, floor, ceil)
(frexp, ldexp, exp, cosh, sinh, tanh, asin, acos, atan, atan2)
(log, log10, pow, isnan, isinf, signbit, fdim, fma, fmax, fmin)
(trunc, round, lround, lrint) [double=64-bit]: Provide double
prototypes.
[double=32-bit]: Provide protos with assembler names which are
the corresponding float function name.

(cosf, sinf, tanf, fmodf, modff, sqrtf, cbrtf, hypotf, squaref)
(floorf, ceilf, frexpf, ldexpf, expf, coshf, sinhf, tanhf, asinf)
(acosf, atanf, atan2f, logf, log10f, powf, isnanf, isinff)
(signbitf, fdimf, fmaf, fmaxf, fmin, truncf, roundf, lroundf)
(lrintf):
Turn from macro to proper prototype.
(fabs, fabsf, isfinite, isfinitef, copysign, copysignf): Implement.

libm/fplib/
* libm/fplib/acos.S: Use correct names for functions that deal
with float, e.g. acosf instead of acos.  Adjust comments.
* libm/fplib/asin.S: Same.
* libm/fplib/atan.S: Same.
* libm/fplib/atan2.S: Same.
* libm/fplib/cbrt.S: Same.
* libm/fplib/ceil.S: Same.
* libm/fplib/copysign.S: Same.
* libm/fplib/cos.S: Same.
* libm/fplib/cosh.S: Same.
* libm/fplib/exp.S: Same.
* libm/fplib/fdim.S: Same.
* libm/fplib/floor.S: Same.
* libm/fplib/fma.S: Same.
* libm/fplib/fmax.S: Same.
* libm/fplib/fmin.S: Same.
* libm/fplib/fmod.S: Same.
* libm/fplib/fp_arccos.S: Same.
* libm/fplib/frexp.S: Same.
* libm/fplib/hypot.S: Same.
* libm/fplib/isfinite.S: Same.
* libm/fplib/isinf.S: Same.
* libm/fplib/isnan.S: Same.
* libm/fplib/ldexp.S: Same.
* libm/fplib/log.S: Same.
* libm/fplib/log10.S: Same.
* libm/fplib/lrint.S: Same.
* libm/fplib/lround.S: Same.
* libm/fplib/modf.S: Same.
* libm/fplib/pow.S: Same.
* libm/fplib/round.S: Same.
* libm/fplib/signbit.S: Same.
* libm/fplib/sin.S: Same.
* libm/fplib/sinh.S: Same.
* libm/fplib/sqrt.S: Same.
* libm/fplib/square.S: Same.
* libm/fplib/tan.S: Same.
* libm/fplib/tanh.S: Same.
* libm/fplib/trunc.S: Same.




___

File Attachments:


---
Date: Thu 17 Oct 2019 08:27:15 AM UTC  Name: math64.diff  Size: 53KiB   By:
gjlayde



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

Follow-up Comment #1, bug #57071 (project avr-libc):


* include/math.h
(cos, sin, tan, fmod, modf, sqrt, cbrt, hypot, square, floor, ceil)
(frexp, ldexp, exp, cosh, sinh, tanh, asin, acos, atan, atan2)
(log, log10, pow, isnan, isinf, signbit, fdim, fma, fmax, fmin)
(trunc, round, lround, lrint) [double=64-bit]: Provide double
prototypes.
[double=32-bit]: Provide protos with assembler names which are
the corresponding float function name.

(cosf, sinf, tanf, fmodf, modff, sqrtf, cbrtf, hypotf, squaref)
(floorf, ceilf, frexpf, ldexpf, expf, coshf, sinhf, tanhf, asinf)
(acosf, atanf, atan2f, logf, log10f, powf, isnanf, isinff)
(signbitf, fdimf, fmaf, fmaxf, fmin, truncf, roundf, lroundf)
(lrintf):
Turn from macro to proper prototype.
(fabs, fabsf, isfinite, isfinitef, copysign, copysignf): Implement.

libm/fplib/
* libm/fplib/acos.S: Use correct names for functions that deal
with float, e.g. acosf instead of acos.  Adjust comments.
* libm/fplib/asin.S: Same.
* libm/fplib/atan.S: Same.
* libm/fplib/atan2.S: Same.
* libm/fplib/cbrt.S: Same.
* libm/fplib/ceil.S: Same.
* libm/fplib/copysign.S: Same.
* libm/fplib/cos.S: Same.
* libm/fplib/cosh.S: Same.
* libm/fplib/exp.S: Same.
* libm/fplib/fdim.S: Same.
* libm/fplib/floor.S: Same.
* libm/fplib/fma.S: Same.
* libm/fplib/fmax.S: Same.
* libm/fplib/fmin.S: Same.
* libm/fplib/fmod.S: Same.
* libm/fplib/fp_arccos.S: Same.
* libm/fplib/frexp.S: Same.
* libm/fplib/hypot.S: Same.
* libm/fplib/isfinite.S: Same.
* libm/fplib/isinf.S: Same.
* libm/fplib/isnan.S: Same.
* libm/fplib/ldexp.S: Same.
* libm/fplib/log.S: Same.
* libm/fplib/log10.S: Same.
* libm/fplib/lrint.S: Same.
* libm/fplib/lround.S: Same.
* libm/fplib/modf.S: Same.
* libm/fplib/pow.S: Same.
* libm/fplib/round.S: Same.
* libm/fplib/signbit.S: Same.
* libm/fplib/sin.S: Same.
* libm/fplib/sinh.S: Same.
* libm/fplib/sqrt.S: Same.
* libm/fplib/square.S: Same.
* libm/fplib/tan.S: Same.
* libm/fplib/tanh.S: Same.
* libm/fplib/trunc.S: Same.


(file #47705)
___

Additional Item Attachment:

File name: math64.diffSize:53 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

[Georg-Johann Lay]

URL:
  

 Summary: Fix math.h and function names that block 64-bit
double
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Thu 17 Oct 2019 07:10:37 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.0.0
   Fixed Release: None

___

Details:

Implementation of math.h / libm currently blocks 64-bit double, namely:

1) Function names are wrong, e.g. 32-bit implementation of sine is named
"sin", not "sinf".

2) There are "aliases" in math.h (macros actually) that define the float
version (like "sinf") to the double version (like "sin").  Problem is that
this:

2a) This is the wrong way round ("sin" should be alias of "sinf").

2b) There are no proper prototypes.

2c) Macros are bad, e.g. in C++ when some class implements a method for which
math.h defines a macro, C++ functions / methods are silently renamed.

3) math.h is unconditional, i.e. treats double != float just like double =
float.






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #56093] Wrong constraint in pgmspace.h::pgm_get_far_address

[Georg-Johann Lay]

URL:
  

 Summary: Wrong constraint in pgmspace.h::pgm_get_far_address
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Sun 07 Apr 2019 01:00:58 PM UTC
Category: Header
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Header files
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.0.0
   Fixed Release: None

___

Details:

Macro pgm_get_far_address() from avr/pgmspace.h has a wrong constraint for
operand %1: Is must be "ni" (known at compile-time (n) or known ar assembly
time or later (i)) instead of "p".

Moreover, the asm is not volatile, hence the "volatile" can be dropped.

The "tmp" should also be recplaced by an identifier from implementation space
like __tmp.

Last not least, the macro should come with "extension" so that it will work in
strict C mode (and not only with GNU-C which valued blocks are).

Putting everything together, the macro should read


#define pgm_get_far_address(var)  \
(__extension__({  \
uint_farptr_t __tmp;  \
  \
__asm__ ( \
"ldi%A0, lo8(%1)"   "\n\t"\
"ldi%B0, hi8(%1)"   "\n\t"\
"ldi%C0, hh8(%1)"   "\n\t"\
"clr%D0""\n\t"\
: "=d" (__tmp)\
: "ni" (&(var))   \
);\
__tmp;\
}))






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] fwrite() not working as expected

[Georg-Johann Lay]

avr-libc-...@nicohood.de schrieb:

Hi,
I am trying to use fwrite() to write the first X bytes of a string like
this, but with a wrong output:

auto ret = fwrite("Hello World!", 1, 5, stdout);
printf("%d\n", ret);
// Output: H0

Its documented here:
https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gadd519a41713629a62b68c239a774

Can anyone please tell me if this is a bug or if I am doing something
wrong. I am using avr-libc 2.0.0 on Arch Linux with the latest avr-gcc 7.3.0

~Nico


How did you setup stdout? Using FDEV_SETUP_STREAM?
https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaea2b6be92ead4673bc487b271b7227fb

Are you sure the communication / output routines passed to stdout are 
correct and I/O correctly set up? Including host I/O, given you use it.


Johann

___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] PSTR() in static initialisers

[Georg-Johann Lay]

Joerg Wunsch schrieb:

As Georg-Johann Lay wrote:


If that static is not function-static, then __flash can be used:


Thanks for that, Johann.

I tried to come up with a __flash-based implementation myself,
but didn't get it to work.

Maybe your "recipe" would be worth an entry into the avr-libc FAQ?


Dunno if that's actually specified or just works by accident.  What's 
really strange is that it doesn't work for locals, and there is no 
technical reason for that.


https://gcc.gnu.org/PR84163

Maybe it had just been overlooked when ASes were added to gcc, as the 
first AS targets didn't go as far as avr (iirc they didn't even need 
statics as it was all about using specific instructions for 
memory-mapped I/O).


FWIF there's also a mention at
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_flash_und_Embedded-C

Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] PSTR() in static initialisers

[Georg-Johann Lay]

On 31.01.2018 21:15, Paul "LeoNerd" Evans wrote:

On Wed, 31 Jan 2018 21:04:55 +0100
Joerg Wunsch  wrote:


As Paul "LeoNerd" Evans wrote:


Does anyone have a suggestion on how I can have a string pointer to
a flash-stored string in a static initialiser?


This only works by allocating each of the string into a variable
(well, constant actually) in flash by itself, and then mention their
names in the struct initializer.


Hrm; that's upsettingly annoying. Is there perhaps a way this can be
convinced into working? I generally dislike the untidiness of having to
define lots of things above the main array definition, just so I can
pull them in by name into it, and use that name nowhere else. Inline
things would be nicer there.


If that static is not function-static, then __flash can be used:


#if !defined __FLASH || (defined __AVR_PM_BASE_ADDRESS__)
// For devices that see flash in RAM address space, resort to vanilla C.
#define __flash // empty
#endif // have __flash

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char* const __flash animals[] =
{
  FSTR ("mite"), FSTR ("slug"), FSTR ("sloth")
};

const __flash char flash[] = "flash";
const __flash char *pram_to_flash = FSTR ("pet");
const __flash char * const __flash pflash_to_flash = FSTR ("cat");

const __flash char* ani (int i)
{
  return animals[i];
}

Notice that in contrast to progmem, __flash is a qualifier and *not* an 
attribute.  In particular, it matters where it occurs in a declaration, 
e.g. whether left or right of a "*".  gcc will generate accesses as 
desired, no need for pgm_read macros or inline asm.  However gcc rejects 
FSTR for function-static so that there is no one-fits-all solution:


const __flash char* get_pet (void)
{
  static const __flash char *pet = FSTR ("pet");
  return pet;
}

In function 'get_pet':
error: compound literal qualified by address-space qualifier
   return FSTR ("pet");
   ^~


Johann

___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9553] Fix some issues in libc/

[Georg-Johann Lay]

URL:
  

 Summary: Fix some issues in libc/
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Wed 24 Jan 2018 04:01:56 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This patch fixes some build warnings and a potential wrong-code issues in
GETBYTE as used by vfprintf and vfscanf:

Inline asm operand %0 might override operand %2 as the compiler may assign the
same hard register to either operands.  Hence, %0 needs an early-clobber
constraint so that setting %0 will never set %2 (%2 is used after the first
set of %0).  Presumably, this has never led to a problem because %2 is used in
a loop and is not dead after the asm, yet it is a potential bug.


* libc/stdio/vfscanf.c (GETBYTE) [LPMx]: Early-clobber %0.
(GETBYTE) [default]: Use shorter instruction sequence.
* libc/stdio/vfprintf.c: Same.
(vfprintf): Fix build-warnings.
* libc/stdlib/dtostre.c (dtostre): Fix build warning.
* libc/stdlib/getenv.c (getenv): Fix build warning.





___

File Attachments:


---
Date: Wed 24 Jan 2018 04:01:56 PM UTC  Name: avrlibc-libc.diff  Size: 2KiB  
By: gjlayde
patch


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #8, patch #9543 (project avr-libc):

There must still be missing something, at least _PROTECTED_WRITE_SPM.  Apart
from a build warning for a missing prototype, it's neither resolved by a macro
nor my a symbol:


$ echo 'int main(){}' | avr-gcc -xc - -Wl,-u,eeprom_write_block
-mmcu=attiny1616
/srv/local/gnu/install/gcc-8/bin/../lib/gcc/avr/8.0.1/../../../../avr/lib/avrxmega3/libattiny1616.a(eewr_block_xmega.o):
In function `eeprom_write_block':
eewr_block_xmega.c:(.text.avr-libc+0x80): undefined reference to
`_PROTECTED_WRITE_SPM'
collect2: error: ld returned 1 exit status




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #6, patch #9543 (project avr-libc):

Thanks, I can build avr-libc now and a quick test looks good.

Regarding the changes to eewr_block_xmega.c, maybe it's clearer to
special-case the different NVM flavours instead of #define + #undef + #define
chains?

I allowed me to attach a respective patch as avrxmega3-v4.diff.bz2


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Additional Item Attachment, patch #9543 (project avr-libc):

File name: avrxmega3-v4.diff.bz2  Size:283 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #4, patch #9543 (project avr-libc):

With that patch, avr-libc fails to build:

++
Making all in avrxmega3
make[4]: Entering directory
'/srv/local/gnu/build/avrlibc-trunk/avr/lib/avrxmega3'
Making all in attiny1614
make[5]: Entering directory
'/srv/local/gnu/build/avrlibc-trunk/avr/lib/avrxmega3/attiny1614'
/local/gnu/install/gcc-8/bin/avr-gcc -DHAVE_CONFIG_H -I.
-I../../../../../../source/avrlibc-trunk/avr/lib/avrxmega3/attiny1614
-I../../../..  -I../../../../../../source/avrlibc-trunk/common
-I../../../../../../source/avrlibc-trunk/include -I../../../../include  -Wall
-W -Wstrict-prototypes -mmcu=attiny1614  -mcall-prologues -Os  -MT
eewr_block_xmega.o -MD -MP -MF .deps/eewr_block_xmega.Tpo -c -o
eewr_block_xmega.o
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c: In
function 'eeprom_write_page':
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c:26:13:
error: 'NVM' undeclared (first use in this function)
   } while ((NVM.STATUS & NVM_NVMBUSY_bm) == NVM_NVMBUSY_bm);
 ^~~
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c:26:13:
note: each undeclared identifier is reported only once for each function it
appears in
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c:26:26:
error: 'NVM_NVMBUSY_bm' undeclared (first use in this function); did you mean
'RTC_CMPBUSY_bm'?
   } while ((NVM.STATUS & NVM_NVMBUSY_bm) == NVM_NVMBUSY_bm);
  ^~
  RTC_CMPBUSY_bm
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c:58:13:
error: 'NVM_CMD_ERASE_WRITE_EEPROM_PAGE_gc' undeclared (first use in this
function)
   NVM.CMD = NVM_CMD_ERASE_WRITE_EEPROM_PAGE_gc;
 ^~
../../../../../../source/avrlibc-trunk/libc/misc/eewr_block_xmega.c:59:29:
error: 'NVM_CMDEX_bm' undeclared (first use in this function); did you mean
'TCD_CMPDEN_bm'?
   ccp_write_io (, NVM_CMDEX_bm);
 ^~~~
 TCD_CMPDEN_bm
Makefile:632: recipe for target 'eewr_block_xmega.o' failed
--

Notice that avr-gcc defines AVR_XMEGA for these devices (in case that
matters).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9405] Add ISR_NOGCCISR macro to avr/interrupt.h

[Georg-Johann Lay]

Follow-up Comment #1, patch #9405 (project avr-libc):

Ping #1

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9416] AVR_TINY: Avoid conatraint "w" in delay.h

[Georg-Johann Lay]

Follow-up Comment #1, patch #9416 (project avr-libc):

Ping #1

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

[Georg-Johann Lay]

Follow-up Comment #1, patch #9543 (project avr-libc):

> Changed files: [...] ChangeLog 

The delta to ChangeLog is not reasonable, too much lines affected.

Usually, ChangeLog is prone to conflicts as each push is touching it; hence it
might be more comfortable to supply it as plain text snipped and leave it out
of the patch.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #52181] assert should make Serial.flush() before calling abort()

[Georg-Johann Lay]

Follow-up Comment #1, bug #52181 (project avr-libc):

This is not an avr-libc problem.  The stdio routines like prinf are fully
synchronous, and there is no buffering.

Hence any buffering must emerge from the applicaton's stream implementation,
i.e. from the callbacks you are providing with FDEV_SETUP_STREAM or by similar
means.

One fix is to provide a destructor for your static buffering object.  abort
will call _exit which will run all the static destructors and all the
functions registered with atexit.

Beside thar, gnu tools allow to provide own static destructors even for C, and
avr tool allow to override abort, _exit and exit and to run own shutdown code
located in dedicated sections .fini9 ... .fini0.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9416] AVR_TINY: Avoid conatraint "w" in delay.h

[Georg-Johann Lay]

URL:
  

 Summary: AVR_TINY: Avoid conatraint "w" in delay.h
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mon 24 Jul 2017 12:47:36 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

delay_basic.h might use constraint "w" for AVR_TINY which as an empty register
class.


* include/util/delay_basic.h (_delay_loop_2) [__AVR_TINY__]: Avoid
constraint "w".





___

File Attachments:


---
Date: Mon 24 Jul 2017 12:47:36 PM UTC  Name: alibc-delay-tinyw.diff  Size:
619B   By: gjlayde



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9405] Add ISR_NOGCCISR macro to avr/interrupt.h

[Georg-Johann Lay]

URL:
  

 Summary: Add ISR_NOGCCISR macro to avr/interrupt.h
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mon 10 Jul 2017 01:12:15 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This adds new ISR_NOGCISR macro to be used as ISR attribute with a similar
naming like the already existing ones.  For the feature, see

https://gcc.gnu.org/onlinedocs/gcc/AVR-Function-Attributes.html
https://sourceware.org/PR21683


* include/avr/interrupt.h (ISR_NOGCCISR): New ISR convenience macro.
(ISR_NOICF) [!__has_attribute]: Define as empty.





___

File Attachments:


---
Date: Mon 10 Jul 2017 01:12:15 PM UTC  Name: alibc-nogccisr.diff  Size: 1kB  
By: gjlayde



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #41435] math library functions in uril/delay.h

[Georg-Johann Lay]

Follow-up Comment #2, bug #41435 (project avr-libc):


> /* #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.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9400] Add avrxmega3 multilibs

[Georg-Johann Lay]

URL:
  

 Summary: Add avrxmega3 multilibs
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Wed 05 Jul 2017 07:58:48 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi, as lined out in

http://lists.gnu.org/archive/html/avr-libc-dev/2017-06/msg0.html

this patch adds multilib support for the 2 new variants needed for avrxmega3
familiy (like ATtiny816).  No devices are added.  Without this patch, the
tools will generate wrong code because non-existing multilibs will silently
use default variant (avr2).

The according Binutils feature is here:
https://sourceware.org/PR21472

The according GCC feature is here:
https://gcc.gnu.org/PR81072



Add multilib support for avrxmega3 + avrxmega3/short-calls.

* configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
(AM_CONDITIONAL): Add one for HAS_avrxmega3.
(AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
avr/lib/avrxmega3/short-calls/Makefile.

* devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
(AVRXMEGA3_DEV_INFO): New.
(AVRXMEGA3SC_DEV_INFO): New.
(AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.

* include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.





___

File Attachments:


---
Date: Wed 05 Jul 2017 07:58:48 PM UTC  Name: alibc-avrxmega3.diff  Size: 3kB  
By: gjlayde



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [patch] Add support for avrxmega3.

[Georg-Johann Lay]

On 08.06.2017 12:44, Georg-Johann Lay wrote:

Hi,

this patch adds avrxmega3 support and the 2 multilib versions
associated with it.

avr-gcc doesn't yet have respective support, but the Makefiles
scale accordingly.  As is is easier to get something into avr-gcc,
and because the libc and gcc must agree on the support, I am
starting with the "hard" part.


FYI, the respective extension has been added to GCC and is
available since

https://gcc.gnu.org/r249124

It

* Adds -mmcu=avrxmega3
* Adds -mshort-calls
* Adds some devices (not yet supported by avr-libc)
* Adds a configure check so it's restrictive in that it
  requires https://sourceware.org/PR21472 to build avr-gcc.

Johann


 Add multilib support for avrxmega3 + avrxmega3/short-calls.

 * configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
 (AM_CONDITIONAL): Add one for HAS_avrxmega3.
 (AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
 avr/lib/avrxmega3/short-calls/Makefile.

 * devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
 (AVRXMEGA3_DEV_INFO): New.
 (AVRXMEGA3SC_DEV_INFO): New.
 (AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.

 * include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

[Georg-Johann Lay]

Follow-up Comment #1, patch #9187 (project avr-libc):

Ping #1

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch] Add support for avrxmega3.

[Georg-Johann Lay]

Hi,

this patch adds avrxmega3 support and the 2 multilib versions
associated with it.

avr-gcc doesn't yet have respective support, but the Makefiles
scale accordingly.  As is is easier to get something into avr-gcc,
and because the libc and gcc must agree on the support, I am
starting with the "hard" part.


Johann


Add multilib support for avrxmega3 + avrxmega3/short-calls.

* configure.ac (CHECK_AVR_DEVICE): Add one for avrxmega3.
(AM_CONDITIONAL): Add one for HAS_avrxmega3.
(AC_CONFIG_FILES): Add avr/lib/avrxmega3/Makefile,
avr/lib/avrxmega3/short-calls/Makefile.

* devtools/gen-avr-lib-tree.sh (CFLAGS_SHORT_CALLS): New.
(AVRXMEGA3_DEV_INFO): New.
(AVRXMEGA3SC_DEV_INFO): New.
(AVR_ARH_INFO): Add entries avrxmega3, avrxmega3/short-calls.

* include/avr/pgmspace.h (__AVR_HAVE_RAMPD__): Fix comment.
Index: configure.ac
===
--- configure.ac	(revision 2537)
+++ configure.ac	(working copy)
@@ -1124,6 +1124,11 @@ CHECK_AVR_DEVICE(atxmega32e5)
 AM_CONDITIONAL(HAS_atxmega32e5, test "x$HAS_atxmega32e5" = "xyes")
 
 
+# avrxmega3
+CHECK_AVR_DEVICE(avrxmega3)
+AM_CONDITIONAL(HAS_avrxmega3, test "x$HAS_avrxmega3" = "xyes")
+
+
 # avrxmega4
 CHECK_AVR_DEVICE(avrxmega4)
 AM_CONDITIONAL(HAS_avrxmega4, test "x$HAS_avrxmega4" = "xyes")
@@ -1571,6 +1576,16 @@ AC_CONFIG_FILES([
 	avr/lib/avrxmega2/atxmega32e5/Makefile
 ])
 
+# avrxmega3
+AC_CONFIG_FILES([
+	avr/lib/avrxmega3/Makefile
+])
+
+# avrxmega3/short-calls
+AC_CONFIG_FILES([
+	avr/lib/avrxmega3/short-calls/Makefile
+])
+
 # avrxmega4
 AC_CONFIG_FILES([
 	avr/lib/avrxmega4/Makefile
Index: devtools/gen-avr-lib-tree.sh
===
--- devtools/gen-avr-lib-tree.sh	(revision 2537)
+++ devtools/gen-avr-lib-tree.sh	(working copy)
@@ -47,6 +47,7 @@ PATH=/usr/xpg4/bin:$PATH
 
 CFLAGS_SPACE="-mcall-prologues -Os"
 CFLAGS_TINY_STACK="-msp8 -mcall-prologues -Os"
+CFLAGS_SHORT_CALLS="-mshort-calls -mcall-prologues -Os"
 CFLAGS_BIG_MEMORY='-Os $(FNO_JUMP_TABLES)'
 CFLAGS_SPEED="-Os"
 
@@ -302,6 +303,12 @@ atxmega32d4:crtx32d4.o:${DEV_DEFS}:${CFL
 atxmega32e5:crtx32e5.o:${DEV_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS}\
 "
 
+AVRXMEGA3_DEV_INFO="\
+"
+
+AVRXMEGA3SC_DEV_INFO="\
+"
+
 AVRXMEGA4_DEV_INFO="\
 atxmega64a3:crtx64a3.o:${DEV_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 atxmega64a3u:crtx64a3u.o:${DEV_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
@@ -371,6 +378,8 @@ avr5::AVR5_DEV_INFO:${LIB_DEFS}:${CFLAGS
 avr51::AVR51_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avr6::AVR6_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega2::AVRXMEGA2_DEV_INFO:${LIB_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avrxmega3::AVRXMEGA3_DEV_INFO:${LIB_DEFS}:${CFLAGS_SPACE}:${DEV_ASFLAGS};\
+avrxmega3:short-calls:AVRXMEGA3SC_DEV_INFO:${LIB_DEFS}:${CFLAGS_SHORT_CALLS}:${DEV_ASFLAGS};\
 avrxmega4::AVRXMEGA4_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega5::AVRXMEGA5_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
 avrxmega6::AVRXMEGA6_DEV_INFO:${LIB_DEFS}:${CFLAGS_BIG_MEMORY}:${DEV_ASFLAGS};\
Index: include/avr/pgmspace.h
===
--- include/avr/pgmspace.h	(revision 2537)
+++ include/avr/pgmspace.h	(working copy)
@@ -892,8 +892,8 @@ #ifndef __DOXYGEN__		/* These are intern
 }))
 
 /*
-Check for architectures that implement RAMPD (avrxmega3, avrxmega5,
-avrxmega7) as they need to save/restore RAMPZ for ELPM macros so it does
+Check for architectures that implement RAMPD (avrxmega5, avrxmega7)
+as they need to save/restore RAMPZ for ELPM macros so it does
 not interfere with data accesses.
 */
 #if defined (__AVR_HAVE_RAMPD__)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Approaching #49567: Use meta-info from --print-multi-lib

[Georg-Johann Lay]

On 29.05.2017 15:40, Georg-Johann Lay wrote:

Hi.

This thread is about https://savannah.nongnu.org/bugs/?49567 and how
it can be solved.

The current implementation is agnostic of gcc's multilib layout and
uses much of hard-coded knowledge.

This makes it hard to extend avr-gcc and add new multilib variants
because avr-libc must always be adjusted in sync.

Information about multilib layout can be retrieved from the compiler
by --print-multi-lib.  This exposes the available multilib directories
together with the options needed to select that multilib variant.

Moreover, for each set of options, in particular -mmcu=, the
compiler can report the respective multilib directory by means of
--print-multi-directory.

These are old features available "since ever" and nothing new.

The current problem with avr-libc is that it abuses autotools in
some weird way:  The "bootstrap" script generates a tree of .am
automake templates by using input templates with special <>
entries, replaces the <>s to get automake input, them runs
automake, then runs autoconf.

The major problem here is that "bootstrap" is completely agnostic
of the compiler in use, and hence no information can be retrieved
from the compiler.


The following approach is more conservative and builds on the present
bootstrap scheme:

"bootstrap" gets the compiler from the command line so it can be
used in the poor man's configure-like queries for avr-gcc features
and multilib layout by devtools.

The specified compiler, "avr-gcc" per default, is written to a file,
and configure picks it up and will use it as CC.

That way, "configure" and "bootstrap" are basing on the same avr-gcc
and features.  Specifying CC on the configure command line is
explicitly forbidden.

The patch below shows how it would look like.  The devtools and
how multilib tree is build has not been changed, it's still all
about how to teach "bootstrap" about the compiler and keeping
consistency between "bootstrap" and "configure".


Johann


The first question is: Would work on #49567 be welcome?




diff --git a/bootstrap b/bootstrap
index 43625b2..d429495 100755
--- a/bootstrap
+++ b/bootstrap
@@ -14,6 +14,49 @@ AUTOMAKE="${AUTOMAKE} --foreign --add-missing --copy"
 
 export AUTOMAKE AUTOCONF ACLOCAL AUTOHEADER
 
+# Get the avr-gcc to use.  Do NOT assume the environment has CC set,
+# because if the user exported CC before running bootstrap, that CC
+# will remain in the environment after this script and might confuse
+# other scripts.
+
+# Consume all arguments to support CC=$mypath/xgcc -B $mypath
+
+if test -z "$*"; then
+CC="avr-gcc"
+else
+CC="$*"
+fi
+
+# Check similar to the one in configure.ac to ensure we've got
+# something that looks like avr-gcc.
+
+bad_cc ()
+{
+quot='"'
+echo "error: wrong C compiler found or specified: ${quot}${CC}${quot}"
+exit 1
+}
+
+case "${CC}" in
+*gcc*)
+	case "X`${CC} -dumpmachine`X" in
+XavrX) ;;
+*) bad_cc ;;
+	esac ;;
+*) bad_cc ;;
+esac
+
+# Export CC so that devtools can use it.
+export CC
+
+# Notify the user about the compiler version.
+echo "avr compiler: `$CC --version | head -n 1`"
+
+# Write the compiler to a file so configure can pick it up.
+# This is needed to make sure that bootstrap and configure
+# are using the same compiler and same features.
+echo "$CC" > cc.btstrp
+
 # to see what is executed
 set -x
 
diff --git a/configure.ac b/configure.ac
index 174fbeb..5b6703d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -136,6 +136,33 @@ m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.64],
 
 # Checks for programs.
 
+# The bootstrap scripts runs before this one and also runs autoconf.
+# As bootstrap makes assumptions about the compiler, the following
+# lines ensure that configure will use the same compiler as bootstrap.
+# The nuisance is that autoconf does not provide any useful arguments
+# to ship information from the caller of autoconf (bootstrap) to here,
+# hence bootstrap wrote the used CC to cc.btstrp.  Pick it up now.
+
+AC_MSG_CHECKING([which compiler was used during bootstrap])
+
+if test -f ${srcdir}/cc.btstrp; then
+   cc_boot="`cat ${srcdir}/cc.btstrp`"
+   AC_MSG_RESULT([${cc_boot}])
+else
+AC_MSG_RESULT([no bootstrap was run])
+AC_MSG_ERROR([you must run bootstrap before configure])
+fi
+
+if test -n "${CC}"; then
+   AC_MSG_ERROR([setting CC on the command line or in the environment is not
+supported. if you want to use a special version of avr-gcc, please
+	run "bootstrap my-avr-gcc" before configure])
+fi
+
+CC="${cc_boot}"
+
+AC_MSG_NOTICE([bootstrap implies CC=${CC}])
+
 AC_PROG_CC
 AC_CHECK_TOOL(AS, as, as)
 AM_PROG_AS
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Approaching #49567: Use meta-info from --print-multi-lib

[Georg-Johann Lay]

Hi.

This thread is about https://savannah.nongnu.org/bugs/?49567 and how
it can be solved.

The current implementation is agnostic of gcc's multilib layout and
uses much of hard-coded knowledge.

This makes it hard to extend avr-gcc and add new multilib variants
because avr-libc must always be adjusted in sync.

Information about multilib layout can be retrieved from the compiler
by --print-multi-lib.  This exposes the available multilib directories
together with the options needed to select that multilib variant.

Moreover, for each set of options, in particular -mmcu=, the
compiler can report the respective multilib directory by means of
--print-multi-directory.

These are old features available "since ever" and nothing new.

The current problem with avr-libc is that it abuses autotools in
some weird way:  The "bootstrap" script generates a tree of .am
automake templates be using input templates with special <>
entries, replaces the <>s to get automake input, them runs
automake, then runs autoconf.

The major problem here is that "bootstrap" is completely agnostic
of the compiler in use, and hence no information can be retrieved
from the compiler.

The first question is: Would work on #49567 be welcome?

Provided I'll come up with something that works, whatever that
will be it will be a big delta.  And as I am not an autotools
expert and not very familiar with avr-libc internals, the outcome
us not unlikely to produce some hickups.

The second question is which approach to take?

Try to extend on the current "bootstrap" script, or try to switch
to a solution with less home-brew and less automake template generation?

Moreover, information is duplicated is several places:

* Devices are listed in configure.ac

* Devices are listed in devtools/gen-avr-lib-tree.sh (sub of bootstrap)

* Devices are listed in devtools/generate_iosym.sh

My current approach is this:  Devices and relevant info (currently only
the old-style crt) is listed in configure.ac:

ADDIF_DEVICE_GCC(at90s4414,   x)
ADDIF_DEVICE_GCC(attiny26,tn26)
ADDIF_DEVICE_GCC(attiny261,   tn261)

This is used to probe whether the compiler supports that device, and if,
the information is appended to some AC_SUBST.  A script to build the
multilib tree is

AC_CONFIG_FILES([gen-multilib.sh], [chmod +x gen-multilib.sh])

and gets replacement of needed vars:

gen-multilib.sh:

MULTILIB_LAYOUT=".; avr25;@mmcu=avr25 ..."
MULTILIB_TOP="avr/lib"

ALL_DEVICES=" at90s4414 attiny26 attiny261 ..."
ALL_DEVICES_INFO=" at90s4414:.:@mmcu=avr2:x 
attiny26:tiny-stack:@msp8:tn26 
attiny261:avr25/tiny-stack:@mmcu=avr25@msp8:tn261 ..."


the intended purpose of this script is to generate

$(MULTILIB_TOP)/avr25/Makefile and friends.

The Makefile is triggered by looping over the multilibs, which
requires GNU make to work, in particular := assignments and
patsubst.  Given libgcc is using a similar approach to
implement loops, this appears to be not a too big restriction,
cf.

https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib2-object.mk?revision=195878=markup#l1

https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/t-avr?revision=216525=markup#l139

Notice how lib2-object.mk is used to implement the loop.

The problem with this approach will be that no automake or
autoconf will run on the generated Makefiles, whereas the
current approach uses a heavy degree of copying the templates
together, amongst them:

Architecture.am, Avr.am, Device.am, Lib.am from devtools.

Ideas?


Johann









___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #50811] using -Wl, -u, vfprintf -lprintf_min causes program to grow a lot

[Georg-Johann Lay]

Follow-up Comment #9, bug #50811 (project avr-libc):

Re. the "compiler thing" mentioned above:

avr-gcc might replace a call to printf by a call to puts provided the
arguments of printf allows to do so.  You can avoid this optimization by means
of -fno-builtin-printf which takes away any knowledge (except prototype
information) about printf from the compiler.  This will result in a call to
printf (which you are using anyway), saving the call to fputs.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #50987] Not all registers need to be declared volatile

[Georg-Johann Lay]

Follow-up Comment #1, bug #50987 (project avr-libc):

Would you be a /bit/ more specific?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Missed optimizations

[Georg-Johann Lay]

On 16.04.2017 19:30, Raul Sanchez wrote:

Your email is badly broken, something it terribly wrong with your line 
breaks.



Just wanted to report the following observations in generated code.
Target: __AVR_ATtiny85__
Version: AVR gcc 4.6.4


Quite old a version, dates 6 years back which is 6 major GCC versions.


Optimization level: -Os
 C source --
  uint16_t sum_adc;
  uint16_t analog;
  uint16_t adc_buffer[64];
  uint8_t adc_index;
...


This is not valid C. "..." may only occur as varargs function parameter


  sum_adc += ADC;


This is not valid C: Assignments may only occur inside functions.


  sum_adc -= adc_buffer[adc_index];
  analog = (uint16_t) (sum_adc >> 3);
...
--- end C source 
--- assembly code (with corresponding C statements) 
//  sum_adc += ADC;
lds r18,sum_adc
lds r19,sum_adc+1
in r24,36-0x20
in r25,36+1-0x20
add r24,r18
adc r25,r19
sts sum_adc+1,r25
sts sum_adc,r24
// sum_adc -= adc_buffer[adc_index];
lds r18,sum_adc  ; why not "mov r18,r24" "mov r19,r25" ?


Presumably, because you are using an outdated version of avr-gcc. The 
oldest version I have handy is avr-gcc 4.7, and with that, the generated 
code is different.  But very likely, your "missed optimization" roots 
somewhere in the extra obfuscation "...".



lds r19,sum_adc+1
lds r30,adc_index
ldi r31,lo8(0);why not "clr r31"?


Because LDI *,0 performs as well as CLR * but with the advantage that 
the former does not clobber SREG.



ldi r24,lo8(adc_buffer)
ldi r25,hi8(adc_buffer)
lsl r30
rol r31
add r30,r24
adc r31,r25
ld r20,Z
ldd r21,Z+1
sub r18,r20
sbc r19,r21
sts sum_adc+1,r19
sts sum_adc,r18
// analog = (uint16_t) (sum_adc >> 3);
lds r18,sum_adc   ; loading into r18, r19 the same values 
they alredy hold!
lds r19,sum_adc+1
lsr r19
ror r18
lsr r19
ror r18
lsr r19
ror r18


This shift appears to be invoked by -O2 or -O3, not by -Os as stated above.


sts analog+1,r19
sts analog,r18



Just for the recored, I compiled the following C code

#include 

uint16_t sum_adc;
uint16_t analog;
uint16_t adc_buffer[64];
uint8_t adc_index;

void func (void)
{
sum_adc += ADC;
sum_adc -= adc_buffer[adc_index];
analog = (uint16_t) (sum_adc >> 3);
}

with

$ avr-gcc-4.7 code.c -mmcu=attiny85 -S -O2

and the resulting code.s reads:

func:
in r24,0x4
in r25,0x4+1
lds r18,sum_adc
lds r19,sum_adc+1
add r24,r18
adc r25,r19
lds r30,adc_index
ldi r31,0
lsl r30
rol r31
subi r30,lo8(-(adc_buffer))
sbci r31,hi8(-(adc_buffer))
ld r18,Z
ldd r19,Z+1
sub r24,r18
sbc r25,r19
sts sum_adc+1,r25
sts sum_adc,r24
lsr r25
ror r24
lsr r25
ror r24
lsr r25
ror r24
sts analog+1,r25
sts analog,r24
ret


Johann



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Request: gcrt1.S with empty section .init9

[Georg-Johann Lay]

Marko Mäkelä schrieb:

Hallo Johann,

When you need optimizations at a lever where 2 instructions matter, 
then it's very likely you need a project specific start-up code and 
linker description anyway.  For example, you might truncate the vector 
table after the last vector used by the application.


Good idea, thanks! I did think about the interrupt vector table already, 
and that approach would allow me to trim it too.



For an easy fix, you can

1) Set up own start-up code omitting .init9

2) Provide own linker description file without input section .init9

3) Or, as a quick fix: 3a) Link with -Wl,--unique=.init9 so that
  .init9 becomes an output section, and then 3b) drop it by means
  of avr-objcopy --remove-section=.init9 foo.elf

All of these approaches require main in .init8 or earlier.


Right. I successfully had put main in .init3 already before posting.

The quick fix 3) works and shortens the program by 4 words and reduces 
stack usage by 2 bytes. The .init9 section would be emitted to the end 
of the ELF binary and indeed omitted from the avr-objcopy output.


[snip]
gcrt1.S would need yet another #if __GNUC__ >= 7 or so, and because 
toolchain distributors are usually not aware of such subtleties, you 
will observe complaints of "brain dead misoptimization" à la


 CALL main
 JMP exit
 CALL main
 JMP exit

throughout avr forums all over the net if someone bundles avr-gcc with 
the new feature together with avr-libc without conditional removal.


Right, so the risk could be greater than the savings.

One last note: As you are coming straight from asm programming, you 
will have a hard time reading the compiler generated code.


Actually I write C and C++ code bigger systems for living.


Ya, but on such systems you won't dive into generated assembly and
propose library changes when you come across a pair of instructions
you don't need in your specific context :-P

The 8-bit processors are just a hobby, and my ‘first love’ is the 6502, 
not the AVR. I was happy to learn that the avr-llvm changes were 
recently merged to the upstream repository. The experimental AVR target 
for clang generates some code, but it still needs work. I am hoping that 
one day clang generates similar code as avr-gcc. Also clang++ works, 
which is nice if you watched the CppCon 2016 talks touting zero-overhead 
abstraction, such as these:

https://www.youtube.com/watch?v=zBkNBP00wJE
https://www.youtube.com/watch?v=uzF4u9KgUWI
https://www.youtube.com/watch?v=D7Sd8A6_fYU


Maybe your are shocked enough to jump into contributing to GCC :-)


Not an impossible idea, but I find the idea of LLVM more promising,


Many developers find llvm more attractive than gcc because it is
not GPL and the newer code "pure doctrine" C++, whereas gcc might
deliberately use macros (for host performance) which many developers
find disgusting.  When you are coding a backend, it hardly matters
whether you write XX_FOO (y) or xx.foo (y), what's paramount is that
you are able to express what you want to express and get your job
done w.r.t. target features, target code performance, etc.

As gcc supports way more hosts and targets, in particular in realm of
embedded, I cannot well what's the best choice.  But yes, llvm
appears to be much more attractive and appealing these days.


because it could be easier to add other 8-bit processor targets there.


ymmv

So far I found the generated code surprisingly good. I feared that GCC 
would target a ‘virtual machine’ with 32-bit registers, but that does


GCC targets a target, and the description should match the real hardware
as close as it can :-)

not seem to be the case, or there are good peephole optimizations in 
place, and my input is so simple. I am using the Debian package gcc-avr 
1:4.9.2+Atmel3.5.3-1.


avr-gcc implements some peepholes, but imho peepholes are a last resort
optimization to clean up mess from other passes which didn't perform as
expected.

My only complaint is that avr-gcc does not allow me to assign a pointer 
to the Z register even when my simple program does not need that 
register for anything else:


register const __flash char* usart_tx_next asm("r28"); // better: r30:31


This is not the Z pointer, R28 is the Y register, which in turn might be
the frame pointer.  Even if avr-gcc allowed to reserve it globally, you
would get non-functional code.  Same with reserving Z.  __flash will
try to access via Z, and if you take that register away by fixing it
then the compiler will no more be able to use Z for its job.

My strong impression is that you are inventing hacks to push the
compiler into generating the exact same sequence as you would write
down as a smart assembler programmer.  Don't do it. You will come
up with code that it cluttered up with hard-to-maintain kludges
or it might even be non-functional (as with globally reserving
registers indispensable to the compiler).



ISR(USART_TX_vect)
{
 char c;
 if (!usart_tx_next);
 else if ((c = *usart_tx_next++))
   

Re: [avr-libc-dev] Request: gcrt1.S with empty section .init9

[Georg-Johann Lay]

Marko Mäkelä schrieb:
I am trying to move from assembler to C programming on the AVR while 
avoiding unnecessary overhead. I see that crt1/gcrt1.S contains the 
following code:


.section .init9,"ax",@progbits
#ifdef __AVR_ASM_ONLY__
XJMPmain
#else/* !__AVR_ASM_ONLY__ */
XCALLmain
XJMPexit
#endif/* __AVR_ASM_ONLY__ */


When you need optimizations at a lever where 2 instructions matter,
then it's very likely you need a project specific start-up code and
linker description anyway.  For example, you might truncate the
vector table after the last vector used by the application.

For an easy fix, you can

1) Set up own start-up code omitting .init9

2) Provide own linker description file without input section .init9

3) Or, as a quick fix: 3a) Link with -Wl,--unique=.init9 so that
   .init9 becomes an output section, and then 3b) drop it by means
   of avr-objcopy --remove-section=.init9 foo.elf

All of these approaches require main in .init8 or earlier.

The above references to main() and exit() are needed for complying with 
the C standard. However, I would tend to believe that normally programs 
written for bare metal (such as the AVR) never terminate. Such programs 
do not need an exit() function or even a call or jump to main().


One approach is to handle it similar to bits of the start-up code which
are only dragged if needed.  For example, if avr-gcc sees some stuff
being put into .bss or COMMON, it emits ".global __do_clear_bss" where
the latter is implemented in libgcc, cf. http://gcc.gnu.org/PR18145

Using a similar approach for, say, call_main will lead to the unpleasant
effect that you'll get the same code twice except you are using a libc
version which removed .init9 from gcrt1.S :-) and you still need to set
a command option to /not/ drag the call to main by having the compiler
/not/ emit the ".global __init9_call_main".

gcrt1.S would need yet another #if __GNUC__ >= 7 or so, and because
toolchain distributors are usually not aware of such subtleties, you
will observe complaints of "brain dead misoptimization" à la

  CALL main
  JMP exit
  CALL main
  JMP exit

throughout avr forums all over the net if someone bundles avr-gcc
with the new feature together with avr-libc without conditional removal.

Johann

One last note: As you are coming straight from asm programming, you will
have a hard time reading the compiler generated code.  Maybe your are
shocked enough to jump into contributing to GCC :-)

Would it be possible to introduce a (necessarily non-standard) option 
that allows the .init9 section of the runtime libary to be omitted?  
Then, the user could declare their infinite main loop something like this:


__attribute__((naked)) __attribute__((section(".init9")))
static
void
mainloop (void)
{
for (;;) do_my_stuff ();
}

This would save 3 instructions and some RAM (call main/ret, jump exit).

I am aware of the linker options -nostartfiles -nostdlib, but I do want 
the interrupt table and the sections .init0 through .init8.


Perhaps .linkonce or some clever use of .weak could help here? Or 
perhaps an alternative crt.o file could be provided for a minimal startup?


I would have tried to patch gcrt1.S myself, but I am having trouble 
setting up the build environment.


Best regards,

Marko


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #49984] fabs missing from libm implementation.

[Georg-Johann Lay]

Follow-up Comment #1, bug #49984 (project avr-libc):

Some text has been thrown away by the web interface:

* Linker error re. missing fabs implementation occurs of compiled with
-ffreestanding or with -fno-builtin

* Compiler error because of unknown key word "inline" occurrs in C90 mode.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #49984] fabs missing from libm implementation.

[Georg-Johann Lay]

URL:
  

 Summary: fabs missing from libm implementation.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Wed 04 Jan 2017 11:19:01 AM GMT
Category: Library
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.0.0
   Fixed Release: None

___

Details:

fabs is missing from the libm implementation:


#include 

float use_fabsf (float x)
{
return fabsf (x);
}

double use_fabs (double x)
{
return fabs (x);
}

int main (void) { return 0; }


* Compiling with -ffreestanding or with -fno-builtin will run against a linker
error  use_fabs.o: In function `use_fabsf':
use_fabs.c:(.text+0x24): undefined reference to `fabs' 
* Compiling with -std=c90 will run into "inline", which is not available in
C90:  avr/include/math.h:341:42: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'int'
 __ATTR_CONST__ static inline int isfinite (double __x)
  ^~~
/srv/local/gnu/install/gcc-6/avr/include/math.h:359:42: error: expected '=',
',', ';', 'asm' or '__attribute__' before 'double'
 __ATTR_CONST__ static inline double copysign (double __x, double __y)


"inline" should be replaced by __inline__.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Suggested improvement to

[Georg-Johann Lay]

On 02.01.2017 11:58, Marko Mäkelä wrote:

Hi all,

I am trying to revive my AVR hobby again, this time using the avr-libc,
mainly to introduce my kids to low-level programming. I am using a
couple of Arduino boards with the ATmega328P.

I started with a simple "hello world" program that outputs a
NUL-terminated string to the UART:

static void msg(const char* PROGMEM msg)
{
 char c;
 while ((c = pgm_read_byte_postinc ())) {
   UDR0 = c;
   loop_until_bit_is_set(UCSR0A, UDRE0);
 }
}


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. There is no guarantee for an optimal code being generated
for that example (as applies to any other C code).

Also notice that PROGMEM is just a variable attribute; its only
effect is to locate data to .progmem.data for variable definitions
which are attributed progmem. Specifying it with prototypes or
declarations is void.

The advantage is that less typing is needed and the feature is more
trqansparent w.r.t. code that only addresses generic address space,
e.g. to deflate to .rodata (which is located in RAM for avr) you
only need to

#define __flash /* empty */


Johann



For optimal AVR implementation, this would require some inline assembly:

static char pgm_read_byte_postinc (const char** PROGMEM s)
{
#ifdef __AVR_HAVE_LPMX__
 char c;
 asm volatile ("lpm %0, %a1+" "\n\t" : "=r" (c), "+z" (*s));
 return c;
#else
 return pgm_read_byte((*s)++);
#endif
}

I would like to have pre/post-increment/decrement variants of all
pgm_read_* functions in  that are natively supported on
some AVR platform. I wonder what would be the practical way to achieve
this. Contribute a patch myself? I hereby contribute the above idea to
the public domain.

Best regards,

Marko

___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev




___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Even faster decimal code

[Georg-Johann Lay]

George Spelvin schrieb:

Georg-Johann Lay wrote:

We only have multilib granularity, and there are not so many features
that are related to the flash size.  One is __AVR_HAVE_JMP_CALL__ which
applies to devices with >= 16 KiB flash.  The next size milestone is
__AVR_HAVE_ELPM__ which means >= 128 KiB.  The JMP + CALL looks
reasonable to me; I used it for 64-bit divisions in libgcc (which leads
to the funny situation that 64-bit division might run faster than a
32-bit division for the same values).


Interesting suggestion.  I could just use the multiplierless base-100 code,
which is smaller and still reasonably fast.

And thank you very much!  I knew that HAVE_JUMP_CALL meant that RJMP/RCALL
range wasn't enough, which means more than 12 bits of PC (2^13 bytes of
flash), but it had gotten lost in the forest of confusion.

I'm befuddled by all of the different architecture options and don't
understand the difference between most of them.  I've been slowly
downloading data sheets for different examples from gcc's list and
looking for differences, but it's a laborious process.  (That document
on avr-tiny started out with me documenting my realization that avr1
was something else.)

For example, does MUL support imply MOVW support?  (I've been assuming
so, but that's an easy edit.)


gcc sources provide a good overview of features per core, cf.

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr-devices.c?revision=243994=markup

A bit more comments for the structure which is initialized with
that data:

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr-arch.h?revision=243994=markup#l51

The devices are here:

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr-mcus.def?revision=243994=markup

Johann



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Even faster decimal code

[Georg-Johann Lay]

George Spelvin schrieb:

I mentioned last time trying doing something like this, and now
I have it coded up (as utoa_bytes()).

Input   Decimal
bitsmem_toa mem_tod itoanibbles bytes
 8   269 220 217 141 143
16   664 462 451 321 273
24  1294 783 838 608 432
32  205912191167 948 666
40  3059177516491395 941
48  41942373212718951217
56  54773069273324591551
64  69953822342031301902

It's larger (120 bytes, vs, 90 for the nibbles code), and has a bit more
startup overhead, but is quite fast.  I also have a 122-byte variant
which saves 1 cycle per pair of digits.  (1895 cycles for 2^64-1.)

I'm interested in this both for speed, and because it's a good fit to my
suggestion of saving RAM space buffering the converted digits in BCD.

So now that we have several good candidates, how to proceed?
What size/speed tradeoff should be the final choice?


After all it's you who will provide the final implementation and
testing, hence the final decision of what's appropriate, how much
effort will be put into the implementation, and what the final code
will look like is your decision, IMO.


Personally, I'm not worried about 30 bytes of code on enhanced AVRs with
a multiplier, and although I haven't coded up the combined algorithm, I
believe the whole thing is smaller than the ultoa_invert code it replaces.


We only have multilib granularity, and there are not so many features
that are related to the flash size.  One is __AVR_HAVE_JMP_CALL__ which
applies to devices with >= 16 KiB flash.  The next size milestone is
__AVR_HAVE_ELPM__ which means >= 128 KiB.  The JMP + CALL looks
reasonable to me; I used it for 64-bit divisions in libgcc (which leads
to the funny situation that 64-bit division might run faster than a
32-bit division for the same values).


But this is a judgement call, and I'd appreciate some other voices.


For smaller devices (e.g. no CALL but MUL some bytes can be squeezed
out by moving LDI of the constants to the inner loop which saves
PUSH + POP.  But on smaller devices, where xprintf is already a
major code consumer, a programmer might prefer something like ulltoa
over the bloat from xprintf.



#define __zero_reg__ r1
#define __tmp_reg__ r0

.macro DEFUN name
.section .text.\name,"ax",@progbits
.global \name
.func \name
\name:
.endm

.macro ENDF name
.size \name, .-\name
.endfunc
.endm

#if defined (__AVR_HAVE_JMP_CALL__)
#define XCALL call
#define XJMP  jmp
#else
#define XCALL rcall
#define XJMP  rjmp
#endif

.macro  wmov  r_dest, r_src
#if defined (__AVR_HAVE_MOVW__)
movw \r_dest,   \r_src
#else
mov \r_dest,\r_src
mov \r_dest+1,  \r_src+1
#endif
.endm

.text

[...u64toa_nibbles...]

;;;

;; This works simularly, but in base 100.  Every step, we take a
;; remainder <= 99, multiply by 256, and add the next byte (<=255).
;; The result is in the range 0 <= x < 25600.
;;
;; To divide by 100 with multiply:
;; x *   0x29 >> 12 == x/100 for 0 <= x <  1099
;; x *  0x51f >> 17 == x/100 for 0 <= x <  4699
;; x * 0x147b >> 19 == x/100 for 0 <= x < 43699
;; x * 0x28f6 >> 20 == x/100 for 0 <= x < 43699
;;
;; Using a multiplier one bit larger than strictly necessary gives us
;; a more convenient shift amount.  This is still small enough that we
;; can compute the high bits of the product we need in only two registers.
;;
;; The largest possible x = 0x63ff also has the largest possible
;; lsbyte, so it will give us the largest possible partial products.
;; Multiplying that by 0x28f6 requires four partial products:
;;
;;   FF *   F6 = F50A
;;   FF * 28-- =   27D8--
;; 63-- *   F6 =   5F22--
;; 63-- * 28-- =  F78
;;
;; The important thing is that the sum of the first three partial products
;; is 0x87ef0a, a 24-bit number.  So there is no need to propagate
;; carries into the msbyte.  We immediately discard the lsbyte of the
;; first partial product, and sum the others into a 2-byte register.
;; Then we throw away the lsbyte of that register and use it for the msbyte
;; of the final sum.

;; extern void utoa_bytes(char *pBuf, void *pNum, uint8_t Length)
;; Length in [1, 127]
#define ZH  r31
#define ZL  r30
#define XH  r27
#define XL  r26

#define Q2  r23 /* Byte 2 of 4-byte product */

> #define Q1 r22 /* Byte 1 (and 3) of 4-byte product */

Maybe it's a bit easier to grasp if

#define Q3Q1

and then use Q3 where byte #3 is computed (starting with "clr Q1")


#define Count   r21
#define Length  r20 /* Argument */
#define Rem r19
#define Hundred r18 /* Constant 0x64 = 100 */
#define Khi r17 /* Constant 0x28 =  40 */
#define Klo r16 /* Constant 0xf6 = 246 */
#define Num r15


DEFUN utoa_bytes
movwXL, r24 ; pBuf (output) to X
movwZL, r22 ; pNum (input) to Z
ldi Hundred, 100
pushKhi
   

Re: [avr-libc-dev] Printing octal (brain dump)

[Georg-Johann Lay]

On 20.12.2016 00:51, George Spelvin wrote:

Is 8000 ticks too slow?

Is 3000 ticks acceptable? And for what reason? Are 3000 acceptable just
because we have an algorithm that performs in 3000 ticks?

My strong preference is still to have a one-fits-all algorithm that
might very well be slower than an optimal one.  But hey, an ordinary
division of a 64-bit value by 10 already costs 2300 cycles, so why
should we hunt cycles just for printf...?


Well, I went and asked the customer.

As I mentioned, the motivating application is the TAPR time interval
counter (TICC).
Info:   http://tapr.org/kits_ticc.html
Source: https://github.com/TAPR/TICC(Not up to date.)
Manual: http://www.tapr.org/~n8ur/TICC_Manual.pdf

Basically, it timestamps input events to sub-nanosecond resolution.
It prints them with picosecond (12 decimal place) resolution.

E.g. fed a 1 Hz input signal, it might print:

104.897999794440
105.897999794492
106.897999794549
107.897999794551
108.897999794553
109.897999794552
110.897999794667

It would like to be able to run until 2^64 picoseconds wrap around in
213 days.


Just out of interest:  Isn't this overflow a problem? Hence isn't a
different representation warranted that doesn't overflow so soon?


Anyway, although it only prints every input transition, the main
processing loop has a 1 ms schedule to meet (it *can* print at up to
1 kHz, synchronized with the USB polling interval), and of the 16,000
clock cycles available in that ms, 8000 are currently spoken for.
8000 are available for formatting and output device drivers.

So yeah, they'd definitely prefer 4000 cycles to 8000.

But they're going to use custom code *anyway*, since they don't want
to wait for an avr-libc release, so that doesn't have to determine what
avr-libc does.


IMO that's a sound approach -- not only because of avr-libc release
schedule but also because you actually have to guarantee some upper
bound for the execution time (of conversion etc.).

What consumes the other 8000 cycles? Arithmetic?

Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Printing octal (brain dump)

[Georg-Johann Lay]

On 19.12.2016 23:05, George Spelvin wrote:

Georg-Johann Lay wrote:

George Spelvin schrieb:

It is unfortunately one instruction longer than ultoa_invert:

   textdata bss dec hex filename
188   0   0 188  bc ultoa_invert.o
190   0   0 190  be itoa_engine.o
208   0   0 208  d0 itoa_engine.o (+OPTIMIZE_SPEED)
212   0   0 212  d4 itoa_engine.o (without HAVE_MUL)



hmmm, that's quite some increase in code size...


Um... just how serious are you being?  I didn't think two bytes was
"quite some increase".  But compared to your alternatives... sigh,
I may have been wasting my time. :-(


oh, I was just misreading this table and thought that it means yet
another 200 bytes atop of ultoa_invert (just demonstrating that
it isn't worse than ultoa_invert).

But it appears you are intending to drop ultoa_invert which is great!


IMO octal conversion is so remote from any practical purposes that we
should use an algorithm that works for all radices.


Well, I sort of did that.  I did one that works for all power-of-two
sizes, and used it for both hex and octal.

Hex alone can be done much faster, but it isn't bad with the more
generic code.

...but you don't mean limited to powers of 2.  Just plain old binary long
division.  As I said when I started this, it's hard to escape certain
optimization habits.


This can be done in less than 70 bytes (variable length / radix
algorithm that operates on memory, no need for MUL, needs strrev.


H'm... let me have a poke at that.

The actual code changes are at the end, but I found 90 cycles
in one place, and 91 cycles + 1 instruction in another.

With those changes, here's a timing table, for values of the from 2^k - 1:

Decimal Hex mod100
Input   mem_toa itoamem_toa itoamem_toa
 8 bit   293 217 194  98 194
16 bit   700 451 527 187 440
24 bit  1342 8381008 276 748
32 bit  211911671637 3651142
40 bit  314316492414 4541697
48 bit  429021273339 5432301
56 bit  558527334412 6322991
64 bit  711534205633 7213743


Really funny results (just noticed you are using TABs and therefore
the whole table is rigged ;-))


That's really attractive for decimal.  Also, for not much extra code,
we could do the long division in base 100 (timing for only this part is
above), and then split that into 2 digits.

For hex, it's a bit painful.


So all is boiling down to the question what execution time is
acceptable or not:

Is 8000 ticks too slow?

Is 3000 ticks acceptable? And for what reason? Are 3000 acceptable just
because we have an algorithm that performs in 3000 ticks?


The answer, of course, is the same as to "Is 190 bytes too big?":
It Depends On The Application.

And as library writers, we don't *know* the application.  For many
applications, an AVR is too slow and they need an ARM or a DSP.

"Best" is somewhere on the convex hull of the space/time plot, but I
can't say where.

I was designing a helper function for printf, and that's a certain size:

   textdata bss dec hex filename
   1648   0   01648 670 ./avr/lib/avr4/vfprintf_flt.o
948   0   0 948 3b4 ./avr/lib/avr4/vfprintf_std.o
505   0   0 505 1f9 ./avr/lib/avr4/vfprintf_min.o

That, and the initial size of __ultoa_invert, kind of set the size scale
of what I was aiming for.

I have a faster algorithm that uses a 100-byte binary-to-BCD lookup table
to do everything two digits at a time.  Some applications might want that.


My strong preference is still to have a one-fits-all algorithm that
might very well be slower than an optimal one.  But hey, an ordinary
division of a 64-bit value by 10 already costs 2300 cycles, so why
should we hunt cycles just for printf...?


There is that.  But an intelligent programmer might only use 64 bits
for a final accumulation (of, say, 32x32-bit products), avoiding
even 64-bit multiplies.


Often programmers are bitten by their smartness when they observe
that avr-gcc generates "some" extra instructions around the core
64-bit arithmetic.  But that's a different story...


I played around some more; attached is a version that operates on
memory, variable length and radices, and doesn't need MUL. It's
called mem_toa and needs < 70 bytes / 8000 ticks for decimal.
The signed version adds yet another 40 bytes:


I made the following changes:

Since you already have pointers to the beginning and end of the string,
which is what the first half of strrev finds, a slight rearrangement of
that code (which saves space and 1 cycle per byte at the expense of one
extra loop iteration for odd-length inputs) would let you jump to the
middle of it.

Copying that code to the end of this to make my benchmarking
simpler, I get 7296 cycles to print

Re: [avr-libc-dev] Supporting AVR_TINY, draft HOWTO

[Georg-Johann Lay]

George Spelvin schrieb:

Having seen Georg-Johann's patch to enable more code on AVR-TINY, I'd
like to know how to do it myself.  So I've written the following draft
of a document explaining how, which might eventually be useful for
the project, but currently is for people to point out the error is.

One thing that jumps out at me is that the X_lpm macro should be extended
to invoke LD in case of __AVR_TINY__.  It looks very simpe.  Is there
a reason that nobody has done this yet?


Presumably because nobody has put effort in this :-)

And mybe because X_lpm is not needed on Tiny because you can avoid
progmem gobbledegook altogether.  All you need is an appropriate
linker description file, cf. "progmem" + "Reduced AVR Tiny cores" in

http://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html

I also filed https://sourceware.org/PR20849

But as it appears nobody is picking this up...


The smallest microcontrollers in the AVR family are the "AVR-tiny" group.

They implement a subset of the AVR architecture, and receive limited
support.

(Note that most processors sold as "ATtiny" are *not* the AVR-tiny
architecture.  Even the ATtiny13 is a full AVR core.  As of this writing,
the list of AVR-tiny processors is ATtiny 4, 5, 9, 10, 20 and 40)


There is yet another family of such Tinys like ATtiny104 (not yet
supported)

* 16 GPRs
* Support for SBIW, ADIW, MOVW
* Support for Z+q and Y+q addressing modes.

Hence the current "#ifdef __AVR_TINY__" idiom is not very robust
w.r.t. future extensions...  The ATtiny104 class of controllers
will require a new multilib (same for ATtiny817 class cores which
are 32-GPR cores also not yet supported and requiring multilib
extension).


Unlike the different "avr1" subset, the avrtiny *is* supported by GCC.
However, avr-libc has limited support.

Compilation for an AVR-tiny processor is identified by the __AVR_TINY__
symbol.  Large parts of the library are wrapped in "#ifndef __AVR_TINY__"
and generate an empty object file.  This is the basic requirement for
AVR-tiny non-support.


Presumably, this was a quick fix in order to get avr-libc built
and to be sure that no wrong code is generated as the 16-GPR cores
come with a different ABI w.r.t argument passing and call-used
registers.


However, if not too difficult, and makes sense, it's nice to make your
code usable on AVR-tiny.  This document explains how to do that.

The biggest issue is the fact that registers r0-r15 are not implemented.
Only registers r16-r31 exist.  Since these registers are used more heavily
anyway (they're the call-used registers available to leaf functions, and
can be used with the immediate instructions), many functions fit into
this limit already.  If your function can't fit, it's a good candidate
for #ifndef __AVR_TINY__.


Actually only R18-R19, R28-R28 are callee-saved.  R16 (tmp_reg) and
R17 (zero_reg) are fixed registers, i.e. never allocated by the
compiler.  Registers used for argument passing are R25..R18 instead
of R25..R8 for classical AVRs.


The AVR-tiny calling convention is almost the same as the regular one,
except that r16 is used for the temporary register instead of r0, and
r17 is used for the zero register instead of r1.  Note that this means
that the only call-saved registers are r28 and r29 (the Y pointer).


R18 and R19 are also callee-saved.


To make this easier in assembly code, the macros __tmp_reg__ and
__zero_reg__ are defined and map to r0/r1 on non-tiny processors, and
r16/r17 on tiny cores.

A second large difference is that tiny cores have only one address space.
They do not have the LPM instruction, but map flash to the data address
space starting at 0x4000.  Thus, all of avr-libc's *_P() functions
(which take program memory pointers) are unwanted, and just alias the
non-suffixed functions.

(TODO: Update the X_lpm macro to use LD in case of __AVR_TINY__)


Maybe the _P versions should not be provided at all; this would only
cause confusion.  Appears that after almost 20 years of progmem,
developers have problems to no more think in those terms ;-) as
everything is fine with a grain of salt in the linker script...


Another difference in the address space is that the registers are not
memory-mapped.  This is unlikely to be an issue; this feature is not
used much on avr-libc.  The address space looks like:

0x-0x003f: I/O registers (instead of 0x20-0x5f on other AVR)
0x0040-0x005f: SRAM (yes, 32 bytes!)
...unused
0x3f00-0x3f01: NVM lock bits
0x3f40-0x3f41: Configuration bits
0x3f80-0x3f81: Calibration bits
0x3fc0-0x3fc1: Device ID
0x4000-0x41ff/0x43ff: Program memory


Third, there are the instruction set differences.

AVR-tiny lacks all the usual extensions you might think of (multiply, DES
round, XMEGA load-and-update extensions), but also:

- LDD Y+offset and LDD Z+offset.  Only X, X+, -X, Y, Y+, -Y, Z, Z+ and -Z
  addressing modes are allowed.
- MOVW.  The existing macro X_movw can handle this, however.
- ADIW/SBIW.  The *only* 16-bit 

Re: [avr-libc-dev] Printing octal (brain dump)

[Georg-Johann Lay]

George Spelvin schrieb:

tl;dr: Beta code included below; it passes my initial testing.  I named
it _itoa_engine, following "ftoa_engine", but suggestions are welcome.
It is unfortunately one instruction longer than ultoa_invert:

   textdata bss dec hex filename
188   0   0 188  bc ultoa_invert.o
190   0   0 190  be itoa_engine.o
208   0   0 208  d0 itoa_engine.o (+OPTIMIZE_SPEED)
212   0   0 212  d4 itoa_engine.o (without HAVE_MUL)


hmmm, that's quite some increase in code size...

IMO octal conversion is so remote from any practical purposes that we
should use an algorithm that works for all radices.

This can be done in less than 70 bytes (variable length / radix
algorithm that operates on memory, no need for MUL, needs strrev.

So all is boiling down to the question what execution time is
acceptable or not:

Is 8000 ticks too slow?

Is 3000 ticks acceptable? And for what reason? Are 3000 acceptable just
because we have an algorithm that performs in 3000 ticks?

My strong preference is still to have a one-fits-all algorithm that
might very well be slower than an optimal one.  But hey, an ordinary
division of a 64-bit value by 10 already costs 2300 cycles, so why
should we hunt cycles just for printf...?

Also I think it's a good idea to have conversion routines like
[u]lltoa, so we need generic conversions anyway.

The current __ultoa_invert is quite verbose and also adds a noticeable
amount of code.  It performs faster than ultoa from stdlib.h, but is
this essential?

I played around some more; attached is a version that operates on
memory, variable length and radices, and doesn't need MUL. It's
called mem_toa and needs < 70 bytes / 8000 ticks for decimal.
The signed version adds yet another 40 bytes:

#define __zero_reg__ r1
#define __tmp_reg__ r0

.macro DEFUN name
.global \name
.func \name
\name:
.endm

.macro ENDF name
.size \name, .-\name
.endfunc
.endm

#if defined (__AVR_HAVE_JMP_CALL__)
#define XCALL call
#define XJMP  jmp
#else
#define XCALL rcall
#define XJMP  rjmp
#endif

.macro  wmov  r_dest, r_src
#if defined (__AVR_HAVE_MOVW__)
movw \r_dest,   \r_src
#else
mov \r_dest,\r_src
mov \r_dest+1,  \r_src+1
#endif
.endm

;; End preamble

#define pNum26
#define pBuf30

#define nBytes  20
#define Radix   18

#define Num 19
#define Count   21
#define nBits   22
#define Rem 23

;; extern void mem_toa (char *pBuf, void *pNum, uint8_t nBytes, uint8_t 
Radix);

.section .text.mem_toa,"ax",@progbits

DEFUN mem_toa
wmovpBuf, 24
wmovpNum, 22

.LnextDigit:
add pNum, nBytes
adc pNum+1, __zero_reg__
mov Count, nBytes
;; nBytes < 0  <==>  nBytes is unknown
ldi nBytes, -1
clr Rem

.LnextByte:
ld  Num, -X
ldi nBits, 8

.LnextBit:
;; Bit-wise construct (complement of) quotient into Num.
;; Bit-wise reconstruct Num into Rem.
rol Num
rol Rem

;; Reducing Rem mod Radix;  C = 0  <==>  reduction applied
cp  Rem, Radix
brcs1f
sub Rem, Radix
1:
dec nBits
brne.LnextBit

rol Num
com Num
st  X, Num

breq2f
sbrcnBytes, 7
mov nBytes, Count
2:
dec Count
brne.LnextByte

subiRem, -'0'
cpi Rem, '9' + 1
brlt3f
subiRem, '9' + 1 - 'a'
3:
st  Z+, Rem

sbrsnBytes, 7
rjmp.LnextDigit

st  Z, __zero_reg__

;; pBuf survived in R25:R24
XJMPstrrev

ENDF mem_toa

#define Minus1 pBuf

;; extern void mem_toa_signed (char *pBuf, void *pNum, uint8_t nBytes, 
uint8_t Radix);

.section .text.mem_toa_signed,"ax",@progbits

DEFUN mem_toa_signed
wmovpNum, 22
add pNum, nBytes
adc pNum+1, __zero_reg__
ld  Num, -X
tst Num
brpl9f

;; Negate pNum[] according to -N = ~N + 1 = ~N - (-1).
;; Carry is clear now because ADC above didn't overflow.
wmovpNum, 22
mov Count, nBytes
ldi Minus1, -1
1:
ld  Num, X
;; Must use EOR for complement because COM clobbers carry.
eor Num, Minus1
sbciNum, -1
st  X+, Num
dec Count
brne1b

wmovpBuf, 24
ldi Num, '-'
st  Z, Num
adiw24, 1
9:
XJMPmem_toa

ENDF mem_toa_signed

#undef Minus1
#undef pNum
#undef pBuf

#undef nBytes
#undef Radix

#undef Rem
#undef Num
#undef Count
#undef nBits



For purely decimal there's a version consuming 90 bytes only,
requiring MUL and which is only 10% slower than yours:

(Using the same preamble as the code above)

.section .text.u64toa_nibbles,"ax",@progbits

#ifdef __AVR_HAVE_MUL__
#define SPEED 1
#else
#define SPEED 0
#endif

#define pBuf26
#define pNum30
#define Length  r20

#define Rem r19
#define Quotr21
#define Count   r22
#define Num r23

#if SPEED
#   define Ten r16
#   define Ox67

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

[Georg-Johann Lay]

URL:
  

 Summary: [AVR_TINY]: Support 16-bit xtoa functons and more
string functions.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Fri 09 Dec 2016 01:02:16 PM GMT
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This improves support for AVR_TINY architecture.

It'a collection of low hanging fruit from from /libc/misc/ and libc/string,
mostly achieved by

* Using new X_sbiw instead of sbiw
* Replace r0 by __tmp_reg__


* common/asmdef.h (X_sbiw): New asm macro.
* common/macros.inc (X_sbiw): New asm macro.
* libc/misc/itoa.S: Don't restrict to !AVR_TINY.
* libc/misc/itoa_ncheck.S: Same.
* libc/misc/utoa.S: Same.
* libc/misc/utoa_ncheck.S: Same. And use X_sbiw instead of sbiw.
* libc/string/strlcat.S: Same.
* libc/string/strncat.S: Same.
* libc/string/strrev.S: Same.
* libc/string/strrchr.S: Same.
* libc/string/memchr.S: Don't restrict to !AVR_TINY.
[AVR_TINY]: Use "ld __tmp_reg__,-R" instead of "sbiw R,1".
* libc/string/strcat.S: Same.
* libc/string/strchr.S: Same.
* libc/string/memrchr.S: Don't restrict to !AVR_TINY.
(r0): Use __tmp_reg__ instead.
(adiw ZL,0): Use X_sbiw ZL,0 for comparison against 0 instead.
* libc/string/strchrnul.S: Don't restrict to !AVR_TINY.
(r0): Use __tmp_reg__ instead.
[AVR_TINY]: Use "ld __tmp_reg__,-R" instead of "sbiw R,1".
* libc/string/strpbrk.S: Same.
* libc/string/strstr.S: Don't restrict to !AVR_TINY.
Use X_sbiw instead of sbiw.
(chr2): Define to __tmp_reg__ instead of to r0.
* libc/string/strtok_r.S: Don't restrict to !AVR_TINY.
Use X_sbiw instead of sbiw.
(dch) [AVR_TINY]: Push / pop r18 around function.
[AVR_TINY]: Use "ld __tmp_reg__,R+" instead of "adiw R,1".




___

File Attachments:


---
Date: Fri 09 Dec 2016 01:02:16 PM GMT  Name: alibc-tiny-1.diff  Size: 12kB  
By: gjlayde
Patch against trunk


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

[Georg-Johann Lay]

Additional Item Attachment, patch #9187 (project avr-libc):

File name: alibc-tiny-2.diff  Size:12 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #8729] [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers.

[Georg-Johann Lay]

Follow-up Comment #1, patch #8729 (project avr-libc):

PING!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [untested PATCH] Save 11 instructions in vfprintf_flt.o

[Georg-Johann Lay]

George Spelvin schrieb:

As part of poking around vfprintf.c, I came across this low-hanging fruit.

I'm waiting to test all of my printf changes together, but I thought
I'd throw it out for comment early.  I presume this sort of thing is okay?

Basically, by reversing the sense of the FL_FLTUPP flag so it has the same 
polarity
as bit 5 of the ASCII character set, you can save some code.  Both getting the
flag from the format letter, and copying the flag to the output.

The difference is 16 bytes on <= avr31, 20 bytes on avr35, and 22 on the rest:

   /- Before -\/-- After -\
   text dec hextext dec hex filename
   18761876 75418601860 744 ./avr/lib/avr2/vfprintf_flt.o
   18761876 75418601860 744 
./avr/lib/avr2/tiny-stack/vfprintf_flt.o
   17021702 6a616821682 692 ./avr/lib/avr25/vfprintf_flt.o
   17021702 6a616821682 692 
./avr/lib/avr25/tiny-stack/vfprintf_flt.o
   19421942 79619261926 786 ./avr/lib/avr3/vfprintf_flt.o
   19481948 79c19321932 78c ./avr/lib/avr31/vfprintf_flt.o
   17701770 6ea17501750 6d6 ./avr/lib/avr35/vfprintf_flt.o
   17041704 6a816821682 692 ./avr/lib/avr4/vfprintf_flt.o
   17681768 6e817461746 6d2 ./avr/lib/avr5/vfprintf_flt.o
   18501850 73a18281828 724 ./avr/lib/avr51/vfprintf_flt.o
   18501850 73a18281828 724 ./avr/lib/avr6/vfprintf_flt.o
   17681768 6e817461746 6d2 
./avr/lib/avrxmega2/vfprintf_flt.o
   18381838 72e18161816 718 
./avr/lib/avrxmega4/vfprintf_flt.o
   18381838 72e18161816 718 
./avr/lib/avrxmega5/vfprintf_flt.o
   18381838 72e18161816 718 
./avr/lib/avrxmega6/vfprintf_flt.o
   18381838 72e18161816 718 
./avr/lib/avrxmega7/vfprintf_flt.o

Here's the diff.  (The changes of "/* no break */" to "/* FALLTHROUGH */"
are to silence GCC 7's new fallthrough warning.)

diff --git a/avr-libc/libc/stdio/vfprintf.c b/avr-libc/libc/stdio/vfprintf.c
index 3ba6f9a9..83849432 100644
--- a/avr-libc/libc/stdio/vfprintf.c
+++ b/avr-libc/libc/stdio/vfprintf.c
@@ -114,6 +114,22 @@
 })
 #endif
 
+/*

+ * Copy bit (src & smask) to (dst & dmask).
+ *
+ * Unlike "if (src & smask) dst |= dmask", which is also two instructions


This is confusing because the BST + BLD code below is not a replacement
for what the C code is indicating.  For example the C code never clears
the bit as opposed to BLD.


+ * and two cycles, this overwrites the destination bit (clearing it
+ * if necessary), and has fewer constraints; it can operate on the low
+ * 16 registers.
+ */
+#define COPYBIT(dst, dmask, src, smask)\
+asm(   "bst %2,%3"   \
+   "\nbld %0,%1" \
+   : "=r" (dst)  \


This is wrong because the old value of dst does not die here:
all bits except %1 are surviving. Correct constraint is "+r".


+   : "I" (ntz(dmask)),   \
+ "r" (src),  \
+ "I" (ntz(smask)))
+
 /* 
*/
 #if  PRINTF_LEVEL <= PRINTF_MIN
 
@@ -219,7 +235,7 @@ vfprintf (FILE * stream, const char *fmt, va_list ap)

goto ultoa;
  case 'p':
flags |= FL_ALT;
-   /* no break */
+   /* FALLTHROUGH */
  case 'x':
flags |= (FL_ALTHEX | FL_ALTLWR);
base = 16;
@@ -278,7 +294,7 @@ vfprintf (FILE * stream, const char *fmt, va_list ap)
 #define FL_ALTUPP  FL_PLUS
 #define FL_ALTHEX  FL_SPACE
 
-#define	FL_FLTUPP	FL_ALT

+#defineFL_FLTLWR   FL_ALT
 #define FL_FLTEXP  FL_PREC
 #defineFL_FLTFIX   FL_LONG
 
@@ -367,23 +383,22 @@ int vfprintf (FILE * stream, const char *fmt, va_list ap)

 # error
 #endif
 
-#if PRINTF_LEVEL >= PRINTF_FLT

-   if (c >= 'E' && c <= 'G') {
-   flags |= FL_FLTUPP;
-   c += 'e' - 'E';
-   goto flt_oper;
-
-   } else if (c >= 'e' && c <= 'g') {
-
+   if ((c >= 'E' && c <= 'G') || (c >= 'e' && c <= 'g')) {
+#if PRINTF_LEVEL < PRINTF_FLT
+   /* Float printf not supported; stub */
+   (void) va_arg (ap, double);
+   buf[0] = '?';
+   goto buf_addr;
+#else
int exp;/* exponent of master decimal digit */
int n;
unsigned char vtype;/* result of float value parse  */
unsigned char sign; /* sign character (or 0)*/
 # define ndigs c   /* only for this block, undef is below  */
 
-	flags &= ~FL_FLTUPP;

+   COPYBIT(flags, FL_FLTLWR, c, 'e'-'E');
+   c |= 'e' - 'E';
 
-	  flt_oper:

if (!(flags & FL_PREC))
prec = 6;
flags &= 

Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED

[Georg-Johann Lay]

On 06.12.2016 23:59, Joerg Wunsch wrote:

As George Spelvin wrote:


Perhaps the two different reduction-mod-5 schemes should depend on
OPTIMIZE_SPEED?


Doesn't really matter much.  Since the library is pre-compiled, you
cannot map it to the user's -Ox compiler option anyway.

As Johann already explained, most AVR users care for saved flash
and RAM more than for saving a few CPU cycles.


Skimming generated code, IMO modules like vfprintf should be
compiled with -mcall-prologues; at least the versions that
supply float support (as many float functions use call-prologues
anyway).

Johann




___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Interested in 64-bit printf support?

[Georg-Johann Lay]

On 08.12.2016 00:34, George Spelvin wrote:

Georg-Johann Lay <a...@gjlay.de> wrote:

The algo is rather slow because it always iterates over all
digits, i.e. it won't run faster for small numbers.

Have fun!

Code size is ~140 bytes.


Well, it's bigger (140 > 124), slower, and doesn't handle sizes *other*
than 64 bits, so that's not terribly useful.

I think you could shrink it a bit, replacing these 16 instructions of messy
digit output code (why are you looping incrementing DIGIT2 when you know it
is never more than 1?):


It's a transcript from antique C-code for 32-bit values, which
don't have this nice property.  I shouldn't write code to late in
the evening.

And I didn't actually intend nor expect to beat your code, just was
interested in how far it can be pushed...


clr DIGIT2
1:
inc DIGIT2
subiDIGIT, 10
brcc1b

brts2f
;; T = 0 is the first round.  Output the high digit if it's not '0'.
set
subiDIGIT2, 1-'0'
;; Initialize nonZero.  We only output digits if we saw a digit != '0'.
mov nonZero, DIGIT2
cpi nonZero, '0'
breq2f
st  X+, DIGIT2
2:
;; Output digits except the highest (except that for 10^19).
subiDIGIT, -10-'0'
or  nonZero, DIGIT
;; We only output digits if we saw a digit != '0', i.e. strip leading 
'0's.
cpi nonZero, '0'
breq3f
st  X+, DIGIT

With these 9 instructions:
cpi DIGIT, 10   ;; First "digit" can be as high as 18
brcs2f
ldi nonZero, '1';; '1' is non-zero, which is perfect
st  X+, nonZero
subiDIGIT, 10
2:
or  nonZero, DIGIT
breq3f  ;; Don't print leading zeros
subiDIGIT, -10-'0'
st  X+, DIGIT
3:

With this, you can also delete the leading clt.  It eliminates DIGIT2,
but unfortunately that doesn't save a spill.  You also have to adapt
the final "lone zero" printing code to print if nonZero == 0, but that's
the same size.

Also, this is just silly:
dec Count
cpseCount, Zero
rjmp.Loop

"dec" sets the zero flag, so that can just be "dec Count $ brnz .Loop".

And finally, your multiply loop is wasting two instructions:

mul A0,Ten  $  mov A0,r0  $  add A0,Cy  $  mov Cy,r1  $  adc Cy,Zero
mov __tmp_reg__,A0
mov A0,A1   $  mov A1,A2  $  mov A2,A3  $  mov A3,A4
mov A4,A5   $  mov A5,A6  $  mov A6,A7  $  mov A7,__tmp_reg__

"mov A0,r0" and "mov __tmp_reg__,A0" are cancelling each other out


Nice spotting!


and should both be deleted (with the "A0 += Cy" adjusted to add to r0,
of course).  Just make it:

mul A0,Ten  $  mov A0,r0  $  add r0,Cy  $  adc r1,Zero  $  mov Cy,r1
mov A0,A1   $  mov A1,A2  $  mov A2,A3  $  mov A3,A4
mov A4,A5   $  mov A5,A6  $  mov A6,A7  $  mov A7,r0


That saves 22 bytes, leaving it 6 bytes smaller than mine.  Nice to have 
available!


The reworked version comes up with 110 bytes (still asserting MUL).

But I like your approach more, as it does not rely on special properties
of the numbers and comes with some nice ideas.

perf-metering with avrtest reveals a run time from ~3100 up to < 4800 
ticks; high as expected.


Johann

#define __zero_reg__ r1

.macro DEFUN name
.global \name
.func \name
\name:
.endm

.macro ENDF name
.size \name, .-\name
.endfunc
.endm

.macro  wmov  r_dest, r_src
#if defined (__AVR_HAVE_MOVW__)
movw \r_dest,   \r_src
#else
mov \r_dest,\r_src
mov \r_dest+1,  \r_src+1
#endif
.endm

#if defined (__AVR_HAVE_JMP_CALL__)
#define XCALL call
#define XJMP  jmp
#else
#define XCALL rcall
#define XJMP  rjmp
#endif

.text

#define A0  18
#define A1  A0 + 1
#define A2  A0 + 2
#define A3  A0 + 3
#define A4  A0 + 4
#define A5  A0 + 5
#define A6  A0 + 6
#define A7  A0 + 7

#define BUF026
#define BUF1BUF0 + 1

#define Digit   31

#define Carry   31
#define Ten 30
#define Count   29
#define nonZero 28

;;; extern void put64 (uint64_t A, char *buf);
;;; This function writes up to 21 characters (including final '\0') to buf.

DEFUN put64
pushr28
pushr29

wmovBUF0, 16
ldi Count, 19
ldi nonZero, '0'

.Loop:
;; A[] -= 1.000.000.000.000.000.000  as often as we can.
;; Digit will hold the net number of subtractions (plus '0').
ldi Digit, '0'-1
1:
inc Digit
;;  1.000.000.000.000.000.000 = 0DE0 B6B3 A764 
subiA2, 0x64
sbciA3, 0xa7
sbciA4, 0xb3
sbciA5, 0xb6
sbciA6, 0xe0
sbciA7, 0xd
brcc1b

;; -1.000.000.000.000.000.000 = F21F 494C 589C 
;; Undo the underflow from above
subiA2, 0x9c
sbciA3, 0x58
sbciA4, 0x4c
sbciA5, 0x49
sbciA6, 0x1f
sbci  

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

[Georg-Johann Lay]

George Spelvin schrieb:

Either Debian is running patches atop GNU, or avr-libc test suite has
not been adjusted to factor out different gcc versions.


The Debian diffs can be found in the right-hand column of
https://packages.debian.org/sid/gcc-avr
specifically
http://http.debian.net/debian/pool/main/g/gcc-avr/gcc-avr_4.9.2+Atmel3.5.3-1.diff.gz


That comes with external references, e.g. all the XMEGA stuff and many
others like 55-gcc-4.3.0-attiny167.patch etc.

I'd propose you use GCC trunk HEAD and Binutils master; if that and
rerunning bootstrap does not do the trick, you found a bug and I
wonder how the folks are testing avr-libc :-)


Presumably, someone adds this option by hand, because if avr-gcc
added it the error message would be "ld: cannot find -latmega128".


That is indeed what runtest.sh does.  Here's the result of "bash -x ./runtest.sh 
-s".
The actual compiler invocation is the tenth last line.

[...]
+ avr-gcc -Wundef -I. -gdwarf-4 -W -Wall -pipe -Os -isystem ../../include 
-nostdlib -std=gnu99 -mmcu=atmega128 -o aux.elf time/aux.c 
../../avr/lib/avr51/libc.a ../../avr/lib/avr51/libm.a 
../../avr/lib/avr51/atmega128/libatmega128.a -lgcc
avr-gcc: error: ../../avr/lib/avr51/atmega128/libatmega128.a: No such file or 
directory


Presumably, it goes like follows: avr-libc detects from the version of
avr-gcc that it does not add -latmega128 and hence skips building
libatmega128.a, hence no such .a in the avr-libc build tree.

Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

[Georg-Johann Lay]

George Spelvin schrieb:

Thanks for the help.  It's not on the critical path yet, but I would
like to get some self-tests working.


This looks strange. With avr-libc from trunk and a reasonable
up to date avr-gcc (5.2+) the crt should be located in

$prefix/avr/lib/avr51/crtatmega128.o


Perhaps the fact (I mentioned in in passing in a previous message to
the list) that I'm using 4.9.2 (because that's what Debian has packaged)
has had an effect?


avr-gcc 4.9 shouldn't try to link against libatmega128.a at all, and
this is how my 4.9.2-pre1 (home-brew canadian cross) behaves.
avr-gcc 4.9 defines a spec function to add -lm128, but that spec
function is dead :-)

http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/avr/avr.h?view=markup#l495

The question is where the libatmega128.a is coming fromcomes from...
Either Debian is running patches atop GNU, or avr-libc test suite has
not been adjusted to factor out different gcc versions.

Presumably, someone adds this option by hand, because if avr-gcc
added it the error message would be "ld: cannot find -latmega128".


Another thing is that I haven't installed *anything* yet; there is no
$prefix/avr directory.  I was assuming that the tests would run against
the built tree *before* installation.  (If I can't run "make check"
before "make install", that smells like a bug that needs fixing.)


Well, I never ran avr-libc tests, I am just doing the avr-gcc thing...

Maybe for the time being it's the simplest approach to build your own
GCC and Binutils all with same $prefix in $HOME, dito for libc.

avr-libc can build against non-installed avr-gcc by
CC="$build/gcc/xgcc -B$build/gcc" where $build refers to the gcc
build dir, which should never be in $source b.t.w.

Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Interested in 64-bit printf support?

[Georg-Johann Lay]

On 04.12.2016 23:53, George Spelvin wrote:

The developers of the TICC time interval counter are having
a problem printing 64-bit integers:
https://github.com/TAPR/TICC/blob/master/TO-DO.txt

I went to work figuring out how to do that conversion, and after some
false starts, came up with some quite efficient arbitrary-precision
printing code.  It's small, fast, and works for any number of bytes.
(Implementation currently limited to 255 bytes.)

The code, in its current state, is appended; it's been tested extensively
on x86 and more lightly on simulavr.  Any comments from experienced AVR
programmers is definitely appreciated.  Like the current __ultoa_invert,
it formats the number backward in a caller-provided buffer.

It's (currently) slightly larger, but slightly faster than __ultoa_invert.
Timing in cycles for a simulated atmega1280:

Input   genprint__ultoa_invert
0   160
0xff316 480
0x  584 792
0xff10051260
0x  14341572
0xff2024
48 ones 2626
56 ones 3286
64 ones 4103

I could just pass this over to the TICC project, but is there any interest
in me making the necessary overhauls to vfprintf to incorporate this?

I'd have to change vfprintf to pass around a pointer and length internally
rather than copying the value.  The printing code requires the input
in a modifiable little-endian buffer, but that's how varargs works on
AVR anyway.  (Adding the hex/octal and negative number handling is quite
simple.)


It it possible to do it with the same code and not special-casing 
different radices?  Even if the code runs slower (which is not really 
important for output routines) the code size might drop.



If I get really sneaky, I could eliminate the output buffer by having
it push the formatted number on the stack and call down to an output
routine that supplies the necessary prefix padding once the length is
known. But that might not be doable in C unless there's a way to force
allocation of a stack frame.


(If anyone cares, I have some other code for 16- and 32-bit numbers based
on the ideas at http://homepage.divms.uiowa.edu/~jones/bcd/decimal.html.
It converts 2 digits at a time, using a 100-byte binary-to-BCD lookup
table, but is a lot larger, extending it to 64 bits is a mess, and doing
without a hardware multiplier bloats it with shift-and-add sequences.)


Usually, we are after code-size, not speed; in particular for such 
output and conversion routines.



#if __AVR_ARCH__


In the library you'll have to protect the code against AVR_TINY, i.e.

#ifndef __AVR_TINY__


typedef _Bool bool;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
#define false (bool)0
#define true (bool)1


Dunno how libc's modules are compiled, but they are using stdint.h all 
over the place, so stdbool.h and stdint.h should be in order, no?



/* Reduce a byte mod 5. */
static uint8_t __attribute__((const))
mod5(uint8_t x)
{
#if __AVR_ARCH__
uint8_t tmp;
/* Reduce x mod 15.  We add the high halves, to get a carry. */
asm("mov __tmp_reg__,%0"
"\nswap __tmp_reg__"
"\ncbr %0,15"
"\nadd %0,__tmp_reg__"
"\ncbr %0,15"
"\nswap %0"   /* Swap and add carry bit to low */
"\nadc %0,__zero_reg__"   /* End-around carry */
: "+d" (x) :: "r0");
#else
x = (x >> 4) + (x & 0xf); /* 1 <= x <= 30 */
x = (x >> 4) + (x & 0xf); /* 1 <= x <= 15 */
#endif
/* 1 <= x <= 15; now for final reduction mod 5 */
if (x >= 10)
x -= 10;/* 0 <= x <= 9 */
if (x >= 5)
x -= 5; /* 0 <= x <= 4 */
return x;
}


Again, we can safe code size by slightly slowing things down, e.g.

mod5 (uint8_t x)
{
#if __AVR_ARCH__
asm ("0: $ subi %0,%1 $ brcc 0b $ subi %0,%n1" : "+d" (x) : "n" (35));
asm ("0: $ subi %0,%1 $ brcc 0b $ subi %0,%n1" : "+d" (x) : "n" (5));
return x;
#else
...

The intermediate step via 35 is not essential, it's just a speed-up.


do {
uint16_t accum;
uint8_t i = len;
bool lsbit = false;

/*
 * Pass 1, msb-to-lsb: divide bin[] by 2, and return the
 * value mod 10 (the new value mod 5, combined with the
 * previous lsbit).
 */
digit = 255;/* Could also be zero */


If 0 is just as fine, use 0.  I am getting better code size and less 
stack usage (using -mcall-prologues).



#if __AVR_ARCH__
/*
 * The one implementation hassle is the need for two
 * carry bits.  One for the shift, and the other for
 * the end-around carries modulo 255.
 *
 * Unfamiliar AVR inline 

[avr-libc-dev] [bug #49565] at43usb320 in wrong multilib set

[Georg-Johann Lay]

URL:
  

 Summary: at43usb320 in wrong multilib set
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Wed 09 Nov 2016 02:03:26 PM GMT
Category: Library
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Build system
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.0.0
   Fixed Release: None

___

Details:

Mentioned device is filed in avr31 which is for "old" 180KiB devices, but
AT43usb320 has only support for 64 KiB program memory.  In particular, it has
no support for ELPM.

This issue is also present in avr-gcc, cf. http://gcc.gnu.org/PR78275




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #45701] redundant stack initialization in crt1.o

[Georg-Johann Lay]

Follow-up Comment #1, bug #45701 (project avr-libc):

The current startup code allows a custom value for SP init by defining symbol 
__stack , for example:  -Wl,--defsym,__stack=0x123  or by defining that symbol
in a custom linker description file.

Moreover it is not uncommon to (re)start an application by jumping to 0x0,
e.g. from a bootloader.  If the startup code was "optimized" as proposed, that
code will no more work as expected.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #48473] FAQ: "How do I relocate code to a fixed address?" can be misleading

[Georg-Johann Lay]

Follow-up Comment #1, bug #48473 (project avr-libc):

If inlining is a problem, then the same applies to cloning.  Hence the docs
should also recommend  __noclone__  and  __no_icf__  (provided gcc supports
these attributes).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

[Georg-Johann Lay]

Jacob Moroni schrieb:

Got it. I'll add the support to GCC's libatomic then send it in. Thanks.


Here is some introduction on contributing to GCC:

http://gcc.gnu.org/contribute.html

As it is hard to follow discussions in top-posting style, that style is 
usually voided :-)


https://en.wikipedia.org/wiki/Posting_style#Top-posting


On Jun 25, 2016 5:13 PM, "Joerg Wunsch" wrote:


As Georg-Johann Lay wrote:


As libatomic will need close cooperation with the compiler, I'd
recommend to add it to GCC.


That would be my recommendation, too.  If it's a compile feature,
it would better be there.  Perhaps it's then even possible to find
a more efficient implementation (no function call overhead).

cheers, Joerg   .-.-.   --... ...--   -.. .  DL8DTL


There are quite some standard insns for atomics known to gcc, cf. 
"atomic_" insns in


http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html

This can avoid overhead of function calls.  But I still don't see the 
great advantage of using stdatomic over the "classical" util/atomic.h 
from avr-libc.  For C++ we don't have portability because there is no 
libstdc++ generated for avr, not even libsupc++...


Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Need new avr-libc release

[Georg-Johann Lay]

Sivanupandi, Pitchumani schrieb:

-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: 25 January 2016 21:56
To: Joerg Wunsch <joerg_wun...@uriah.heep.sax.de>; avr-libc-dev@nongnu.org;
Sivanupandi, Pitchumani <pitchumani.sivanupa...@atmel.com>; Selvaraj,
Senthil_Kumar <senthil_kumar.selva...@atmel.com>
Subject: Re: [avr-libc-dev] Need new avr-libc release

Joerg Wunsch schrieb:

As Sivanupandi, Pitchumani wrote:


Can you make a new release?

I can give it a try, to see whether "make distcheck" works out of the
box.

As a quick fix, it could be pointed out on AVR-LibC's front page that
1.8.1 won't work with GCC v5.2+ and at least SVN trunk xyzw is needed with
GCC v5.2+.

FYI, GCC v5.0 and v5.1 won't work and should not be used.


Current trunk should work with GCC v5.x or later. It auto detects the gcc
version and builds accordingly.

>
> Ref: https://savannah.nongnu.org/bugs/?44869

The point is that v5.1 itself is broken, namely the new specs stuff.

v5.2+ uses a different directory layout to fix the problems, and 
avr-libc adjusted to the new layout.  But the problem with v5.1 was 
inherently due to the old directory layout, and whatever avr-libc does 
cannot work around these problems of v5.1 (even worse for v5.0).


I was quite surprised back then when I saw that effort was put into 
avr-libc just to make it work together with a compiler that was known to 
be broken...



http://svn.savannah.nongnu.org/viewvc?view=rev=avr-libc=2475

Regards,
Pitchumani



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Need new avr-libc release

[Georg-Johann Lay]

Joerg Wunsch schrieb:

As Sivanupandi, Pitchumani wrote:


Can you make a new release?


I can give it a try, to see whether "make distcheck" works out
of the box.


As a quick fix, it could be pointed out on AVR-LibC's front page that 
1.8.1 won't work with GCC v5.2+ and at least SVN trunk xyzw is needed 
with GCC v5.2+.


FYI, GCC v5.0 and v5.1 won't work and should not be used.


What's the opinion of others, are there any show-stoppers in the
current state of the tree?



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #8728] [stdio.h] Use __extension__ with long long.

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/patch/?8728

 Summary: [stdio.h] Use __extension__ with long long.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mi 26 Aug 2015 13:20:27 GMT
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This helps avr-gcc testing as the GCC testsuite contains many C90 tests.



___

File Attachments:


---
Date: Mi 26 Aug 2015 13:20:27 GMT  Name: avrlibc-stdio-longlong.diff  Size:
540B   By: gjlayde

http://savannah.nongnu.org/patch/download.php?file_id=34738

___

Reply to this item at:

  http://savannah.nongnu.org/patch/?8728

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [patch #8729] [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers.

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/patch/?8729

 Summary: [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix
namespace of identifiers.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mi 26 Aug 2015 13:28:10 GMT
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This fixes the namespaces of: signal, interrupt, naked, used, alias, asm,
externally_visible.  It moves them from the namespace of the application to
the one of the implementation (use __asm__ for example).

It also introduces 2 new Macros for function attributes, namely ISR_FLATTEN
for __flatten__ and ISR_NOICF for __no_icf__.

Instead of hard-coded selecting between jmp and rjmp it uses %~jmp in
asm.




___

File Attachments:


---
Date: Mi 26 Aug 2015 13:28:10 GMT  Name: avrlibc-interrupt-attributes.diff 
Size: 6kB   By: gjlayde

http://savannah.nongnu.org/patch/download.php?file_id=34739

___

Reply to this item at:

  http://savannah.nongnu.org/patch/?8729

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] User-manual/optimization.html

[Georg-Johann Lay]

Am 06/18/2015 um 02:58 PM schrieb David Brown:

Hi,

In the user manual:

http://www.nongnu.org/avr-libc/user-manual/optimization.html

there is a discussion about the unexpected code generation from:

#define cli() __asm volatile( cli ::: memory )
#define sei() __asm volatile( sei ::: memory )
unsigned int ivar;
void test2( unsigned int val )
{
val = 65535U / val;
cli();
ivar = val;
sei();
}

This came up recently in a gcc-help mailing list question - the problem
is that the call to __udivmodhi4 may be generated after the cli
instruction, disabling interrupts for longer than necessary.  The web
page says there is no way to force the desired code generation (with
val being calculated before cli).


If my recollection is right -fno-tree-ter was a fix as the code motion was 
performed by respective pass.


Some technical background:  The avr back-end pretends it implements integer 
division and remainder by providing respective insns, hence the middle-end 
assumes that the division can be performed with a few instructions.


Rationale is that avr-libgcc has many hand-written and -optimized assembler 
routines, and many of these routines have a smaller register footprint than 
required by the ABI.  avr-gcc uses this information to implement respective 
features (like div) as a transparent library call together with clobbering all 
destroyed registers and providing arguments to respective registers by hand.


This results in much smaller code, and many functions become leaf functions. 
Without that approach any function using a feature as basic as integer 
multiplication would generate proper library calls similar to ordinary functions.


If division was a library call it wouldn't be moved across the memory clobber, 
but the result would considerably increase in code size.




However, there /is/ a way to get the right results - using a fake
assembly input to force the calculation:

#define cli() __asm volatile( cli ::: memory )
#define sei() __asm volatile( sei ::: memory )
unsigned int ivar;
void test2( unsigned int val )
{
 val = 65535U / val;
 asm volatile( ::  (val));
 cli();
 ivar = val;
 sei();
}

The memory clobber on cli() and sei() ensures that no memory operations
are moved before or after those statements.  But as already noted, the
memory clobber does not affect non-memory operations such as
calculations or register-only manipulation.


The problem is that one has to know respective dependencies which is usually 
not the case.  Just consider the case where the cli() is part of an inlined 
function and the division or multiplication is performed by the caller.  or the 
multiplication is part of an address computation like in  val = 
list-next-next-next-val.



My recommendation is to try -fno-tree-ter before cluttering up code with ugly 
patterns.


Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [bug #43828] wdt.h: Wrong inline assembler arguments

[Georg-Johann Lay]

Am 04/30/2015 um 12:09 PM schrieb Sivanupandi, Pitchumani:

-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Wednesday, April 29, 2015 3:11 PM
To: Sivanupandi, Pitchumani
Cc: avr-libc-dev@nongnu.org
Subject: Re: [bug #43828] wdt.h: Wrong inline assembler arguments

Am 04/28/2015 um 12:53 PM schrieb Sivanupandi, Pitchumani:

Hi Johann,

...

Below is the patch to fix this issue.

diff --git a/avr-libc/include/avr/wdt.h b/avr-libc/include/avr/wdt.h
index [...]


Is this change Ok?


That patch is malformed, presumably because of missing / spurious spaces or
new lines.


Attached the patch.


Several notes:

Some asm use ORI with operand of constraint r, e.g. temp or temp_reg in 
wdt_disable().  Correct constraint is d (or a subset thereof).


Some flag values are using constraint I which is 0 = * = 63.  Dunno whether 
there are devices that have flags located in bit 6 or 7.  Proposed constraint 
is n, I doesn't have any benefit here.


Some memory (non-I/O) addresses use M as constraint which is 0 = * = 0xff. 
 Dunno whether there are devices that have SFRs with memory addresses outside 
that range.  LDS and STS are fine with i (known at link time) or even n 
(known at compile time).  M has no advantage here.


All the asms are changing memory but don't mention that.  Usually it is not 
wanted that (non-volatile) memory accesses are dragged across the inline asm. 
Easy fix is to clobber memory, more exact is to explicitly describe the effect 
on memory.  For example, one sequence reads:


  sts %0, %2
  : /* no outputs */
  : M (_SFR_MEM_ADDR(_WD_CONTROL_REG)),

Explicit memory modelling would read something like:

  sts %1, %3
  : +m (_WD_CONTROL_REG)
  : n (_SFR_MEM_ADDR(_WD_CONTROL_REG)),


There are magic values like 0xd8, 0x8, 0x7.  Can't these be represented by 
macros from io.h?


Named asm operands are easier to grasp, but they use / expose identifiers which 
are in the namespace of the application, not in the namespace of the 
implementation.  For example, the code will raise strange errors if


#include avr/wdh.t

#define tmp
#define temp
#define SIGNATURE 0x1234

void nofun (void)
{
wdt_enable (0);
}


Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [bug #43828] wdt.h: Wrong inline assembler arguments

[Georg-Johann Lay]

Am 04/28/2015 um 12:53 PM schrieb Sivanupandi, Pitchumani:

Hi Johann,

...

Below is the patch to fix this issue.

diff --git a/avr-libc/include/avr/wdt.h b/avr-libc/include/avr/wdt.h index
[...]


Is this change Ok?


That patch is malformed, presumably because of missing / spurious spaces or new 
lines.


Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

[Georg-Johann Lay]

Am 04/27/2015 um 04:52 PM schrieb Sivanupandi, Pitchumani:

From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de]

Yes. If we release from revision r2473 it will work with gcc-5.1, not

trunk.


If we release from last revision r2474, it will work with gcc trunk, not

gcc-5.1.


It will also work with 5.1.1 and up.


Following table illustrates the crt file and device library name/layout
expected by gcc. AVR-LibC configure is updated to follow this layout.

Example: atmega1280
++-+-+-+
|| GCC  5.0.0 | GCC 5.1.0   | Others  |
++-+-+-+
| crt file   | crtm1280.o  | crtm1280.o  | crtatmega1280.o |
++-+-+-+
| device library | | dev/atmega1280/libdev.a | libatmega1280.a |
++-+-+-+


avr-gcc 5.1.0 will use dev/atmega1280/crt1.o%s as start file where %s means to 
search in multilib paths.


For the change see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296#c10
which is also a backport to 5.1.1+

Johann


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

[Georg-Johann Lay]

Follow-up Comment #5, bug #44869 (project avr-libc):

The GCC 5 release notes say that when avr-gcc is used together with AVR-LibC,
that requires at least avr-gcc 5.2:

https://gcc.gnu.org/gcc-5/changes.html

___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?44869

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

[Georg-Johann Lay]

Follow-up Comment #1, bug #44869 (project avr-libc):

If you want to use avr-gcc 5.0 or 5.1 with avr-libc, avr-libc must not be
newer than svn r2473.

If you want to use svn r2474 or newer, you need avr-gcc 5.2 or up.

___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?44869

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #44574] Place device-specific libraries in their multilib directory.

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/bugs/?44574

 Summary: Place device-specific libraries in their multilib
directory.
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mi 18 Mär 2015 19:10:31 GMT
Category: Library
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Build system
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.0
   Fixed Release: None

___

Details:

The current naming scheme for device-specific libraries

dev/DEVICE/libdev.a

bears the problem that it won't work if the install path contains spaces (as
not uncommon under MS windows).

This is actually not an avr-libc problem but a problem with avr-gcc.  However,
the new device-specific spec files have very limited means to handle paths
containing spaces.

Wrapping the path in a space-escaping spec function does not work because that
would require more than one level of escaping (which is not possible because
the escape character would become a part of the path name).

One approach to make avr-gcc 5.0 + avr-libc work with paths containing spaces
is renaming the device library to

libDEVICE.a

and installing it in its multilib directory, i.e. in the multilib subdirectory
as reported by

$ avr-gcc -mmcu=DEVICE [options] -print-multi-directory

For devices not natively supported by avr-gcc, avr-libc would have to know the
correct multilib subdir.

Rationale is that multilib subdirs are common library search paths.  Hence the
device library could then be specified as

-lDEVICE

and thus without explicit absolute path which works as expected.





___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?44574

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #44514] Wrong build option '-mtiny-stack' instead of '-msp8'

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/bugs/?44514

 Summary: Wrong build option '-mtiny-stack' instead of '-msp8'
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mi 11 Mär 2015 19:37:20 GMT
Category: Build Infrastructure
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Build system
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.0
   Fixed Release: None

___

Details:

Libraries are being built with a wrong option -mtiny-stack:

devtools/gen-avr-lib-tree.sh:49

CFLAGS_TINY_STACK=-mtiny-stack -mcall-prologues -Os


To query avr-gcc for it's multilib layout, use -print-multi-lib:


$ avr-gcc -print-multi-lib
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@mmcu=avr25@msp8


For each line:  Left of ';' stands the multilib subdir, right of ';' are the
option(s) to select that multilib subdir (replace '@' with ' -' to get the
option(s)).

Notice that -mtiny-stack is *not* an avr-gcc multilib option!  The correct
option is -msp8.

In order to query for the multilib subdir for a specific set of command
options, use


$ avr-gcc -print-multi-directory options


Example:

$ avr-gcc -print-multilib -mmcu=avr2 -msp8 -Os
tiny-stack


'-Os' is ignored (no multilib option)
'-mmcu=avr2' is the default multilib, hence will yield '.'.
'-msp8' selects the tiny-stack subdir for avr2 and the result is
'./tiny-stack' i.e. 'tiny-stack'.

Also notice that apart from their multilib properties, -msp8 and -mtiny-stack
are working differently:

* -msp8 asserts that the stack pointer (SP) is 8 bits wide *physically*. 
avr-gcc will set -msp8 as needed except for the cases -mmcu=avr2 and
-mmcu=avr25.  These are the only core architectures which intermix devices
with 16-bit wide and 8-bit wide SP.  Or, to put it more precisely:  avr-gcc
uses -msp8 to decomposes these to sets of devices into 4 core architectures.

* -mtiny-stack is an optimization option:  Only the lower 8 bits of SP will be
changed, no matter how SP is layed out physically.  This applies to all
devices and archirectures.





___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?44514

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] device libs and spaces

[Georg-Johann Lay]

avr-gcc adds the new device specific libraries like dev/atmega8/devlib.a 
by means if lib_spec, which is defined in the device specific specs 
file.  Here an example for ATmega8:


*lib:
-lc dev/atmega8/libdev.a%s

The %s makes the compiler driver to expand the argument to an absolute 
path provided the file can be found in multilib / startfile search paths 
and can be accessed.


This works as expected except in the case when the expanded path 
contains spaces.  The expanded path could escaped by an avr-specific 
spec function, however one level of escaping is not enough as lib_spec 
and its expansion is (re)used several times and passed around, e.g. by 
passthrough mechanisms of LTO compilations.  Escaping escaped sequences 
is not possible because the escape character will become a part of the 
path name then.


To make a long story short:

The current location for libdev.a is likely to cause problems when 
avr-gcc 5.0 hits user land, in particular windows where spaces in path 
names are not uncommon.


Consequently, a new device library naming convention is needed.  The 
simpliest solution would be to rename the device lib to libatmega8.a 
and place it in its multilib directory, i.e. what


$ avr-gcc -print-multi-directory -mmcu=atmega8

will print (avr4 in that case).  With that naming convention lib_spec 
could be written as


*lib:
-lc -latmega8

which works as expected.

Advantage of multilib directory is that it works exactly the same way if 
we should ever have more than one multilib per device, e.g. if we raise 
any ordinary option to a multilib option in the future.



Johann




___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] [Patch] Generalize wdt.h by removing hardcoded device names

[Georg-Johann Lay]

Senthil Kumar Selvaraj schrieb:
The attached patch to wdt.h gets rid of the huge device specific 
conditional branches for wdt_enable and wdt_disable. The branching is

now based primarily on architecture (xmega, tiny and everything else)
and then on the legality of using the OUT instruction to write to the
watch dog control register.

For the latter, I had to make wdt_{enable/disable} an inline function
and use the _SFR_IO_REG_P macro to emit different inline assembly
fragments for OUT versus STS (as suggested by Johann in the binutils
mailing list). The compiler optimizes away the
range comparison done in _SFR_IO_REG_P, so the generated code should be
identical. I verified that it is indeed identical (at -O1 and -Os),
except for a couple of devices (atmega{8,32,64,128}a) for which the
previous conditional branch was taking the STS path when OUT is more 
optimal.


I do see bigger code at -O0 though. Is that an acceptable tradeoff?


What's essential is that the instruction sequence is emit as expected 
which is the case as it is one single asm.  -O0 is overhead almost 
anywhere in the code, hence the user may expect that's also some 
overhead with wdt.h at -O0.


In some cases GCC gives better code at -O0 if the argument is const 
qualified, e.g. __builtin_constant_p together with


...  wdt_enable (const uint8_t value)

instead of

...  wdt_enable (uint8_t value)


always_inline is not C-Standard, better use __always_inline__.

Johann



If ok, could someone commit please? I don't have commit access.

Regards
Senthil

ChangeLog

2014-10-06  Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com

* include/avr/wdt.h: Generalize implementation of wdt_enable and
wdt_disable based on arch and addressability of _WD_CONTROL_REG.


diff --git avr-libc/include/avr/wdt.h avr-libc/include/avr/wdt.h
index 57a20c3..0c2b021 100644
--- avr-libc/include/avr/wdt.h
+++ avr-libc/include/avr/wdt.h
@@ -132,45 +132,7 @@
 */
 
 
-#if defined(__AVR_ATxmega16A4__) \

-|| defined(__AVR_ATxmega16A4U__) \
-|| defined(__AVR_ATxmega16C4__) \
-|| defined(__AVR_ATxmega16D4__) \
-|| defined(__AVR_ATxmega32A4__) \
-|| defined(__AVR_ATxmega32A4U__) \
-|| defined(__AVR_ATxmega32C4__) \
-|| defined(__AVR_ATxmega32D4__) \
-|| defined(__AVR_ATxmega64A1U__) \
-|| defined(__AVR_ATxmega64A3__) \
-|| defined(__AVR_ATxmega64A3U__) \
-|| defined(__AVR_ATxmega64A4U__) \
-|| defined(__AVR_ATxmega64B1__) \
-|| defined(__AVR_ATxmega64B3__) \
-|| defined(__AVR_ATxmega64C3__) \
-|| defined(__AVR_ATxmega64D3__) \
-|| defined(__AVR_ATxmega64D4__) \
-|| defined(__AVR_ATxmega128A1__) \
-|| defined(__AVR_ATxmega128A1U__) \
-|| defined(__AVR_ATxmega128A3__) \
-|| defined(__AVR_ATxmega128A3U__) \
-|| defined(__AVR_ATxmega128A4U__) \
-|| defined(__AVR_ATxmega128B1__) \
-|| defined(__AVR_ATxmega128B3__) \
-|| defined(__AVR_ATxmega128C3__) \
-|| defined(__AVR_ATxmega128D3__) \
-|| defined(__AVR_ATxmega128D4__) \
-|| defined(__AVR_ATxmega192A3__) \
-|| defined(__AVR_ATxmega192A3U__) \
-|| defined(__AVR_ATxmega192C3__) \
-|| defined(__AVR_ATxmega192D3__) \
-|| defined(__AVR_ATxmega256A3__) \
-|| defined(__AVR_ATxmega256A3U__) \
-|| defined(__AVR_ATxmega256C3__) \
-|| defined(__AVR_ATxmega256D3__) \
-|| defined(__AVR_ATxmega256A3B__) \
-|| defined(__AVR_ATxmega256A3BU__) \
-|| defined(__AVR_ATxmega384C3__) \
-|| defined(__AVR_ATxmega384D3__)
+#if defined(__AVR_XMEGA__)
 
 /*

wdt_enable(timeout) for xmega devices
@@ -225,175 +187,7 @@ __asm__ __volatile__ (  \
 : r0 \
 );
 
-#elif defined(__AVR_AT90CAN32__) \

-|| defined(__AVR_AT90CAN64__) \
-|| defined(__AVR_AT90CAN128__) \
-|| defined(__AVR_AT90PWM1__) \
-|| defined(__AVR_AT90PWM2__) \
-|| defined(__AVR_AT90PWM216__) \
-|| defined(__AVR_AT90PWM2B__) \
-|| defined(__AVR_AT90PWM3__) \
-|| defined(__AVR_AT90PWM316__) \
-|| defined(__AVR_AT90PWM3B__) \
-|| defined(__AVR_AT90PWM161__) \
-|| defined(__AVR_AT90PWM81__) \
-|| defined(__AVR_AT90USB1286__) \
-|| defined(__AVR_AT90USB1287__) \
-|| defined(__AVR_AT90USB162__) \
-|| defined(__AVR_AT90USB646__) \
-|| defined(__AVR_AT90USB647__) \
-|| defined(__AVR_AT90USB82__) \
-|| defined(__AVR_ATmega128A__) \
-|| defined(__AVR_ATmega1280__) \
-|| defined(__AVR_ATmega1281__) \
-|| defined(__AVR_ATmega1284__) \
-|| defined(__AVR_ATmega1284P__) \
-|| defined(__AVR_ATmega128RFA1__) \
-|| defined(__AVR_ATmega1284RFR2__) \
-|| defined(__AVR_ATmega128RFR2__) \
-|| defined(__AVR_ATmega164__) \
-|| defined(__AVR_ATmega164A__) \
-|| defined(__AVR_ATmega164P__) \
-|| defined(__AVR_ATmega164PA__) \
-|| defined(__AVR_ATmega165__) \
-|| defined(__AVR_ATmega165A__) \
-|| defined(__AVR_ATmega165P__) \
-|| defined(__AVR_ATmega165PA__) \
-|| defined(__AVR_ATmega168__) \
-|| defined(__AVR_ATmega168A__) \
-|| defined(__AVR_ATmega168P__) \
-|| defined(__AVR_ATmega168PA__) \
-|| defined(__AVR_ATmega169__) \
-|| defined(__AVR_ATmega169A__) \
-|| defined(__AVR_ATmega169P__) \
-|| defined(__AVR_ATmega169PA__) \
-|| defined(__AVR_ATmega16HVA__) \
-|| 

[avr-libc-dev] [bug #38125] Distribute gcrt1.S

[Georg-Johann Lay]

Follow-up Comment #2, bug #38125 (project avr-libc):

I'd propose in a place that's part of the default include path so that it can
be dragged by #include optional-path/gcrt1.S. Maybe in ./avr/include/util
?

Unfortunately gcrt1.S has some dependencies (macros.inc) and some awkward
includes (#inclule IOSYMFILE) whith make it harder to (re)use the startup
code.

___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?38125

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #32945] Wrong PF implementation in pmstring

[Georg-Johann Lay]

Follow-up Comment #3, bug #32945 (project avr-libc):

If someone fixes this issue, please don't forget to reset RAMPZ to 0 after
changing it.  This is necessary for devices that have RAMPD.  Otherwise,
reading vom RAM using indirect Z addressing might read from the wrong address.
 For devices without RAMPD, RAMPZ need not to be reset to 0.

Cf. also the notes on RAMPx in the GCC docs at
http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?32945

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause relocation truncated to fit: R_AVR_13_PCREL linker error

[Georg-Johann Lay]

Follow-up Comment #15, bug #33698 (project avr-libc):

FYI, if the compiler is configured with --with-avrlibc, it will omit functions
from libgcc that are known to be provided by libm.a.

This is supported in avr-gcc 4.7.2 and up, cf. http://gcc.gnu.org/PR54461

However, I still think AVR-LibC needs to be fixed because sections are not
sorted by their names.

___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?33698

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #35483] ./configure does not accept --target

[Georg-Johann Lay]

Follow-up Comment #2, bug #35483 (project avr-libc):

--host specifies the platform that runs the software, thus --target=avr would
be confusing.

--host is common practice.  For example, if you cross-build libraries like GSL
(so that they run on a platform fifferent to the build platform), you specify
that by means of --host.


___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?35483

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #37778] _MemoryBarrier() in cpufunc.h error on compile

[Georg-Johann Lay]

Follow-up Comment #3, bug #37778 (project avr-libc):

Question is whether or not NOP should be allowed to be moved across
ordinary memory moves.

For SEI and CLI, for example, I think this is not wanted in general.

NOP is less intrusive than SEI / CLI, of course, but avr-gcc emits
__builtin_avr_nop() with a memory clobber:

http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.md?revision=195151view=markup#l5938


___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?37778

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #38125] Distribute gcrt1.S

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/bugs/?38125

 Summary: Distribute gcrt1.S
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: So 20 Jan 2013 15:15:31 GMT
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Startup code
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.0
   Fixed Release: None

___

Details:

The assembler source code of the startup code  ./crt1/gcrt1.S -n could be
added to the installation.

This makes it easier for the user to adjust the startup code and / or compiler
it for devices that are not yet supported by avr-gcc as lined out in avr-gcc
Wiki: Supporting unsupported Devices
http://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices.

The onyl dependency should be #include avr/io.h.

Other dependencies like macros.inc and sectionname.h can easily be avoided
altogether, which makes using gcrt1.S more straigh forward.





___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?38125

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] avr-libc and stdfix.h

[Georg-Johann Lay]

avr-gcc 4.8 supports fixed-point arithmetic according to the ISO/IEC TR 
18037 Embedded C paper.


Some parts of stdfix.h that are closely related to avr-gcc could be 
supplied by the compiler, for other parts that are supplied by avr-libc, 
it makes sense if avr-libc supplies these bits.


This could be accomplished by means of an #include_next in gcc's 
stdfix.h in lib/gcc/$target/$version/include which would use stdfix in 
$target/include


Problem is that avr-libc does not supply stdfix.h at all, not even an 
empty one.


Ideas?

Are there plans that avr-libc comes with stdfix.h in the near future?

Johann



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #38037] Building and Installing needs round-up

[Georg-Johann Lay]

URL:
  http://savannah.nongnu.org/bugs/?38037

 Summary: Building and Installing needs round-up
 Project: AVR C Runtime Library
Submitted by: gjlayde
Submitted on: Mo 07 Jan 2013 18:17:52 GMT
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Build system
  Status: None
Percent Complete: 0%
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.8.0
   Fixed Release: None

___

Details:

The Building and Installing under Linux, FreeBSD, and Others documentation
[1] needs some fixes:

1)
Installing GCC states in [2]:
   First, we *highly* recommend that GCC be built into a
   separate directory from the sources which does not reside
   within the source tree. [...] building where srcdir == objdir
   should still work, but doesn't get extensive testing;
   building where objdir is a subdirectory of srcdir is
   not supported.

Nevertheless [1] uses ../configure, i.e. objdir is a subdirectory of srcdir.

2)
Depending on its version, GCC needs several prerequisites: GMP, MPFR, MPC. 
The recommended way to get them is to cd $(srcdir) and then to run
./contrib/download_prerequisites and to do an in-tree build with these
prerequisites.  This ensures the right versions of the prerequisites are used
and that they are configured in sync with GCC, cf. [3]

3) GCC configure should be performed with --with-avrlibc, cf. [2] and see [4]
for reasoning.

4) Recent versions of GCC are distributed as one chunk, there is no gcc-core
etc. any more.

5) Binutils need not to be in the PATH as GCC is being built provided both are
configured with the same prefix.

6) With Linux, Binutils and GCC for MS windows can be built as easily as the
tools for Linux:  Just configure with, say, --target=i386-mingw32
--build=x86-linux-gnu.  This requires working avr-gcc (you already built it as
described) and i386-ming32-gcc cross-compilers.  The rest of the build process
is the same, including the in-tree builds of the prerequisites.


[1] http://nongnu.org/avr-libc/user-manual/install_tools.html
[2] http://gcc.gnu.org/install/configure.html
[3] http://gcc.gnu.org/wiki/InstallingGCC
[4] http://gcc.gnu.org/PR54461





___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?38037

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

[Georg-Johann Lay]

Weddington, Eric wrote:
 First, I think it's great that you're working on this, and I'm all for
 having RTEMS synced with avr-libc, as much as is feasible.
 
 The current release of avr-libc is 1.8.0, though we've been discussing
 recently about fixing a bunch of bugs on HEAD for a future 1.8.1 release.
 So, I would definitely suggest taking a look at porting 1.8.0, or even
 better making sure that it works with HEAD.
 
 Avrtest is what is being used to test with the GCC testsuite. Although I
 thought some work was also being done with simulAVR to make it work with the
 GCC testsuite (perhaps someone else on this list can confirm or correct me
 if I'm wrong).
 
 Additional recommendations: IIRC, there are some specific GCC bugs that are
 avr-rtems specific (though less than a handful). Eventually, you, or someone
 else on the RTEMS team, may want to take a look at those.

AFAIK, there are no avr-rtems bugs in GCC.  There are PR50925 (ICE: spill fail
in newlib build) and PR52488 (ICE for insanely memory allocation like 2000
bytes for attiny).  These are no genuine RTEMS problems, they just occur
because a different, less common code base (newlib) is compiled.  Similar
problems can just as well occur with non-rtems configuration.

 Joel and I have talked off and on over the years, and as I understood it,
 RTEMS was using newlib for its C library. Does RTEMS now use avr-libc? Or
 just a portion of avr-libc?
 
 If RTEMS will be using avr-libc on a more permanent basis for the future,
 then perhaps we'll want to make sure that we coordinate testing, bug fixing,
 etc.

If RTEMS wants to use avr-libc, extending --with-avrlibc seems warranted so
that is covers avr-rtems, see PR54461.


Johann

___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [bug #38021] pgm_read macros don't model the memory accesses

[Georg-Johann Lay]

Follow-up Comment #2, bug #38021 (project avr-libc):

Jan Waclawek wrote in comment #1:
 It is a very bad idea overall. It would increase code size
 of existing programs, with little to no benefit except of
 a negligibly small group of applications.

Would you give a test case from the real world?

I don't see how this would increase the code size in ordinary programs --
except in the case where a clear if RAMPZ is missing and must be added to
comply with avr-gcc.  But in that case, the code size increase is inevitable.

 1. FLASH is inherently non-volatile; SPM out of bootloader
 context is uncommon and those who use that should be aware
 of the risks (there are much more involved anyway).
 Your suggestion is the same as to make all global variables
 volatile just because some of them may be used both in
 interrupts and main.

No, that is not true.  The pgm-macros don't model a memory access at all. 
Notice that the memory access can be modeled and there is no need for a
volatile.  Please read my example code again and try to understand it.
 
 Instead, I suggest documentation enhancement, and perhaps
 a new set of macros,

The problem is that it is very hard for the user to cover the remaining,
uncommon cases, whereas providing proper macros does not do harm.  Not even a
memory barrier will help to fix the uncommon cases because there is no memory
access in the asm.

 3. is related only to the _far variety of pgm_read.
 That is used only by a minority group of users using
 the 64kB FLASH varieties (including me), and given
 the relatively large FLASH, it is likely the pessimisation
 imposed by your suggestion would be significantly
 detrimental to their existing applications. 

It's not a pessimization, it's inevitable so that your code will still work
with GCC 4.7.  I don't see a point in code that is efficient but incorrect.


___

Reply to this item at:

  http://savannah.nongnu.org/bugs/?38021

___
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev