AVR-AS complete documentation?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there such thing as a dedicated AVR-AS (not the generic GCC AS) complete documentation (User's Guide)?

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just as there is no avr-gcc documentation, in fact.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the problem with the "generic" AS documentation?
The AVR specific things are also covered there.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
First, I would't like to dig through the tons of specific information about hundreds of other than AVR supported devices.
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.

Quote:
E.g. I couldn't even get the .byte directive working in a code space
Show us what you have tried, and perhaps (quite likely) we can help you.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:
and it does have a structured and only dsPIC/PIC24 related manual
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?

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:
and it does have a structured and only dsPIC/PIC24 related manual
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?

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
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?
Because there is no special AVR usage for .byte, so it can't be a AVR specific usage error.

Quote:
Do you happen to be one of the as developers, or familiar with its internals?
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.

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:
It could contain clarification on details relevant to AVRs, which in the "official" line might be seen as superfluous.
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.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
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.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

.vtable_entry
.vtable_inherit

OO assembler? Gulp! :shock:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Then that is an error in the manual!
Yeah, that's all I meant.
ka7ehk wrote:
I don't see that it warrants a special manual for AVR that will never be sync'd to the current AVR-AS.

Jim

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.