From patchwork Mon Jan 30 13:55:25 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Georg-Johann Lay X-Patchwork-Id: 138576 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 179EC1007D1 for ; Tue, 31 Jan 2012 00:55:58 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328536560; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=LH4fk0OUrg/7EAcYBwisKg17jGg=; b=JYKSQysLEEKduD/ bXXVZx05kkAqE4eq5E7fbGe/daBZq7I6jngPIoFYuPjKOQTiNj5ehm/p0IZOBRhd iR7AXWIcD9uH99H/tUeQdBUA2mlNTpXTTmNrg7LeJcY+PwrZJta8UlGIDm6VTHu7 4VoIk3sHFAMMKDwf1esjD26MXHMw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:X-RZG-AUTH:X-RZG-CLASS-ID:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=rq7RPMVjFOZnPGIify21UyLdtnUYngLVQ3siyUzr0GHBNG8mm6RevNCxPYtKJJ v6HwgHNOkAqkUzqNi33pTgVzjpzcDRZnB9MrJribQTWOdYTt9Veo5VRlLgeAdYMD U55u2wJZ8neON5sC33vzmZBYIjajDl9cJzzKyG14oI6MA=; Received: (qmail 5532 invoked by alias); 30 Jan 2012 13:55:52 -0000 Received: (qmail 5523 invoked by uid 22791); 30 Jan 2012 13:55:50 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_NONE 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 13:55:36 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGObUOFkj18odoYNahU4Q== X-RZG-CLASS-ID: mo00 Received: from [192.168.0.22] (business-188-111-022-002.static.arcor-ip.net [188.111.22.2]) by smtp.strato.de (fruni mo51) (RZmta 27.6 AUTH) with ESMTPA id a0518fo0UD7FeJ ; Mon, 30 Jan 2012 14:55:25 +0100 (MET) Message-ID: <4F26A14D.4050207@gjlay.de> Date: Mon, 30 Jan 2012 14:55:25 +0100 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (X11/20100302) MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org CC: Gerald Pfeifer , Denis Chertykov , Eric Weddington Subject: Re: [Patch,wwwdocs,AVR]: AVR release notes References: <4F19B2BB.2020401@gjlay.de> In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Gerald Pfeifer wrote: > On Fri, 20 Jan 2012, Georg-Johann Lay wrote: >> Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html > > Index: changes.html > =================================================================== > +
  • The AVR port's libgcc has been improved and its multilib structure > + has been enhanced. As a result, all objects contributing to an > + application must either be compiled with GCC versions up to 4.6.x or > + with GCC versions ≥ 4.7.
    • > > How about "...compiled with older versions of GCC, up to GCC 4.6.x, > or GCC 4.7.0 and later" ? The "compiled with" might be confusing, for example if someone uses a library generated with 4.6 and compiles his application with 4.7. He does not compile the library, but yet he might run into problems because the code assumes a specific layout of libgcc. Therefore I used the "all objects" wording. It's bit more technical, but I hoped the reduce misunderstandings. > And I'd omit the   just ≥4.7.0 should work? > > +
  • Support has beed added for instrinsic named address spaces > > "Support for...has been added" (also typo: beed -> been) > > + __pgm, __pgm1, …, __pgm5 > > How about omitting   here? > > + and __pgmx. These address spaces locate read-only data in > + flash memory and allow reading from flash memory by means of vanilla > + C instructions, i.e. without the need of (inline) assembler code.
    • > > What's a C instruction? C builtins? Is "C code" better? Or C-code? Without the extension, inline assembler must be used to get correct code, using C like a = b or pstruct->component will yield wrong code without the extensions if b or *pstruct is located in flash. > +
  • Support for AVR-specific built-in functions has beed added.
    • > > Which ones? Must they all be named explicitly? Or is it ok to link to onlinedocs? I'd prefer a link to the explanation in onlinedocs but I am unsure how stable the links are as docs evolve over time/versions. > +
  • New command-line options -maccumulate-args, > + -mbranch-cost=cost and -mstrict-X > + were added to allow better fine-tuning of code optimization.
    • > > Should X be put under ... here, to? No, the X refers to X-register and must be literally, nothing else than uppercase X is permitted. > +
  • Many optimizations to: > +
      > +
    • 64-bit integer arithmetic
      • > +
    • Widening multiplication
      • > +
    • Integer divide-by-constant
      • > > "division by a constant" > > +
    • Generic built-in functions + like __builtin_ffs*, > __builtin_clz*, etc.
      • > > I don't think we need   here. Breaking the lines here is something > a web browser should avoid, but it is not verboten, technically. Tried to get typesetting all right and avoid Hurenkinder, and I really don't know if browsers add penalties like TeX does. I frequently see browsers offend typesetting rules if there is no nanny. What does "need no  " mean? Nothing at ",etc." all or blank ", etc."? > > +
    • Merging of data in .progmem
      • > > What is ".progmen"? Perhaps paraphrase this briefly? Not easy without getting into too much technical details... Maybe Eric can help. He is definitely better in English than I am. > The update is fine assuming you look into my suggestions. Attached an updated patch as there were many changes and so that Eric and Denis can easier catch up. Johann Index: changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.73 diff -u -r1.73 changes.html --- changes.html 12 Jan 2012 19:35:29 -0000 1.73 +++ changes.html 30 Jan 2012 13:42:13 -0000 @@ -45,6 +45,11 @@ -compat-bsd compiler option is not recognized any longer. +
    • The AVR port's libgcc has been improved and its multilib structure + has been enhanced. As a result, all objects contributing to an + application must either be compiled with GCC versions up to 4.6.x or + with GCC versions 4.7.0 or later.
      • +
    • The ARM port's -mwords-little-endian option has been deprecated. It will be removed in a future release.
      • @@ -530,6 +535,44 @@

      New Targets and Target Specific Improvements

      +

      AVR

      +
        +
      • Support for the + named address spaces + __flash, __flash1,…, + __flash5 and __memx has beed added. + These address spaces locate read-only data in + flash memory and allow reading from flash memory by means of ordinary + C code, i.e. without the need of (inline) assembler code.
        • +
      • Support for AVR-specific built-in functions + has beed added.
        • +
      • Support has beed added for the built-in, 24-bit, signed and unsigned + integer types __int24 and __uint24.
        • +
      • New command-line options -maccumulate-args, + -mbranch-cost=cost and -mstrict-X + were added to allow better fine-tuning of code optimization.
        • +
      • Many optimizations to: +
          +
        • 64-bit integer arithmetic
          • +
        • Widening multiplication
          • +
        • Integer division by a constant
          • +
        • Generic built-in functions like + __builtin_ffs*, __builtin_clz*, etc.
          • +
        • If-else decision trees generated by switch instructions
          • +
        • Merging of data located in flash memory
          • +
        • New libgcc variants for devices with 8-bit wide stack pointer
          • +
        • …
          • +
        +
      • Better documentation: +
          +
        • Handling of EIND and indirect jumps on devices with + more than 128 KiB of program memory.
          • +
        • Function attributes OS_main and OS_task.
          • +
        • AVR-specific built-in macros.
          • +
        +
        • +
      +

      ARM

      • GCC now supports the Cortex-A7 processor implementing the