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

[Richard Henderson]

On 2/6/20 2:03 PM, Taylor Simpson wrote:
> Some of the more complex instructions need a lot of operands.  Here's an 
> example
>     if (Pv4) memb(Rs32 + Ru32 << #u2) = Rt32
> This is a predicated store with 5 operands:
>     Pv4predicate
>     Rs32, Ru32, u2used to compute the effective address
>     Rt32value to store
> In addition, every helper gets an env argument, and predicated instructions 
> get a "slot" argument.  The slot argument refers to the VLIW slot where the 
> instruction is located within the packet.  It is used for predicated 
> instructions to communicate to the end-of-packet handling to determine 
> whether the instruction should commit.
> 
> So, the signature for the helper for this instruction is
>     void HELPER(S4_pstorerbt_rr)(CPUHexagonState *env, int32_t PvV, int32_t 
> RsV, int32_t RuV, int32_t RtV, int32_t uiV, uint32_t slot)


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.

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:

        and     t0, pv, 1
        brcondi t0, 0, over

        shli    t0, ru, u2
        add     t0, t0, rs
        qemu_st rt, t0, mmu_idx, MO_UB
 over:

But suppose this were something more complicated than a bare store, and the
point still stands about pre-computing full addresses.


r~