Is there such thing as a dedicated AVR-AS (not the generic GCC AS) complete documentation (User's Guide)?
AVR-AS complete documentation?
Author
Message
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?
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3270 View posts
Location: Bratislava, Slovakia
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.
MBedder wrote:
Why do you think you have to? The AS documentation is quite well organized into a big generic part, and lots of small separate device dependent parts. Simply don't read the device dependent parts you are not interested in.
First, I would't like to dig through the tons of specific information about hundreds of other than AVR supported devices.
Quote:
Show us what you have tried, and perhaps (quite likely) we can help you.
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.
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
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3270 View posts
Location: Bratislava, Slovakia
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?
sternst wrote:
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
wek wrote:
Because there is no special AVR usage for .byte, so it can't be a AVR specific usage error.
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?
Quote:
No. And of course, if it is a AS bug, then it can be AVR specific. But then a avr-as documentation wouldn't helped either.
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?"
Quote:
Just to clarify, I don't think that the AS documentation is absolutely perfect, but I can't comprehend the problems the OP seems to have with it.
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.
MBedder wrote:
Please give me an example of what AVR specific functionality is missing, merely to satisfy my curiosity.
The AVR specific chapter lists/describes only a few AVR particular additions and does not cover the AVR specific functionality in a whole.
sternst wrote:
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
Quote:
.vtable_entry
.vtable_inherit
OO assembler? Gulp! :shock:
ka7ehk wrote:
Yeah, that's all I meant. Then that is an error in the manual!
ka7ehk wrote:
I'm not advocating a seperate manual for avr-as. I'm just pointing out that there is enough information missing in the gcc as manual that people will assume/hope that the information is in another 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.