Announcement

Collapse
No announcement yet.

Fedora Discussion: "ARM Is A Dead End"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by uid313 View Post
    Are you saying that Intel would make an ARM CPU or that Intel would add the ARM instruction set to the x86 CPU?
    Not going to happen.
    Intel had already ARM CPUs, but they abandoned them:
    http://en.wikipedia.org/wiki/StrongARM
    http://en.wikipedia.org/wiki/XScale

    Comment


    • #17
      Originally posted by TobiSGD View Post
      Intel had already ARM CPUs, but they abandoned them:
      Those were separate chips. ARM chips have a zillion suppliers in all sorts of flavours.

      The problem is what to do if you accept the large ARM installed base, but also believe it dying (or want it to die). If an Intel x86 chip is swapped for an ARM chip, you still have the problem that you need to recompile your OS and use different device drivers. That is to be expected. But you now have the problem that much of the software won't work. For example if you grab the Android package for Angry Birds it won't run without the included ARM library. A platform that not many applications work on, or require the majority of apps to be recompiled is going to have a hard time getting traction.

      Intel *could* add an ARM ISA to internal micro-ops translator which would let you run existing ARM software while "migrating" to Intel. This is mostly a business decision than a technical hardship.

      Comment


      • #18
        CISC and RISC does not mean Complex or Simple Instructions, actually means Complex or Reduced Instruction-Set, that means Complex or Reduced relations between Instructions. So on RISC, Instructions are relative between them, that means the one is a little the other and goes on. So RISC can execute all kinds of Instructions (float,integer,...) by the same units --and-- with the same way, while the ugly CISC cannot. All the above means that RISC wants 1-Million-Transistor without cache for 2.5dmips/mhz while CISC wants 20m, also the difference goes to 40/1 for Stream-Processing like Gaming. Finally CISC does not translating or decoding anything to internal RISC, decoding for processors its a totally different thing, CISC to RISC is recompiling and its the reason for Intel to insist on x86, because it was difficult to emulate a CISC on a RISC or another ISA CISC. But that is in the past: http://en.wikipedia.org/wiki/Loongson See this in LC3-part: 2*512bit(fmac) vectors for Float and another same length unit for Integer (bigger against Ivy Bridge). Also has Emulation-Instructions and Mips3D-Instruction, in order to accelerate Qemu and Software-Rasterizers like LLVMpipe, and its not the smallest of the RISC processors (16cores@2ghz=20watt). Don't invest on Intel, Amd, Nvidia, Microsoft, Apple, Adobe, Unreal,...

        Comment


        • #19
          Originally posted by sirdilznik View Post
          I fully agree. x86 may still be the king in terms of raw horsepower at the moment, but ARM still beats x86 by leaps and bounds when it comes to power consumption. In the mobile space, which is the area of real growth, power consumption, not raw horsepower, is king.
          That x86 smartphone shows that power consumption is just fine on x86. Most x86 machines just haven't optimized everything for power like they could - like creating SoC's instead of using big power hungry motherboards.

          Although I agree it's silly to claim ARM is going away. They're getting more important every day.

          Comment


          • #20
            Originally posted by artivision View Post
            CISC and RISC does not mean Complex or Simple Instructions, actually means Complex or Reduced Instruction-Set, that means Complex or Reduced relations between Instructions. So on RISC, Instructions are relative between them, that means the one is a little the other and goes on. So RISC can execute all kinds of Instructions (float,integer,...) by the same units --and-- with the same way, while the ugly CISC cannot. All the above means that RISC wants 1-Million-Transistor without cache for 2.5dmips/mhz while CISC wants 20m, also the difference goes to 40/1 for Stream-Processing like Gaming. Finally CISC does not translating or decoding anything to internal RISC, decoding for processors its a totally different thing, CISC to RISC is recompiling and its the reason for Intel to insist on x86, because it was difficult to emulate a CISC on a RISC or another ISA CISC. But that is in the past: http://en.wikipedia.org/wiki/Loongson See this in LC3-part: 2*512bit(fmac) vectors for Float and another same length unit for Integer (bigger against Ivy Bridge). Also has Emulation-Instructions and Mips3D-Instruction, in order to accelerate Qemu and Software-Rasterizers like LLVMpipe, and its not the smallest of the RISC processors (16cores@2ghz=20watt). Don't invest on Intel, Amd, Nvidia, Microsoft, Apple, Adobe, Unreal,...
            Modern x86 processors are all RISC designs, with a frontend that translates x86 into RISC micro-ops.*

            *For the most part. Some of the processors then internally fuse multiple micro-ops back together into macro-ops, so for the most part the things are just hybrids of whatever Intel and AMD can figure out how to run fastest.

            I wouldn't be surprised if Intel adds ARM support, but they might not implement the entire ISA. Instead, they could just implement some of the commonly used instructions, as a x86ARM extension similar to SSE or their virtualization acceleration hardware. Then maybe you'd have an emulator program that would run the ARM programs, and it could translate some of the rarer instructions to x86 while using native x86ARM instructions for the majority.
            Last edited by smitty3268; 06-15-2012, 09:23 PM.

            Comment


            • #21
              Micro-OPs are not RISC because have no relative roots between them, and because there are not instructions. Actually today’s CISC instructions are very complex and they don't executed at once but in frames in space or time/hz. These frames are decided by the MicroCode of the processor and called Micro-OPs. This is the only way to produce a modern CISC, by lowering the different execution units in a number between 3 and 5 instead of 10-20(impossible), while RISC needs only one (vectors). There are more clever ways like MISC and OISC but these are not for today’s intelligence. Anything I said above is 100% correct, some of you must learn to study first.

              Comment


              • #22
                You can actually find studies on the Internet about: MicroCode vs RISC vs VLIW.

                Comment


                • #23
                  x86 has more risk of going dead than ARM. Dead = mainstream rarity.

                  Over time there has been many attempts to introduce a new CPU for Windows users. More and more stories have been added to the x86 house and it is getting tall and weak at the foundations. The makers would love a new set of registers, op codes and features. For it to die though would need a concerted effort from Intel, AMD, Microsoft, Apple, and other users+makers of the CPU structure.

                  Comment


                  • #24
                    Originally posted by maligor View Post
                    The exact same thing (OP) could be said about x86, and that same statement could have been said 20 years ago.
                    IIRC, Linus was laughed at for creating a *nix kernel that would run on his 386.

                    Comment


                    • #25
                      ARM: Fedora 17 ARM Release Candidate VFAD results


                      http://lists.fedoraproject.org/piper...ne/168685.html
                      Sat Jun 16
                      "Paul Whalen redhat.com Good day all,

                      Good day all,

                      Thanks to everyone who was able to participate in our VFAD this afternoon. Below is a summary of the results:

                      The following RC1 images (http://scotland.proximity.on.ca/arm-...o-mirrors/RC1/) worked as expected and all tests were successful:

                      Pandaboard w/serial console & SD
                      Trimslice Bare/Value Pro/H/H250 w/serial console & SD
                      Trimslice Pro/H/H250 w/serial console & SD/SATA
                      Highbank w/serial console & SATA
                      Kirkwood(Guruplug) w/serial console & MicroSD

                      The following images had issues that should be resolved in RC2:

                      Versatile Express(Qemu) - Did not boot, kernel oops. Resolved in RC2.
                      Versatile Express+XFCE (Qemu) - Did not boot, kernel oops. Resolved in RC2.
                      Pandaboard+XFCE w/SD - The RC1 image incorrectly booted to multi-user mode. Fixed in RC2. Using the GUI, options to reboot/shutdown, automatic mounting and updating failed with an authentication error. Bug to be filed.

                      The following images had issues that require further investigation/action:

                      Beagleboard XM w/SD - Booted successfully on a Rev B board, subsequent boots produce a kernel oops. Failed to boot using a Rev A2 board.
                      Efika SmartTop iMX w/SD - Booted successfully, subsequent boots produce a kernel oops.

                      The unofficial nightly images for the Raspberry Pi (http://scotland.proximity.on.ca/arm-nightlies/) were also tested:

                      Raspberry Pi w/SD - Works as expected.
                      Raspberry Pi+XFCE - X not installed. To be resolved in future nightly images.

                      The full results and tests performed can be found here - http://fedoraproject.org/wiki/Archit...ra_17_Test_Day

                      New images for RC2 are being created now!
                      Due to the overwhelming success of today, we are holding another VFAD next week:

                      Fedora 17 - RC2 image validation VFAD
                      Monday June 18th - 12pm EDT
                      #fedora-arm on Freenode


                      Special thanks to the participants today, and we hope you can join us next week.


                      On behalf of the Fedora ARM Team,
                      Paul

                      Comment


                      • #26
                        Lately, Phoronix seems to like to mislead their reader with the title, Or use 'strong words' to add more clicks. Like this one. Fedora Discussion: "ARM Is A Dead End. It's as if majority in the discussion agree that ARM is a dead end.

                        It's unfortunate. I hope for better jounalism on phoronix with each day passing, but looks like it went the opposite.

                        Comment


                        • #27
                          The reason ARM is going to take over the market isn't because of performance or power consumption, it's because of price. Intel has the X86 architecture by the balls, but anyone can go out and buy an ARM license. Looks at companies like Texas Instruments, Samsung, Qualcomm, and even Apple. These are not companies known for making processors, but they're giving Intel a run for their money.

                          All we need is someone to come along and make a desktop ARM chip. One that is tweaked to hell and clocked at 3-4 Ghz. I could easily see AMD or Nvidia making a motherboard chipset that works for both X86 and ARM CPUs to be inserted.

                          Much like AMD, the purpose of ARM is to help remind Intel that they aren't a monopoly.

                          Comment


                          • #28
                            Originally posted by Dukenukemx View Post
                            All we need is someone to come along and make a desktop ARM chip. One that is tweaked to hell and clocked at 3-4 Ghz. I could easily see AMD or Nvidia making a motherboard chipset that works for both X86 and ARM CPUs to be inserted.
                            I'm highly skeptical of any attempt to make an ARM chip competitive with Intel on the desktop. Intel's manufacturing capabilities give it a large advantage over everyone else, and the ARM companies have no experience building those kinds of chips.

                            Where they can succeed is in the server space, where efficiency and power usage are important, and they can easily scale to many cores to provide performance.

                            Comment


                            • #29
                              I'd love a 32-core ARM laptop with two days' battery life.

                              Comment


                              • #30
                                Originally posted by curaga View Post
                                I'd love a 32-core ARM laptop with two days' battery life.
                                You can already buy a tablet and attach an external keyboard.

                                The problem with a 32-core ARM laptop is that nothing on the desktop uses 32-cores, and each one individually is way too slow.
                                Last edited by smitty3268; 06-17-2012, 07:50 AM.

                                Comment

                                Working...
                                X