Patchwork [wwwdocs,AVR] : AVR release notes

login
register
mail settings
Submitter Georg-Johann Lay
Date Jan. 30, 2012, 1:55 p.m.
Message ID <4F26A14D.4050207@gjlay.de>
Download mbox | patch
Permalink /patch/138576/
State New
Headers show

Comments

Georg-Johann Lay - Jan. 30, 2012, 1:55 p.m.
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
> ===================================================================
> +    <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 &ge;&nbsp;4.7.</li>
> 
> 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 &nbsp; just &ge;4.7.0 should work?
> 
> +    <li>Support has beed added for instrinsic named address spaces
> 
> "Support for...has been added" (also typo: beed -> been)
> 
> +    <code>__pgm</code>, <code>__pgm1</code>,&nbsp;&hellip;, <code>__pgm5</code>
> 
> How about omitting &nbsp; here?
> 
> +    and <code>__pgmx</code>.  These address spaces locate read-only data in
> +    flash memory and allow reading from flash memory by means of vanilla
> +    C&nbsp;instructions, i.e. without the need of (inline) assembler code.</li>
> 
> 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.

> +    <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.

> +    <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>
> 
> Should X be put under <i>...</i> here, to?

No, the X refers to X-register and must be literally, nothing else than
uppercase X is permitted.

> +    <li>Many optimizations to:
> +      <ul>
> +	<li>64-bit integer arithmetic</li>
> +	<li>Widening multiplication</li>
> +	<li>Integer divide-by-constant</li>
> 
> "division by a constant"
> 
> + <li>Generic built-in functions + like <code>__builtin_ffs*</code>, 
> <code>__builtin_clz*</code>,&nbsp;etc.</li>
> 
> I don't think we need &nbsp; 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 &nbsp;" mean? Nothing at ",etc." all or blank ", etc."?

> 
> +	<li>Merging of data in <code>.progmem</code></li>
> 
> 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
Weddington, Eric - Jan. 30, 2012, 6:57 p.m.
> -----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
Georg-Johann Lay - Jan. 30, 2012, 11:05 p.m.
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
Gerald Pfeifer - Feb. 12, 2012, 10:16 p.m.
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 &nbsp;" mean? Nothing at ",etc." all or blank ", etc."?

I'd just use a regular space instead of &nbsp; 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
Weddington, Eric - Feb. 13, 2012, 1:37 p.m.
> -----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
Georg-Johann Lay - Feb. 15, 2012, 4:31 p.m.
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 - Feb. 15, 2012, 5:04 p.m.
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

Patch

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>,&hellip;,
+      <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>&hellip;</li>
+      </ul>
+    <li>Better documentation:
+      <ul>
+	<li>Handling of <code>EIND</code> and indirect jumps on devices with
+	  more than 128&nbsp;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