qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] Add support for a helper with 7 arguments


From: Taylor Simpson
Subject: RE: [PATCH] Add support for a helper with 7 arguments
Date: Fri, 7 Feb 2020 04:46:34 +0000


> -----Original Message-----
> From: Richard Henderson <address@hidden>
> Sent: Thursday, February 6, 2020 6:28 PM
> To: Taylor Simpson <address@hidden>; Richard Henderson
> <address@hidden>; address@hidden
> Cc: Paolo Bonzini <address@hidden>
> Subject: Re: [PATCH] Add support for a helper with 7 arguments
>
> On 2/6/20 5:52 PM, Taylor Simpson wrote:
> >
> >
> >> -----Original Message-----
> >> From: Richard Henderson <address@hidden> On Behalf Of Richard
> >> Henderson
> >> Sent: Thursday, February 6, 2020 9:35 AM
> >> To: Taylor Simpson <address@hidden>; address@hidden
> >> Cc: Paolo Bonzini <address@hidden>
> >> Subject: Re: [PATCH] Add support for a helper with 7 arguments
> >>
> >>
> >> I think this is quite ugly.  I know you've been talking about auto-
> generating
> >> everything but we ought to do better than this.
> >>
> >> You should be passing values not regnos if you can possibly do so.  You
> >> should
> >> be passing full virtual addresses not N separate components of an
> address.
> >> Predicates should be evaluated earlier so that the helper isn't even called
> if
> >> it's false.
> >
> > We are passing values, not reg numbers.  The generator doesn't know
> anything about the semantics of the instruction...
>
> And this, I claim, is wrong.
>
> If you can generate C for the operation out of line, then you can interpret it
> inline as well.  Or, make a reasonable decision about what bit to be out of
> line and what bit to be a helper.
>

The C code for the operation is not generated - it comes as the semantics of 
the instruction.  The generator only knows how to set up the call to the helper 
based on the signature of the instruction, and it pastes the C code into the 
body of the helper.

> > It only knows which operands are read, written, or both.  So, there's no
> way
> > to combine the 3 operands into a single effective address until we are
> > inside the helper.  Also, there's no way to know if the instruction is
> > predicated or if it just has a predicate as an operand.  Also, there are
> > instructions where the predicate is used in the false sense.
> There certainly is a way to know what the effective address is.  From the
> pseudo-code that I browsed today, "EA = foo" is a big clue.
>
> There certainly is a way to know if the instruction is predicated.  From the
> pseudo-code that I browsed today,
>
>   if (pred) {
>     operation;
>   } else {
>     NOP;
>   }
>

I don't see the value of having the generator generate TCG for part of the 
semantics and using a helper for another part.  We already have a mechanism for 
overriding the entire instruction.  For instructions where there's a reason not 
to use the helper, we replace it completely.

> is the clue, vs
>
>   Rd = mux(Pu, Rs, Rt).
>
> Of course there are insns where !Pd is used; that doesn't change anything.
>
> >> Combine that with 3.3.1 Packet execution semantics, "dual stores, new-
> value
> >> stores, and slot1 store with slot0 loads have non-parallel execution
> >> semantics", and you need no special helper at all:
> >>
> >> andt0, pv, 1
> >> brcondit0, 0, over
> >>
> >> shlit0, ru, u2
> >> addt0, t0, rs
> >> qemu_strt, t0, mmu_idx, MO_UB
> >>  over:
> >>
> >
> > We can't actually do the store here.  We have to record it in a side data
> structure in the env and perform the store when the packet commits.
>
> I think that we can do the store immediately -- I give specifics above.  Do 
> you
> have a counter-example?  Admittedly I'm new to browsing the architecture,
> but I
> don't see a legal packet for which you can't just Store Now.

You can have two stores in a packet, and the second one could fault.  If 
anything in the packet faults, none of the instructions commit.

>
> > Currently, there are a total of 35 instructions that need a helper with 7
> arguments.  32 of them are predicated stores, but there are also 3 vscatter
> instructions.  For example,
> >     if (Qs4) vscatter(Rt32, Mu2, Vv32.w).w = Vw32
>
> Ok, vscatter is indeed complex.  But I still count 6 operands.  Is it the
> "slot" one that you're concerned is the 7th?  I don't see that as strictly
> necessary, since this can only be in slot 0.

Yes, the 7th operand is the slot.  Today, these instructions can only be in 
slot 0.  We could hard code that, but what happens down the road when the 
architects change it?  That's a bad tradeoff to make just to avoid allowing 7 
arguments to a helper.

>
>
> r~

reply via email to

[Prev in Thread] Current Thread [Next in Thread]