Is there such thing as a dedicated AVR-AS (not the generic GCC AS) complete documentation (User's Guide)?
AVR-AS complete documentation?
I don't think so.
You do know of the two sections in the avr-libc documentation ("avr-libc and assembler programs" and "Inline Assembler Cookbook"), yes?
Just as there is no avr-gcc documentation, in fact.
JW
What is the problem with the "generic" AS documentation?
The AVR specific things are also covered there.
First, I would't like to dig through the tons of specific information about hundreds of other than AVR supported devices.
Next, I'd like to have a single bookmarked document where all AVR specific stuff (especially directives) is listed and detailed.
E.g. I couldn't even get the .byte directive working in a code space like the .db works in AVRASM2, although it is described in the generic AS documentation without any code space usage restriction.
First, I would't like to dig through the tons of specific information about hundreds of other than AVR supported devices.
E.g. I couldn't even get the .byte directive working in a code space
This is not a specific problem I couldn't solve - I'm just missing the structured manual with AVR specific stuff ONLY. If one will help me now with this .byte directive, next time I would have to ask another specific question instead of reading the appropriate and proven manual chapter.
As an example - I'm succesfully working with another GCC assembler (ASM30 for dsPIC/PIC24), and it does have a structured and only dsPIC/PIC24 related manual.
Sorry, but I still don't get your point. The AS documentation HAS a section with "AVR specific stuff ONLY" (9.4 AVR Dependent Features). But you won't find the .byte directive there, because it is not AVR specific, it is a generic directive. There is nothing special with .byte on an AVR. If your .byte-code does not work, then you have a "generic" problem, not a "AVR specific" one.
and it does have a structured and only dsPIC/PIC24 related manual
There is nothing special with .byte on an AVR. If your .byte-code does not work, then you have a "generic" problem, not a "AVR specific" one.
Oh, Stefan, how can you be sure with that?
Do you happen to be one of the as developers, or familiar with its internals?
Quote:A AVR-AS documentation covering all stuff (instead only the AVR specific one like now) would contain exactly the same text for .byte as the generic AS documentation has. So what would be the benefit?and it does have a structured and only dsPIC/PIC24 related manual
It doesn't need to be "spoiled" with the stuff which is not AVR related.
It could contain clarification on details relevant to AVRs, which in the "official" line might be seen as superfluous.
And more.
Due to FSF's policy, it's hard to get anything fixed in the GNU projects for an "outsider", including documentation. An AVR-specific manual, not depending on . That is the role of the avr-libc "manual" - note how much of it is not really that avr-libc relevant. But it's not perfect either - it contains only anecdotal pieces of non-avr-libc documentation and is not updated in line with the official issues of the whole suite, whatever would be its name.
The same applies for the rest of the toolchain, too. As I said, I was always missing a real avr-gcc manual.
JW
sternst wrote:There is nothing special with .byte on an AVR. If your .byte-code does not work, then you have a "generic" problem, not a "AVR specific" one.
Oh, Stefan, how can you be sure with that?
Do you happen to be one of the as developers, or familiar with its internals?
Of course I can be wrong, but I don't see how his .byte problem could be caused by the fact that there is no AVR specific documentation for .byte. And that was his point, "tried .byte after reading the generic documentation, didn't worked, documentation must be insufficient, isn't there a AVR specific documentation?"
It could contain clarification on details relevant to AVRs, which in the "official" line might be seen as superfluous.
Again: rather than using a trial and error approach I'd prefer to have a clear documentation which could help me to avoid this in all future aspects, not only with a .byte example I mentioned above. The AVR specific chapter lists/describes only a few AVR particular additions and does not cover the AVR specific functionality in a whole.
The AVR specific chapter lists/describes only a few AVR particular additions and does not cover the AVR specific functionality in a whole.
Please give me an example of what AVR specific functionality is missing, merely to satisfy my curiosity.
Here's an example of non-functionality
.vtable_entry .vtable_inherit
avr-as doesn't support these directives but that isn't mentioned in the manual so a trial-and-error aproach is required to find this out.
Then that is an error in the manual! I don't see that it warrants a special manual for AVR that will never be sync'd to the current AVR-AS.
Jim
.vtable_entry
.vtable_inherit
OO assembler? Gulp! :shock:
Then that is an error in the manual!
I don't see that it warrants a special manual for AVR that will never be sync'd to the current AVR-AS.Jim
This is all open source, including the manual, and put together by volunteers.
Instead of complaining, patches to improve the manual (or any of the tools) are always welcome.