This is great news. When I was in college the microprocessor design class used a variant of MIPS though this started the quarter after I took the class. In my class we had to wire-wrap a 16-bit MIPS-like CPU using discrete chips and a couple programmable ones. MIPS is relatively easy to implement for educational purposes due to the simple instruction encoding and clean architecture. MIPS, unlike some other processors like ARM, also allows you to add your own instructions using coprocessor 2 which can be a great way to differentiate a processor and enhance it for different tasks. MIPS is a much simpler design compared to ARM or even PowerPC. MIPS is still widely used, especially in networking devices.
For example, my current employer has added a lot of instructions useful for encryption and hashing as well as some useful atomic instructions.
The move from 32-bits to 64-bits is actually quite clean on MIPS which did not require any major changes to the instruction set other than adding 64-bit instructions and sign-extending the 32-bit instructions. There are a few warts on it, such as the fact that the instruction following a branch instruction is always executed (SPARC is the same way). This is no longer all that useful with modern superscalar architectures and the branch delay slot can't always be filled with something useful. Things are also a bit cramped for 32-bits since only the lower 2GB of memory is available for user-space. Kernel space (KSEG0) is from 0x80000000-0x9fffffff and an uncached copy is at 0xa0000000-0xbfffffff. 0xC0000000 - 0xDFFFFFFF can be mapped using the translation look-aside buffer, making another 512MB available to the kernel. Both of these address ranges map directly to the lower 512MB of RAM which somewhat limits things. In 64-bit mode this isn't a problem though since all addresses are sign-extended. Another nice feature in kernel mode is that all physical addresses can be directly accessed, without requiring any special mapping other than setting bit 63 to 1.
Most MIPS processors do not use a hardware page table walker, instead relying on a software configured translation look-aside buffer. When there's a page miss, a quick interrupt occurs to replace an entry in that table with some hardware assist. This goes back to the original philosophy of keeping the hardware design simple. Due to the way it works, it allows total freedom with how page tables are represented in the operating system though there can be a slightly bigger overhead compared to hardware page tables.
The instruction set is quite clean and the instruction encodings are quite simple with only a few classes of instructions, unlike ARM64. Instruction decoding can be handled with only a few look-up tables. MIPS assembly language is far simpler and straight forward than, say X86 and it's quite mature, though not all processors implement all instructions. Many embedded MIPS processors lack floating point and the multimedia extensions, and many are 32-bit only. This helps cut cost and power when making chips for devices that don't need these features. MIPS also can scale up nicely. For example, the chips I work with currently scale up to 48 cores per chip and with two chips running in tandem Linux runs on 96 cores, all with a coherent cache. The newer ABIs are nice in that the only real difference between N32 and N64 is that pointers are 64-bits instead of 32-bits, just about everything else is the same so you get all of the features of 64-bit registers but keep the compactness of 32-bit pointers. This has been present for many years and is a fairly recent addition to X86 and ARM.
