SoylentNews is people
SoylentNews
Wave Computing Adopts Low Power MIPS 64-bit Multi-Threaded Core
Wave Computing [...] announced today that it has selected a 64-bit Multi-Threaded processor core from MIPS Technologies for future AI solutions. Wave will use the MIPS core in its next generation of Dataflow Processing Unit (DPU) chips that will ship in Wave's future deep learning systems to handle device control functions including management of the real-time operating system (RTOS) and system-on-chip (SoC) subsystem.
As design complexity and software footprints continue to increase, the 64-bit MIPS architecture is being used in an even broader set of datacenter, connected consumer devices, networking products, and emerging AI applications. In addition to Wave, companies including Mobileye, Fungible, ThinCI, and DENSO, among others, are using the MIPS 64-bit processor core as they develop ground-breaking AI applications. [...] Last August, Denso group company NSITEXE, Inc. announced that it licensed the newest MIPS CPU to drive enhanced in-vehicle electronic processing.
Related: MIPS Strikes Back: 64-bit Warrior I6400 Arrives
PEZY's Next Many-Core Chip Will Include a MIPS 64-Bit CPU
ARM Cortex-A35, Snapdragon 820, and New Imagination MIPS Processors
Linux-Based, MIPS-Powered Russian All-in-One PC Launched
Imagination Technologies Acquired for $675 Million, MIPS to be Sold Off
(Score: 3, Interesting) by TheRaven on Thursday March 08 2018, @02:39PM (3 children)
We don't have an ecosystem, so we can't sell anywhere where people have existing software that they expect to work. We don't really understand how to build an ecosystem, so we're not imposing any constraints on customers who want to make incompatible versions of our ISA. This it really attractive to customers that think in the short term and want to benefit from the fact that we kind-of have some half-arsed compiler support and want to ride a wave of hype and sell their company before they have to think about long-term support. MIPS is perfect for these people!
Yes, I am bitter that we chose MIPS as the base ISA for our research processor. Until RISC-V came along, MIPS was the only 64-bit ISA with some vague software support that was old enough to be out of patent. The lack of patents is the main thing that MIPS IV has going for it. MIPSr6 doesn't even have that, nor does it have any existing software.
sudo mod me up
(Score: 4, Informative) by RamiK on Thursday March 08 2018, @05:26PM (1 child)
1. Complete mainlining for RISC-V isn't scheduled to be completed until 4.16/4.17 so it's not so much as short-term as it is time-to-market.
2. Rumor has it Meltdown/Spectre pushed back multiple RISC-V core designs to CAD with generous ETAs scheduled around 3-6month.
3. The MIPS tool-chain is maturely optimized for in-order operations with width flags and the like all in-place and well understood algorithmic choices. RISC-V is going to have multiple in and out-of-order designs of varying width all coming out in a span of a couple of years... Even if ARM's and MIPS's work on the device tree sorted the kernel out (give or take), you're going to have some serious delays in the compilers and libraries as conflicting branches get merged and libraries adjusted. Depending on the project it could spell a lot of grief and time lost.
Mind you, I'm still a strong RISC-V proponent. Just say, there's still a business case for MIPS. Even a research one depending on schedule and focus... No?
compiling...
(Score: 2) by TheRaven on Friday March 09 2018, @10:30AM
We picked MIPS 8 years ago. If RISC-V had been in the state now that it was then, we'd have picked RISC-V. You have two choices with MIPS now: new MIPS (r6) or old MIPS (r2 or earlier). These are different ISAs that are not compatible. ImagTec wibbled a lot about binary translation for old MIPS code to MIPSr6, but never actually shipped a binary translator. If you go MIPSr6 (which were the cores that ImagTec was trying to sell, because those were the ones definitely still in patent) then you lose existing toolchain support.
GCC is a clusterfuck for MIPS, because all of the vendors made their own incompatible extensions and didn't do the compiler work properly (with the exception of Cavium, which has now switched entirely to ARM) and so broke every other MIPS vendor's targets and couldn't upstream things. This means that the state in GCC is pretty bad. Modifying GCC is also just pain. MIPS in LLVM is mediocre. It now works (in part because I've upstreamed a load of fixes), but it generates pretty poor code for a few common patterns and the design of the MIPS ISA makes it difficult to improve. A lot of the ImagTec work was directed at things like MIPS16 / microMIPS, which no one actually cares about, rather than improving performance and correctness.
The entire ecosystem is broken and dying. If you want something that works now, MIPS might be it if you squint, but you're going to be taking on most of the ecosystem maintenance costs yourself because everyone else is migrating their stuff away from MIPS as fast as humanly possible.
Oh, and LLVM's scheduler currently generates much better code for OoO cores, so if you've got an in-order design then it's less than idea. Not sure about GCC, because it's been years since I worked with any companies that cared about it.
sudo mod me up
(Score: 2) by Dr Spin on Thursday March 08 2018, @05:43PM
The lack of patents is the main thing that MIPS IV has going for it.
No it is not HOracle - that is an even bigger plus!
Warning: Opening your mouth may invalidate your brain!
(Score: 3, Interesting) by Snotnose on Thursday March 08 2018, @03:39PM (9 children)
Back around the turn of the century, if a manufacturer wanted to be certified for WinCE they had to pass a Microsoft-written test suite. My job was to get various CPUs to pass this test suite. One of the tests was to ensure the entire 32 bit address space was addressable. MIPs had this hardware quirk where something like 1/4 of their address space was dedicated to I/O. Microsoft had plans in place to get waivers on certain requirements, but I'm guessing I was the first one to try and make use of them. The guy I dealt with clearly didn't want to work with me, thought he was much smarter than me, and flat out didn't want to deal with my emails. Finally got MIPs certified, but man what a pain.
That was a fun job. I got to certify the ARM, MIPS, and SH-4 for WinCE (took 2-3 month each to get the test suite running). Then a few months later I had to actually use WinCE. What a royal pain in the ass that was. WinCE was designed for embedded systems. Embedded systems need hard limits on things like interrupt latency, stack size, etc etc etc. WinCE didn't support any of these. I was trying to play video. It would go great for a minute or so, then start stuttering for no apparent reason. The root cause was WinCE doing it's nails, or whatever. There was no way to avoid it, bigger buffers didn't help because the problem was WinCE's latency issues.
Recent research has shown that 1 out of 3 Trump supporters is as stupid as the other 2.
(Score: 2) by RamiK on Thursday March 08 2018, @05:44PM (8 children)
FYI Last I checked your typical x86-64 can't address more than 48bit directly or 52bit with PAE.
Just some pointless trivia...
compiling...
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @07:57PM (5 children)
And often underappreciated. Most operating system level code is going to have to be rewritten when that gets expanded out, and given that everything bit 52 and above is used means that there might be userspace code out there that actually DOES either poll or filter those bits, meaning old code may need some major rewrites to work with full 64 bit addressing. Honestly I dislike the fact that they call them 64 bit processors without more clearly defining if they mean 64 bit addressing, or simply 64 bit integer processing.
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @08:02PM (2 children)
Operating systems are ready for full 64-bits since the beginning of amd64 support. There is no reason to implement any type of filtering in "userspace code" since it never does see the underlying physical address (every process has its own virtual address space). I'd suggest you look into how an operating system works in terms of memory management, it might be useful...
(Score: 2) by TheRaven on Friday March 09 2018, @10:34AM (1 child)
sudo mod me up
(Score: 2) by FatPhil on Friday March 09 2018, @02:09PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by shortscreen on Friday March 09 2018, @06:57AM (1 child)
The CPU insists that those unused bits remain zero (rather than just ignoring them like a 68000), so people wouldn't be tempted to put random garbage in there that would only cause problems in the future.
(Score: 2) by TheRaven on Friday March 09 2018, @10:43AM
sudo mod me up
(Score: 0) by Anonymous Coward on Thursday March 08 2018, @07:59PM (1 child)
Pointless and incorrect. There is no PAE for amd64. You're thinking of virtual and physical address spaces. Neither is truly 64-bit wide in any current implementation.
(Score: 0) by Anonymous Coward on Friday March 09 2018, @07:43PM
( Intel® 64 and IA-32 Architectures Software Developer’s Manual [intel.com] Ch. 4.5 IA-32E PAGING )
The tables and diagrams explain what "direct" means here.
(Score: 2) by Subsentient on Friday March 09 2018, @11:04AM
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti