What does the FC field represent in the MIPS machine code for floating point compare instructions? Refer to figure below

Can you also tell me how to assembler behaves for values of FC=00,01,10 and 11.

When I execute the instruction on my assembler - I found FC=11. But I have no idea what it means.

The 2-bit fc field and the following 4 bits, both together, are really just the 6-bit func field.

I don't know why those authors choose break this apart into two side-by-side fields as it seems to serve no particular purpose that I can see.

Further, while they break the func field in two just for those several instructions, they revert to depiction of a 6-bit func field for all other instruction descriptions.

Because of this notation, in looking for an fc field of 0x0, 0x1, 0x2, 0x3, with the subsequent 4 bits being 0xc, we can also look for func field values of 0x0c, 0x1c, 0x2c, and 0x3c, some of which can be found.

A func value of 0x3c is for c.lt.s/d (with the proper opcode=0x11 and fmt=0x10/0x11 for single vs. double, of course).

A func field value of 0x0c is for round.w.s/d.

The other values, 0x1c & 0x2c are not to be found in the documentation, and this sort of omission is typical of unused opcodes, so one possibility is then that these are indeed unused opcodes for the R2000.

Entering 46 00 00 3c into https://disasm.pro/ (MIPS/big-endian) yields the proper c.lt.s, and 46 00 00 0c yields the expected round.w.s, whereas ending in 1c or 2c yield no disassembly.

Another source, MIPS green sheet, offers the same answers: 0x0c is for round and 0x3c for compare, while 0x1c and 0x2c are shown as unassigned.

What would we expect the processor to do with unassigned opcodes?  It is unclear and typically unspecified in great detail.  It takes work to detect these things so designers may allow the implementation to do what is most convenient (i.e. lowest hardware effort).  Thus, unspecified can be by omission or maybe even by explicitly being defined as undefined behavior!  Possibilities for execution range from causing some kind of exception/fault (unimplemented), to decoding the instruction improperly, which might mean running an instruction of very similar encoding.