This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Minor tweaks to the MIPS documentation
- From: Eli Zaretskii <eliz at gnu dot org>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: rdsandiford at googlemail dot com, binutils at sourceware dot org
- Date: Wed, 26 Jun 2013 05:50:04 +0300
- Subject: Re: Minor tweaks to the MIPS documentation
- References: <87a9mi5d8l dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1306252252320 dot 16287 at tp dot orcam dot me dot uk>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Tue, 25 Jun 2013 23:15:23 +0100
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
> CC: Eli Zaretskii <eliz@gnu.org>, <binutils@sourceware.org>
>
> On Sat, 22 Jun 2013, Richard Sandiford wrote:
>
> > Several small and unexciting changes:
> >
> > - Consistently use "MIPS" rather than "@sc{mips}". "@sc{mips}" looks strange
> > in the PDF output and "MIPS" was already the prevalent form. Also,
> > "@sc{mips}" doesn't really look right alongside "microMIPS".
>
> Thanks, I think you missed a couple that are not strictly "MIPS" though,
> a patch follows. And I think @sc{isa} might fall into the same category
> (but I haven't touched these). I also changed one "MIPS3" to "MIPS III"
> for consistency with "MIPS V" used elsewhere, and replaced some other @sc
> commands with @samp for consistency with the corresponding part of
> as.texinfo. Also I think we should standardise on "MIPS16" rather than
> "MIPS 16" used in some places, the latter has never been proper usage.
>
> Overall perhaps using @acronym{MIPS}, @acronym{microMIPS}, @acronym{ISA},
> etc. like the GDB manual does for these names would be a good idea? I
> remember Eli (cc-ed), the GDB manual reviewer, being quite keen on using
> this command for this purpose. Plus keeping the manuals at least remotely
> consistent in style across toolchain pieces seems reasonable to me.
>
> As to this change -- checked html, info and pdf output. OK to apply?
I'd prefer to use @acronym, indeed. @samp is certainly not right in
these cases.