Re: [doc] extend.texi copy-editing, 3/N (hyphenated phrases)

[Sandra Loosemore <sandra at codesourcery dot com>]

On 12/18/2012 10:42 PM, Gerald Pfeifer wrote:
> Hi Sandra,
>
> On Sat, 10 Nov 2012, Sandra Loosemore wrote:
> > 2012-11-10  Sandra Loosemore<sandra@codesourcery.com>
> >
> > 	gcc/
> > 	* doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
> > 	involving "bit", "byte", "word", "precision", and "floating"
> > 	modifiers.
>
> Index: gcc/doc/extend.texi
> ===================================================================
> -for targets having @code{long long} integer with less then 128 bit width.
> +for targets having @code{long long} integer less than 128 bits wide.
>
> Should this one read "long long integer_s_" (plural)?

I'd probably rephrase this one as

for targets with @code{long long int} less than 128 bits wide.

> -causes the compiler to pass up to 3 floating point arguments in
> +causes the compiler to pass up to 3 floating-point arguments in
>
> While we are at it, should this be "three" instead of "3"?  It would
> in my native Austrian/German, but perhaps English is different here?

I'm not picky about use of digits vs spelled-out numbers as long as 
parallel constructions use the same thing (e.g., not "3 dogs and four 
cats").  Journalism style guides recommend spelling out numbers less 
than 10, while technical ones recommend using digits most of the time, 
but there are all sorts of exceptions in both cases.

> -Generate code that uses (does not use) the popcount and double
> -precision FP reciprocal estimate instruction implemented on the POWER5
> +Generate code that uses (does not use) the popcount and double-precision
> +FP reciprocal estimate instruction implemented on the POWER5
>
> Should this one by "floating-point" instead of FP?
>
> And @code{popcount} ?

I wouldn't know what the right terminology for these instructions is 
without looking it up in the architecture manual.  Is popcount even the 
literal name of the instruction?  Most of the other items in this list 
seem to be describing the purpose of the instructions rather than naming 
them.

In general, the GCC manual is not consistent about markup on machine 
instruction names.  I think @code markup is a good choice, but in the 
same section I see other instructions named as "@samp{dlmzb}" and 
"ISEL".  This is something that's hard to identify with mechanical 
searching, too.

BTW, in my copy-editing I've tried to avoid messing too much with text 
that's full of technical details or jargon I'm not familiar with, since 
I might inadvertently change the meaning by attempting to rewrite it. 
I've spent the time to look up the details and correct terminology for 
some sections that seemed particularly unreadable, but in cases like 
this one I thought the text was probably comprehensible as-is to 
somebody familiar with the processor.

> I'll be happy to make all those changes, wanted to verify with you as
> a native speaker, and one who cares about grammar, first though. ;-)

Heh, glad to offer what help I can.

-Sandra