Re: [avr-libc-dev] fplib and MUL

[Björn Haase]

Hi,

btw. I forgot to say that work on the fplib would be really helpful. IMO one 
could then make also one additional step: Presently the FPLIB resides in 
avr-libc. IMO it should belong to libgcc.a instead (gcc's own internal 
library). Positive side-effect would be that we then could better optimize 
the patterns since within gcc we could communicate the exact register 
usage/register clobbering of the fplib functions to the compiler. We would 
also no longer have bugs if users forget to link against libm. For efficiency 
the main issue would be that one would no longer be restricted by gcc's 
calling convention for usual functions within fplib! If you would like to 
know how to integrate fplib in gcc (namely how to use your own calling 
convention), I'd be willing to show you.

Nice side-effect of moving fplib to gcc would be that the number of asm files 
in avr-libc decreases.

> Note that the current scheme needs to be refined some day, as we
> recently saw the first devices that don't fit anymore, and had to be
> ``downgraded'' into the next lower class: ATtiny13 and ATtiny2313.
> Both have some features of avr4 cores (word instructions) yet don't
> have a hardware multiplier, so they are effectively avr2.5 or
> something like that...   I guess the same will apply to all future
> ATtiny devices that appear on the market.  Currently, GCC cannot use
> their ability to handle word instructions.

Indeed, I agree that this issue would be worth to be addressed. There are also 
minor related questions that stem from the fact that the information on the 
devices is scattered around. E.g. presently we aren't doing checks if the 
program actually fits into ram/eeprom/flash or not. This would require using 
an individual linker script for each device where the maximum values are 
defined and the linker presently does not have this information.

IMO, it would be best if one could realize one single centralized database 
that all the three of them, gcc, binutils and avr-libc use. Presently the 
information for gcc is scattered somewhere in the port's avr.h and avr.c 
files. The binutils already have an individual, more detailed information on 
which instructions are supported. Binutils lack, however, the information on 
the memory size of the devices (IIUC). The memory size is only found 
somewhere in avr-libc. The information relevant for each individual part of 
the toolchain is presently duplicated and there is always the danger to be 
unsynchronized or incomplete (see devices with movw but without hw 
multiplier).

I already thought of using the method of the binutils own encoding as a basis: 
One could generate a unique decimal number identifying the instruction set 
from the definitions like "AVR_ISA_M323". One could continue using a binary 
encoding such that e.g. bit #5 of the number informs if memory is larger than 
8k and bit#6 might signalize that the device has a hw multiplier.
One would be generating multilibs for all of the distinct numbers that show up 
in the centralized device table. 
The central data struct of binutils would be extended to contain the size of 
the three memories and would be generating an individual linker script file 
for each entry and information on the crt file on this base. One would be 
ending up with strange and possibly large numbers, but since one would no 
longer have to maintain the list by hand, this would not be a really serious 
problem, IMO.

Yours,

Bjoern