Re: [PATCH][2/3] Instruction patterns changes and instruction attributes

[Roman Zippel <zippel at linux-m68k dot org>]

Hi,

On Tue, 11 Sep 2007, Maxim Kuvyrkov wrote:

> > emit_move_double() should actually look quite different - especially a lot
> > simpler, a number of move combination should be avoided in first place, any
> > register adjustments should be avoided.
> 
> Could you implement this, please?

It's on my todo list, but you were already working in this area. Not that 
many people are working on the m68k port, so it would have been nice to 
avoid this duplication of work...

> > Most of the problem is propably, that your 3rd patch is incomplete.
> 
> The 3rd patch is a complete set of changes, but it is certainly not the whole
> ColdFire scheduling support I'm working on.  Submitting everything at once
> would make the patch much larger and harder to review.

The point is that stuff is currently unused and I have no idea how it will 
be used.

> > My suspicion is that you barely take advantage of the m68k instruction
> > format. It should be possible to derive some of these from the type.
> 
> I don't follow you here.  If you mean 'derive other attributes from the type
> attribute' then this is the way its done to a reasonable extent.

I had the op_mem attribute in mind, m68k has quite a few operand patterns 
(e.g. <ea>,%d0 or #imm,<ea>), but they are quite uniform for most 
instructions, so then classifying operands this can be used to keep things 
simple.

> > Well, since it's only a debugging feature, what's the problem, if it's a
> > little hackish?
> 
> There is a standard way of mapping properties to instruction patterns -
> instruction attributes.  It is simple and hence more robust.

The point is that there are different ways at getting the same 
information, so why make it more complicated than necessary?
Below is example patch which would annotate the assembler source already 
with some basic split information and only there it can't be determined 
attributes are needed.

> > I also don't think it's a good idea to document all constraints, some should
> > be left to internal use. It also seems that it's already incorrect (e.g.
> > Cmvq).
> 
> I believe that all constraints should be documented.  Especially when there is
> a plan to generate texinfo for constraints directly from .md files.

Yes, but even this provides means to mark a few of them privately.
That still doesn't change the fact you added incorrect documentation.

bye, Roman