Re: optimisation for default_print_insn().

["Frank Ch. Eigler" <fche at toenail dot toronto dot redhat dot com>]

Hi -

:  > OK to commit?
: 
: I'd rather not.  Studying the code, the comment above print_insn,
: and the m32r port makes it seem to me that the read_insn
: at the start of print_insn is the duplicate.
: Why was it added?

It looks related to fr30 assembly support; one of the first ports
that exercised varying length instructions.  To me, it makes sense
to have the read_insn() call in print_insn().  The ambiguity could
be resolved by eliminating that buf[] argument that passes between
default_print_insn and print_insn.  It seems that the only reason
for having two calls to read_insn() in the first place was the hack
to decode the 16-bit-insn-pair vs. single-32-bit-insn alternatives
in the m32r disassembler.

- FChE