Slashdot Mirror


Imagination Tech Announces MIPS-based 'Warrior P-Class' CPU Core

MojoKid writes "Imagination Technologies has announced the first CPU based on its new version of the MIPS architecture. The new P5600 chip (codenamed Warrior) is a 32-bit CPU based on the MIPS Series 5 architecture and is designed to challenge companies like ARM in the embedded and mobile markets. Major features of the new chip include: support for 40-bit memory extensions, or up to 1TB of RAM, a 128-bit SIMD engine (Single Instruction, Multiple Data), and Hardware virtualization (MIPS R5 can virtualize other machines in hardware). The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400. According to IT, the chip is capable of executing 3.5 DMIPs/MHz in CoreMark, which theoretically puts the P5600 on par with the Cortex-A15."

122 comments

  1. 32 bit? by Jeremy+Erwin · · Score: 1

    That's a bit dated, isn't it?

    1. Re:32 bit? by jockm · · Score: 4, Insightful

      It depends what you are doing. I don't think anyone is making servers or desktops out of this, and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead. That being said MIPS64 has been around for quite a while, so I don't think it will be a problem to adapt to it at some point in the future.

      --

      What do you know I wrote a novel
    2. Re:32 bit? by jockm · · Score: 1

      From TFA:

      This new core is the first of a family, with later 64-bit chips to follow. The 64-bit warrior chips, when they do launch, will be fully backwards compatible with 32-bit software, much like the 64-bit implementations of ARM and Intel/AMD.

      --

      What do you know I wrote a novel
    3. Re:32 bit? by Anonymous Coward · · Score: 1

      Not really, especially on embedded.

    4. Re:32 bit? by Anonymous Coward · · Score: 0

      Can this run Linux distros?

    5. Re:32 bit? by viperidaenz · · Score: 1

      My router has a MIPS CPU, it runs linux fine. Most consumer routers have a MIPS CPU from Broadcom in them.

    6. Re:32 bit? by viperidaenz · · Score: 1

      Imagination Tech are the ones who make PowerVR GPU's. It also has two double precision FPU pipelines, if you bothered to look at the pretty picture in TFA.

    7. Re:32 bit? by green+is+the+enemy · · Score: 1

      Can anyone enlighten us why MIPS has been much less visible than ARM? Their business model and CPU architectures are similar nowadays. Why are people seriously trying to build servers based on the brand new and untested ARMv8 architecture, while ignoring MIPS64 (in existence since 1999)? Is is all about ARM being cheaper and the network effect?

    8. Re:32 bit? by GodWasAnAlien · · Score: 1

      If MIPS would sell a cubieboard sized SBC, as open as Beagle, Panda or Cubie (more open than the raspberry pi), sign me up.

    9. Re:32 bit? by fuzzyfuzzyfungus · · Score: 1

      That's a bit dated, isn't it?

      If the cores themselves are merely 'competitive' with A15s, probably not. I'm sure that there is some special application out there that needs minimal CPU power and 64TB of RAM; but if the things do 32 bit address spaces with 40-bit PAE(or whatever the equivalent acronym is for MIPS), that covers your just-under-4-usable-Gigabytes SoC configuration, and would also cover fairly large interconnected systems, for applications that have lots of lightweight processes (which would be the only thing you'd use a swarm of these things for, given the limited per-core performance).

    10. Re:32 bit? by Misagon · · Score: 1

      The "64-bit" Intel and ARM have more to do with new instruction set architectures than the size of a processor word or the address space.
      The new instruction sets are more capable than the ones before, not just in the larger size of pointers and words but also in other ways, such as in the number of registers. For instance, ARM's "64-bit" ISA has 32 integer registers instead of 16.

      MIPS32 is already a very capable instruction set, with 32 integer registers from the start. The 64-bit MIPS instructions is just an extension, not a replacement as on ARM and Intel.

      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
    11. Re:32 bit? by Anonymous Coward · · Score: 1

      MIPS started out as a workstation and server killer micro (I worked with them in the early 90s), ARM started out more modestly as being cheap, quite fast and small (a 6502 replacement for the Archimedes). Then Apple threw some money at it to make a low power CPU for the Newton. It's in the history.

    12. Re:32 bit? by Anonymous Coward · · Score: 2, Informative

      Go to ARM.com, try and download the ARM ISA, fail, sign NDA, get ISA.

      Go to MIPS.com, download MIPS64 ISA, done.

      Tell me again how ARM is more open than MIPS?

    13. Re:32 bit? by Anonymous Coward · · Score: 0

      MIPS64 is an "just" extension because their 32-bit architecture isn't fucked up like ARM32 and x86. ARM64 is actually VERY similar to MIPS64 (I suspect that a major reason for ARM purchasing a bunch of MIPS patents is precisely because their buyer (imagination) has the money to enforce any related patents in court).

      That said, warrior is an incremental update to PRO-APTIV. While it's DMIPS score is similar to A15, it's coremark score is the highest of ANY tested processor (coremark/MHz) and coremark is believed to be much more representative of normal computing.

      Broadcomm bought lifetime licenses to the entire MIPS patent portfolio a year or so ago. I'm looking forward to what they intend to to with them. Broadcomm already uses MIPS in 8-core 4xSMT MIPS64 monsters for their router hardware. I imagine derivatives could compete with x86, POWER, SPARC, etc in the server and HPC markets.

    14. Re:32 bit? by Bill,+Shooter+of+Bul · · Score: 1

      Whoops, moderated troll wrong way. My apologies.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    15. Re:32 bit? by fuzzyfuzzyfungus · · Score: 3, Insightful

      In either case, the main stumbling block to 'openness' (from the perspective of people who don't have the cash to implement a core and get it fabbed, or even buy a run of a pre-cooked design, and don't want to enjoy the pleasures and efficiencies of implementing their CPU in an FPGA) isn't really the CPU ISA; but the fact that the SoCs you can actually buy tend to be coupled with GPUs that make Nvidia look like a model of transparency and AMD a model of driver-writing competence.

      If memory serves, the rPi's SoC depends on a fairly massive binary blob driver and a 'VideoCore 4' GPU thing that is right up to Broadcom's usual standards for openness in documentation, which is presumably what the grandparent poster doesn't like.

      Most of the punchier ARM options aren't a whole lot better (though some of them are somewhat less weird). Certainly, given that Imagination Technologies is already a supplier of GPU architectures to ARM licencees (and occasionally Intel), I'd assume that any MIPS SoCs you end up being able to buy will be approximately as bad as the ARM scene, maybe a bit worse.

      Now, if you do want to bake your own CPU, MIPS64 is probably a better option (though don't they still have a few patented instructions? I vaguely remember some flap concerning the legal status of that Chinese MIPS-and-national-pride CPU a few years back...)

    16. Re:32 bit? by fuzzyfuzzyfungus · · Score: 1

      Newer Broadcom (802.11ac router SoCs, possibly some of their late 802.11n stuff) are going ARM as well. I don't know what the reasons are. For about a zillion routers in the field, though, including the venerable WRT-54G which made 'it runs linux fine' into a particularly useful feature, it's still MIPS at present.

    17. Re:32 bit? by ChunderDownunder · · Score: 1

      32-bit is the norm on phones and tablets. This company is best known for their mobile GPU found in such products - PowerVR.

    18. Re:32 bit? by Anonymous Coward · · Score: 1

      If I'm baking my own cpu, licensing a core is the least of my worries. Unless it's in an FPGA, it makes no difference to me whether the SoC I'm using has a free core or a licensed core in it, as long as the ISA is public, since in both cases I can't go in and change it (alas, I don't have FIB deposition/erosion tools at my disposal). It's just a piece of silicon that either works right, or I'm SOL.

      You're right about the GPUs, pretty much every ARM SoC GPU is Ninja Destruction Agreemented beyond all hell. The new Intel Atom SoCs have Intel GPUs and are as completely documented as their desktop parts, unfortunately, while they have much better performance/watt than ARM SoCs, they don't have anything that scales down to sub-watt profiles. Vortex86DX by DMP is a nice hybrid 486/Pentium chip, that does fit that profile, and has very good integrated facilities for robotics (no GPU): ADCs, PWM, 4 UARTs. Unfortunately they are expensive parts, at least as far as the devkits go ($300USD).

      The not-so-obvious reason that the GPUs are so ninja-secret is that the secret sauce is all in the compilers*, and not the rather simple VLIW architectures of the GPUs themselves. If they were to document the GPUs ISA to an extent that you could make use of them, they would be giving away details of how their compilers worked, something they very much don't want to do.

      What I would like to see, is a PC or ARM/MIPS/whatever Linux, system on DIP, where the SoC chip and companion parts (VREG, flash, level shifters, ethernet PHY) are all embedded on a PCB with DIP legs, so I can use it in place of an AT90/ATMEGA in projects, as breadboarding SMT parts is not so easy, and breadboarding highspeed BGA parts is practically impossible. Especially cool would be an 8086/80386 part with 4MB RAM and 128~1G of flash that I could program in {Free,PC-,MS-}DOS (and could PXE-boot or SMI trap console over ethernet). Also cool would be an alternative ethernet standard for low-speed embedded networks, something I call uEthernet, using LVDS or CML and where magnetics are not required, there are literally hundreds of projects I have thought up which I want ethernet but magnetics make it price-infeasible.

      * In the case of GPUs, the compiler is contained in the OpenGL(es)/VG implementation, and is a runtime compiler that translates your drawlists into GPU programs.

    19. Re:32 bit? by hedley · · Score: 1

      I think it stems from the initial directions each co took.

      MIPS started from a 32bit Stanford grad project (MIPS-X) spun out to become the R2000 workstation class CPU. No hint of embedded arch at all at that time.
      They steamed on finally hitting 64bit archs relatively quickly. Once they got to the R4K32 series and upon adding MIPS-16, they had a small footprint embedded soln but...

      ARM started from basically a hobbyist computer, already with some small footprint pedigree built in. Very quickly Thumb was adopted, arch just as a translator initially but subsequently with on chip native decode. Now they have a 64bit arch, but because of their small footprint roots and aggressive licensing, they
      really caught the lions share of sockets. They can now come to capture a 64bit space that was MIPS's to own years ago by osmosis of the socket market.

      ARM had a first mover advantage in embedded and they executed well and did not allow competition to unseat them. It could have been different, they could have mucked up a design and lost share, but that did not happen.

      Both companies have first rate tool chains also (that can be a deal killer). Thus its a wash for softies when HW pitches a design, if the license is favorable, and the die area+power draw meets managements expectations, then that vendor will get the nod for new IP. ARM has been fortunate in that there is also a bit of industry simpatico wrt ARM adoption... others are using it, so why not us?

      H.

    20. Re:32 bit? by Anonymous Coward · · Score: 0

      Can anyone enlighten us why MIPS has been much less visible than ARM? Their business model and CPU architectures are similar nowadays. Why are people seriously trying to build servers based on the brand new and untested ARMv8 architecture, while ignoring MIPS64 (in existence since 1999)? Is is all about ARM being cheaper and the network effect?

      At least in part, it is Microsoft's fault. Back around the turn of the century there were many PDA's running Windows CE on a variety of RISC CPU's including ARM, MIPS (32 and 64 bit chipsets), Hitachi, and maybe even Motorola 68000 (although that may have only been Palm). Intel developed the Strong ARM and next thing you know, Microsoft stopped supporting all the other architectures. Although Windows CE later faded and became a phone OS which was popular at one time, this was really the last you heard of MIPS in the portable consumer electronics market.
      This was well after the Newton had come and gone.

    21. Re:32 bit? by tlhIngan · · Score: 2

      and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead.

      The main reason Apple with with ARMv8 (the big difference between ARMv7 and ARMv8 is basically 64-bit) is that the 64-bit architecture (AArch64) is way more efficient than 32-bit (AArch32). It's a lot easier to speed up the 64-bit system as it gets rid of a lot of legacy AArch32 features that get in the way of a modern superscalar design CPU.

      Surprisingly, things like conditional execution, great back in the 80s, are painful these days with heavy pipelining, register renames, speculative sxecution and superscalar multi-issue back ends. Think about it - the only way to find out if you need to retire the instruction to the architecture registers is at the end when you find out if the instruction should've been executed.

      And AArch64 has few other improvements to make it scale better in the future.

      Apple went 64-bit not because they planned on putting 4GB of RAM in an iPhone, but because they needed the speed. That's why everything's 64-bit - you're able to take advantage of the speed up and efficiencies AArch64 has.

      ARMv8 processors running 32-bit code aren't much faster than their ARMv7 counterparts. But the 64-bit code runs significantly faster.

    22. Re:32 bit? by unixisc · · Score: 1

      Although Linux theoretically supports the most architectures, most distributions have either not embraced RISC CPUs, or down & out dropped support for them altogether. A fine example being Red Hat, which had dropped SPARC support a while ago.

    23. Re:32 bit? by unixisc · · Score: 1

      In that case, why 32-bit first, when the market is already @ 64? They can start w/ something like an R4600, and just release 32-bit versions of that chip whenever it's needed. It's easier to chop then to scale up.

    24. Re:32 bit? by Bert64 · · Score: 1

      64bit MIPS has been around a lot longer than 1999, SGI were using them in the early 90s...
      Availability of current designs to play with however is a problem, i tried very hard to buy one of the loongson mips designs from china and i just couldn't get one anywhere.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    25. Re:32 bit? by Anonymous Coward · · Score: 0

      since when does an rpi have a MIPS CPU?

    26. Re:32 bit? by hattig · · Score: 1

      ARM got the mobile phone market early on - very early on (late 90s) - presumably due to a very hard working sales team and an established pedigree in mobile designs (Apple Newton, for example), as well as proven low power (MIPS wasn't there then, Hitachi was with SH3/4 which was used in early Windows CE fliptops). They also had Java support (hardware assistance) which was very big on the client at the time.

      ARM clearly has very good engineers who work with their customers - this means a lot when you're licensing cores to integrate, not buying ready made chips. And they went for the cheap licensing and hope for bulk option. I'm sure early MP3 players using it helped too.

      And clearly since then they took the ball and ran with it, by delivering updates on time meeting what their customers need.

      MIPS has languished for a long time, it's like the company didn't care to target what was to become a massive market - and by the time they did it was too late. They probably didn't see it coming, kept on selling into the embedded market, and have kicked themselves ever since. Until Imagination bought them that is - Imagination's established sales team (from GPU sales) will be able to get this core (which will be Android compatible) into SoCs - maybe not many initially.

      It's nice to see a decent CPU architecture possibly re-emerging.

    27. Re:32 bit? by hattig · · Score: 1

      This would be a very good idea for Imagination to work towards - a "Raspberry MIPS" based around this MIPS core, a low-end current-gen Imagination GPU, and some other standard features. Get it out into the market at a cheap price, support it (the ecosystem is as important as getting it out there in the first place) and you could get a lot of people using their hardware, testing software by using it, etc.

    28. Re:32 bit? by Goaway · · Score: 1

      The market is still very much at 32 bit. You are just confused about what "the market" is. It is not desktop PCs or servers.

    29. Re:32 bit? by fatphil · · Score: 1

      Get your Loonsong MIPS from Lemote:
      http://www.lemote.com/en/products/mini-computer/2010/0310/111.html

      --
      Also FatPhil on SoylentNews, id 863
    30. Re:32 bit? by Exophase · · Score: 1

      You don't need an NDA to download the ARM architectural specifications, you just need to register on their site. Which you need to do for MIPS as well.

    31. Re:32 bit? by drinkypoo · · Score: 1

      One of the punchiest ARM options is the quad-core RK3188. It has the least punchy GPU in the class, a clock-increased (by 25%) Mali400. However, this is the ARM-coupled GPU with the most functional OSS driver. It is already possible to boot Linux on RK3188 directly, and play Quake3, with an OSS driver. OHI, there is now an installer. However, it does not appear that the installer includes recovery. Hmm, reading further, it does not include the accelerated video driver or working bluetooth either, so I guess I'll stick with Finless for now on my MK908. I want to run Linux for a variety of reasons, not least PS3 BD Remote support.

      With that said, if the MIPS tools are better, I'd still rather have MIPS for a Linux box. It's not that interesting for Android though, since the majority of the Android world is on ARM.

      Also, it's possibly notable that nVidia has stated repeatedly that Tegra's GPU isn't encumbered by agreements with other corporations as their desktop GPUs are, and that they will continue to release increased amounts of driver source code for that platform. I'm not holding my breath, of course.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    32. Re:32 bit? by unixisc · · Score: 1

      I wasn't thinking about desktops or servers. If the competition is ARM, it's pretty obvious that the market in question is tablets & phones. But even there, 32-bit ain't gonna cut it any more: memory sizes can easily exceed 4GB, and in those sort of designs, you don't want to go w/ PAE. Given all that, Imagination Technologies is doing fine w/ MIPS, but IMO making a wrong move going 32-bit.

    33. Re:32 bit? by kriston · · Score: 1

      From TFA:

      "Support for 40-bit memory extensions, or up to 1TB of RAM rather than the typical 4GB limit associated with 32-bit processors. It's worth noting that there's typically a significant performance hit associated with this kind of work-around for memory addressing in 32-bit chips."

      --

      Kriston

    34. Re:32 bit? by Anonymous Coward · · Score: 0

      With that said, if the MIPS tools are better, I'd still rather have MIPS for a Linux box. It's not that interesting for Android though, since the majority of the Android world is on ARM.

      While a major majority of Android devices are ARM based, there has been support in place for running Android on other architectures for several years. If you get the Android NDK, you'll find Android api level 9 includes support for MIPS and x86. Now I'm wondering how soon we'll see the 64-bit architecture variants of those processor appearing. From what I've read, ARM64 offers a substantial performance improvement because the architecture got rid of things that hurt performance in the modern era.

    35. Re:32 bit? by unixisc · · Score: 1

      Precisely, and hence my original question - why not simply go 64-bit, instead of eating this performance hit?

    36. Re:32 bit? by unixisc · · Score: 1

      Don't Android applications, being Dalvik based, get distributed in Bytecode? In which case, it should make little difference what the bottom CPU is if there is a Dalvik VM underneath that converts .class bytecode to .dex, which would be specific to the CPU in question.

    37. Re:32 bit? by drinkypoo · · Score: 1

      Yes, but if the NDK is used often they don't bother to include MIPS support. That's more work and it applies to vanishingly few users.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    38. Re:32 bit? by Bert64 · · Score: 1

      That's a loongson 2F, ie an old model.. I wanted the loongson 3 or more specifically i was looking at this:
      http://www.loongson.cn/product_info.php?id=36

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    39. Re:32 bit? by Goaway · · Score: 1

      There's like a single 64-bit ARM processor in existence yet. The market is still pretty much entirely 32-bit, and it will be a long time before most of it moves to 64 bit. Sure, in some years it will be different. But not now.

  2. In before the haters by Rinikusu · · Score: 2, Insightful

    COMPETITION IS GOOD.

    I'd love to see MIPS make a comeback. I've been looking for one of the looongson (?) netbooks for awhile now, just so I can have a MIPS Linux box to play with, but those seem hard to come by.

    --
    If you were me, you'd be good lookin'. - six string samurai
    1. Re:In before the haters by Anonymous Coward · · Score: 0

      I love you looongson

    2. Re:In before the haters by ozmanjusri · · Score: 1

      Ingenic make a few interesting MIPS devices - the iPPea TV http://www.ippea.com/ is a $50 Android thumb drive computer that can be modded to run Debian chroot. They also supplied the SoCs for the Ainol Novo 7 MIPS tablets.

      --
      "I've got more toys than Teruhisa Kitahara."
    3. Re:In before the haters by aaronb1138 · · Score: 1

      Competition is not necessarily good when ImgTech is involved. They have a pretty nasty reputation of not providing drivers that work outside of very narrowly defined Linux or Windows builds (not versions, builds, their drivers will break if they find themselves outside the "licensed" environment) they are directly involved with. They've colluded pretty nicely with Apple to have iOS devices having magical GPU performance superiority on their own, identical hardware, again, because they do not license driver source even to top tier partners like Samsung and Intel. There is of course the cautionary tale of the GMA 500 / 600 devices where an Intel employee compiled OpenGL compliant Windows drivers from a source tree he found internally and then was silenced and told the drivers would never see the light of day.

      ImgTech is the horror of paranoia and IP defensiveness you would expect from a company that spent over 5 years essentially out of business and bankrupt. They're a little like the pigs in Hannibal. Disappointing too, because they had innovative tech in the 90's (infinite planes & tile rendering) and they have really nice hardware now, but they simply aren't trustworthy.

      You will certainly NOT have a Linux / MIPS box where ImgTech is involved.

    4. Re:In before the haters by Anonymous Coward · · Score: 0

      I'd love to see a SPARC in this market, after all you don't even have to pay any license fees for it

    5. Re:In before the haters by MachineShedFred · · Score: 1

      I'm more interested in the competition that is represented by Intel's "Bay Trail" Atom. That thing might actually win some phone / tablet designs, and not just be relegated to Thin Clients and vastly underpowered also-ran Netbooks.

      If Chipzilla can finally bring something to market that makes the ARM crowd stand up and take notice, that will have much more effect than someone pulling MIPS out of the dustbin of architecture history.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    6. Re:In before the haters by fatphil · · Score: 1

      > They have a pretty nasty reputation of not providing drivers that work [...]

      You could simply have ended that sentence there. They're bodgers, full stop. When they deliver you the next version of the driver, it's in the form of a patchbomb which intersperses functional changes with cosmetic changes, so it's hard to see what's actually changed. I once even wrote a whitespace-changes remover *specifically* for IMG's patchbombs.

      And let's not even start on the fact that their drivers were clearly written for MS Windows, and were then very very clumsily ported to Linux, so they do plenty of things in an inappropriate way.

      --
      Also FatPhil on SoylentNews, id 863
    7. Re:In before the haters by unixisc · · Score: 1

      Yeah, it's the only liberated netbook out there, according to RMS. I doubt it'll run Windows, so if you take one of those, load it up w/ gNewSense and run emacs on it, you'll have good company

    8. Re:In before the haters by unixisc · · Score: 1

      Are there any SPARC V8 or V9 implementations that are as low powered as some of the ARM, Atom & MIPS CPUs in that field? Also, who are the major SPARC manufacturers left?

    9. Re:In before the haters by aaronb1138 · · Score: 1

      Their Windows drivers are nearly as bad as the Linux ones. One of the interesting anecdotes in the tablet PC community is the inability to Frankenstein a driver package with any combination of OpenGL, DirectX, Flash, and x264 acceleration. You only get to pick the former 2 or latter 2 at a given time based on driver version (or one or none in later drivers). The only PVR drivers with any merit are on OSX / iOS in the iShinys where magical OpenGL + x264 support exists (which would be more than enough for Linux OR Windows). Some tablet devices with PVR integrated GPUs have dedicated Broadcom x264 decoders because ImgTec will not license the x264 hardware decoding to Intel on the Atom platform despite the fact that the hardware supports decode and encoding of the streams (Intel has trade show video of dozens of x264 streams being decoded real time and hardware accelerated on an Atom, but consumer drivers won't even decode a single one without dropped frames and out of sync sound).

    10. Re:In before the haters by Anonymous Coward · · Score: 0

      Do you actually have any idea what you're talking about ?

      Do you think Imagination is able to license out x264 ?

      Intel drivers failed because INTEL failed to do what was needed.

      Maybe check out what IP licensing means for IP licensing companies before embarassing yourself.

  3. What's the power consumption? by Anonymous Coward · · Score: 0

    It all sounds great, but if consumes more power than similar performance ARM SoCs then what's the point?

    1. Re:What's the power consumption? by sribe · · Score: 1

      It all sounds great, but if consumes more power than similar performance ARM SoCs then what's the point?

      Ahem, unless it consumes significantly less power than similar performance ARM, or offers significantly more performance for the same power as ARM, then what's the point?

      ;-)

  4. floating point performance? by godrik · · Score: 1

    That is a bit strange to count Integer operations. Most of the computations one do nowadays are mostly floating point. Also,there is no mention of memory bandiwdth and cache size. Though I'll stay tuned.

    1. Re:floating point performance? by viperidaenz · · Score: 1

      It has two Int/SP/DP floating point pipe lines in the SIMD unit

    2. Re:floating point performance? by godrik · · Score: 1

      That means little. can it do vectout = cosine(vectin);? In how many cycle? can it do multiply-add in a single instruction and in a single cycle? Can it do that in EACH pipe?

    3. Re:floating point performance? by Anonymous Coward · · Score: 1

      True floating point (float, double) performance does not really matter, except, sometimes, for games.
      There are also some special applications, like video decode, which rely on SIMD... or the GPU.
      For ordinary software, both in embedded (a car, an usb key, a digital camera, whatever) or in smartphones/tablets/computers, integer and memory are what makes the difference.

    4. Re:floating point performance? by RamiKro · · Score: 1

      There's a GPU core you know... Besides, it's not the CPU core but the memory bandwidth that matters.

    5. Re:floating point performance? by godrik · · Score: 1

      TFA does not mention any GPU core. Did I miss something?

      People often say that the core does not matter, the memory bandwidth does. That is only true for applications doing "bookkeeping"

      The application defines how much "computation per byte" it does and you want an architecture that can play well with a wide range of "computation per byte". When the kernels are a little bit complicated, getting the right data to the core can take many instructions (so many cycles even if the data fits in L1 cache), so you want the "computation" part of the kernel to use as little instructions as possible. That way the "inner loops" of your kernel can saturate the memory controller.

      If your "inner loop" takes too many instruction, you won't be able to saturate the memory controller. Then all the bandwidth in the world will not help you.

    6. Re:floating point performance? by viperidaenz · · Score: 1

      When ARM released the Cortex A15, there was no mention of a GPU. It's up to the SoC designer to integrate one.
      Imagination Technologies already have their own GPU that is up there with the rest of them, the PowerVR series.

    7. Re:floating point performance? by RamiKro · · Score: 1

      When ARM released the Cortex A15, there was no mention of a GPU. It's up to the SoC designer to integrate one.
      Imagination Technologies already have their own GPU that is up there with the rest of them, the PowerVR series.

      The only thing that matters is that there's going to be a GPU core to take care of those operations so you won't be missing them.

      And, in ARM's case, there was the reference Mali GPU core...

    8. Re:floating point performance? by RamiKro · · Score: 1

      Going down that road, you can discredit all RISC instructions sets on account of their lower code density.

      As for the "only true for applications doing "bookkeeping"", since MIPS is already used in embedded so it's not an issue there, what exactly are you doing aside from bookeeping on a mobile SoC that won't be moved into the GPU core?

  5. MIPS never went away, but why? by Anonymous Coward · · Score: 4, Interesting

    You can still find plenty of MIPS based embedded cpus but they're getting more and more obscure.

    One of my very favorite things about the "smartphone revolution" is the proliferation of cheap ARM based SoCs. For a couple of bucks you can get a complete system in a package that runs on a couple of watts and runs circles around a high end workstation from a decade ago. (It's hard to belive 2003 was a decade ago.) And these aren't crippled micros. They're complete systems that run a real full fat operating system. Just look at the raspberry pi. Memory management On package DDR memory. Frame buffer with openGL aclleration and hardware video decoding. Amazing stuff.

    Point is, arm is everywher, easy, and cheap. What's the benefit of going MIPS? (Or SH3, or PPC..)

    1. Re:MIPS never went away, but why? by Anonymous Coward · · Score: 0

      I've not seen these SoCs you speak of.

      My workstation in 2003 had an Athlon XP 2400+ and a Geforce 4 Ti. Slow by today's workstation standards, but there is still no SoC that comes close in performance to it, except perhaps the newest Intel Atom SoCs.

    2. Re:MIPS never went away, but why? by Anonymous Coward · · Score: 0

      What's the benefit of going MIPS? (Or SH3, or PPC..)

      Avoiding monoculture?

    3. Re:MIPS never went away, but why? by Matt_Bennett · · Score: 1

      Obscure? You can buy a MIPS based embedded CPU right now from Digikey for $2.50 ea in single qty- the PIC32MX110 - it is M4K core based.

    4. Re:MIPS never went away, but why? by fuzzyfuzzyfungus · · Score: 1

      And, while it would have been a good price/performance buy, that 2003-era workstation was hardly 'high end'. Dual socket was sufficiently painfully expensive that multicore CPUs were a fine development indeed; but if you wanted 'high end', a couple of Xeons or Athlon MPs could be making a dreadful howling noise under your desk in 2003.

    5. Re:MIPS never went away, but why? by Anonymous Coward · · Score: 0

      Well, I was saying what I actually had in 2003, not making up some strawman of some hypothetical topend workstation that was available in 2003.

      I can't remember what the memory speed was, but the big difference between a 2003 workstation and a 2013 SoC, in performance is the memory bus width, 128-bit vs. 16 and sometimes 8 bit (maybe there are some 32-bit external bus SoCs). Even a SoC with DDR2-800/8bit is going to be slow compared to an 2003 AMD chip with 128bit DDR266, and perhaps DDR400 and DDR533 was available back then, I can't recall.

      I suspect this will all change when the 4 corners and 72 hours of the Hybrid Memory Cubes come along and they stack one of those on/beside a SoC with 16/32/64/128 10/20/28GT/s lanes as TSV or SI wires between the SoC and RAM. Look forward to a one-time better than Moore's Law improvement in performance and energy efficiency.

    6. Re:MIPS never went away, but why? by fuzzyfuzzyfungus · · Score: 1

      Oh, certainly. As I said, that looked like a very sensible 2003 build (and, aside from now being spoiled by multiple cores and more than 4GB of RAM, probably one that you could use today without active pain). The grandparent post posited a 'high end workstation'.

    7. Re:MIPS never went away, but why? by Anonymous Coward · · Score: 2, Interesting

      It is not the problem of architecture but rather of MIPS company. I have worked on MIPS for many years and still do. MIPS architecture is not worse than ARM in any respect but MIPS company does not promote the architecture and therefore there are no inexpensive boards available. PIC32 is MIPS architecture but without the MMU. I found that when implemented correctly performance of MIPS is on par with ARM per MHz but ARM can clock higher in most common implementations. There is a perception of MIPS being slower or more power hungry. In my experience this is not the case. I also like architecture itself. It is very clean and with modern additions it has all of the tricks that ARM has.
      If MIPS company would promote its chips the same way as ARM does it would be just as popular with the hobby crowd. MIPS is used in many devices - cars, settop boxes, routers, etc. It is just not popular in the DYI community due to absence of cheap hardware.

    8. Re:MIPS never went away, but why? by aiadot · · Score: 1

      Obscure as in not a main feature in the consumer market. MIPS, along side many other embedded architectures, are still present everywhere. The thing is that they're just yet another component and not something developers and engineers are whiling to spend money and time on(hence your couple of bucks PIC). You don't choose a microwave because it has a 64 bit quadcore ARM SoC with 2 GB RAM and and 64 CUDA cores, you choose it because it heats. The cheapest controller that can satisfy the specification is the one that will be used.

    9. Re:MIPS never went away, but why? by Anonymous Coward · · Score: 0

      What's the benefit of going MIPS? (Or SH3, or PPC..)

      License cost. A SPARC for example is free in terms of licensing.

    10. Re:MIPS never went away, but why? by syockit · · Score: 1

      BULLSHIT.

      An Athlon 2400+ has a CPUMark of 357.

      Athlon or Athlon XP? (your mark seems to be from the latter)

      An A7 (iPhone 5S) has a CPUMark of 35274.

      You workstation is slow by any standard. Modern SoCs are much faster than you imagine. Even your Geforce 4 is so abysmal slow compared to modern mobile GPU that you assertion is simply laughable.

      Welcome to reality. Phones annihilate you ancient workstation and blow it in the middle of next week.

      Indeed, this page gives the same results too. It dwarfs even the current state-of-the-art workstation class CPU, Xeon E5-2687W, which could only net 14630 CPUMarks!

      --
      Democracy is for the people; you only vote once per season and we'll do the rest of the work for you don't have to.
    11. Re:MIPS never went away, but why? by xt · · Score: 1

      Hilarity ensues...

      By comparing the results from benchmark software with different code bases for desktop and mobile processors that happen to use the same term (CPUMarks) for results...

    12. Re:MIPS never went away, but why? by AmiMoJo · · Score: 1

      All off Microchip's current PIC32 line is MIPS based, and their reps always push them aggressively when I talk to them. Their theory seems to be that they wanted a 32 bit microcontroller but didn't want to get into direct competition with ARM vendors.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    13. Re:MIPS never went away, but why? by MachineShedFred · · Score: 1

      You aren't kidding about that howling noise - I built a workstation with dual Xeons around then. The CPU fans would eventually start causing harmonic vibrations in the case, and it was annoying enough that I converted the whole thing to liquid cooling just so I could hear something besides steel rattling against steel.

      That thing was the shit for VMware back in the day, though.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    14. Re:MIPS never went away, but why? by Exophase · · Score: 1

      Few decent mobile SoC released in the last several years use an 8-bit or 16-bit memory bus... today most of them use dual 32-bit, ie 64-bit. They're not using DDR2 either, typical is LPDDR2, LPDDR3, or DDR3/3L.

  6. Enemy of your freedom by Anonymous Coward · · Score: 0

    I hate to sound like Richard, but Imagination Technologies has a horrible track record when it comes to even supporting Linux let alone supporting open source. MIPS was better off dead.

  7. Yeah, but... by Anonymous Coward · · Score: 0

    Can it run IRIX?

    1. Re:Yeah, but... by fuzzyfuzzyfungus · · Score: 1

      Can it run IRIX?

      Not only that; but if you try, the bootloader will reward you for your loyalty by spitting "This is a Unix system. I know this" onto the serial debug interface.

    2. Re:Yeah, but... by unixisc · · Score: 1

      I'd like to see Microsoft port Windows RT to it

  8. Based on MIPS Technologies ProAptiv by Anonymous Coward · · Score: 0

    The headline doesn't say, but this chip is based on the MIPS Technologies ProAptiv fully synthesizable core, which has the highest Coremark score/area. Note the Coremark score is not representative of a processors performance as that is largely limited by the attached memory hierarchy, which is not measured by Coremark. In modern CPUs the core uses less than 10% and in some cases less than 1% of the power and area of a chip, so the design of the memory hierarchy, particularly the L2 and L3 cache, and how they handle contention is far mroe important.

  9. This is a Core, not a Chip. by chopper749 · · Score: 1

    Chips based on this new Core are a ways out.

  10. And thusly PowerVR admits defeat (again) by Anonymous Coward · · Score: 1, Interesting

    We've seen this before. Imagination blown to bits in the PC 3D-accelerator marketplace, and forced to withdraw with its tail between its legs. Now Imagination seems on the edge of admitting defeat in the hight-end ARM GPU market, and vanishing into this fantasy market of competing with ARM using its MIPS core.

    The problem Imagination has is that there are too many players in the ARM GPU space. ARM itself provides MALI cores, both cheap and nasty ones for all bottom end ARM SoC devices, and high-end ones for GPGPU applications. Qualcomm, of course, has the Adreno (via a long ago purchase of ATI's mobile GPU division), and Qualcomm is the current 'Intel' of the ARM market. Nvidia and AMD are both providing their AAA gaming/GPGPU cores to 2014 ARM parts, moving the ARM high-end beyond anything Imagination can dream of matching.

    At the moment, PowerVR is 3DFX (at the height of its success) strong in the ARM market, but faces the same problems that brought 3DFX's fortunes crashing down. PowerVR is currently used by Apple in all its non-x86 products. The important Chinese ARM chip companies are also starting to use PowerVR as well. PowerVR is in a golden age, but struggles to see a sunny future.

    Soon, basic OpenGL ES2.0 functionality on ARM SoC parts will return almost worthless to the GPU IP companies. Good enough acceleration for everything but proper games (which have yet to have an important impact on ARM devices) is in a hardware race-to-the-bottom, with too many excellent competing designs. This mirrors the end of value in the PC 2D video space, after years of excellent profit for companies like Hercules, S3 and Number-nine.

    No-one survived against AMD/ATI and Nvidia in the AAA-gaming GPU space. AMD won the Wii U, PS4 and Xbone. The existing handhelds are the last bastion of non-Nvidia, non-AMD GPU designs for proper gaming. AMD and Nvidia have worked hard recently to scale their desktop solutions into the high-end of the ARM mobile space, and intend to provide no-compromise gaming GPUs for this market.

    The last time Imagination went up against Nvidia and AMD, it was a bloodbath, and both companies are far better and far more ruthless today.

    So, now Imagination is biting the hand that feeds it- namely ARM. You can imagine how this will end. And Imagination is throwing their hat into a ring where Intel fights (with ZERO success). If Intel cannot beat ARM (and it most certainly cannot), Intel can take some pointless satisfaction in pummelling Imagination's MIPS ambition into non-existence. Wherever Imagination takes MIPS, it will find Intel there first with 'Quark' and other assorted Intel rubbish that Intel has the money to persuade companies to use ahead of anything but ARM.

    1. Re:And thusly PowerVR admits defeat (again) by rsborg · · Score: 1

      At the moment, PowerVR is 3DFX (at the height of its success) strong in the ARM market, but faces the same problems that brought 3DFX's fortunes crashing down. PowerVR is currently used by Apple in all its non-x86 products. The important Chinese ARM chip companies are also starting to use PowerVR as well. PowerVR is in a golden age, but struggles to see a sunny future.

      Soon, basic OpenGL ES2.0 functionality on ARM SoC parts will return almost worthless to the GPU IP companies. Good enough acceleration for everything but proper games (which have yet to have an important impact on ARM devices) is in a hardware race-to-the-bottom, with too many excellent competing designs. This mirrors the end of value in the PC 2D video space, after years of excellent profit for companies like Hercules, S3 and Number-nine.

      This assertion is ridiculous. Smartphones and tablets will suck down all the graphics power-per-watt mobile GPU vendors can provide, as they are (and since the iPhone, have been) consumer-bought devices, where high-touch and bling win and win big. The differentiator is that, without massive enterprise control of spending, consumers will rightly choose the best graphics chip out there (enterprises just wanted enough to be able to surf spreadsheets and basic imagery - anything more was a liability - games capabilities are generally not preferred in corporate environments).

      If you want an example of how important graphics capabilities are, take a look at the top grossing in the iOS App Store or Google Play markets. They are mostly games, and if not, apps that make extensive use of the graphics capabilities of the device.

      Imagination will continue to thrive as long as Apple thrives - and if Apple fails, then I might start to get worried - Android-based manufacturers may not show the same desires as Apple to push forward the envelope on graphics - but then again, I doubt it even then.

      --
      Make sure everyone's vote counts: Verified Voting
    2. Re:And thusly PowerVR admits defeat (again) by Anonymous Coward · · Score: 0

      > Now Imagination seems on the edge of admitting defeat in the hight-end ARM GPU market, and vanishing into this fantasy market of competing with ARM using its MIPS core.

      Had you mother tested you if you are insane?

      >ARM itself provides MALI cores

      The Mali ones aren't very good. No high-end stuff. Cheap and awful.

      > Qualcomm is the current 'Intel' of the ARM market.

      Is that supposed to be a positive argument?

      > Nvidia and AMD are both providing their AAA gaming/GPGPU cores to 2014 ARM parts, moving the ARM high-end beyond anything Imagination can dream of matching.

      NVidia trails the market. Their Tegra chips are slower than the competition. And suck more power.
      Where are AMD ARM GPU used? Until now they have NO products. Only announcements for next year.

      >No-one survived against AMD/ATI and Nvidia in the AAA-gaming GPU space.

      We are talking mobile. Not irrelevant and obsolete gaming rigs for a tiny minority.
      In mobile, neither AMD nor Nvidia are on top.

      >So, now Imagination is biting the hand that feeds it- namely ARM. Y

      No. Mobile GPUs have nothing to do with ARM per se.

      You posting is so wrong on so many levels. It's awkward.

    3. Re:And thusly PowerVR admits defeat (again) by Anonymous Coward · · Score: 0

      >Imagination is biting the hand that feeds it- namely ARM
      There is no honor among thieves. ARM would be nowhere without Linux yet they have no interest in open sourcing their drivers.

    4. Re:And thusly PowerVR admits defeat (again) by gl4ss · · Score: 1

      arm is trying to come up with things to compete with powervr products and arm doesn't use powervr so... what hand were they biting again?

      --
      world was created 5 seconds before this post as it is.
    5. Re:And thusly PowerVR admits defeat (again) by hattig · · Score: 1

      There are high end Mali cores - things have moved on in the three years since Mali-400 MP4 was on the market in the Galaxy SII. Sadly it is still a popular GPU core in the low-end market (ARM actually recently created Mali-450 to cater for this area), but there is the Mali T6xx family for higher end uses - e.g., http://www.arm.com/products/multimedia/mali-graphics-plus-gpu-compute/mali-t678.php

      Agreed R.e., NVIDIA - Tegra 4 is an outdated GPU core, even by mobile standards, but there's a lot of it to get good performance, and most games don't use the more advanced OpenGL ES 3 yet.

      AMD's ARM products aren't out until next year. They'll presumably be an ARM version of their low-end Jaguar-based APUs.

    6. Re:And thusly PowerVR admits defeat (again) by Anonymous Coward · · Score: 0

      This is incredibly insigtful post, I would add that ARM64 is as fast as 2010 Intel desktop CPU now and at the fraction of the wattage, Intel is toast unless they have some miracle undisclosed architecture coming.

    7. Re:And thusly PowerVR admits defeat (again) by edxwelch · · Score: 1

      the powervr 6 series, as seen in the the new iphone is currently the most advanced mobile gpu. Mali has always been one step behind powervr and adreno. Meanwhile, tegra has a disadvantage in the mobile space because it's not tile based and less power effient.

    8. Re:And thusly PowerVR admits defeat (again) by edxwelch · · Score: 1

      AMD only use ARM in there server products.

    9. Re:And thusly PowerVR admits defeat (again) by hattig · · Score: 1

      ???

  11. Imagination Tech. by Microlith · · Score: 1

    Odds on there being any open source drivers for this SoC? ImgTec is known for being hostile towards open source in general and delivering shit-grade binary-blob drivers that perform poorly and are rife with compatibility issues.

    1. Re:Imagination Tech. by Narishma · · Score: 1

      It's a CPU core they're announcing, not an SoC.

      --
      Mada mada dane.
  12. Silly rabbit! by eclectro · · Score: 1

    MIPS are for kids!

    --
    Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
  13. Obscure??? by Anonymous Coward · · Score: 0

    Many of the MOST POPULAR dd-wrt systems are MIPS based

  14. enough chip for a cell? by Gravis+Zero · · Score: 1

    ... designed to challenge companies like ARM in the embedded and mobile markets. ...
    Major features of the new chip include: support for 40-bit memory extensions, or up to 1TB of RAM, a 128-bit SIMD engine (Single Instruction, Multiple Data), and Hardware virtualization (MIPS R5 can virtualize other machines in hardware). The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400. According to IT, the chip is capable of executing 3.5 DMIPs/MHz in CoreMark...

    hmm... seems a bit limited for a smartphone processor.

    --
    Anons need not reply. Questions end with a question mark.
  15. 32 bit MIPS? by unixisc · · Score: 1

    Precisely!!! At this day & age, if your 32-bit CPU requires 40-bit memory extensions, then why bother making it 32-bit? Particularly when the architecture in question - the MIPS - has by now mature 64-bit implementations in MIPS IV & V? Incidentally, what do they mean by Series 5? MIPS V, if that's what they mean, is a 64-bit CPU - starting from the R10k onwards.

    I recall in the early 90s, when some companies such as QED & IDT did CPUs like the R4600: that would have been a fine template to start from in making this one. Which also brings up the question - what's the target application? If it is tablets/cellphones, then even that market is already headed towards 64-bit, w/ the iPhone already there, and probably Android & Windows Phone next.

    1. Re:32 bit MIPS? by Anonymous Coward · · Score: 0

      MIPS32R5 - 5 generations later than MIPS V.

    2. Re:32 bit MIPS? by unixisc · · Score: 1

      MIPS V was a 64 bit implementation. So 32R5 is what exactly - did they take MIPS V, make all the registers & 64 bit instructions 32 bit, and then come up w/ this?

  16. M(IP)S by unixisc · · Score: 1

    Looking back @ things, MIPS would have been the perfect platform for Microsoft, given what it does today. It was 64-bit (R4k) when NT debuted, and it was one of the platforms supported by CE. It has been low powered, and popular in routers & other networking gear. Had Microsoft consistently supported that platform on NT & CE, then they could have done something like Windows 8 a lot earlier than they did, at least as far as phones & tablets went.

  17. Apple might drop PowerVR by Ottibus · · Score: 1

    Imagination will continue to thrive as long as Apple thrives

    I wouldn't bet on that, Apple have been building a GPU team for a while now.

    1. Re:Apple might drop PowerVR by Anonymous Coward · · Score: 0

      Indeed, it was noticeable that Apple didn't mention PowerVR in the last iPhone announcements, just "GPU". Many believe that they are paving the way for a replacement, especially as Rogue wasn't the big leap ahead of the competition that everyone thought it would be.

      It may be that the new GPU that they eventually unveil will be based on Img tech that Apple engineers have updated, same as they did with ARM, so Img won't be out completely.

      Img have made some bad acquisitions lately, the voice tech that no-one big uses, the ray tracing graphics IP that will likely get made redundant by other lighting techniques that produce better results - and now MIPS, an also-ran in the processor race.

      Picking a fight with your best two processor partners is not a smart move IMO, ARM neatly avoided this with their partner programme.

      Their DAB radio line got a pasting too on UK TV this week, it got tossed across the room by the presenter for being too hard to use.

  18. er, yeah, dated a bit. by Anonymous Coward · · Score: 0

    And where to we get 1 TB of ram? For consumer use - good luck.

  19. AB by Anonymous Coward · · Score: 0

    Does it run angry birds?

  20. Small correction on coherency by YoopDaDum · · Score: 1

    The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400.

    The CCI-400 is not relevant here. In both MIPS and ARM worlds CPUs are now multi cores capable out of the box. One cluster can be configured from 1 to 4 cores typically, and here for this latest MIPS up to 6. The L2 management is handled as part of the cluster, which also typically supports coherency with external hardware accessing the L2 through one or several coherency port(s). The L1 cache(s), the L2 and the hardware are kept coherent inside a cluster (with some limitations at times on the low end, there are variants). All this can be taken for granted at the high-end, as here.

    Now what the CCI-400 does is different: it extends coherency management between several clusters. This is very important in the ARM world because of the big.LITTLE scheme: you want the big cluster and little cluster to be kept coherent to speed-up and easy the transition between the low-power and high performance modes (that also helps when all cores are used at all times, as the OS can migrate tasks between cores more efficiently).

  21. MIPS is a better choice anyway by AaronW · · Score: 5, Interesting

    MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

    I have spent many years working with MIPS and the last three working for a 64-bit multi-core MIPS manufacturer. MIPS also allows for clean extensions to the instruction set by various vendors, something ARM does not allow. For example, my employer has added a lot of instructions using coprocessor 2 (COP2) to add encryption, hashing, CRCs and more without breaking standard MIPS compatibility since COP2 is typically reserved for vendor extensions.

    MIPS page tables are also interesting. They are entirely managed by software, allowing the operating system to use whatever format they want for them. While some vendors have added hardware walkers they typically don't make much difference in performance.

    MIPS32 is fairly old and many implementations don't provide cache coherency which is a pain in the butt and impacts performance but the ones I deal with (Cavium's OCTEON processors) are fully cache coherent.

    As for doing encryption in the instruction set it allows full acceleration in user space without needing to deal with descriptors or DMA or userkernel transitions.

    Perhaps the only thing I would get rid of is the branch delay slot. It no longer really buys anything. The MIPS tools are much more mature than ARM, especially for 64-bit support. There are 32 general purpose registers with register 0 always being 0.

    With ARM64 most of the interesting ARM features are gone and in fact it looks a lot more like MIPS except that the instruction decoding is a lot more complicated. MIPS hasn't been standing still either. Extensions have been added for things like virtualization, 16-bit instructions (like Thumb) which usually don't buy you much and some multimedia extensions.

    I periodically work on MIPS assembly language with some of the bootloader stuff I do. All I can say is it's a joy to work with compared to X86 and is quite elegant. It's nice when I can have just a couple dozen lines of assembly language put a stack in cache memory and go straight to 64-bit C code. At this point it's quite hard for me to beat recent versions of GCC when it comes to optimizing code.

    I don't know why they're limiting their Warrior P-Class CPU core to 32-bits though. Moving to 64-bit MIPS is not very difficult. Personally I'd love to see 32-bit MIPS go away and just do 64-bit MIPS and use either the N32 or N64 ABI. N32 runs in 64-bit mode but with 32-bit addressing so you get all the advantages of 32-bit pointers and 64-bit registers.

    My employer makes MIPS processors with up to 32 cores and soon will have 48 cores and fully support Linux.

    --
    This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    1. Re:MIPS is a better choice anyway by Anonymous Coward · · Score: 0

      ... can you ask your employer to kick one or two development boards to FreeBSD?

      We do a lot with MIPS in the packet pushing world.

      -adrian

    2. Re:MIPS is a better choice anyway by adri · · Score: 1

      ... replying from my real account.

      Yeah, FreeBSD? dev boards? Any interest?

    3. Re:MIPS is a better choice anyway by tlhIngan · · Score: 1

      MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

      All in the name of speed, actually. Conditional execution is cool, until you realize it complicates a super-scalar multi-issue pipeline with out-of-order execution because the conditional dependency might not get resolved until late in the game.

      It's why an ARMv8 chip will not run ARMv7 code much faster - there's very little optimizations left to speed things up.

      So ARM re-did a lot of things for 64-bit to make it scalable in the future - rather than try to retain compatibility (there's wasn't any 64-bit code to speak of until ARM defined it), it was time for a clean break.

      So 64-bit code runs much faster because many of the architectural changes were designed for scalability.

      And in doing so, they also get rid of a lot of cruft in the 32-bit architecture that makes no more sense - notably, coprocessors are gone and replaced with system registers. Stuff like the CPSR are now broken out into PSTATE - more complex to use, but architecturally more scalable in the future.

      Plus, they added more architectural registers which is always a nice bonus. And there's a fixed mapping so setting up the 32-bit environment is fairly trivial (it really only takes a few bits to flip and the CPU will switch to AArch32 - I've gone it in pure assembly).

      64-bit ARM cleans up a lot of mess, and is pretty damn easy to code in. The encodings may differ, but the coding is a lot simpler and still very familiar.

    4. Re:MIPS is a better choice anyway by Anonymous Coward · · Score: 0

      MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

      Unfortunately many of those things turn out to also drag down performance very substantially. Having conditional execution on every instruction means the processor may not be able to retire them until much later. Meanwhile it turns out catering to compilers is a bigger issue in the modern era. 99% of code is compiled nowadays. One still misses architectures that had interesting features.

      I periodically work on MIPS assembly language with some of the bootloader stuff I do. All I can say is it's a joy to work with compared to X86 and is quite elegant. It's nice when I can have just a couple dozen lines of assembly language put a stack in cache memory and go straight to 64-bit C code. At this point it's quite hard for me to beat recent versions of GCC when it comes to optimizing code.

      That isn't much of a statement. Working with dog poo is joyful compared to working with x86, even though amd64 did clean things somewhat, the architecture make abstract art look normal. Sometimes bootloaders can be fun, I managed to write one that didn't use `objdump` or `objcopy` at any point during the build process. Simply run the C files through `gcc` then run the assembly language file through `gcc`, then link everything together and the resultant program would install itself correctly. I had some fun figuring out what the assembler was doing, and getting it to mark things the right way.

    5. Re:MIPS is a better choice anyway by AaronW · · Score: 1

      I can certainly ask. Our processors are designed for packet pushing. Here's an inexpensive router using one of our older low-end chips:

      http://www.amazon.com/EdgeRouter-ERLite-3-512MB-Ethernet-Router/dp/B00CPRVF5K/ref=sr_1_2?ie=UTF8&qid=1381865052&sr=8-2&keywords=router+million+packets

      It's capable of pushing a million packets per second using Linux and a modified TCP/IP stack. While Ubiquity source releases all the source sadly they're using a rather old SDK (2.0). Once things settle down at work I hope to incorporate support for this into our base bootloader. I'd also love to push all of the bootloader changes I have made to U-Boot upstream though I'm dreading the battle involved due to the huge amount of code and some of the unorthodox things we do.

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    6. Re:MIPS is a better choice anyway by AaronW · · Score: 1

      That is true. I am not that familiar with ARM personally. As I said most of my experience is with MIPS. I have been working with MIPS processors for the last 14 years at the device driver and bootloader level.

      The biggest issue with ARM64 right now is that it is still rather immature. It will take a while for things to fully stabilize. I will likely be working on it in the future since my employer is working on 64-bit ARM chips. The funny thing is that from what I looked at, ARM64 looks an awful lot like MIPS.

      What I love about MIPS is that it never really got all the cruft that ARM did and certainly not all the crap that was piled into X86. While MIPS did pick up some crap, like MIPS16, I rarely see it implemented. It was their answer to Thumb. It doesn't really improve code density much and the performance penalty isn't worth it so in practice most vendors don't support it. The migration from MIPS32 to MIPS64 is quite elegant with no major instruction changes except for adding new 64-bit instructions to augment some of the 32-bit ones and a few changes to the ABI.

      I still use objcopy for our bootloaders and it takes experience to get the assembler to always do the right thing. I have to remember to always tell it to not reorder instructions since otherwise it tries to hide the branch delay slot for example. So far my favorite bootloader is an 8K MMC and SD bootloader. All of the assembly code fits in the first sector in front of the partition table. I had a lot of room left so I put most of the serial port routines in there to print strings and hex values. The 64-bit C code loads the next stage bootloader out of a bootable FAT16 or FAT32 partition into the L2 cache, has the MMC and SD drivers, validates the bootloader CRC and will use two alternate backups if the CRC fails. It can even load an environment file off of the SD card for the bootloader as well.

      For U-Boot we use virtual memory so we don't have to relink. It also allows it to run seamlessly from any memory location with a single binary. Even though the code is 32-bit it will happily run at the top of memory even when 64GB of RAM is installed. That way the same bootloader works if we boot over PCIe, JTAG, MMC or NOR flash. On MIPS not having a page table makes this trivial. I just have to program a few Coprocessor 0 registers to load it into the MIPS translation look-aside buffer to set up virtual memory. That way we have virtual memory running before running any C code.

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    7. Re:MIPS is a better choice anyway by alexvoica · · Score: 1

      We're not going to do 32-bit cores only, we have 64-bit 'Warrior' CPUs in the pipeline too. 64-bit CPUs have area and power implications that are too complicated to go into detail here; for affordable mobile devices and microservers, 32-bit MIPS + XPA + EVA should be more than enough. Regards, Alex.

    8. Re:MIPS is a better choice anyway by Anonymous Coward · · Score: 0

      Sounds like Cavium Octeon.
      If yes, I've got one, use it with FreeBSD, it's OK.

  22. It's about time by kriston · · Score: 1

    It's about time for a competitive MIPS mobile processor. The relatively open architecture is so well-supported by so many different operating systems for decades. I'm glad to see the modernization of MIPS32 as well as the MIPS64 Chinese Loongson supercomputing initiative.

    --

    Kriston

  23. What happened to SPARCs? by unixisc · · Score: 1

    Yet nobody has gone w/ an embedded SPARC. Think of the advantages - SPARC had a rich host of applications, and could run not just Solaris, but Linux & OpenBSD as well. So if something like, say, Scientific Linux, were ported to it, it would be the perfect engineering workstation out there. Yet, SPARC ultimately lost all that first to RH/PCs, and later to Wintel. W/ the result that it has no niche even there anymore.

    The companies that used to make SPARCS are either dead (Ross Technologies) or abandoned it (Cypress). Who else makes them?