avr-gcc + 64-bit double

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. Dec 17, 2019 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avr-optimized “doubles”, or gcc generic “doubles”?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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/

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Sat. Jan 11, 2020 - 11:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just noticed now that you have a prebuilt Win version in your repository https://sourceforge.net/projects...

I will take a look.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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

 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent. Thank you. I'll try to kick the tires soon...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uploaded again as tgz.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 

Last Edited: Fri. Jan 17, 2020 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

Quote:

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.

 

@joeymorin

 

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

 

 

 

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. Jan 17, 2020 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
It's never been upstream in Binutils.  Too much of a hack as to have a chance of ever being approved.
The issue was that to show percentages you have to know the total dimensions which meant the patch to avr-size had to keep being updated with a database of all the chip dimensions (then there were issues with things like chips that have external SRAM on their bus too and so on). 

 

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

 

Last Edited: Fri. Jan 17, 2020 - 11:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

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

 

 

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
$ 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.