Re: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Joerg Wunsch
Jan Waclawek konf...@efton.sk wrote:

 I know this is not the best place to mention it, but I don't know
 *where* is the best place to mention...

By filing a bug report + patch to GNU binutils.  The better it fits
into the project (e.g.: include a ChangeLog snippet), the higher the
probability it will go in.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Jan Waclawek
 By filing a bug report + patch

OK, so here we go again, Joerg.

First, I have no idea what the source of docs is (and I suspect it is in some 
arcane language I would have trouble to work with anyway), where it is nor how 
to prepare a patch the high esteemed gnu gurus would be akin to have a glimpse 
at. Not to mention, that I have only a very faint idea of what these operators 
really do or don't.

Is it really that hard to accept suggestions from mere *users*?  

Jan

PS. Recently I've posted you personally on another suggestion not fitting 
anywhere, which came from avrfreaks, a small mod in the MFile template, have 
you had opportunity to have a look at that?



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


RE: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Weddington, Eric

You don't have to write a patch if you don't know how.

Just fill out a bug report at the binutils project.:
http://sourceware.org/bugzilla/

Technically this is a bug in the GNU Assembler project (gnu as, or gas), in the 
documentation. Please put my email address in the CC list.

Eric

 -Original Message-
 From: 
 avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org 
 [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
org] On Behalf Of Jan Waclawek
 Sent: Saturday, May 22, 2010 10:10 AM
 To: Joerg Wunsch; avr-gcc-list@nongnu.org
 Subject: Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
 
  By filing a bug report + patch
 
 OK, so here we go again, Joerg.
 
 First, I have no idea what the source of docs is (and I 
 suspect it is in some arcane language I would have trouble to 
 work with anyway), where it is nor how to prepare a patch the 
 high esteemed gnu gurus would be akin to have a glimpse at. 
 Not to mention, that I have only a very faint idea of what 
 these operators really do or don't.
 
 Is it really that hard to accept suggestions from mere *users*?  
 
 Jan
 
 PS. Recently I've posted you personally on another suggestion 
 not fitting anywhere, which came from avrfreaks, a small mod 
 in the MFile template, have you had opportunity to have a 
 look at that?
 
 
 
 ___
 AVR-GCC-list mailing list
 AVR-GCC-list@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
 

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Joerg Wunsch
As Jan Waclawek wrote:

 First, I have no idea what the source of docs is

GNU binutils, if you look around, it's easy enough to find: there's a
directory named gas (for GNU assembler) which in turn has a
subdirectory named doc.  There, you can find a file named
c-avr.texi, which is supposed to document AVR extensions to the GNU
assembler.

 (and I suspect it is in some arcane language I would have trouble to
 work with anyway),

texinfo, which is nothing terribly hard to guess, since basically, you
could just look around how the other entries are formatted.

 where it is nor how to prepare a patch the high esteemed gnu gurus

You are sounding arrogant, sorry.  Not much sense in continuing the
discussion.  If you don't know something, you can simply ask.  If you
don't want to contribute, that's fine, too, but then don't expect
anyone else to spend much more energy into fixing it than you did
yourself.  There's no God here, there's just people doing their work
like you and me are doing.

Btw., as a stop-gap measure, we added it to the avr-libc documentation
some time ago, as avr-libc is a relatively small project where it is
simple enough to add a bit of documentation without pushing it through
half a dozen of instances it first.  But as Eric mentioned, the bug is
really in GNU binutils, they ought to document it.

 PS. Recently I've posted you personally on another suggestion not
 fitting anywhere, which came from avrfreaks, a small mod in the
 MFile template, have you had opportunity to have a look at that?

Not really, and I'm a little sorry there is no formal bug tracker
available for Mfile, as it isn't really a standalone project of its
own.  We used to host it in the WinAVR repository, but as Eric is
going to transition WinAVR to another project (under the umbrella of
Atmel), there's no longer a bug  patch tracker around.  As such, your
suggestion simply sits in my inbox, hoping I'll find enough time and
devotion to polish up Mfile again some day, and then going to remember
there's still an email from you.

I'm not quite satisfied with that situation, but Mfile is just such a
minor thing so I'm a little reluctant about pushing it up into a
full-blown savannah or sourceforge project of its own.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Jan Waclawek
 If you don't know something, you can simply ask.

Okay.
What do pm() and gs() exactly do?

 Btw., as a stop-gap measure, we added it to the avr-libc documentation
 some time ago, 

Could you please point me at it, I can't find it. I can find a mention of pm in 
http://www.nongnu.org/avr-libc/user-manual/assembler.html (although not its 
modifications documented in the as documentation); but I can't find explanation 
of gs.

 The better it fits
 into the project (e.g.: include a ChangeLog snippet), the higher the
 probability it will go in.

I've browsed through the changelogs of gas, but found no mention of gs(). I 
doubt some random snippet of changelog would do the trick ;-)

However, I did find this:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00534.html

which says, among others:
In order to distinguish relocs where stubs should be generated and relocs 
where no stubs should be generated, there are now two new ldi-type PM relocs 
that
carry the GS suffix instead of PM. Gas now knows of the directives gs() that
has the same functionality as pm(), only that it generates the GS relocs that
force the linker to generate stubs.

It is sort of Greek to me, though; not really something I would call user 
documentation (as I said, I do have a faint idea what those things do, but I 
like things to be straight and solid).

Btw., isn't Bjoern Haase subscribed to this forum? He seems to be the right 
person to be pestered for the proper docs...  

---

 Not really, and I'm a little sorry there is no formal bug tracker
 available for Mfile, as it isn't really a standalone project of its
 own.  We used to host it in the WinAVR repository, but as Eric is
 going to transition WinAVR to another project (under the umbrella of
 Atmel), there's no longer a bug  patch tracker around.  As such, your
 suggestion simply sits in my inbox, hoping I'll find enough time and
 devotion to polish up Mfile again some day, and then going to remember
 there's still an email from you.

Oh, and we even provided the patch this time! ;-) Okay, not a formal one, but 
it's just inserting 3 lines anyway.

 
 I'm not quite satisfied with that situation, but Mfile is just such a
 minor thing so I'm a little reluctant about pushing it up into a
 full-blown savannah or sourceforge project of its own.

I believe it could be simply sticked to avr-libc. There are 
not-that-strictly-libc things there anyway, at least in the docs, and I don't 
believe anybody would complain. The decision is, of course, all yours.

Thanks anyway.

Jan

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] documenting pm() and gs() avr-as operators

2010-05-22 Thread Joerg Wunsch
As Jan Waclawek wrote:

 Could you please point me at it, I can't find it. I can find a
 mention of pm in
 http://www.nongnu.org/avr-libc/user-manual/assembler.html (although
 not its modifications documented in the as documentation); but I
 can't find explanation of gs.

You're right, the explanation of gs is missing.

 However, I did find this:
 http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00534.html

 which says, among others:
 In order to distinguish relocs where stubs should be generated and relocs
 where no stubs should be generated, there are now two new ldi-type PM relocs 
 that
 carry the GS suffix instead of PM. Gas now knows of the directives gs() that
 has the same functionality as pm(), only that it generates the GS relocs that
 force the linker to generate stubs.

OK, so you found all the documentation that we've got about it. :-/

(Now I even understand what GS stands for generate stubs.)

 It is sort of Greek to me, though; not really something I would call
 user documentation (as I said, I do have a faint idea what those
 things do, but I like things to be straight and solid).

Did you understand the pm operator?  Basically, it's performing a
shift operation by one bit, which is needed since all the code
addresses in flash are meant to be in units of 16-bit words, while
everything else (including all the GNU tools) think in units of
8-bit bytes.

The pm operator works at the linker level, so it can accept
relocatable symbols (where the actual address is inserted by the
linker after resolving the relocation).  That's why it requires the
introduction of a relocation code within the object file, so the
assembler can transfer that information to the linker.  That's also
the reason why you cannot perform the bit shift directly in assembly
language: neither the ELF file format nor the GNU linker has any
method to transfer that bit shifting into the linker, as there is no
support for performing arbitrary arithmetics on relocational symbols.
(Well, the linker used on the PDP-11, running RSX-11 did have the
ability to do that.  But that's been 30 years ago. ;-)

For machines with = 128 KiB of flash ROM, the gs operator works the
same.  For larger machines, it tells the linker to perform special
actions on the data labelled that way, so the linker can take care to
handle addresses beyond the current 128 KiB segment where a trampoline
entry is needed.  (Disclaimer: that's how *I* understood it.  Bjoern
might correct me here...)

 Btw., isn't Bjoern Haase subscribed to this forum? He seems to be
 the right person to be pestered for the proper docs...

Yes, he is, but I'm afraid he might have unsubscribed some time
ago. :-(

[Mfile]

 Oh, and we even provided the patch this time! ;-) Okay, not a formal
 one, but it's just inserting 3 lines anyway.

Appreciated, be sure.

  I'm not quite satisfied with that situation, but Mfile is just
  such a minor thing so I'm a little reluctant about pushing it up
  into a full-blown savannah or sourceforge project of its own.

 I believe it could be simply sticked to avr-libc.

I already thought about that as on option, yes.  Might be a good
compromise, indeed.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list