"Always been multithreaded"? MIPS burst into the scene as one of the original RISCS (Hennessy and Stanford created MIPS, Patterson and Berkley created SPARC) and shot to amazing heights with SGI. Eventually, it lost ground in the big server/workstation world but was ruling the consoles with an iron fist. During none of this do I remember MIPS being multithreaded (it might have lasted slightly longer if it had been).
I'm guessing that happened during the long years when ARM squeezed it out of the phone market, but MIPS was getting more and more obscure then.
Please don't take things out of context: "The special-sauce of MIPS CPUs has always been their multi-threading capabilities."
That is not the same as saying they have always been multithreaded. Just that their multithreading implementations have been interesting from an architecture standpoint.
Huh? Was ANYTHING besides Nintendo64 MIPS-based? Granted, that seemed to turn out fairly well. But the decision to use MIPS was largely down to the partnership with SGI to design the thing.
Perhaps you're thinking of POWER. For a time, all current consoles were built around POWER-derived cores: Game Cube/Wii, XBox 360, and PS3.
"VMT on the other hand doesn’t execute two threads at the same time, but is able to efficiently switch between threads at extremely low context switch cost."
Wait, why would anyone do that in a multi-core processor?
The same reason we use SMT. Inevitably all of your hardware threads will be out-numbered by software threads. The goal of SMT is to leverage unused cycles to execute multiple threads concurrently. The goal of VMT is to avoid introducing cycles when switching between non-concurrent threads. This is similar to how fine-grained multithreading worked on the last generations of UltraSPARC chips, except it is likely more flexible.
I would disagree with the claim that VMT is a kind of SMT as they serve different purposes. VMT guarantees execution time for threads sharing a core (good for real-time scheduling) and it is also more predictable when instructions will run compared to SMT. Whereas, SMT just tries to get instructions through as quick as possible and there are no guarantees what order they are executed in, beyond the data dependency requirements.
TL;DR: VMT is good for predictable and/or real-time execution of multiple SW threads; SMT is good for maximizing IPC at the expense of predictability.
In MIPS the VPE is a virtual processor, this is almost identical to how SMT. If you have a two core process or and two VPEs per core you have four logical cores. Simple...This MIPS processor supports 3 VPEs per core meaning 12 Logical processors on a 4 core system.
The more complex bit is the VMT where you have TC's or thread contexts. MIPS has some special instructions to support this (provided it hasn't changed since I last worked with it). One instruction is called "fork". A programmer can call fork and pass an argument of a register with a memory address in it. The processor launches a new thread and starts executing at the address held in that register.
If you imagine you are processing network packets in real time. When a packet arrives, if you have a a spare thread which isn't running you can call fork and instantly start running a new thread and have that thread go off an process the packet. When it completes it can signal the main thread and exit via another special instruction.
This is quite a powerful technique for real-time systems. Last time I was working with MIPS processors Linux only saw Virtual cores (VPE's) but couldn't make use of the VMT or Thread context based instructions. It is a technique which only makes sense in real-time systems.
I assume the real issue here is that the TC part of the VMT assumes a common address space. So you can cheaply swap between threads within the same app, but there is a cost to switching to a different app. User-level register state is duplicated (triplicated!) in hardware, but OS-level state (like memory mapping) is not.
VMT sounds a lot like PowerPC, low latency context switching. That made our radio front-end techs happy, back when I was working at a radio shop. This MIPS architecture feels like they have been listening to their LTE, 5G customers.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
16 Comments
Back to Article
wumpus - Tuesday, May 1, 2018 - link
"Always been multithreaded"? MIPS burst into the scene as one of the original RISCS (Hennessy and Stanford created MIPS, Patterson and Berkley created SPARC) and shot to amazing heights with SGI. Eventually, it lost ground in the big server/workstation world but was ruling the consoles with an iron fist. During none of this do I remember MIPS being multithreaded (it might have lasted slightly longer if it had been).I'm guessing that happened during the long years when ARM squeezed it out of the phone market, but MIPS was getting more and more obscure then.
SaberKOG91 - Tuesday, May 1, 2018 - link
Please don't take things out of context: "The special-sauce of MIPS CPUs has always been their multi-threading capabilities."That is not the same as saying they have always been multithreaded. Just that their multithreading implementations have been interesting from an architecture standpoint.
mode_13h - Tuesday, May 1, 2018 - link
Yeah, MIPS' history goes way back before SMT.> ... was ruling the consoles with an iron fist.
Huh? Was ANYTHING besides Nintendo64 MIPS-based? Granted, that seemed to turn out fairly well. But the decision to use MIPS was largely down to the partnership with SGI to design the thing.
Perhaps you're thinking of POWER. For a time, all current consoles were built around POWER-derived cores: Game Cube/Wii, XBox 360, and PS3.
Interestingly, I just learned 3DO was ARM-based!
wolrah - Wednesday, May 2, 2018 - link
> Huh? Was ANYTHING besides Nintendo64 MIPS-based?PSX used a R3000 CPU, and of course PS2s used it as an I/O controller.
mode_13h - Wednesday, May 2, 2018 - link
Thanks.Heh, you forgot to point out that gen1 PS3 included it, by virtue of including a full PS and PS2 implementation for full backward-compatibility.
mr_tawan - Thursday, May 3, 2018 - link
I think EE's cpu core is also MIPS (R5900) as well.mr_tawan - Thursday, May 3, 2018 - link
Seems like PSX, PS2 and PSP are all MIPS-basedHStewart - Sunday, May 6, 2018 - link
I thought MIPS was dead - this stuff is extremely old - this was RISC before ARM was there.But PS3 was something totally different - the problem was that it hard to developed for.
psychobriggsy - Tuesday, May 1, 2018 - link
MIPS page on nanoMIPS: https://www.mips.com/products/architectures/nanoMI...fishjunk - Tuesday, May 1, 2018 - link
"VMT on the other hand doesn’t execute two threads at the same time, but is able to efficiently switch between threads at extremely low context switch cost."Wait, why would anyone do that in a multi-core processor?
SaberKOG91 - Tuesday, May 1, 2018 - link
The same reason we use SMT. Inevitably all of your hardware threads will be out-numbered by software threads. The goal of SMT is to leverage unused cycles to execute multiple threads concurrently. The goal of VMT is to avoid introducing cycles when switching between non-concurrent threads. This is similar to how fine-grained multithreading worked on the last generations of UltraSPARC chips, except it is likely more flexible.I would disagree with the claim that VMT is a kind of SMT as they serve different purposes. VMT guarantees execution time for threads sharing a core (good for real-time scheduling) and it is also more predictable when instructions will run compared to SMT. Whereas, SMT just tries to get instructions through as quick as possible and there are no guarantees what order they are executed in, beyond the data dependency requirements.
TL;DR:
VMT is good for predictable and/or real-time execution of multiple SW threads; SMT is good for maximizing IPC at the expense of predictability.
jab701 - Tuesday, May 1, 2018 - link
In MIPS the VPE is a virtual processor, this is almost identical to how SMT. If you have a two core process or and two VPEs per core you have four logical cores. Simple...This MIPS processor supports 3 VPEs per core meaning 12 Logical processors on a 4 core system.The more complex bit is the VMT where you have TC's or thread contexts. MIPS has some special instructions to support this (provided it hasn't changed since I last worked with it). One instruction is called "fork". A programmer can call fork and pass an argument of a register with a memory address in it. The processor launches a new thread and starts executing at the address held in that register.
If you imagine you are processing network packets in real time. When a packet arrives, if you have a a spare thread which isn't running you can call fork and instantly start running a new thread and have that thread go off an process the packet. When it completes it can signal the main thread and exit via another special instruction.
This is quite a powerful technique for real-time systems. Last time I was working with MIPS processors Linux only saw Virtual cores (VPE's) but couldn't make use of the VMT or Thread context based instructions. It is a technique which only makes sense in real-time systems.
name99 - Tuesday, May 1, 2018 - link
I assume the real issue here is that the TC part of the VMT assumes a common address space. So you can cheaply swap between threads within the same app, but there is a cost to switching to a different app.User-level register state is duplicated (triplicated!) in hardware, but OS-level state (like memory mapping) is not.
peevee - Tuesday, May 1, 2018 - link
"L1I/$ caches"Andrei, it looks like they use "$" as a shorthand for "cache". So "L1$s" in their text means Level 1 caches.
Elstar - Tuesday, May 1, 2018 - link
Ya. Using "$" as shorthand for "cache" is a fairly common industry convention.watersb - Thursday, May 3, 2018 - link
VMT sounds a lot like PowerPC, low latency context switching. That made our radio front-end techs happy, back when I was working at a radio shop. This MIPS architecture feels like they have been listening to their LTE, 5G customers.