| Message ID | 4F26A14D.4050207@gjlay.de |
|---|---|
| State | New |
| Headers | show |
> -----Original Message----- > From: Georg-Johann Lay > Sent: Monday, January 30, 2012 6:55 AM > To: gcc-patches@gcc.gnu.org > Cc: Gerald Pfeifer; Denis Chertykov; Weddington, Eric > Subject: Re: [Patch,wwwdocs,AVR]: AVR release notes > > 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. 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? Other than those things, the updated patch looks good to me. Let me know if I can help with wording / language. Eric Weddington
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
On Mon, 30 Jan 2012, Georg-Johann Lay wrote: >> "Support for...has been added" (also typo: beed -> been) Hmm, this still seems to be in the latest version? > 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. Thanks for the background. I really like how you have changed this in the new version of the patch! >> + <li>Support for AVR-specific built-in functions has beed added.</li> >> 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. If you think it's not beneficial, we don't have to do anything. The links should be rather stable in general (and I am running link checks somewhat regularly). + <li>Support has beed added for the built-in, 24-bit, signed and unsigned + integer types <code>__int24</code> and <code>__uint24</code>.</li> I believe that should be "signed and unsigned 24-bit integer types" (omitting "built-in" should be fine, but in any case without commas). > What does "need no " mean? Nothing at ",etc." all or blank ", etc."? I'd just use a regular space instead of in that case. >> What is ".progmen"? Perhaps paraphrase this briefly? > Not easy without getting into too much technical details... Okay. > Attached an updated patch as there were many changes and so that Eric > and Denis can easier catch up. Looks good! Please fix the one typo, and consider the other comments as well, and go ahead and commit this I'd say. We can always make further changes later. This looks like an impressive release for AVR! Gerald
> -----Original Message----- > From: Gerald Pfeifer > Sent: Sunday, February 12, 2012 3:17 PM > To: Georg-Johann Lay > Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Weddington, Eric > Subject: Re: [Patch,wwwdocs,AVR]: AVR release notes > > > This looks like an impressive release for AVR! > > Gerald Johann has been doing some excellent work for the AVR backend. It's been very much appreciated. Eric Weddington
Gerald Pfeifer wrote: > Looks good! Please fix the one typo, and consider the other comments > as well, and go ahead and commit this I'd say. We can always make > further changes later. Committed with the following changes: * Support for XMEGA cores * Mini-example for address space code. http://gcc.gnu.org/gcc-4.7/changes.html But there is a problem with the link to built-ins in onlinedocs. The HTML reads <li>Support for AVR-specific <a href="http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html">built-in functions</a> has been added.</li> But that is not used literally but as "http://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html" instead leading to 404 "Not found" error. It _002d link works from by local sandbox but not from the upstream version. What is the trick? Johann
Georg-Johann Lay wrote: > http://gcc.gnu.org/gcc-4.7/changes.html > > But there is a problem with the link to built-ins in onlinedocs. > > The HTML reads > > <li>Support for AVR-specific <a > href="http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html">built-in > functions</a> has been added.</li> > > But that is not used literally but as > "http://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html" > instead leading to 404 "Not found" error. > > It _002d link works from by local sandbox but not from the upstream version. > > What is the trick? Hacked around it by escaping _002d as %5f002d so that _002d is not resolved to - Johann
On Wed, 15 Feb 2012, Georg-Johann Lay wrote: > Georg-Johann Lay wrote: > >> http://gcc.gnu.org/gcc-4.7/changes.html >> >> But there is a problem with the link to built-ins in onlinedocs. >> >> The HTML reads >> >> <li>Support for AVR-specific <a >> href="http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html">built-in >> functions</a> has been added.</li> >> >> But that is not used literally but as >> "http://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html" >> instead leading to 404 "Not found" error. >> >> It _002d link works from by local sandbox but not from the upstream version. >> >> What is the trick? > Hacked around it by escaping _002d as %5f002d so that _002d is not > resolved to - None of this should be necessary (and should not have been for 18 months or so), finally. :-) If you still run into anything, please let me know and I'll look into it. Gerald
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 @@ <code>-compat-bsd</code> compiler option is not recognized any longer.</li> + <li>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.</li> + <li>The ARM port's <code>-mwords-little-endian</code> option has been deprecated. It will be removed in a future release.</li> @@ -530,6 +535,44 @@ <h2 id="targets">New Targets and Target Specific Improvements</h2> +<h3 id="avr">AVR</h3> + <ul> + <li>Support for the + <a href="http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html">named address spaces</a> + <code>__flash</code>, <code>__flash1</code>,…, + <code>__flash5</code> and <code>__memx</code> 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.</li> + <li>Support for AVR-specific <a href="http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html">built-in functions</a> + has beed added.</li> + <li>Support has beed added for the built-in, 24-bit, signed and unsigned + integer types <code>__int24</code> and <code>__uint24</code>.</li> + <li>New command-line options <code>-maccumulate-args</code>, + <code>-mbranch-cost=<i>cost</i></code> and <code>-mstrict-X</code> + were added to allow better fine-tuning of code optimization.</li> + <li>Many optimizations to: + <ul> + <li>64-bit integer arithmetic</li> + <li>Widening multiplication</li> + <li>Integer division by a constant</li> + <li>Generic built-in functions like + <code>__builtin_ffs*</code>, <code>__builtin_clz*</code>, etc.</li> + <li>If-else decision trees generated by <code>switch</code> instructions</li> + <li>Merging of data located in flash memory</li> + <li>New libgcc variants for devices with 8-bit wide stack pointer</li> + <li>…</li> + </ul> + <li>Better documentation: + <ul> + <li>Handling of <code>EIND</code> and indirect jumps on devices with + more than 128 KiB of program memory.</li> + <li>Function attributes <code>OS_main</code> and <code>OS_task</code>.</li> + <li>AVR-specific built-in macros.</li> + </ul> + </li> + </ul> + <h3 id="arm">ARM</h3> <ul> <li>GCC now supports the Cortex-A7 processor implementing the