[Patch,wwwdocs,AVR]: AVR release notes

[Georg-Johann Lay]

Weddington, Eric schrieb:
>>From: Georg-Johann Lay 
>>
>> Attached an updated patch as there were many changes and so that Eric
>> and Denis can easier catch up.
> 
> Hi Johann,
> 
> Comments:
> 
> In the first hunk of the patch, you say that libgcc has been improved
> and enhanced. Can you elaborate just a little in the docs as to how it
> has been improved and enhanced? The reason is that we are telling users
> that they have recompile all their code with a new version of gcc
> because of these improvements and enhancements, but I think we are too
> vague in giving them a reason. Users will want to know why they have to
> do a rebuild. It doesn't have to go into great detail, but just a little
> less vague.

There are new assembler functions in libgcc. Just to mention some:

__umulhisi3
__usmulhisi3
__mulshisi3
__mulohisi3
__muluhisi3
__mulsi3

__muldi3
__umoddi3
__udivdi3
__moddi3
__divdi3
__adddi3
__adddi3_s8
__subdi3
__cmpdi2
__cmpdi2_s8
__negdi2
__ashldi3
__ashrdi3
__lshrdi3
__rotldi3

__load_3
__load_4
__xload_1
__xload_2
__xload_3
__xload_4
__movmemx_qi
__movmemx_hi

__ffssi2
__ffshi2
__ctzsi2
__ctzhi2
__clzdi2
__clzsi2
__clzhi2
__paritydi2
__paritysi2
__parityhi2
__parityqi2
__popcountqi2
__popcounthi2
__popcountsi2
__popcountdi2
__bswapsi2
__bswapdi2


Some of these functions are new. Examples are __parityqi2 or __muluhisi3.

Thus, if code contains references to such a function, you need the right 
libgcc version or otherwise you'll get a complain from the linker.

Some of the function were already present in libgcc. Examples are 
__ashldi3 and __paritysi2. For many functions with assembler 
implementation the compiler has knowledge about the register footprint 
and can generate better code by exploiting that knowledge. If is's known 
that __ashldi3 does not clobber Z, for example, Z need not to be saved 
around that call resulting in better code.

The problem with this kind of improvment is that you get an 
abi-per-function imlpementation as the compiler has explicit knowledge 
beyond ABI and makes use of that.

Up to now, this was used in multiply, divide and modulo functions; but 
there was never an ABI change because these implementations are there 
since the beginning of time.

But as soon as you write one single such function after beginning of 
time, it's the fall of man. And you can just as well write hundreds of 
them...

So the goal was to add as many of such functions in 4.7 as possible, and 
not spread them over several versions -- or never add them.

So we can blaime the users always nagging for better code quality and 
better 64-bit support ;-)

As 4.7 comes with new features like named address spaces (and I also 
hoped to see Xmega support from you and fixed-point support from Sean), 
4.7 can be regarded as milestone justifying such a transition.

Built-ins also need libgcc support like __fmuls or PSImode support for 
__int24 and __uint24 (not listed above).

Unfortunately, there was too little time to make even more use of the 
4.6 -> 4.7 transition, for example by raising fshort-double to a 
multilib option in order to render avr-gcc standard compliant and get 
rid of hard-coded double=float in avr.h.

But I guess now it's too late?

> s/Support has beed added/Support has been added/
> 
> If the list of built-in functions added is really long, I'm ok leaving
> out the whole list. But, can we give some sort of short description as
> to the types of built-in functions added?

There are built-ins that map to machine instructions like NOP or supply 
soft-equivalents like FMUL.

There is built-in to map to a delay routine.

There are built-ins to help user fiddle with non-contiguous port 
layouts. (The map8 built-in has a bug that's not yet fixed and I'd like 
to change semantics to render it more usable.)

And there was proposal for thing like
    bool __builtin_avr_ram_p (const __memx void*);
    bool __builtin_avr_flash_p (const __memx void*);
in order to test if memx pointer points to flash ot to RAM.

> Other than those things, the updated patch looks good to me. Let me know
> if I can help with wording / language.

What about
You = wording/language
Me  = technical details

I think it's easier that way: Ask me if something is unclear with 
technical stuff, and native speaker compose first class text :-) You 
will be better than me with explaining technical stuff. You ar ebetter 
in english and I tend to go too deep into details.

Johann