Re: [m68k]: patch to fix objdump/MAC/EMAC for ColdFire

[Peter Barada <peter at the-baradas dot com>]

>   * You are still using K&R style function prototypes and headers.  We 
>are using ISO C now, so it would be good if you could use their, more 
>compact, style.
>
>   * Do you really need to use the "register" keyword ?  Any modern 
>compiler is going to produce good code with or without this keyword 
>being present, so I tend to regard it as noise in the sources.  [This is 
>an optional change.  I just bugs me that's all].

All I did was to lift the code as it was an moved it into a new
function while touching it as little as possible.  With your urging
I'll clean it up :)

>   * The code to work out the fixed length portion of an instruction in 
>match_insn_m68k() rings alarm bells to me.  Having special heuristics 
>here is just going to lead to trouble in the long run.  (eg if new 
>instructions are added which need more special case handling).  A much 
>cleaner approach would be to include this information as a new field in 
>the m68k_opcode structure and then statically initialise it in m68k_opc.c.

Opcodes on 68k have to be decoded to figure out the true instruction length
since the extension word(s) really dictates how long it can be, but I see
your point of having a field in the opcode table that indicates the
*nominal* size of the instruction so the special case for pflusha and
lpstop can be removed.  I'll have to think of how the length is
decoded depending on the addressing modes and extension words.

-- 
Peter Barada
peter@the-baradas.com