Documentation for movstrM, clrstrM -- more rambling and patch

[Jeffrey A Law]

  In message <199801182123.WAA01914@scar.axis.se>you write:
  > I guess I used the word "mode" confusingly in my previous mail a week ago.
  >  I meant the "mode" as in the *name* of the pattern; not really the mode of
  > its operands (although the third operand has this mode).
Yes, I think we saw "mode" and obviously thought of two different
things :-)

  > > The mode merely indicates the size of the units moved within the hunk.
  > No, the mode M in the pattern name does not reflect the size of the *units*
  > within the hunk; the *size of the entire "hunk"* must fit in a mode M.
  > The only indication of any "unit size" is the alignment, and it's just a
  > correlation. 
Yes, you're right.  I stand corrected :-)  The things one forgets
over time.  Somehow I had it in my brain that XX movstrXX had
something to do with size of each item and/or alignment.  That is
wrong.  Those patterns are free to move data in whatever sized hunk
they can handle and the alignment is a separate argument.

The moral, I should have re-read the docs first :-)

  > My point is for the documentation to be clear on that "movstrqi"
  > should *not* be defined instead of "movstrsi" (or larger), if
  > only for the reason that the instruction moves byte-wise, or needs
  > no specific block alignment, and that there's normally no use in
  > defining several "movstrM" patterns.  If people think that's already
  > clear, then sorry about the rambling.
There's nothing in md.texi about this, so a little clarification would
probably be a good thing.  It's easy to miss the interactions between
the existance of movstrXX patterns if you have more than one.

  > Anyway, it seems like no machine descriptions in the distribution is
  > affected by any confusion about this, so it's just a documentation issue.
Those are important too :-)

I made a couple minor edits and installed your change into egcs.  For
reference here's the text:

  Descriptions of multiple @code{movstr@var{m}} patterns can only be
  beneficial if the patterns for smaller modes have less restrictions
  on their first, second and fourth operands.  Note that the mode @var{m}
  in @code{movstr@var{m}} does not impose any restriction on the mode of
  individually moved data units in the block.


Thanks,
jeff