Vladimir thanks for help!
With respect to your answer I would like to point to you a possible way to
solve the scheduling problem
(which I think wont be too difficult to be implemented in genautomata).
To explain it, I will make use of the “move insn” example pointed in the
previous email.
First of all I do not change anything in the 2 automatons (aut1 and aut2); they
are correctly built by the genautomata.
Next to the original
> (define_reservation "move" "( (unit1_aut1, unit1_aut2) |
> (unit2_aut1, unit2_aut2)
> )
I define two separate fake move instructions (i.e., “move_fake1” and
“move_fake2”) of which semantic does play any role; each of them
having a unit reservation one of the alternatives of the “move”:
(define_reservation "move_fake1" "( (unit1_aut1, unit1_aut2)), and
(define_reservation "move_fake2" "( (unit2_aut1, unit2_aut2) ).
Those two extra moves are then used during the sched2 target hook
TARGET_SCHED_DFA_NEW_CYCLE to decide which of the move alternative unit
reservations can be correctly claimed.
Suppose the ready instruction is a “move”.
First I make 2 copies of the current state: temp_state1 and temp_state2.
Then I check which of the two fake moves ( “move_fake1” and “move_fake2”) with
different unit occupation can be issued at the current state:
cost_move_fake1 = internal_state_transition (insn_code_move_fake1, temp_state1);
cost_move_fake2 = internal_state_transition (insn_code_move_fake2, temp_state2);
Once I find the correct choice (suppose cost_move_fake1 <0), I set
dfa_insn_codes[] of the ready instruction to the one of move_fake1.
int uid = INSN_UID (ready);
if (uid >= dfa_insn_codes_length)
dfa_insn_code_enlarge (uid);
dfa_insn_codes[uid] = internal_dfa_insn_code (insn_code_move_fake1);
In this way when the scheduler calls internal_state_transition, the ready
instruction has been already set its dfa_insn_codes to a unit reservation
schedulable in the current state.
regards,
Alex
--- On Tue, 3/3/09, Vladimir Makarov <[email protected]> wrote:
> From: Vladimir Makarov <[email protected]>
> Subject: Re: query automaton
> To: [email protected]
> Cc: [email protected]
> Date: Tuesday, March 3, 2009, 4:35 PM
> Alex Turjan wrote:
> > Dear Vladimir,
> >> Not really. There is no requirement for "the
> units
> >> part of the alternatives of a reservation must
> belong to the
> >> same automaton". Querying should also work
> in this
> >> case because function cpu_unit_reservation_p
> checks all
> >> automata for an unit reservation.
> > Indeed it checks all automata but Im afraid that
> according to my pipeline description this check is not
> enough to guarantee a correct scheduling decision, e.g.,
> > suppose the following insn reservation:
> > (define_reservation "move" "(
> (unit1_aut1, unit1_aut2) | (*)
> > (unit2_aut1,
> unit2_aut2) )
> > ,where unitN_autM refers to unit N from automata M. In
> this case there are 2 automata. Now supose a scheduling
> state S made of the individual states of the two automatons
> S=<S_aut1,S_aut2>. According to what I see happening
> in insn-automata.c (and target.dfa), from S_aut1 there is a
> transition for unit1_aut1 and from S_aut2 there is a
> transition for unit2_aut2.
> > It seems that the automata do not communicate with
> each other. As a consequence, A scheduling decision which
> results in the resource reservation (unit1_aut1,
> unit2_aut2) would not be rejected, while it should. In my
> opinion, the current implementation sees the reservation
> defined in (*)
> > As equivalent to the following one
> > (define_reservation "move" "(
> (unit1_aut1| unit2_aut1) ,
> > (unit1_aut2|
> unit2_aut2) ) Which does not seem true to me.
> > Is there a way for automatons to communicate so that
> the alternative (unit1_aut1, unit2_aut2) would be rejected?
> >
> >
> Last two days, I've been working on this issue. I
> found that you are right, genautomata permits to generate
> incorrect automata although I did not find that it is a case
> for major current description which I checked.
>
> I found the issue is complicated. Genuatomata has already
> a check for correct automata generations in
> check_regexp_units_distribution but that is not enough. I
> am working on formulation of general rules for correct
> automata generation and implementation of their check. I
> think it will take a week or two to do this and check how
> does it work for all current automata description.
>
> Alex, thanks for pointing out this issue to me.
