Re: 2nd try for patch for automaton based pipeline hazard recognizer (part #1)

[Vladimir Makarov <vmakarov at redhat dot com>]

Dan Nicolaescu wrote:
> 
> Vladimir Makarov <vmakarov@redhat.com> writes:
> 
>   > Dan Nicolaescu wrote:
>   > >
>   > > Vladimir Makarov <vmakarov@redhat.com> writes:
>   > >
>   > >   > Dan Nicolaescu wrote:
>   > >   > >
>   > >   > > [snip]
>   > >   > >
>   > >   > > I have a comment on the constructs used to describe the pipeline, it
>   > >   > > uses regular expressions in a string.
>   > >   > >
>   > >   > > That is a little bit not-orthogonal with the rest of the .md file, as
>   > >   > > regexps are an infix notation and the rest of .md language is a prefix
>   > >   > > language.
>   > >   > >
>   > >   > > IMO something like:
>   > >   > >
>   > >   > > (define_insn_reservation "mult" 4 (eq_attr "cpu" "mult")
>   > >   > >                          (sequence "i1_pipeline"  (nothing 3)
>   > >   > >                                    (or "port_0"  "port1")))
>   > >   >
>   > >   > Hi, Dan.
>   > >   >
>   > >   > Sequence requires list of rtl expressions.  That means you should write
>   > >   >
>   > >   > (sequence (const_string "i1_pipeline")  (nothing 3)
>   > >   >
>   > >   > > is a little bit more understandable and probably easier to parse
>   > >   > > than:
>   > >   > >
>   > >   > > (define_insn_reservation "mult" 4 (eq_attr "cpu" "mult")
>   > >   > >                          "i1_pipeline, nothing*3, (port_0 | port1)")
>   > >   > >
>   > >   > > (stolen from your example)
>   > >   > >
>   > >   > > Of course this could turn into a religious discussion...
>   > >   > > Just wondering what everybody thinks...
>   > >   >
>   > >   >   RTL has some constructions which could be used to describe the
>   > >   > reservations (sequence, parallel etc.). If we are using rtl
>   > >   > constructions to describe the reservation, it will be too verbose.
>   > >   > Typical example is using (const_string "a") instead of "a".  A 200 lines
>   > >   > description (of one VLIW processor) would be 400-600 lines in such
>   > >   > case.  Also this description would be not readable.  Actually, the first
>   > >   > design used such approach and was rejected.
>   > >   >
>   > >   >   If we don't use existing RTL constructions, we need to create new ones
>   > >   > slightly different to the existing constructions which is also not
>   > >   > good.  So I'd choose brevity and simplicity to orthogonality in this
>   > >   > case.  That is not only my opinion.
>   > >
>   > > You could create a few new constructs: (pipe_sequence ... )
>   > >                                   or (pseq ... )
>   > >
>   > > You just need 3-4 of them. (You introduce new constructs with the
>   > > regexp syntax anyway, so I don't think this is a problem).
>   > >
>   >
>   >   Dan, it will be too verbose.  Even if you don't use the existing rtl
>   > construction,  you need nested constructions which is rtl expressions.
>   > It results in that you should always use for each name (const_string
>   > "...").  If we don't use the nested constructions, the model will be too
>   > primitive.
> 
> You don't have to. You are writing a new reader anyway, so you can
> make it read whatever you want. So the change is just from a regexp
> infix format to a prefix parenthesized format.

My reader is standard RTL reader.  You need only to define templates in
rtl.def which says about parameter types.  If you define parameter type
as a string, you can not use expression (the nested constructions).  If
you define the paarmeter type as an expression, you should use
(constant_string "...").  Unless somebody writes new insfrastructure for
RTL which permits to define union of types, you should use
(constant_string "...").

Vlad