Re: Help with UDI instructions

[Richard Sandiford <rdsandiford at googlemail dot com>]

Hi Steve,

Thanks the answer.

Steve Ellcey <sellcey@mips.com> writes:
> On Wed, 2013-07-17 at 20:49 +0100, Richard Sandiford wrote:
>> Steve, this is going to seem like a bit of a pointless distraction, sorry,
>> but do you have any internal info about how the "udi..." instructions are
>> being used in practice?  Since the whole point is that the instructions are
>> _user_-defined, I realise the answer's probably "no" by design.
>> 
>> The instructions were added in:
>> 
>>     http://article.gmane.org/gmane.comp.gnu.binutils/27744/match=udi0
>> 
>> I was just wondering about the way that they all have WR_d|RD_s|RD_t
>> (write to the rd register, read from the rs and rt registers).
>> The use of these flags is pretty limited, so it probably isn't going to
>> matter in practice.  But the ISA manual doesn't AIUI force a particular
>> format for the middle part of user SPECIAL2 opcodes, and things like
>> Octeon's CINS write to rt instead of rd, so I was wondering whether
>> it would be safer to assume that "udi..." modifies all GPRs (except $0,
>> of course).  Anyone agree or disagree?
>> 
>> The only reason I'm asking is that I'm trying to make the opcode descriptions
>> list the read and write operands by operand number rather than field type,
>> and this is one of the few cases where that isn't possible.  We could have
>> a special flag for the equivalent of "modifies rd, rs and rt" instead,
>> if assuming all GPRs seems too heavyweight.
>> 
>> Thanks,
>> Richard
>
> I am afraid I don't have any real information for you.

It's good information. :-)  It helps give an idea about the scope of thing.

> I talked to a few
> people here and while they think a couple of customers used them they
> don't have any details.  I did see a couple of documents over at
> developer.mips.com about using CorExtend (the MIPS name for UDI's)
> but I don't know if they bear any relationship to what people have
> actually implemented on any chips.

Hmm, OK.  In that case it'd probably be better to keep the current behaviour
after all.  The maintenance saving isn't big enough to justify the risk.
I'll just convert RD_s|RD_t|WR_d into a single "UDI" flag instead;
at least that means there's only one place making the assumption.

Thanks,
Richard