Hi, in case you want to try 64-bit double support in avr-gcc, here is a pointer to such a toolchain for windos together with instructions how to build such tools from souce:
.
https://www.mikrocontroller.net/topic/480840#6076058
.
GCC is v10 from svn trunk head.
avr-gcc + 64-bit double
This is wonderful to hear.
Can we expect a Linux build at any point, or will have to "build such tools from souce" ourselves for the foreseeable future?
Avr-optimized “doubles”, or gcc generic “doubles”?
GCC 10 timeline
https://gcc.gnu.org/develop.html#timeline
isn't that also the version that AVR was deprecated
https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now
Standard libc would promote float to double by default for various things, but I don't want that on AVR. A double could be helpful in exceptional cases, but what would avr-libc do to use it.
In a fork of newlib called picolibc (for ARM and RISC-V) some work was recently done to allow floats (like avr-libc) without having to promote to a double. It is an interesting kluge that I barely understand, but is something like that a better path forward?
https://keithp.com/blogs/picolibc-float/
Yes, it's v10.
.
Promotion is performed by the compiler, and without extra options float/double/long double is 32/32/64.
.
It's IEEE doubles.
I just noticed now that you have a prebuilt Win version in your repository https://sourceforge.net/projects...
I will take a look.
Uploaded a x86_64-linux-gnu build to the location mentioned in the post above (there is only one for linux).
If you want to build it yourself, you'll need patches for avr-libc which are not yet upstream. They are attached here:
https://savannah.nongnu.org/bugs...
https://savannah.nongnu.org/bugs...
After applying and before running ./bootstrap, set x-flag for /devtools/mlib-gen.py
Excellent. Thank you. I'll try to kick the tires soon...
Hmm... the execute file attributes aren't preserved in the .zip:
$ find -type f -executable $
Comparing against Atmel's 3.6.2 toolchain:
$ find -type f -executable ./x86_64-pc-linux-gnu/avr/lib/libopcodes.la ./x86_64-pc-linux-gnu/avr/lib/libbfd.la ./libexec/gcc/avr/5.4.0/install-tools/fixincl ./libexec/gcc/avr/5.4.0/install-tools/mkheaders ./libexec/gcc/avr/5.4.0/install-tools/mkinstalldirs ./libexec/gcc/avr/5.4.0/install-tools/fixinc.sh ./libexec/gcc/avr/5.4.0/cc1 ./libexec/gcc/avr/5.4.0/plugin/gengtype ./libexec/gcc/avr/5.4.0/collect2 ./libexec/gcc/avr/5.4.0/liblto_plugin.so.0.0.0 ./libexec/gcc/avr/5.4.0/cc1plus ./libexec/gcc/avr/5.4.0/liblto_plugin.la ./libexec/gcc/avr/5.4.0/lto-wrapper ./libexec/gcc/avr/5.4.0/lto1 ./avr/bin/ld.bfd ./avr/bin/objcopy ./avr/bin/strip ./avr/bin/as ./avr/bin/ld ./avr/bin/objdump ./avr/bin/ar ./avr/bin/nm ./avr/bin/readelf ./avr/bin/ranlib ./bin/avr-g++ ./bin/avr-objdump ./bin/avr-strings ./bin/avr-strip ./bin/avr-ranlib ./bin/avr-c++ ./bin/avr-gcov-tool ./bin/avr-cpp ./bin/avr-gcc-nm ./bin/avr-ld.bfd ./bin/avr-gdb ./bin/avr-gcc ./bin/avr-gcc-ar ./bin/avr-gcc-5.4.0 ./bin/avr-c++filt ./bin/avr-gdb-py ./bin/avr-gcc-ranlib ./bin/avr-gprof ./bin/avr-nm ./bin/avr-man ./bin/avr-ld ./bin/avr-size ./bin/avr-as ./bin/avr-objcopy ./bin/avr-ar ./bin/avr-gcov ./bin/avr-addr2line ./bin/avr-elfedit ./bin/avr-readelf ./lib64/libcc1.so.0.0.0 ./lib64/libcc1.la ./lib/gcc/avr/5.4.0/plugin/libcc1plugin.la ./lib/gcc/avr/5.4.0/plugin/libcc1plugin.so.0.0.0 $
Just to be sure I wasn't driving my unzipper incorrectly:
$ zipinfo avr-gcc-10.0.0_2020-01-14_x86-linux64.zip | grep ^.rw. | head -rw---- 1.0 fat 0 bx stor 20-Jan-14 16:51 gcc-10-strip/ -rw---- 1.0 fat 0 b- stor 20-Jan-14 16:51 gcc-10-strip/include/ -rw---- 1.0 fat 0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/ -rw---- 1.0 fat 0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/gcc/ -rw---- 1.0 fat 0 b- stor 20-Jan-14 16:51 gcc-10-strip/libexec/gcc/avr/ -rw---- 1.0 fat 0 b- stor 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/ -rw---- 2.0 fat 104080 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/liblto_plugin.so -rw---- 2.0 fat 18781992 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/lto1 -rw---- 2.0 fat 104080 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/liblto_plugin.so.0.0.0 -rw---- 2.0 fat 1107376 bl defN 20-Jan-14 16:53 gcc-10-strip/libexec/gcc/avr/10.0.0/lto-wrapper $
$ zipinfo avr-gcc-10.0.0_2020-01-14_x86-linux64.zip | grep ^...x $
I could manually re-instate via chmod based on 3.6.2, but that would be tedious.
Is't possible to re-zip (or tarball) your Linux build?
Uploaded again as tgz.
Thanks.
I've grabbed it, and tried it out on some test code for a current project. Although FP isn't necessary for the test code, it simplifies some things for now. Certainly 64-bit doubles are not necessary, but I tried out your build as a drop-in replacement for 3.6.2. No obvious issues. I had to add -Wno-error=implicit-fallthrough to allow a build (I have a case which deliberately falls through to the next case), but that was it. For the below tests I changed the case to avoid the fallthrough.
Code size is quite a bit larger, even with the default FP behaviour (double = 32 bit):
-O3
3.6.2: 8,430 bytes
10.0.0: 10,122 bytes
-Os
3.6.2: 7,538 bytes
10.0.0: 8,138 bytes
Switching to long double on 10.0.0, of course, yields even larger code:
-O3: 13,376 bytes
-Os: 11,432 bytes
I realise some of the increase in code size will be due to bug fixes and now-correct behaviour, and the increase for -O3 might be justified based on cycles (I didn't check), but I would have expected an overall improvement for -Os, not an 8% fattening.
Of course this is just one piece of test code, and a piece not very carefully crafted, so this is not a very meaningful result. However, it does seem to fit the trend I've noticed over the last several releases of the Atmel toolchain. No doubt some of this is due to changes in the compiler make to benefit other targets, but which have the side effect of negatively affecting the AVR backend. After all, it is apparently not long for this world...
In any event, my untargetted test of 64-bit FP seems to work as expected.
Compiled Send_Hello_World from Microchip examples for a 4809
https://github.com/MicrochipTech/TB3216_Getting_Started_with_USART
This link shows the deltas on a circuit board I am looking at, but yet to build, testing may happen someday.
https://github.com/epccs/PiUpdi/commit/cd791b982150c6fd3c601c3d5b415907d48589af
Is it OK to link the atpack files like this?
avr-size failed with the -C option; I guess that is not in the upstream.
https://github.com/epccs/PiUpdi/commit/cd791b982150c6fd3c601c3d5b415907d48589af
There should really be no need to add system include paths like ./avr/include or /lib/gcc/avr/10.0.0/include/ by hand. Using the compiler from ./bin (directly or via PATH) *must* be enough. If not, the installation is broken.
avr-size failed with the -C option; I guess that is not in the upstream.
It's never been upstream in Binutils. Too much of a hack as to have a chance of ever being approved.
-O3 is overkill. Unrolling loops usually does not improve speed.
It's a tad fact that avr-gcc code size is deteriorating from version to version. Once I wrote a small project in C99 to compute 4000 digits of π on a ATtiny2313:
https://www.mikrocontroller.net/...
The project uses float and the size was just under the 2048 bytes limit (where most of the binary code does not change from version to version because it is from libm).
With v8 I see a size of 2004 bytes (with -mmcu=attiny2313 -Os -DF_CPU=22118400 -DBAUDRATE=115200 -DHOST_WINDOWS -mcall-prologues -fno-caller-saves -fno-tree-loop-optimize -fno-move-loop-invariants -fno-split-wide-types -mrelax).
With v9 it's 2260 bytes.
With v4.7 it was less than 2000 bytes, with v7 it's 1998.
It's never been upstream in Binutils. Too much of a hack as to have a chance of ever being approved.
In AS7 Atmel/Microchip now have a slightly different approach to this - at build time a "hidden" section (.note.gnu.avr.deviceinfo) is added to the ELF which records the dimensions of just the target chip. Then later, at analysis time, that is extracted along with the actual dimensions and can be used to show the size in terms of percentage:
D:\test\test\Debug>avr-objdump -s -j .note.gnu.avr.deviceinfo test.elf test.elf: file format elf32-avr Contents of section .note.gnu.avr.deviceinfo: 0000 04000000 2d000000 01000000 41565200 ....-.......AVR. 0010 00000000 00400000 00380000 00080000 .....@...8...... 0020 00000000 00010000 08000000 01000000 ................ 0030 00617474 696e7931 36313400 00000000 .attiny1614.....
So rather than trying to resurrect the old avr-size -C, if you want to know more about sizes you might want to explore what can be done with .note.gnu.avr.deviceinfo and perhaps to understand more about how it is created. Or even (as i don't know!) what the data format hidden in their actually is!
EDIT: just proving that sometimes Google works:
https://www.eit.lth.se/fileadmin/eit/courses/edi021/Avr-libc-2.0.0/mem_sections.html#sec_dot_note
So all is revealed:
04000000 = namesz 2d000000 = descsz 01000000 = type 41565200 = "AVR" = note_name 00000000 = flash_start 00400000 = flash_size (16K) 00380000 = sram_start 00080000 = sram_size (2K) 00000000 = eeprom_start 00010000 = eeprom_size (256bytes) 08000000 = offset_table_size 01000000 = offset into table 00617474 696e7931 36313400 = NULL, "attiny1614", NULL
[...] explore what can be done with .note.gnu.avr.deviceinfo and perhaps to understand more about how it is created.
It's introduced by the startup code from avr-libc, added november 2014:
http://svn.savannah.nongnu.org/v...
http://svn.savannah.nongnu.org/v...
$ avr-objdump -s -j .note.gnu.avr.deviceinfo Uart0_hello.elf Uart0_hello.elf: file format elf32-avr Contents of section .note.gnu.avr.deviceinfo: 0000 04000000 2d000000 01000000 41565200 ....-.......AVR. 0010 00000000 00c00000 00280000 00180000 .........(...... 0020 00000000 00010000 08000000 01000000 ................ 0030 0061746d 65676134 38303900 00000000 .atmega4809.....
I see the data but not an easy way to use it, can also see it somewhat with readelf.
$ readelf -a Uart0_hello.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Atmel AVR 8-bit microcontroller Version: 0x1 Entry point address: 0x0 Start of program headers: 52 (bytes into file) Start of section headers: 29780 (bytes into file) Flags: 0x67, avr:103 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 17 Section header string table index: 16 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .data PROGBITS 00802800 0001d3 000000 00 WA 0 0 1 [ 2] .text PROGBITS 00000000 000074 000150 00 AX 0 0 2 [ 3] .rodata PROGBITS 00004150 0001c4 00000f 01 AMS 0 0 1 [ 4] .comment PROGBITS 00000000 0001d3 00002a 01 MS 0 0 1 [ 5] .note.gnu.avr.dev NOTE 00000000 000200 000040 00 0 0 4 [ 6] .debug_aranges PROGBITS 00000000 000240 000038 00 0 0 1 [ 7] .debug_info PROGBITS 00000000 000278 00294e 00 0 0 1 [ 8] .debug_abbrev PROGBITS 00000000 002bc6 0024b3 00 0 0 1 [ 9] .debug_line PROGBITS 00000000 005079 00050d 00 0 0 1 [10] .debug_frame PROGBITS 00000000 005588 000074 00 0 0 4 [11] .debug_str PROGBITS 00000000 0055fc 001278 00 0 0 1 [12] .debug_loc PROGBITS 00000000 006874 00009d 00 0 0 1 [13] .debug_ranges PROGBITS 00000000 006911 000058 00 0 0 1 [14] .symtab SYMTAB 00000000 00696c 000600 10 15 23 4 [15] .strtab STRTAB 00000000 006f6c 000430 00 0 0 1 [16] .shstrtab STRTAB 00000000 00739c 0000b7 00 0 0 1 ... skipping some cruft ... Displaying notes found in: .note.gnu.avr.deviceinfo Owner Data size Description AVR 0x0000002d NT_VERSION (version) description data: 00 00 00 00 00 ffffffc0 00 00 00 28 00 00 00 18 00 00 00 00 00 00 00 01 00 00 08 00 00 00 01 00 00 00 00 61 74 6d 65 67 61 34 38 30 39 00 00
I will just use avr-size (without -C) for now, since my foo is weak.
$ ~/Samba/avr8-10.0.0.2020jan14/gcc-10-strip/bin/avr-size Uart0_hello.elf text data bss dec hex filename 351 0 0 351 15f Uart0_hello.elf
I wonder if optiboot would build and be small enough, think I will try that next.