From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2549 invoked by alias); 30 Jan 2012 23:07:01 -0000 Received: (qmail 2531 invoked by uid 22791); 30 Jan 2012 23:06:59 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SARE_BAYES_5x8,SARE_BAYES_6x8,SARE_BAYES_7x8,TW_CL,TW_LZ,TW_TQ,TW_YQ X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Jan 2012 23:06:46 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTS5oCa/h49L+8o= X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-058-252-148.pools.arcor-ip.net [84.58.252.148]) by post.strato.de (mrclete mo36) (RZmta 27.6 DYNA|AUTH) with ESMTPA id x044cao0UMOl7L ; Tue, 31 Jan 2012 00:06:20 +0100 (MET) Message-ID: <4F272236.1050800@gjlay.de> Date: Mon, 30 Jan 2012 23:07:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: "Weddington, Eric" CC: gcc-patches@gcc.gnu.org, Gerald Pfeifer , Denis Chertykov Subject: Re: [Patch,wwwdocs,AVR]: AVR release notes References: <4F19B2BB.2020401@gjlay.de> <4F26A14D.4050207@gjlay.de> <8D64F155F1C88743BFDC71288E8E2DA806D3EC05@csomb01.corp.atmel.com> In-Reply-To: <8D64F155F1C88743BFDC71288E8E2DA806D3EC05@csomb01.corp.atmel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01685.txt.bz2 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