[PATCH] Add MIPS ufr macro instruction

[Richard Sandiford]

Andrew Bennett <Andrew.Bennett@imgtec.com> writes:
>> On Sun, 24 Nov 2013, Richard Sandiford wrote:
>> 
>> > The problem with using ufr for disassembly is that AFAICT it isn't
>> > mentioned in the manuals.  People disassembling pass-me-downs might
>> > struggle to know what it means.  Maybe the ideal would be to disassemble
>> > the CTC1 normally and add a comment "; ufr [01]" next to it.  But that's
>> > probably make-work.
>> > 
>> > So TBH I preferred your original patch.
>> > 
>> > There haven't been any more objections, so if you're still OK with the
>> > original version, I suggest we go with that.  I can apply it for you if so.
>> 
>>  Apologies for late coming, I missed this thread.  I object.  I think it 
>> would make more sense if we followed the practice already established with 
>> CP0 register names and instead defined cooked names for CP1 control 
>> registers as well.  E.g.:
>> 
>> 	ctc1	$0, $c1_ufr
>> 	ctc1	$0, $c1_unfr
>> 	cfc1	$2, $c1_ufr
>> 
>> or suchlike.  I think it would be more obvious, user friendly (including 
>> disassembly) and consistent.  If we wanted $0 implied for cases where 
>> applicable we could define single-argument aliases, e.g.:
>> 
>> 	ctc1	$c1_ufr
>> 	ctc1	$c1_unfr
>> 
>> preferably as macros as far as I'm concerned (although I'm not too
>> enthusiastic about such aliases in the first place).
>> 
>>  Of course we'd add the rest at the same time too, i.e. $c1_fir, $c1_fcsr, 
>> etc.
>> 
>>  Thoughts?
>
> I like this solution.  Firstly, it makes it much easier to see what the c[ft]c1
> instruction is actually doing when either assembling or disassembling.
> Secondly,
> it is clear when a ufr instruction is being used, so I don't think it
> requires the
> need to have an explicit ufr macro.
>
> If everyone is happy with this I will rework the patch, and post it back on to
> the list.

Thanks, soounds good to me too.

Richard