On Mon, 16 Aug 2021, Dragan Mladjenovic via Gcc-patches wrote:
> I'll respin the tests for mips64r2 and mips64 just in case.
>
> This check would fail for -mips64. GAS accepts jr.hb for both '.set mips64'
> and
> '.set mips64r2' and '.set mips32' for that matter. mips-opc.c has the
> following
> comment:
> /* jr.hb is officially MIPS{32,64}R2, but it works on R1 as jr with
> the same hazard barrier effect. */
That it works on R1 is however not universally true, because as I recall
at least the original 4Kc CPU does trap with RI on non-zero hint values.
It may have qualified as a processor erratum though. I just did a quick
run-time check with a 5Kc CPU and that one does execute the JR.HB encoding
just fine. I don't have a specimen of 4Kc that I could readily use, even
though I do believe I have a 4Kc module along with an Algorithmics board
that could use it and which could possibly run NetBSD (I haven't checked).
NB the semantics claim is even less true, because there is no hazard
barrier effect with the R1 JR or JALR instructions ever, and for example
the 4Kc does require to have any hazards resolved by placing a suitable
number of intervening instructions (which do not have to be SSNOP however
as the 4Kc is not superscalar). So a typical instruction hazard such as a
change of the ASID is requires 1 spacing instruction and 3 such for a data
access and an instruction fetch respectively affected by a change of the
ASID[1].
I don't know where the note in mips-opc.c originally came from and at
this point it cannot be verified. As it was typical at the time, the
change was posted with just a vague note referring a "mixed bag of opcode
table changes" as it was applied[2], so it does not help.
References:
[1] "MIPS32 4K Processor Core Family Software User's Manual", MIPS
Technologies, Inc., Document Number: MD00016, Revision 01.17,
September 25, 2002, Table 2-6 "Instruction Hazards", p. 28
[2] "MIPS opcode table update",
<https://sourceware.org/ml/binutils/2006-05/msg00056.html>
Maciej
