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: Richard Henderson
Subject: Re: [PATCH] Add support for a helper with 7 arguments
Date: Fri, 7 Feb 2020 00:27:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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.

> 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;
  }

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.

> 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.


r~



reply via email to

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