11 ms·
Can MIPS Leapfrog RISC-V?
- saagarjha 8y ago> MIPS’ target customers will include Arm licensees looking for alternatives. > MIPS’ advantages over competitors are many. Its instruction sets already have extensions such as SIMD (single instruction, multiple data) and DSP. But…ARM has those things?
- soapdog 8y agoARM has those things but MIPS, once this process is completed, will be open source. This makes a difference regarding license pay.
- justincormack 8y agoAlso you can modify the instruction set, which you cannot do with Arm. Risc-V has a detailed model of which bits you can change,what is the common core and so on, which Mips will need too.
- Vogtinator 8y agoARM has vendor extension space as well. Intel used that for DSP and "Wireless MMX" in their Xscale CPUs.
- JoachimS 8y agoDepending on what the license actually will be. ARM has for example presented "free" cores to fight against RISC-V. Free as in slightly cheaper beer. https://www.bit-tech.net/news/arm-responds-to-risc-v-threat-with-free-cortex-cores/1/ https://www.bit-tech.net/news/arm-responds-to-risc-v-threat-...
- JoachimS 8y agoYes, and so to some extent so does RISC-V. Some RISC-V ISA extensions are still under development, but getting getting stable. Also the RISC-V is in comparison to MIPS a cleaner ISA. No delay slots for example.
- floatboth 8y agoAre there delay slots in modern / 64-bit MIPS? I've heard they're only really present in very old MIPS
- deleted 8y ago[deleted]
- JoachimS 8y agoGood question. I took a look. What is being released is the Release 6 ISA. And I stand corrected, according to wikipedia that ISA doesn't have delay slots: MIPS32/MIPS64 Release 6 in 2014 added[22] the following: a new family of branches with no delay slot: unconditional branches (BC) and branch-and-link (BALC) with a 26-bit offset, conditional branch on zero/non-zero with a 21-bit offset, full set of signed and unsigned conditional branches compare between two registers (e.g. BGTUC) or a register against zero (e.g. BGTZC), full set of branch-and-link which compare a register against zero (e.g. BGTZALC). index jump instructions with no delay slot designed to support large absolute addresses. instructions to load 16-bit immediates at bit position 16, 32 or 48, allowing to easily generate large constants. PC-relative load instructions, as well as address generation with large (PC-relative) offsets. bit-reversal and byte-alignment instructions (previously only available with the DSP extension). multiply and divide instructions redefined so that they use a single register for their result). instructions generating truth values now generate all zeroes or all ones instead of just clearing/setting the 0-bit, instructions using a truth value now only interpret all-zeroes as false instead of just looking at the 0-bit. Removed infrequently used instructions: some conditional moves branch likely instructions (deprecated in previous releases). integer overflow trapping instructions with 16-bit immediate integer accumulator instructions (together HI/LO registers, moved to the DSP Application-Specific Extension) unaligned load instructions (LWL and LWR), (requiring that most ordinary loads and stores support misaligned access, possibly via trapping and with the addition of a new instruction (BALIGN)) Reorganized the instruction encoding, freeing space for future expansions. https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS64_Release_6 https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS6...
- 8y ago
- jononor 8y agoToo little too late probably. But openness and competition is good!
- nickik 8y agoI don't think it will. This is clearly a totally reactionary move of a company that has been absolutely trounced in the commercial market by ARM and saw the writing on the wall that once RISC-V established itself the few gaps they lived in would be eventually replaced. This, 'throw it over the wall' style open sourcing has worked before, Docker being an example. The problem is their current 'open' strategy is probably not open and dynamic enough to compete with RISC-V. And the consumers that don't care still don't have much reason to use it over ARM. Maybe they can find a gap but I don't think they have a long term growth curve.
- iainmerrick 8y agoI think Betteridge’s Law probably applies here: “Any headline that ends in a question mark can be answered by the word no.”
- growlist 8y agoI'd really like to some new OS efforts to go along with new chips. Does it really have to be *nix on everything?
- pjc50 8y agoIf it can't run a browser, adoption is going to be crippled, and porting a browser to a new OS is a much bigger project than writing your own OS.
- saagarjha 8y agoOr, in general, getting code to run on it at all. Almost every OS that hasn’t offered C (and arguably some sort of POSIX) has floundered without gaining traction.
- ken 8y agoAlmost every OS that has offered C and POSIX has floundered without getting traction, too. The number of operating systems that have succeeded in any real way is tiny, and probably not big enough to draw any conclusions from. None of the major players today got to where they are now by following the conventional wisdom of their day. I assume the next big OS (or three) will similarly succeed by breaking all the rules we thought we knew.
- mcbain 8y agoThese chips aren’t going to be running browsers in the near future, unless you mean in a TV (one of the last places you could find MIPS). The market they are headed for is embedded, where every cent of the BOM counts. Licensing costs can add up surprisingly fast as part of that. Server parts are a big step above that - MIPS used to play there, but after a short peak they failed many times over. It tried in the networking and embedded space for a while, but then had its lunch stolen by all the cheap ARM vendors from below, and stomped on by x86 from above. And then desktop/laptop parts? Unless you are Apple (and even then), pushing a new arch on the desktop is a massive, expensive task, and I can’t see it being worthwhile.
- baybal2 8y ago> Can MIPS Leapfrog RISC-V? Not if the company will continue being run by the legal department. From industry insiders, I heard people having exchanges with them like "you are gonna fail, thus we are not gonna be working with you..." https://news.ycombinator.com/item?id=18701898 https://news.ycombinator.com/item?id=18701898
- mtgx 8y agoThe general rule to this type of question titles is that the answer is NO, right?
- muyuu 8y agousually it goes like "technically yes but in practice no"
- JoachimS 8y agoHere is some more info about the MIPS Open community MIPS is trying to establish: https://www.mips.com/mipsopen/ https://www.mips.com/mipsopen/ Based on the FAQ, older MIPS architectures, for example Release 5 is not included, only Release 6. I don't see any info about what the exact license they plan to use.
- fit2rule 8y agoGive me a big fat MIPS pizza box for the 21st Century, and I'm in. Give me a pocketable mobile MIPS device, and I'm in as well. As long as they both work together as platforms.
- twic 8y agoHow much does open-source hardware really matter? It sounds really cool, and i hope it takes off. But is this really where the industry is going, or is this a flash in the pan that gets a lot of attention from people like us?
- lallysingh 8y agoQuite a bit! Look at all the places Linux ended up. Servers, phones, embedded systems, etc. The freedom to modify and tinker encourages innovation. The cost encourages cheap experimentation.
- dragontamer 8y agoThe difference is that most of us don't own million-dollar fabrication labs. At best, we would be tinkering with FPGAs with custom cores, but FPGAs are an order-of-magnitude slower than traditional CPU ASICs. So we the typical user can't make use of open source designs. ------ An open source "conglomerate" of companies may work. But I haven't fully thought about the economics of it.
- bryanlarsen 8y agoLinux is funded by billion dollar companies (https://www.linuxfoundation.org/membership/members/ https://www.linuxfoundation.org/membership/members/), and it is put into phones & cloud servers by billion dollar companies.
- dragontamer 8y agoHow many of those billion dollar companies own a fab? Realistically, only Samsung, Intel, and TSMC can make next-generation chips. (Global Foundries just quit the 7nm race. They're going to be stuck at 12nm). Intel is fully proprietary tech, so that leaves Samsung and TSMC as the only companies that make chips for other companies. At the end of the day, an open-source chip isn't really much benefit when there are only two manufacturers of chips.
- tntn 8y agoGenuine question related to riscv: what is the value of a standard when a majority of it is part of optional extensions? Doesn't that make riscv a ton of distinct standards, marketed as one? RV32I is nothing close to RV64IMAFDQCPBS. It seems like all the fragmentation standards are made to avoid packaged up as a "standard" to make sure everything under the sun can use risc-v. (see also usb-c)
- benj111 8y agoThey're designed to cover a lot of different processor types. Servers have different needs to microcontrollers. Nevertheless you would expect code that works on the microcontroller, to scale up and work on the server so there is some value. You probably don't need to same code to run on such differing hardware though. The value is in your code working on 2 processors with optional FPUs. I don't think you're ever going to get to USB levels of plug and play, but you don't really need that. Edit: So yes you might get usb 3/c/whatever levels of confusion, but you don't swap processors multiple times a day so not really a problem.
- TomVDB 8y agoMany of the optional extensions are either trivial to implement (think multiplier/divider) with minimal logic or are almost considered standard by now (e.g. compressed, because code size is critical for embedded CPUs) For now, the vast majority of RV CPUs will go into embedded CPUs, where an extension is a compile switch away. In practice, I think all embedded CPUs will be RV32IMAC. For bigger CPUs, it's pretty simply: almost all them will be RV64GC. ISA fragmentation is nothing new: x86 and ARM don't seem to have a problem with them, and one could easily argue that those are way more fragmented than RV right now.
- snvzz 8y ago>RV32IMAC Or RV32IMAC+some extension that makes sense for the application. There's also a non-defined but planned RV32E for embedded. >RV64GC I suspect this will be the case at first, then a superset will take over. e.g. bitfield operations extension and vector extension are unlikely not to be taken advantage of by e.g. Debian. Likely resulting in a few arch variants with increasingly more such extensions, such as further adding DSP and JIT extensions. It should be a bit messy at first, and calm down later when there's a lot of frozen extensions that handle most popular tasks. If anything, I fear calling the 'G' subset was premature. That we're already talking about RV64GC and not just RV64G does strongly point to that.
- snvzz 8y ago>Swift added, “The 30+ year legacy of MIPS architecture should mean something. It’s a value.” This reads so desperate. "should mean something" betrays they're not even sure themselves.