Please take my comments below into account for an updated patch, and
once Andrew and Richard have signed of, this is then good to commit.
You did raise a technical question I'd like to get Andrew, Richard or
someone to comment on:
How does the user know what is dialect #0? Same for the others?
When I originally wrote that section, I didn't know the answer (which is
why I left it vague). Now I think I do, but I'd like someone to
confirm. On my builds of gcc, the dialects are listed (in dialect
order) under "Known assembler dialects" in "gcc --target-help". Can I
rely on this enough to put it in the docs? Is there some better source?
(Patches of this size really are tough to review. That surely has
contributed to the delay getting this in the tree most significantly.
True enough.
The goal of this patch was to rewrite section 6.41. That's no simple
task, since 6.41 was ~10 very full pages. Unfortunately the current
text is so random, I couldn't think of any way to update it piecemeal.
Once I started, it became clear to me that I needed to split the text
into two sections (Basic & Extended), which meant I needed a sub-menu.
Once I had the sub-menu, it seemed logical to move the rest of the
asm-related topics here as well.
It was not (and is not) my intent to try to re-work all these
asm-related topics as part of this patch. Some changes have "leaked
in," but I actually have separate files where I have started work on new
patches for these related sections. So while the text in these related
sections may be "perfectly adequate" for the moment, I plan on taking
another shot at them.
In fact, I fell asleep over my notebook thrice reviewing this
Dang, I knew I should have put more car chases and explosions in this
thing. Maybe a love interest?
On last point for Gerald:
A number of your concerns seem to stem from reviewing this text only by
looking at the patch. I think your questions might answered by looking
at the actual generated output. While I'm sure I don't need to teach
the doc maintainer how to generate the files, if you don't have your
build environment handy, you can see the output (with all the changes
below) at:
http://www.LimeGreenSocks.com/gcc/Using-Assembly-Language-with-C.html
+@menu
+* Basic Asm:: Inline assembler with no operands.
+* Extended Asm:: Inline assembler with operands.
+* Constraints:: Constraints for asm operands
Should this be "Asm operands" based on the other references here
or, better @code{asm} in all cases here?
Changed to "Constraints for @code{asm} operands".
+* Explicit Reg Vars:: Defining variables residing in specified registers.
Should this be "Register" instead of just "Reg"?
And "Variables" instead of just "Vars"?
Since reg vars wasn't really the focus of this patch, I mostly left the
existing text. It may look new in the patch because it got moved into
this new menu. I don't know why this was originally written this way
(sounds like laziness). "Register" and "Variables" make more sense to
me. That said, unless you feel strongly, I'd suggest doing this in my
upcoming RegVars patch.
+* Size of an asm:: How GCC calculates the size of an asm block.
@code{asm} ?
Changed to: Size of an asm:: How GCC calculates the size of an
@code{asm} block.
+@subsection Basic Asm - Assembler Instructions with No Operands
--- instead of -
Changed.
+To create headers compatible with ISO C, write @code{__asm__} instead of
+@code{asm} (@pxref{Alternate Keywords}).
Here it's just ISO C, whereas in case of __inline__ you had ISO C90.
Would it make sense to just use ISO C throughout?
Wow, good catch. The change to __inline__ was a mistake. I must have
modified this bit in "Inline" while searching for similar text in the
asm section. I have undone this change to inline.
As for the larger issue of "ISO C" vs "ISO C90", that's a tougher
question. Now that I've undone this change, all the inline asm stuff
says "ISO C," which is what the original text used. "ISO C90" and "ISO
C99" are sprinkled throughout the other sections in extend.texi, and I'm
reluctant to make wholesale changes to the rest of the file as part of
this patch.
+By definition, a Basic @code{asm} statement is one with no operands.
+@code{asm} statements that contain one or more colons (used to delineate
+operands) are considered to be Extended (for example, @code{asm("int $3")}
+is Basic, and @code{asm("int $3" : )} is Extended). @xref{Extended Asm}.
At this point the reader does not yet know the concept of those
colons, does she? So that can be seen as a bit confusing.
I understand what you mean, however I don't see a practical solution
here. Describing the use of colons in Basic asm, only to follow it by
saying "now that you understand all that, none of it applies here" seems
like it would be even more confusing.
Saying that colons are part of Extended asm, and providing a link to
Extended asm which does describe them seems to me the best compromise.
What's more, while a sequential reading of the docs might experience the
problem you describe, does anyone actually read the docs from beginning
to end? "At this point" is an undefined term.
Is this still confusing if you look at the output?
+@subsubheading Parameters
+@emph{AssemblerInstructions}
+@*
+This is a literal string that specifies the assembler code. The string can
Just "assembler code", without "the", would be my take, but let's see
what native speakers so.
"The" sounds right to me. Alternate might be "thine?" Maybe not.
+The GCC compiler does not parse the assembler instructions themselves and
"GCC does". GCC stands for GNU Compiler Collection, and GNU Compiler
Collection Compiler may be a bit confusing. ;-)
<sigh> Ok. "GCC does" it is. Changed.
+You may place multiple assembler instructions together in a single @code{asm}
+string, separated by the characters normally used in assembly code for the
+system.
Might "by the same characters normally...the target system" be more clear?
Hmm. Not to me. I'm not sure what "same" would mean in this context.
The same as what?
I'm guessing that way back at the beginning of time, this text was
originally written as:
"You may place multiple assembler instructions together in a single
@code{asm}
string, separated by semicolons."
However, not all assemblers use semicolons to separate statements. This
new text was a compromise.
I have made no change here.
+A combination that works in most places is a newline to break the
+line, plus a tab character to move to the instruction field (written
+as "\n\t").
Will everyone know what an instruction field is? I'm not sure it's
that common of a term.
Hmm. I brought that text across unchanged from the original text. I
know what it means, but only because I've programmed in languages that
require it. I haven't seen an assembler that cares, but my cross
platform experience is weak.
I don't want to get into the business of describing how to format and
write assembler code. That's (well) beyond the scope of this doc. What
would you say to:
A combination that works in most places is a newline to break the
line, plus a tab character (written as "\n\t").
For people who do have to deal with instruction fields, it will just
work (and since that's their environment, they'll understand why the tab
is needed). It will also work for people who don't, while keeping the
formatting of their asm output pretty.
+Do not expect a sequence of @code{asm} statements to remain perfectly
+consecutive after compilation. If certain instructions need to remain
+consecutive in the output, put them in a single multi-instruction asm
+statement. Note that GCC's optimizer can move @code{asm} statements
+relative to other code, including across jumps.
optimizers (plural)
Changed.
+GCC's optimizer does not know about these jumps, and therefore cannot take
+account of them when deciding how to optimize. Jumps from @code{asm} to C
+labels are only supported in Extended @code{asm}.
How about just saying "GCC does not know..:"?
Changed.
+@subsubheading Remarks
+Using Extended @code{asm} will typically produce smaller, safer, and more
+efficient code, and in most cases it is a better solution.
Why?
As below.
When writing inline assembly language outside C functions, however,
you must use Basic @code{asm}. Extended @code{asm} statements have to
be inside a C function.
Might that be "outside of C functions"? Native speakers?
Could go either way. Since it bothers you: Changed.
The way this is phrased sounds a bit negative. Is this really a
drawback?
If it seems to you I am trying to make Basic asm sound bad, I am. There
are so many things that "look right" when written in Basic asm that just
won't work, I'm trying my best to discourage its use. There are times
when you have no choice but to use Basic, but (IMO) if possible, you
shouldn't.
+Under certain circumstances, GCC may duplicate (or remove duplicates of) your
+asm code as part of optimization. This can lead to unexpected duplicate
+symbol errors during compilation if your asm code defines symbols or labels.
"as part of optimization" -> "when optimizing"
I don't really see the problem here, but since it bothers you: Changed.
@code{asm}
Changed to "if your assembly code defines"
+Safely accessing C data and calling functions from Basic @code{asm} is more
+complex than it may appear. To access C data, it is better to use Extended
+@code{asm}.
Here we are, this looks like (part of) the answer to my question
"Why?" above. :-)
Exactly. It is fantastically easy to write code that looks like it
should work, only to have it not. Or worse, it might partially work and
cause weird problems downstream. While that can happen in Extended asm
too, Basic is particularly bad.
+Since GCC does not parse the AssemblerInstructions, it has no visibility of
^^^^^^^^^^^^^^^^^^^^^
Something wrong here.
AssemblerInstructions is the first parameter to the Basic asm.
+any symbols it references. This may result in those symbols getting discarded
+by GCC as unreferenced.
We can omit "by GCC" here.
Per discussion elsewhere, changed to: This may result in GCC discarding
those symbols as unreferenced.
+While Basic @code{asm} blocks are implicitly volatile, they are not treated
+as though they used a "memory" clobber (@pxref{Clobbers}).
What does it mean for a block to be volatile, as opposed to a variable?
Changed to:
Unlike Extended @code{asm}, Basic @code{asm} blocks are implicitly
volatile.
@xref{Volatile}. Similarly, Basic @code{asm} blocks are not treated as
though
they used a "memory" clobber (@pxref{Clobbers}).
Should this be ``memory'' (note the quotes)?
There's a reason I did it this way. As an example, a common use for asm is:
asm ("" : : : "memory");
Since the memory clobber actually gets enclosed in quotes when used, I
used that format when discussing it. I suppose an argument could be
made for any of:
memory
"memory"
@emph{memory}
``memory''
but I like "memory". If you have a strong feeling for one of these
alternatives, I'll change it. My recommendation is to leave it.
-@section Assembler Instructions with C Expression Operands
+@subsection Extended Asm - Assembler Instructions with C Expression Operands
+@cindex @code{asm} keyword
@cindex extended @code{asm}
-@cindex @code{asm} expressions
@cindex assembler instructions
-@cindex registers
-In an assembler instruction using @code{asm}, you can specify the
-operands of the instruction using C expressions. This means you need not
-guess which registers or memory locations contain the data you want
-to use.
+The @code{asm} keyword allows you to embed assembler instructions within C
+code. With Extended @code{asm} you can read and write C variables from
+assembler and include jumps from assembler code to C labels.
Was there a question here?
+@ifhtml
+asm [volatile] ( AssemblerTemplate : [OutputOperands] [ : [InputOperands] [ :
[Clobbers] ] ] )
-For example, here is how to use the 68881's @code{fsinx} instruction:
+asm [volatile] goto ( AssemblerTemplate : : [InputOperands] : [Clobbers] :
GotoLabels )
+@end ifhtml
+@ifnothtml
+asm [volatile] ( AssemblerTemplate
+ : [OutputOperands]
+ [ : [InputOperands]
+ [ : [Clobbers] ] ])
Why does the @ifhtml variant have a "goto" when the other does not?
They both have goto. Look again.
+By definition, Extended @code{asm} is an @code{asm} statement that contains
+operands. To separate the classes of operands, you use colons. Basic
+@code{asm} statements contain no colons. (So, for example,
+@code{asm("int $3")} is Basic @code{asm}, and @code{asm("int $3" : )} is
+Extended @code{asm}. @pxref{Basic Asm}.)
What does "classes of operands refer to"? This does not seem to be
evident from the context.
Looking at it in context:
asm [volatile] ( AssemblerTemplate : [OutputOperands] [ :
[InputOperands] [ : [Clobbers] ] ] )
Looking at where the colons fall, they separate OutputOperands from
InputOperands and InputOperands from Clobbers. Observation suggests
that makes "OutputOperands", "InputOperands" and "Clobbers" the classes
in question.
On the other hand, I already knew what I meant. If this is unclear,
what would you suggest?
+@subsubheading Remarks
+The @code{asm} statement allows you to include assembly instructions directly
+within C code. This may help you to maximize performance in time-sensitive
+code or to access assembly instructions that are not readily available to C
+programs.
This feels like it comes rather late in the flow. Wouldn't that be
a comment pretty early on in this section?
The very first line on the Extended asm page reads:
The @code{asm} keyword allows you to embed assembler instructions within C
code. With Extended @code{asm} you can read and write C variables from
assembler and perform jumps from assembler code to C labels.
Plus, this is the very first point after listing the parameters with a
short description. I'm not sure where "up" would be? Have you looked
at this in a non-patch format (pdf, html, etc)?
+Note that Extended @code{asm} statements must be inside a function. Only
+Basic @code{asm} may be outside functions (@pxref{Basic Asm}).
We had a similary paragraph earlier on. Perhaps only keep this where
it relates to Extended statements? Not sure about this, though.
The similar text was on the Basic Asm page. It referenced the Extended
page. This text is on the Extended page, referencing back to Basic.
Since we can't know where in the docs the reader "started," each section
should acknowledge the other.
+While the uses of @code{asm} are many and varied, it may help to think of an
+@code{asm} statement as a series of low-level instructions that convert input
+parameters to output parameters. So a simple (if not particularly useful)
+example for i386 using @code{asm} might look like this:
This, without the example possibly, would have been good earlier, when
all the different classes where described.
I'm not sure where you think this would go. The syntax section followed
by the "Qualifiers" section, the "Parameters" section and the "Remarks"
section seems like a very clean approach. Perhaps this isn't as clear
when reading a patch file?
+GCC's optimizer sometimes discards @code{asm} statements if it determines
+that it has no need for the output variables.
How about just saying "GCC", not referring to the optimizer here?
I'm pretty sure it only happens when running the optimizer.
+This i386 code demonstrates a case that does not use (or require) the
+@code{volatile} qualifier. If it is performing assertion checking, this code
+uses @code{asm} to perform the validation.
Is there a question here?
+@code{DoCheck} routine. By omitting the @code{volatile} qualifier when it
+isn't needed you allow the optimizer to produce the most efficient code
+possible.
How about "Only including ...when it is really necessary allows the
optimizer", that is, a more positive ("included" instead of "omitting")
approach?
Hmm. How strongly do you feel about this one? I'm ok with the current
text.
+GCC's optimizer will not treat this code like the non-volatile code in the
+earlier examples. It does not move it out of loops or omit it on the
+assumption that the result from a previous call is still valid.
"GCC will..."
Again, I believe this behavior comes from the optimizer.
+Under certain circumstances, GCC may duplicate (or remove duplicates of) your
+asm code as part of optimization. This can lead to unexpected duplicate symbol
@code{asm}
Changed to "assembly code".
And did we not have the same (or very similar) statement a bit earlier?
Yes we did, but it was in a different section (Basic asm).
+directives. The GCC compiler does not parse the assembler instructions
Just "GCC".
Yes, ok. Changed.
+You may place multiple assembler instructions together in a single @code{asm}
+string, separated by the characters normally used in assembly code for the
+system. A combination that works in most places is a newline to break the
+line, plus a tab character to move to the instruction field (written as
+"\n\t"). Some assemblers allow semicolons as a line separator. However, note
+that some assembler dialects use semicolons to start a comment.
This also looks quite familiar. Is there a way to build up and avoid
the redundancy?
When viewed in context, I believe this is appropriate. Basic asm and
Extended asm are completely separate sections. Among other things, they
end up on separate html pages.
+GCC may support multiple assembler dialects (such as "att" or "intel") for
+inline assembler. The list of supported dialects depends on the implementation
+details of the specific build of the compiler. When writing assembler, be
+aware of which dialect is the compiler's default. Assembler code that works
+correctly when compiled using one dialect will likely fail if compiled using
+another.
How about saying "When writing assembler code", since the term
assembler is a bit ambigous?
Changed.
+@example
+@{ dialect0 | dialect1 | dialect2... @}
+@end example
:
?
Are you saying there is supposed to be a colon here somewhere?
+This construct outputs 'dialect0' when using dialect #0 to compile the code,
+'dialect1' for dialect #1, etc. If there are fewer alternatives within the
+braces than the number of dialects the compiler supports, the construct
+outputs nothing.
How does the user know what is dialect #0? Same for the others?
When I wrote this, I didn't know the answer. Looking now, I see (at
least on my platform) they are listed in "gcc --target-help" under
"Known assembler dialects."
What I don't know is if that will be true on all supported platforms.
+There is no support for nesting dialect alternatives. Also, there is no
+"escape" for an open brace (@{), so do not use open braces in an Extended
+@code{asm} template other than as a dialect indicator.
``escape'' (note the quotes)
Changed. Looks freaky, but changed.
+In addition to the tokens described by the input, output, and goto
operands, there are a few special cases:
How about clobbers?
Nope.
+@itemize
+@item
+'%%' outputs a single '%' into the assembler code.
+@item
+'%=' outputs a number that is unique to each instance of the asm statement
+in the entire compilation. This option is useful when creating local labels
+and referring to them multiple times in a single template that generates
+multiple assembler instructions.
@code{asm} statement
Done.
And again the quotes don't seem right (in a few cases here).
Not sure what I was thinking here. All ' changed to ".
+Output constraints must begin with either "=" (a variable overwriting an
+existing value) or "+" (when reading and writing). When using "=", do not
+assume the location will contain the existing value (except when tying the
+variable to an input; @pxref{InputOperands,,Input Operands}).
@code{=}
@code{+}
Possibly under proper quotes as well?
I tried it without quotes (@code{=}), and it looked really odd to my
eyes. The effect of the new font doesn't really show up for just a
single character like this.
I've changed this to @code{"="}. Is that what you meant?
+After the prefix, there must be one or more additional constraints
+(@pxref{Constraints}) that describe where the value resides. Common
+constraints include "r" for register, "m" for memory, and "i" for immediate.
Similarly here.
Not sure about this one, but I'll defer to your judgement. "r" and "m"
changed to @code{"r"} and @code{"m"}.
+control to select the specific register you want, Local Reg Vars may provide
+a solution (@pxref{Local Reg Vars}).
Local Reg Vars should be properly expanded, I assume.
Well, the current title of this section really is Local Reg Vars. Unless
we want to expand this patch to start updating even more things...
+Specifies the C variable name of the output (enclosed by parenthesis).
"parentheses" (plural)
Huh. Who knew? Changed.
Accepts
+any (non-constant) variable within scope.
What's a non-constant variable? Or just a constant variable?
const int a = 4; /* A constant variable */
int b = 5; /* A non-constant variable */
In summary, anything that isn't marked as "const" is not const (aka
non-constant).
+@var{b}. Combining the '@code{&}' constraint with the register constraint
+ensures that modifying @var{a} will not affect what address is referenced by
+@var{b}. Omitting the '@code{&}' constraint means that the location of @var{b}
If we use qoutes, they should read `...' in a couple of cases here.
That always looks weird to me. But since you say so, I've changed it.
+Input constraints must be a string containing one or more constraints
+(@pxref{Constraints}). When you give more than one possible constraint
+(for example, @code{"irm"}), the compiler will choose the most efficient
I don't think irm should be under quotes. The entire @code{...} I
could understand better.
Well, if I had an input parameter that accepted Immediate, Register and
Memory, it might look like this:
asm("asm goes here" : : "irm" (a));
Since the irm would actually be enclosed in quotes, that's what I used.
Let me know if you still think I should change it.
+either "=" or "+". If you must use a specific register, but your Machine
Quotes.
Not sure I'm understand here. The quotes seem appropriate. I could add
@code, but I'm not sure that's needed.
+Constraints do not provide sufficient control to select the specific
+register you want, Local Reg Vars may provide a solution
+(@pxref{Local Reg Vars}).
Can we use a better term than Local Reg Vars? Or is that totally
entrenched?
Wouldn't break my heart to see it changed. As before, I'm reluctant to
do that as part of this patch. "Local Reg Vars" is what the section is
called in the existing docs. Since I'm (mostly) just moving it, I
(mostly) left it alone. Now my *next* patch...
+Input constraints can also be digits (for example, @code{"0"}). This indicates
Quotes inside of @code do not seem approriate here.
As I mentioned above, applying @code to a single character isn't
visually distinctive. Though if you feel strongly, I'll change it.
+Remarks:
+
+The total number of input + output + goto operands has a limit of 30.
We also had this data point earlier in the text of this patch already,
didn't we?
It is mentioned in each of input, output and goto. If someone is
working with input parameters, assuming they saw this back in output
parameters seems a stretch.
+constraint @code{"0"} for input operand 1 says that it must occupy the same
Mind the quotes.
As I mentioned above, applying @code to a single character isn't
visually distinctive. Though if you feel strongly, I'll change it.
+The "cc" clobber indicates that the assembler code modifies the flags
Quotes. And @code{cc} I guess.
@code is correct. I've changed that.
As for the quotes around cc, my reasoning here is the same as for
"memory" (way back near the top). If we change that, we should change
this. At present, I have changed neither.
+hardware register; "cc" serves to name this register. On other machines,
+condition code handling is different, and specifying "cc" has no effect. But
+it is valid no matter what the machine.
Two more.
As before.
+The "memory" clobber tells the compiler that the assembly code performs memory
Same here.
As before.
+reads or writes to items other than those listed in the input and output > >
+specific register values to memory before executing the asm. Further, the
@asm
Changed.
+compiler will not assume that any values read from memory before the
+@code{asm} will remain unchanged after the @code{asm}; it will reload them as
+needed. This effectively forms a read/write memory barrier for the compiler.
"before an @code{asm}...after that @code{asm}"
Changed.
+Note that this clobber does not prevent the @emph{processor} from doing
+speculative reads past the @code{asm} statement. To stop that, you need
+processor-specific fence instructions.
"prevent" instead of "stop" (since with "stop" it would have already
started).
Changed.
+An @code{asm goto} statement may not have outputs (which means that the
+statement is implicitly volatile). This is due to an internal restriction in
+the compiler: that control transfer instructions cannot have outputs. If the
I'd say "of the compiler" and omit "that" in "that control transfer...".
Changed.
+assembler code does modify anything, use the "memory" clobber to force the
``memory''
"Memory" clobber is discussed elsewhere.
+To reference a label, prefix it with @code{%l} followed by a number. This
+number is zero-based and includes any input arguments (for example, if the
+@code{asm} has three inputs and references two labels, refer to the first
+label as @code{%l3} and the second as @code{%l4}).
I understood this one, mostly based on the example, and am wondering
how we can improve it.
Something like "@code{%l} followed by its position in GotoLabels
(starting with zero) plus the number of input arguments."
And then "For example,..." as an independent sentence, not in
parentheses.
Here's what I changed this to:
To reference a label, prefix it with @code{%l} (that's a lowercase L)
followed
by its (zero-based) position in GotoLabels plus the number of input
arguments. For example, if the @code{asm} has three inputs and
references two
labels, refer to the first label as @code{%l3} and the second as
@code{%l4}).
+Input, output, and goto operands for extended @code{asm} can use modifiers to
+affect the code output to the assembler. For example, the following code uses
+the 'h' and 'b' modifiers for i386:
extended @code{asm} statements
Changed.
Mind the quotes.
s/'/"
+@multitable {Modifier} {Print the opcode suffix for the size of th} {Operand}
{masm=att} {masm=intel}
WHere does th come from here?
Should this be @var{th}?
Ahh. I know a texi trick you don't?
These parameters to multitable aren't actually output into the text.
They are only used to provide a column width. And if I put the entire
sentence here (from the table below), texi won't wrap the text in that
column. Without wrapping, the text is too long for a single line when
output to pdf. By truncating where I did, it uses a sensible column
width and wraps the text nicely.
+@headitem Modifier @tab Description @tab Operand @tab masm=att @tab masm=intel
@code{masm...} ?
You think? It's not really code. How about @option?
+@tab Print the opcode suffix for the size of the current integer
operand (one of b/w/l/q).
@code{b}/@code{w}/....
Hmm. Ok. Changed.
+@tab Print the QImode name for a "high" register.
``high''
Yuck, but changed.
+Some targets require that GCC track the size of each instruction used,
+in order to generate correct code.
I'd omit the comma here.
Changed.
+instruction supported by that processor. (When working out the number
+of instructions, it assumes that any occurrence of a newline or of
+whatever statement separator character is supported by the assembler --
+typically @samp{;} -- indicates the end of an instruction.)
--- instead of --
Changed.
+Normally, GCC's estimate is perfectly adequate to ensure that correct
"adequate", without "perfectly". That'd be an odd combination. :-)
Changed.
+code is generated, but it is possible to confuse the compiler if you use
+pseudo instructions or assembler macros that expand into multiple real
+instructions, or if you use assembler directives that expand to more
+space in the object file than is needed for a single instruction.
+If this happens then the assembler produces a diagnostic saying that
+a label is unreachable.
"produces" -> "may produce" ?
Changed.
+Sometimes when writing inline asm code, you need to make an operand be a
@code{asm}
Changed.
Hurray, and that's it for now.
Whew.
If you send an updated patch, I'd appreciate if you could also just
send a diff between the file as it is now (after the current patch
applied) and after those updates so that we can see what just changed
in between the two reviews.
I haven't attached a diff yet. Rather than fill everyone's inbox with
partial updates, I'll wait until we've agreed on the questions above.
If someone just can't wait, the web pages mentioned above have all the
items I marked as Changed.
BTW, do you want the standard "diff" output? Or diff -u?
As I wrote above, I approve if you make these changes -- or reply
noting where and why you did not -- and Andrew and Richard ack.
I've tried to make it clear when I made a change, and when I disagreed
with your proposed change. If my explanations as to why I didn't make a
change aren't clear or if you still disagree, let me know. There are
several points where I'm looking for your opinion or clarification
before proceeding.
I'd also like to make one last plug for having you at least page thru
one of the output formats (such as the html I linked to at the top).
While looking at the actual .texi lets you catch things like @ifhtml and
@cindex errors, I believe structure and formatting are clearer in html.
What's more, I feel confident saying more people will view the html text
than the texi, so a little extra effort to make sure the html is correct
is merited.
Thanks for your feedback,
dw
