Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Open Source Hardware

Rise of the ARM Clones 78

Posted by timothy from the but-it's-a-slow-rise dept.
An anonymous reader writes "Clones of the ARM processor intellectual property are again becoming available for free from the open source hardware community. ARM was rigorous in shutting cloners down in the past but the clones are rising again under codenames Amber, Storm and Atlas, albeit of older instruction set architectures."
This discussion has been archived. No new comments can be posted.

Rise of the ARM Clones More

Rise of the ARM Clones

Comments Filter:

  • Rise of the clones (Score:5, Funny)

    by Kopachris ( 1594707 ) on Wednesday June 26, 2013 @10:11AM (#44112743)
    You can finally have your very own clone ARMy.

    • Re: (Score:1)

      by Anonymous Coward

      Oh? What do you call this ARMy? Beowulf's Bridgade? Are they well ARMed? Should we form a Compaq or sign an ARMistice? Or simply do a call to ARMs?

    • Better warn Niven.

    • SEND IN THE CLONES!

  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Wednesday June 26, 2013 @10:12AM (#44112759)
    Comment removed based on user account deletion

    • Re:Why not? (Score:4, Funny)

      by JDG1980 ( 2438906 ) on Wednesday June 26, 2013 @10:13AM (#44112775)

      You actually miss Cyrix?

      • Re: (Score:2)

        by jonwil ( 467024 )

        Worst mistake I ever made in all my years of buying (and building) computers was when I bought a 300MHz Cyrix part as an upgrade to fit into my PC (at the time the Cyrix part was the only real way to upgrade beyond the Pentium 166 MMX that I had without buying an expensive new motherboard). That Cyrix part was a piece of junk and never worked all that great (although to be fair some of that was because I was stupid and used the heatsink and fan from the Pentium 166 MMX on the Cyrix part instead of getting a

        • Apart the crappy thermal solution, what kind of problems did you have with the Cyrix CPU?

          • And I have only happy memories of Cyrix. In particular, I had a Toshiba T5200 with an alleged 20MHz 386. This exhibited the protected-mode bug which was only supposed to afflict 16MHz early 386 chips (maybe it was just overclocked). So although it worked fine with OS/2 2.0, the command shell had a curious bug in the beta of OS/2 2.1 (it only affected command line editing). It also crashed regularly with Windows 3.0
            The T5200 behaved perfectly with Windows 3.0 and OS/2 2.1 once the Intel 386 was upgraded to

          • Cyrix had the same problem with many of their CPUs as the K6 and K6/2, inferior FPU with not enough bits. Also, it had crap performance clock for clock compared to intel, unlike the K6 which I found to be quite competitive any time it wasn't involved in fp math. A K6/3 would give a P2 a good run for its money, clock for clock, but they didn't scale quite as far except occasionally.

    • This time around "Choice" of CPU is virtually impossible for the customizer or customer because none of the hardware that typically use these chips are in sockets. Different era; different mods.

      • Choice of CPU is at the board level, sure, but with a Raspberry Pi selling for $35, is that really a problem?

    • Personally I'm more interested in some of the MIPS chips like the Loognson Dragon that has built in X86 hardware acceleration, supposedly you get 80% of X86 speed

      Last I heard, the latest Loongson processors were performing about on-par with the earliest 1GHz Pentium-4 processors. A processor well over a decade old. That's something to look forward to...

    • Personally I'm more interested in some of the MIPS chips like the Loognson Dragon that has built in X86 hardware acceleration, supposedly you get 80% of X86 speed when it comes to emulation but while having the longer battery life. Sadly we'll never see it in the states thanks to IP laws but if the chip designed were truly opened up I bet we'd see all kinds of new ideas and approaches. Remember when we had choices in X86 besides AMD and Intel? They had chips like WinChip that were more of a RISC design, you had more media leaning like Cyrix, it gave us a wealth of choice and if that happens with the ARM clones I'm all for it.

      I'd argue that we have a bonanza/plethora of choices as far as ARM clones go - you have them coming from Phillips, TI, Qualcomm, Freescale, Marvel, NVIDIA, Atmel and who knows who else. These are all licensees of ARM Holdings. Similarly, MIPS has/had its many licensees. Intel was more restricted, and I'd argue that it was for a worse CPU.

      If you are thinking about an open CPU, a good one would be OpenRISC/OpenCore. Currently, it's a soft CPU, which any company could pick up, license and fab. So all so

      • Re: (Score:2)

        by snadrus ( 930168 )

        AMD's failing in direct x86 competition. Hybrids may be interesting, though could be done at the board level. x86+Video integration hasn't worked well, and part of this is expense when putting too much on the same die.

        MS pushes WinRT to confuse, which would threaten something like that.
        Now that Intel can make 6+ hour laptops and Android can run on x86, what's the advantage of all that work?

        • I'm not talking about putting too much on a single die. I'm talking about taking 2 x64 Thuban cores, 2 ARM core and making a hybrid MCM CPU. The idea being that any system based on this could natively run Windows apps written for x64 as well as Android apps written for ARM. Android does exist on x86, but most of the apps would need to be ported. The base OS could be something like Minix, w/ Windows 8 and Android jails inside.

          Intel can make what it can due to its process advantage over everybody else.

    • supposedly you get 80% of X86 speed when it comes to emulation but while having the longer battery life.

      Actually, it's rather x86 applications run at about 80% the speed of native MIPS applications.

    • Re: (Score:2)

      by higuita ( 129722 )

      IIRC, the last true x86 CISC chip was the pentium (not the pro) and the first x86 RISC chip was the AMD K5.. after that all x86 are internally RISC chips with a CISC compatibility layer

  • naming converntions (Score:1)

    by Anonymous Coward

    If they are ARM clones...similar to ARMs but not quite the same...can we call them LEGs?

  • What restrictions apply to CPU architectures? (Score:3)

    by JDG1980 ( 2438906 ) on Wednesday June 26, 2013 @10:23AM (#44112967)

    ARM will license out their cores to whoever pays. Intel and AMD (and Via, but no one cares about them) are apparently the only ones allowed to make x86 chips. But what type of "IP" is relevant here? What is the legal basis for the restrictions? If someone decided to make their own x86 clone, for instance, what would they be violating? It can't be trademarks, since that could be circumvented simply by changing the wording on the product and literature. I don't see how it could be copyrights, unless the implementers actually copied the original die mask or made a derivative work of it. So that leaves patents. Can you patent opcodes? Or is it only specific methods of implementing the opcodes that are covered by the patents?

    The original Intel Pentium was released in March 1993. This means that the patents on it should either be expired or nearing expiration. Would there be any demand for an open implementation of a 20-year-old x86 CPU? In embedded systems, maybe. And as more time goes by, a greater and greater portion of the x86 ISA could be implemented.

    • From the second to last paragraph in the article, "It is the case that patents usually have a 20 year life and therefore those that were in force in 1990 have now expired. However, modern implementations of old instruction sets could infringe on techniques that have been patented more recently by ARM or other companies – so I don't think the age of the instruction set is a water-tight defense."

      • Re: (Score:1)

        by Anonymous Coward

        I would say that I can't build anything using electronic components today without infringing on some patent. There are simply too many patents. I think that is sort of a big problem.

    • It doesn't matter, because the owners of the "IP" (which is not a real thing) will tie up the cloner in court for a long time, whether or not they have a valid claim. That's how the legal system appears to work.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      ARM will license out their cores to whoever pays. Intel and AMD (and Via, but no one cares about them) are apparently the only ones allowed to make x86 chips. But what type of "IP" is relevant here? What is the legal basis for the restrictions? If someone decided to make their own x86 clone, for instance, what would they be violating? It can't be trademarks, since that could be circumvented simply by changing the wording on the product and literature. I don't see how it could be copyrights, unless the imple

    • Re: (Score:2)

      by AmiMoJo ( 196126 ) *

      All ARM can really do is certify chips as 100% ARM compatible. That's where the value of licensing lies.

      If you are building an ARM based system you are going to want a certified chip so you know that all the ARM software out there will run on it. If you use an non-certified core there might be odd implementation bugs that break things in subtle ways, or maybe a future version of Android crash, or have some other undesirable effects.

      • I say go for it without certification. "100% ARM compatible" is a joke now, given the large number of different, mutually-slightly-incompatible ARM architectures made by ARM and ARM licensees.

    • But what type of "IP" is relevant here? What is the legal basis for the restrictions?

      If you had RTFA you would have seen nice little quotes like this one:

      "not covered by patents so can be implemented without a license from ARM."

      The original Intel Pentium was released in March 1993. This means that the patents on it should either be expired or nearing expiration

      Before June 1995, patents in the US weren't 20-years from filing date. If they were, MP3, and perhaps AAC (-LC) and MPEG-2 would be free and clear

  • If APIs can not be patented (Score:1)

    by Anonymous Coward

    then why can the API of a processor, i.e. the instruction set, be patented?

    • Because it isn't abstract.

      • Re: (Score:1)

        by Anonymous Coward

        How is an instruction set less abstract than any other API? They are all lists of ways to make a machine do specific things.

    • 1) Software can't be patented argument is a lazy and misleading argument. I can describe any piece of hardware(electronics, mechanisms, chemical formulas, etc) as a set of numbers and formulas. Either we get rid of all patents or we make the system harder/more intelligent(no more slide to unlock crap). I don't care which we do as long it makes the lives of us engineers easier. But using misleading arguments do NOT help our cause.
      2) Processor architecture is much more than the instruction set. The way inter

  • Total Annihilation came out in 1997 and you're just reporting on it now?

    Oh wait, wrong ARM and wrong clones.

  • ...The Vitruvian Man.
    http://en.wikipedia.org/wiki/Vitruvian_Man [wikipedia.org]
    Now we just need a LEG clone.

  • Do it in China (Score:3)

    by rodrigoandrade ( 713371 ) on Wednesday June 26, 2013 @11:08AM (#44113695)

    They have the manufacturing ability and steamroll over patents, trademarks, intellectual property, etc.

    Really, was that so hard??

    • If I had mod points, you'd get +1 Insightful. Why not make use of existing capabilities to increase competition?

  • The article mentions that it is compatible with the ARMv2a instruction set, though it may not be implemented the same way regarding pipelining and caching. The ARMv2a instruction set is basically the same instruction set as the ARM7TDMI, but without THUMB, and without the BX instruction. Any pure ARM code that doesn't use newer features (such as saturating arithmetic) should work on it fine. GCC should support this with no problems.

    • Re: (Score:2)

      by Dwedit ( 232252 )

      It also appears to be missing 32x32=64-bit multiplication instructions.

      • This. It will hurt. A lot. This means that 64x64 -> 64 multiply (what gcc will do if you multiply two uint64_t values) will now need 10 multiplies, at least 20 shifts (16 to cut off tops 16 bits of intermediates, 5 for result alignment), and 9 additions, instead of just 2 long multiplies and one long multiply accumulate. Ouch...

    • ARM7TDMI is ARMv4.

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close