Talk:ARM architecture family/Archive 1

Archive 1

Archive 2

Archive 3

Archive 4

Arc

What, no mention of the Archimedes? Phil 15:58, Nov 27, 2003 (UTC)

There should be a disambiguation page for ARM

Since so many people know better ARM than Acorn Risc Machine, it is highly needed a disambiguation page with arm, the part of the body.

Sorry, but i don't know how to create one, and unfortunately have no time now to learn how to do it. :( Hgfernan 14:52, 19 Jul 2004 (UTC)

Done. arm (disambiguation).

Merger

This article needs to be merged with the stub at Advanced RISC Machines. I would suggest moving everything to Advanced RISC Machines as the name 'Acorn RISC Machine' is now only of historical significance and not commonly used. In fact 'Advanced RISC Machines' isn't commonly used either, so an alternative would be to put everything at ARM Ltd or petition to take over the ARM page and move the disambiguation to ARM (disambiguation) as per IBM. -- Solipsist 07:14, 21 Oct 2004 (UTC)

OK so it was a mistake to move this page to ARM Ltd, since the majority of links were to the core design, but quite a few were just mixed up. I still think this page would be better at just ARM since few of the other ARM acronyms a common, but 'ARM architecture' will have to do for now. Next plan is to move Advanced RISC Machines to ARM Ltd which will concentrate on the company itself. -- Solipsist 22:14, 27 Nov 2004 (UTC)

Address bus width

Some other sources on the Internet claim that the addresses of ARM2 were 26-bit wide. Are there any references that it was indeed 24-bit wide, as stated in the article?

Well, in short the address bus was 26 bit, i.e. it could address 2²⁶ bytes.

In more detail: As all ARM instructions were 32 bit and were word-aligned (by ARM words being 4 bytes), the lowest 2 bits of the instruction address (held in the "Programm Counter And Processor Status Register" R15) would always have been zero. Instead these two bits were used to control the processor mode (00 = User Mode, 01 = FIQ Mode, 10 = IRQ Mode, 11 = Supervisor Mode), thus leaving only 24 bits for the "Program Counter". Thus one could claim, that the "Program Counter" was 24-bit wide. On the other hand, the ARM2 was well able to address single bytes when reading (LDR) or writing (STR) from/to memory. To achieve this, the ARM2 of course had a full 26-bit address bus.

Matthias Seifert 79.214.78.140 (talk) 12:12, 25 December 2007 (UTC)

"Many people are of the opinion that it is a very "pure" RISC implementation..."

So name some of the "many people". What makes it "very pure"? What makes it a more "pure" RISC than, say, the MIPS? ARM has a number of "impure" features, for example load/store multiple.

The statement lacks substance. Mirror Vax 11:13, 26 Apr 2005 (UTC)

A small reediting of the article is badly needed

The article is pretty good as it is. It is a very interesting read and it is filled with information and wiki-links, which are always nice. On the other hand, it is stacked with adjectives, which are inheritedly a vehicle of the author's opinions and not of facts. Terms like "excellent power needs", "performed better than", "draw far less", "aging 'i960' line", etc... They are all subjective expressions. The article would greatly benefit if those (and other) terms were substituted with facts, which bring value to an encyclopedia.

--Mecanismo 08:32, 21 July 2005 (UTC)

Please include a link to <http://en.wikipedia.org/wiki/Risc>! "RISC" in an encyclopedia, especially with hyperlinks, really should be defined. I would do it, but I need to learn how (surely, not difficult) and I'm nested about four levels deep in current tasks and need to pop my task stack. Nikevich (talk) 06:23, 13 March 2009 (UTC)

Conditional code

"Conditional execution of most instructions, reducing branch overhead and compensating for the lack of a branch predictor" and later "An interesting addition to the ARM design is the use of a 4-bit condition code on the front of every instruction, meaning that execution of every instruction can be made a conditional."

Is it talking about the same thing? If so, why first time it says "most instructions" and the second time it says "every instruction"? Clarification needed.

I found a lecture about 4-bit NZCV condition field in ARM architecture and PDF document that describes the ARM instruction set. Read it and change this article. Add my links to it if you want. I don't want to change it 'coz of my english :-) Vugluskr 08:55, 2 May 2006 (UTC)

They are talking about the same thing. The 4-bit field has 15 legal values, 1 for "always" and 14 pairs of complementary condition codes (EQ/NE, etc.). The 16th value (1111) historically meany "never" (complement of "always"), but now indicates a different instruction which cannot itself be conditional, because there's no condition field.

Rewrote the "interesting addition" part to avoid the most/every problem as well as avoiding the implication that predicated execution is unique to ARM. Kaleja (talk) 18:56, 23 May 2009 (UTC)

Three Address Architecture?

What is Three Address Architecture? This needs clarification.

Three address architectures are ones where arithmetic instructions have three "addresses", being two addresses (usually register names) for the operands and one for the result. This is distinct from architectures which use a specific accumulator register to which most arithmetic operations refer to implicitly. - Donal Fellows 10:12, 6 November 2006 (UTC)

Is a link to 3-operand RISC clarification enough? --68.0.124.33 (talk) 16:52, 10 March 2008 (UTC)

volatile short

Some early ARM processors (prior to ARM7TDMI), for example, have no instruction to load a two-byte quantity, so that, strictly speaking, for them it's not possible to generate code that would behave the way one would expect for C objects of type "volatile short".

Could this not be implemented with the following code? (My ARM code is a little rusty.)

r0 = address of variable

// for word-aligned address:
// shift left and right to clear top 16 bits
ldr r1,[r0]
mov r1,r1,lsl#16
mov r1,r1,lsr#16

// for half-word-aligned address:
// shift right to clear bottom 16 bits
ldr r1,[r0,#2]  // adding 2 will make address word-aligned
mov r1,r1,lsr#16

That would make it atomic, as opposed to a two-byte access:

ldrb r1,[r0]
ldrb r2,[r0,#1]
orr r1,r1,r2,lsl#8

217.194.34.103 13:42, 23 August 2006 (UTC)

One problem is that you may not be allowed to access the other 16 bits at the same time in a 32-bit read. One common use for a volatile short is a 16-bit register on external hardware, where you generally don't want to read registers without a good reason: for example, some chips I've worked with would clear a register to zero after it's read, or update an internal address after each read (e.g. you set the internal address to some value, then each time you read the register it returns the contents of that internal memory address and increments it ready for the next read). I also seem to remember one chip's documentation saying it may lock up if you read undocumented addresses! So unexpectedly reading any of those registers in order to get the value of a neighbouring register could be bad news. Mark Grant 16:31, 25 August 2006 (UTC)

I think the comment about not being able to support volatile short is spurious (though perhaps true) in that I can't think of any situation where you would need it on an ARM processor. Normally on-chip registers are all 32 bit (AMBA APB doesn't support anything other than 32-bit accesses). All volatile registers whatever their actual size should be 32-bit aligned. --Ashleystevens 12:58, 3 January 2007 (UTC)

I'm sure it's spurious: volatile is defined in the ANSI C standard to mean something when the variable is read rather than when it's written. You might experience other side-effects of volatile (like an unusual addressing mode when writing the variable) but I don't think they're standardised? -- Chris St John 14:21, 4 December 2007 (UTC) —Preceding unsigned comment added by 62.254.208.197 (talk)

I would object to the "strictly speaking" and "not possible" part; C shorts are not required to be 16 bit (that is just the minimum), so strictly speaking a C compiler is allowed to make shorts 32 bits in which case it would be possible to generate code where "volatile short" behaved correctly. —Preceding unsigned comment added by 192.171.3.126 (talk) 15:34, 20 March 2008 (UTC)

C shorts aren't required to be 16 bits, but if they are 16 bits in an implementation, they always have to be 16 bits. The compiler can't make some of them 16 bits and others 32 bits, as sizeof(short) has to have a consistent value. (Note that compiler options might be used to affect the size of a short, but that is not intended for use in making some shorts in a program one size and others a different size, and doing so will generally not yield a program that works as intended.)

However, there's nothing in the standard that prohibits the compiler from adding padding that is not part of the short, so that the short and the padding together occupy 32 bits, and using 32-bit load and store instructions to access the short, along with any required shifting or masking to provide the appropriate semantics. --Brouhaha (talk) 01:20, 29 August 2008 (UTC)

Advertising

I think the article sounds too much like advertising. "one of the most prolific 32-bit architectures in the world." "are found in all corners of consumer electronics" "To keep the design clean, simple and fast" The ARM licensees section is also pretty bad. I'm a bit biased toward 8051 archs personally, so I leave it more up to discussion on how to cut down on the adverty speak in the article. Kevin_b_er 05:18, 5 October 2006 (UTC)

The ARM licensees section is very poor and contains many errors and statements of opinion, and over-generalisations, plus a number of things that are irrelevent to ARM. However, since the title of the Wikipedia page is "ARM Architecture" I think that this whole section is probably in the wrong place anyway. Either the page title should be changed (can you do that?) or this should perhaps moved to either ARM_Holdings or Semiconductor_IP --Ashleystevens 13:06, 3 January 2007 (UTC)

The cores

I would suggest that "the cores" section is becoming unweildy. A few other points would warrant a re-organization of the page here:

• the cores (ARM7TDMI, ARM9, etc.) are implementations of the architecture. Although this information is interesting to some, perhaps, it is not directly relevant to the ARM Architecture, which is the subject of the page.
• only those cores designed by ARM Limited (ARM*) and Intel (XScale) are listed. There are other licensees of the architecture who have publically announced implementations.
• the ARM implementations are cores in the sense that they may appear in a multitude of SoC designs. The Intel XScale cores are in fact complete SoCs, reflecting the different business models.
• the list of cores (from ARM) and other ARM devices is likely to continue to grow as time goes by, making this problem worse.

I propose:

• The list of ARM designed processor cores becomes a new topic.
• The list of XScale processors is moved to the XScale topic.
• The existing The cores section is replaced with links to these topics, and other architectural licensees and publically announced ARM implementations are mentioned here (but not described in full).

Ptoboley 16:54, 4 January 2007 (UTC)

iPhone?

On January 11, 2007, 195.189.142.189 added the Apple iPhone under ARM1136J(F)-S.

As far as I'm aware, this is speculation. --67.127.191.48 15:36, 12 January 2007 (UTC)

You are so correct. It isn't even confirmed that it is ARM at all, even if it is highly likely. -- Henriok 00:55, 14 January 2007 (UTC)

bug in example C code

The example C code for Euclid's Algorithm is basically: while (i != 0) ...; return i; which will always return 0. —Preceding unsigned comment added by 24.64.160.145 (talk) 18:05, 2 October 2007 (UTC)

bug in example ASM code

Ri should be compared to Rj instead of 0 the line loop CMP Ri, 0

must be changed to loop CMP Ri, Rj —Preceding unsigned comment added by 213.134.106.125 (talk) 10:43, 23 November 2007 (UTC)

I do agree, I have even noticed that a week ago -- but in doubt, decided to verify. Note that the code was initially correct in this article, someone changed it (look at the history). Therefore I just updated the article. 201.21.88.110 (talk) —Preceding comment was added at 06:03, 5 December 2007 (UTC)

New topic for Jazelle?

The section on Jazelle has recently been greatly expanded, leaving the "design notes" section unbalanced. I would suggest this is moved to a new topic, with a link and the original brief description left here. Ptoboley (talk) 17:29, 21 February 2008 (UTC)

Yup, please do; it was something I picked up in my edit summary from a month ago: "13:55, 16 January (→Jazelle: Further editing/rewrite/expansion... could almost do with its own Jazelle article now.)" —Sladen (talk) 18:01, 22 February 2008 (UTC)

Strange sentence

The sentence

Access to registers r8-r15 (where the Jazelle/DBX Java VM state is held) and the ability to branch to handlers—small sections of frequently called code—commonly used to implement a feature of a high level language, such as allocating memory for a new object

is unclear. Is access forbidden or is it enabled? Something appears to be missing. --12:42, 20 April 2008 (UTC)

Yes, a well-intentioned edit[1] created this mystifying sentence in 2007 (!).

Most Thumb mode instructions only allows access to r0-r7 -- this ThumbEE mode seems to add instructions that use r9 and r10.

I made a small edit and added a reference to more details -- did that fix the problem? --68.0.124.33 (talk) 22:37, 22 April 2009 (UTC)

Jazelle

The article states, "The published specifications are very incomplete, being only sufficient for writing operating system code that can support a JVM that uses Jazelle. The declared intent is that only the JVM software needs to (or is allowed to) depend on the hardware interface details. This tight binding facilitates that the hardware and JVM can evolve together without affecting other software. In effect, this gives ARM Ltd. considerable control over which JVMs are able to exploit Jazelle."

Do we need a citation for the claim that published specifications being very incomplete, or at least an explation of why?

It says "only sufficient for writing operating system code that can support a JVM that uses Jazelle". That sounds like quite a decent amount of functionality to me. The spec gives you enough information to hook a JVM which supports Jazelle, into the system. Surely if there are any issues here it's with the JVM.

Then we come to "The declared intent is that only the JVM software needs to (or is allowed to) depend on the hardware interface details". Where is this declared?

Finally, "In effect, this gives ARM Ltd. considerable control over which JVMs are able to exploit Jazelle". I really don't see how this is the case though?

Frankly, it reads like an emotionally charged paragraph, with little to support its assertions. What do others think? 80.177.214.113 (talk) 22:59, 16 July 2008 (UTC)

OK, sorry. I've read on a little now and it's a bit more clear. It's not so much that the specification is incomplete, it's more that it's not officially published. As such, 3rd party JVMs cannot guarantee support. I can see how this gives ARM some control, though I'm curious as to why they'd want to do that -- after all, they're in the business of selling hardware chips, not software. Perhaps it's a Sun licensing issue?

I still feel that paragraph could be much better written, however. Any volunteers? 80.177.214.113 (talk) 23:04, 16 July 2008 (UTC)

Yes, it's all a bit strange. The functionality is there, in all those chips, but without any (publicly published) information for how to "turn it on". That information can come from a couple of places; reverse-engineering/good guesswork and research, or from signing an agreement with ARM Ltd (containing money and restrictions). What ARM Ltd have more recently published (through Linux kernel patches) is the bare minimum of how to ensure that OS-level exception handles do not bail out if they see the CPU in an undocumented process state. (Though they won't tell you how to put the CPU into that state!).

Improved wording is always welcome. Please feel do dive in and fix it if you spot where it can be made less emotionally charged. Once again, many thanks for getting involved! —Sladen (talk) 23:39, 16 July 2008 (UTC)

Sophie Wilson

I undid the revision updating Roger Wilson to Sophie Wilson. Having now reviewed WP:MOS#Identity, I've emailed Sophie for her preference and if I don't hear anything back I'll restore the change (to Sophie ...). —Sladen (talk) 22:23, 29 July 2008 (UTC)

Proof?

"Because of their power saving features, ARM CPUs are dominant in the mobile electronics market, where low power consumption is a critical design goal."

Has anybody an proof for this sentence? Have checked the References but didn`t found one.--84.149.149.246 (talk) 11:23, 5 August 2008 (UTC)

Which part of the sentence exactly needs a proof ? 90.36.18.132 (talk) 22:01, 26 September 2008 (UTC)

See WP:VERIFY; everything on Wikipedia should have a source. This sentence as it stands, I think states (or assumes) the following:

1. In mobile applications, low power consumption is important
2. ARM chips are dominant in mobile applications
3. ARM chips are low power
4. Because of ARM chips' low power, they are dominant in mobile

It would be good to find sources to prove all those individual parts. —Sladen (talk) 22:52, 26 September 2008 (UTC)

I think 1 is kind of obvious. And If you would have a citation for 2, then 3 and 4 aren`t important anymore. If a chip is dominant on a market where low power consumption is important, it has to be low power. I had a look at the references, and in deed there is a document saying the ARM chips are dominant in the mobile market, but this document is from ARM Ltd... --217.10.60.85 (talk) 14:35, 14 October 2008 (UTC)

A citation for 2 does not prove 4. Low power is not the only factor required for market dominance. Also, the site (qtronics.net) used as a "reference" for this statement apparently scraped its content from this article. Maghnus (talk) 10:35, 12 January 2009 (UTC)

The selection of ARM by TI for a simple microcontroller probably had little to do with power considerations at the time. The success of TI as the dominant vendor to Nokia, the success of Nokia in consumer mobile phone markets, the support of ARM by the Symbian mobile phone OS, and the success of Symbian in other mobile phones besides Nokia all contributed to ARM's dominance of mobile handsets. No evidence is provided of low power features unique to ARM processors or a causal link between low power features and ARM's dominance. The sentence should be changed.Panscient (talk) 21:47, 30 April 2009 (UTC)

Motorola Rizr Z8

Motorola Rizr Z8 uses an omap2420 SoC (same as N95) which uses ARM1136, why is it listed as using ARM1176?? Y3Ah27 (talk) 21:37, 16 September 2008 (UTC)

It's a wiki, you can fix it directly! Better still, make the change and include a reference citation so that there's no doubt! —Sladen (talk) 22:42, 26 September 2008 (UTC)

T-Mobile G1

The T-Mobile G1 (Qualcomm MSM7201A ARM11) should be added to the chart, yes? Machee (talk) 05:28, 14 November 2008 (UTC)

Still a bug in example code?

In 'ARM architecture#Design notes' the C code will obey the 'else' clause if i <= j, but the corresponding ARM code will only obey the 'else' clause if i < j. Do we need to change 'SUBLT' to 'SUBLE', with corresponding changes in comments? Murray Langton (talk) 11:44, 1 December 2008 (UTC)

As far as I can see, I don't think there's a bug.

• It the C version, the equality test is at the top, therefore the < and >= tests (the latter being the implicit else part) could equally well be changed to <= and > and it would make no difference.
• The ARM assembly version is has a single comparision and three outcomes; A C equivalent to the ARM code would be:

loop:
    {
       int i_is_bigger = (i > j);
       int i_is_smaller = (i < j);
       int i_is_not_equal = (i != j);

       if (i_is_bigger)     i -= j;
       if (i_is_smaller)    j -= i;
       if (i_is_not_equal)  goto loop;
    }

The cunning thing about ARM is being able to selectively not set the flags, allowing the boolean result to last beyond the modification of the comparision inputs (i and j). —Sladen (talk) 12:21, 1 December 2008 (UTC)

Thanks for your explanation. I was only looking at the 'if' statement, without taking into account the context (while) in which that 'if' was embedded. Murray Langton (talk) 12:48, 1 December 2008 (UTC)

Too specialist

The contents of this article are highly specialized; I cannot find a single sentence that states in plain English what ARM architecture is, what its benefits are versus other architectures, why it is used in mobiles, netbooks, etc. I've worked in IT for nearly 15 years and there isn't anything here that explains these things in non-specialist language, if at all. I would expect a clear, non-specialist definition in the first paragraph - certainly somewhere in the first three. As a non-specialist I would appreciate an attempt to provide such a generalist introduction. Thanks. Sneedy (talk) 23:12, 3 June 2009 (UTC)sneedy

I've tried[2] to give a better high-level overview. It would be useful if you'd be able to share any feedback about what you specifically would like to see, or what you expected to find, but didn't. —Sladen (talk) 01:56, 4 June 2009 (UTC)

Slightly dated?

Where do Snapdragon QSD8650, QSD8250, QSD8672 fit into the cpu table? —Preceding unsigned comment added by 216.208.58.190 (talk) 07:23, 19 June 2009 (UTC)

Edit of intro and revert war

i have made major changes to the opening paragraphs/introduction. These were reverted/deleted by someone else. I have now restored them. Here is my justification.

The person who undid my changes did so ostensibly on the grounds that my changes 'removed a whole kilobyte of text'. From this I presume that he/she felt that I am not entitled to make such drastic changes to the article, or to delete such a large quantity of material without asking. I on the other hand maintain that I am absolutely entitled to do so, when the material in question (large though it may be) is either a) factually incorrect or b) not a good way to present or arrange encyclopedic material. In this particular case, both of those are true. In brief, the old material was complete and utter HORSE SHIT.

Firstly, as Sneedy points out above, the old paragraphs were highly technical and completely inpenetrable for anyone who doesn't have a detailed understanding of chip design. Statements like 'the ARM is notable for introducing the concept of conditional execution of all instructions, not just branch instructions' 'for allowing optional writing of the condition flags' 'and for lack of an implicit stack' are highly specialized statements that are meaningless for anyone who isnt extremely well versed in assembly programming/hardware design, and have no place in the articles introduction.

The opening section of an article like this should provide a brief overview and explanation of the topic for the reader, particularly one who is unfamiliar with the subject. Especially in the case of articles on wikipedia, which are primarily used by non specialists looking up terms they are have heard but dont understand, or seen mentioned in a news article and wanting to know more, the opening section should be concise, simply and clear, using plain and simple language that gradually introduces people to the core concepts and information, and then invites people to read on to learn more. The old opening was just terrible, and must have been extremely off-putting for anyone who'd just opened the page up because that heard the ARM mentioned in a story about the iphone or something, and wanted a bit of background. It drowned them in jargon, whilst at the same time failing to give them the information they actually wanted, which was what the arm is what it does, who makes it and what its used for. It was this information that I included in my introduction, and if you read it now I think youll agree its a fairly good setup, and lets people know why, where and how the ARM is used, as well as briefly explaining the IP-licensing business model behind it, as well as listing some prominet examples of arm cores and chips. In short, My first reason for restoring my version of the opening is that its just plain better, and however much of other peoples work got deleted in the process is irrelevant, since it really didn't deserve saving.

My second reason for restoring my work and completly deleting the '1k' of text, is that apart from being inpenetrable to read, the old stuff was completely and utterly WRONG; as in factually incorrect. Most of the technical stuff such as 'it has sixteen registers and a three-stage pipline' etc, were complete BOLLOCKS. Those are descriptions of the features of the original ARM2 chip, circa 1986. They have no relevance whatsoever for an article on the modern ARM architecture, and someone reading the article today would end up utterly confused, and thinking that ARM must have somekind of crazy retro feature set. The fact is that almost all ARM chips of the last ten years or so will have at least a five-stage pipeline, and the latest arm cortex has a 12-stage one, in addition to being superscaler and having countless other features not mentioned or explicable in terms of those paragraphs. The equivalent in terms of PCs would be like writing "the Intel Xeon is a computer chip designed by Intel that has 8 million transistors and supports all operating systems up to windows 98" since those are the features of the original chip back in the 90s. The reader would end up thinking that intel must be crazily behind the times if their flagship processor is only capable of doing those things. In short the old paragraphs were just nonsensical and wierd and couldn't be allowed to continue in an article about a topic as widely in use and discussed by the media as ARM. They were both badly structured and written as well as being wildly inaccurate.

So after that little essay, if anyone still wants to dispute the fact that my version is better, and wants to make a case for the old stuff, then their welcome to try, but please discuss it first here BEFORE deleting/reverting my edits. I am fully confident that any open, general discussion will lead to my version being adopted and the deficiencies of the old ones exposed. 217.42.241.235 (talk) 21:58, 26 June 2009 (UTC)

completely new instruction set architecture

Is it true that "The Cortex-M3 core has a completely new instruction set architecture, different from previous ARM cores. Migrating legacy ARM7 code to the Cortex-M3 requires a complete re-write of the assembler code."[3] ? --68.0.124.33 (talk) 00:14, 20 September 2009 (UTC)

Thumb-2

Has Thumb-2 been publicly documented by now? I can't find anything detailed, other than a "white paper". Mirror Vax 11:41, 16 August 2005 (UTC)

Yes it is, although you cannot download it. You have to request a CD to receive all the technical documentation (including instruction set format). It's free of charge. --JoetjeF 19:53, 27 August 2005 (UTC)

Thanks. Odd that it isn't downloadable. Mirror Vax 20:44, 27 August 2005 (UTC)

ARM has at times been a difficult supplier to work with. I have personally experienced this when in connection with work I requested information on a product release. They never replied. If you search Google Groups you will find more references on how awkward they can be in releasing information needed for working on their devices. This in contrast with other suppliers in this market.

You can find some information on Thumb2 here: http://www.arm.com/documentation/Instruction_Set/index.html YOu will find an instruction set quick reference card there. The full ARM Architecture reference Manual (ARM ARM) for V6 and V7 is not public yet. --Ashleystevens 12:52, 3 January 2007 (UTC)

As of fall 2009, the ARMv7AR architecture spec can be downloaded (register first) from the ARM website, and it has what looks to be pretty thorough docs for both Thumb2 (in full glory!) and its ThumbEE sibling. That's the combined v6/v7 doc. The version of Thumb2 in Cortex-M series chips is a subset, without SIMD; see the ARMv7M arch spec for a slightly more approachable writeup --69.226.238.251 (talk) 07:12, 17 December 2009 (UTC)

6502 similarity

The "design notes" section states :

The ARM instruction set follows the 6502 in concept, but includes a number of features designed to allow the CPU to better pipeline them for execution.

If this statement could be somehow traced back to the original design team, then it seems to clearly reflect the british heritage of the arm design - I would consider this somewhat of an understatement ;-)

Other than the mnemonic "add", I can think of no similarities between the 6502 and ARM instruction set.

The only similarities that come to mind would not be part of the instruction set, but of the implementation :

• Both the 6502 and the ARM (AFAIK) did not use microcode, but were hardwired.
• Both had a simple two-level interrupt priority structure

I have tried to clarify this in the design-notes section.

However, if anybody does know more about the 6502's influence on the ARM design, please add it back.

Also, I am sorry if the list of features I added are not "encyclopedia-like" enough, but I thought it would not help the readability of a "list of features" if they are incorporated in a block of text.

You are right. Mirror Vax 04:01, 18 January 2006 (UTC)

"ADD", "ADC", "SUB", "SBC". Also, the carry flag is the "wrong way round" after subtraction, the same as the 6502. That is, after subtraction, Carry=0 if a carry occured, and SBC does result=operand1-operand2-(1-carry). Other CPUs (eg, Z80) use Carry=1 and result=operand1-operand2-carry. JGHarston 18:36, 04 March 2006 (UTC)

The influence of the 6502 is over-stated in the article. As you rightly say, it was limited to the assembler syntax, the fact that the processor was pipelined and not microcoded, and the design-goal of good interrupt latency (as I mentioned earlier).

--Ashleystevens 12:52, 3 January 2007 (UTC)

SonyEricsson P990i - PDA phone

This phone needs to be listed. Not sure which processor.

Also other in the series are P800, P900i and newer is P1i

All are PDA touchscreen smartphones..... —Preceding unsigned comment added by 92.29.138.200 (talk) 15:51, 22 November 2009 (UTC)

Archiving

Does anyone object to me setting up automatic archiving for this page using MizaBot? Unless otherwise agreed, I would set it to archive threads that have been inactive for 60 days.--Oneiros (talk) 13:03, 18 December 2009 (UTC)

 Done--Oneiros (talk) 14:50, 30 December 2009 (UTC)

Mixing core and CPU itself

>>>ARM processors are developed by ARM and by ARM licensees. Prominent examples of ARM Holdings ARM processor families include the ARM7, ARM9, ARM11 and Cortex. Examples of ARM processors developed by major licensees include the DEC StrongARM, Freescale's i.MX, Marvell (formerly Intel) XScale, NVIDIA's Tegra, ST-Ericsson Nomadik, Qualcomm's Snapdragon, and the Texas Instruments OMAP product line

ARM Ltd. does NOT develop processors, it only develops cores, which are applied in CPUs by licensees. —Preceding unsigned comment added by 79.139.245.9 (talk) 06:49, 11 January 2010 (UTC)

Apple A4

FWIW, arm.com points at an article[4] from a month ago noting the "quad-core" Apple SoC. —Sladen (talk) 22:30, 29 January 2010 (UTC)

That article states:

"We believe it to be a seven-inch HDTV player […]" said Rick Doherty, principal of market watcher Envisioneering.

Wrong, not seven inches.

Doherty expects the rumored Apple system will initially support 720-progressive resolution, use Wi-Fi instead of 3G.

Wrong, not 720-progressive and has 3G.

Doherty believes the mobile system is the target for a custom quad-core mobile ARM processor being designed by the P.A. Semi team.

Pure speculation, no sources cited.

"If the P.A. Semi people could produce a product for apple that fast, I'd be surprised," said Nathan Brookwood.

Same article, opposite opinion.

It was all speculation, different analysts had different theories but unfortunately we can't use this article as a source. Mushroom (Talk) 22:44, 29 January 2010 (UTC)

ARM architecure Licensees

Why isn't the any mention of architecture licensees in the ARM licenses discussion. Marvell and Qualcomm license the architecture allowing them to make their own cores from scratch. —Preceding unsigned comment added by 70.243.119.81 (talk) 22:08, 31 January 2010 (UTC)

OMAP as a branch?

The sentence stating that Marvell XScale and TI OMAP are important branches from ARM bothers me. XScale is certainly a branch because, although it is based on ARM's architecture, it was modified by Intel/Marvell to be its own entity. To my knowledge, TI has never modified the ARM architecture for use in OMAP. I agree that OMAP is a very important licensee of ARM, but they are not a branch in the same sense that XScale is.

I want to just modify the sentence, but have a feeling that it might be controversial to someone out there so I'll put it here first... —Preceding unsigned comment added by Cashannon 19:35, 7 November 2007 (UTC) hello！ I am a newcomer here —Preceding unsigned comment added by 116.228.253.165 (talk) 17:04, 8 April 2008 (UTC)

Most OMAPs use ARM cores with modifications only for integration with the rest of the chip: power management, secure boot, and so forth. The only exception of which I'm aware is the ARM925T, which I'm told had some core modifications from TI ... which caused problems, hence the next iteration of the OMAP1 product line used ARM926ejs. Nowadays ARM has this "lead partner" thing, and TI is "lead"/trailblazer/bloodied by Cortex-A8 and Cortex-A9 productization. --69.226.238.251 (talk) 07:24, 17 December 2009 (UTC)

re: edit on October 30: Originally called "Advanced RISC Machine"?

The historic meaning of the 'A' in ARM seems to be up for debate. Certainly the current owners of the ARM IP are Advanced RISC Macchines, Ltd. And I have no doubt but that they have chosen to use the 'A' in the ARM acronym to stand for "Advanced".

The first paragraph of the article now states that the 'A' _originally_ stood for "Advanced". But to my knowledge that isn't true. I've always been under the impression that the 'A' _originally_ stood for "Acorn". Should the paragraph be reverted back to the original "Acorn" form? Or would it be better to reword it entirely to omit the "originally" part?

The same person seems to have modified a hyperlink in the History section. The first sentence phrase "research project" used to point to "Acorn Computers Ltd#New RISC architecture". This is a valid entry in the Acorn Computers article. Now it points to "Advanced Computers Ltd#New RISC architecture". That's a dead link.24.222.2.222

ARM initially stood for Acorn RISC Machine; later for Advanced RISC Machine. Currently the company is actually called ARM Holdings, i.e. ARM is not a shortening of the company name, but rather is the entire company name. Mike1024 (t/c) 00:02, 8 November 2007 (UTC)

most used CPU architecture in the world?

No, not if you include 8/16-bit microcontroller applications (PIC, 8051, MC6800, etc.) In terms of volume (not revenue, of course), 8/16-bit microcontroller still hold the lead in 'dumb' consumer appliances (alarm clocks, radios, microwaves, etc.) This will not change anytime soon. 32-bit architectures (like the ARM) are overkill for these devices.

Most prevalent 32-bit architecture would be true. --Ashleystevens 15:23, 3 January 2007 (UTC)

Rewording NEON

Article states that ARM core with NEON can execute MP3 decoder in 10 CPU MHz. This is silly. What is 10 CPU MHz? Does that mean it runs in 10 CPU clocks? Or it runs in less than 10ms? This needs clarification.

I don't think it's uncommon to reference that "such-and-such a process runs in X MHz on processor Y", particularly in the embedded world where clock frequencies are more scalable. It gives a general indication of how much of the CPU's bandwidth the task takes. Ptoboley 15:27, 31 July 2006 (UTC)

silly? It is a widly spread habit in the industry. It denotes that a "typical" mp3 decoding application "requires" 10Mhz to keep in sync. Any less, and the CPU will not get the job done, any more and the CPU is idling. True, the many parameters (between ") need clarification, but the wording is clear by itself.

We could do with some more numbers though. a 320bit stream? worstcase 10Mhz? on which stream?217.140.108.2 15:32, 12 April 2007 (UTC)

Additionally, the article says "can run the GSM AMR (Adaptive Multi-Rate) speech codec at no more than 13 MHz." -- the literal meaning of this sounds like it is the opposite of what is intended. If it's clocked at 14 MHz (which is more than 13 MHz) it can't decode AMR? Ridiculous if true, bad use of marketing-speak in the article if not true.

If it runs AMR just fine at speeds over 13 MHz it needs to be changed to something like "at 13 MHz" or if we MUST be dramatic about it, "at only 13 MHz". 76.27.126.37 (talk) 05:53, 22 April 2008 (UTC)

80286 alternative for ACORN

Is it the case that Acorn Computers were refused access to the Intel 80286? According to a near contemporary commentary by Dick Pountain that I recall reading, the company's technicians were unhappy to adopt the 80286 because its interrupt performance was markedly inferior to that of the 6502 and they regarded high interrupt performance as essential to support the direction they were taking in their system software. Alan Peakall 17:32 Nov 15, 2002 (UTC)

They were refused access. I believe they wanted to hack the design to suit their purposes, and Intel didn't want to licence those rights unto them.

Back in the year 2002, more precisely on 8th August 2002, I posted in the newsgroup comp.sys.acorn.hardware the following message:

Hi all,

due to some investigations I got back to the very early days of ARM
processors and found several stories about the reason why Acorn did
start the development of the ARM processor:

- The first says, that Acorn did ask Intel for the 80286 processor and
  Intel refused to deliver it (but why should they?)

- The second says, that Acorn wanted to base its own processor on the
  80286 design - and Intel couldn't deliver

- The third says, that Acorn did check out all the available processors of 
  that time and found that none of them was good enough for their new
  machine (which later became the Acorn Archimedes)

Can anyone around here tell _for_sure_ what really went on?

To this posting I received a private mail on the very same 8th August 2002 from Sophie Wilson with the following statement:

The last. The first two are kind of amazingly wrong in that we had working
286 second processors (and 32016 second processors).

(The 80286 "second processor" is also mentioned by Chris Whytehead, when describing the ABC 300, thus claiming that they were refused access to the 80286 definitely doesn't make any sense.)

Matthias Seifert 79.214.78.140 (talk) 11:54, 25 December 2007 (UTC)

Initiation of the ARM project

It is said that Acorn wanted to have access to the 286 core and use it on their own silicon. Intel were not impressed. A story in the Grauniad says:

Hauser believed that to design a really efficient computer, you also needed to design the chip inside it. Originally, Acorn planned to use Intel's 286 chip in its Archi-medes computer. But because Intel would not let it license the 286 core and adapt it, Acorn decided to design its own.

An Electronics Weekly article quoted Hauser as saying

"I asked Intel for the 286 core and they said we're not interested in selling cores - only microprocessors."

However, I suspect that that particular story was fabricated by Hauser as a post-hoc validation of his "IT Guruship" & therefore a justifcation for his venture Capital "prowess".

The Wikipedia articles on Acorn and the ARM make the decision to design a processor sound as though it was made for mundane reasons. The reality is much more intersting. It very much seems like Acorn was a playground for some very talented people (Wilson & Furber being the most easily identified) and the Acorn RISC Machine seems actually to have been developed for the simple reason that the engineers wanted to play and, more importantly, were able to play. For example, in an Acorn User article on the history of acorn, it is said that:

The most advanced division of the Advanced Research and Development section was, during 1984, working on a new processor chip incorporating the idea of a reduced instruction set - an idea that was at that time quite revolutionary.

Even within Acorn few people knew about the project - it took Roger Wilson some time to tell his boss, Hauser, what he was doing, let alone anyone else.

This ability to "play" was in a large part permitted by the (chaotic?) management structure at Acorn in the early-80s. In designing the replacement for the BBC (inc Master), the Acorn engineers had access to the TUBE. This allowed them to test processors in a fairly unique way. It does seem to be true that they were unhappy with the interrupt responses of the 68000 in particular. In the Acorn User Acorn history, Roger Wilson is quoted as saying that

The jump to 32-bit was a result of all the work on second processors for the BBC micro. By using the Tube, we were the only people in the world who could use the same operating system with all the different processors. We could rate their performance. We ran through every single processor - and the 8086 and 68000 chips that we tried were really slow. They couldn't even keep up with the Tube protocols that the 6502 managed.'

The Electronics Weekly article gives a good idea of what was actually going on when the ARM was born.

68000

Very interesting article at Real World Technologies:

Acorn briefly considered the Motorola 68000 but rejected on the ground that its inclusion of long running uninterruptible instructions, like divide DIVS, would have more than doubled its interrupt latency compared to the 6502. This meant that expensive direct memory access (DMA) hardware would have been needed to support fast input/output operations.

32016

Mark Smotherman's web page reports Sophie Wilson:

The 32016 first exposed the value of memory bandwidth to Steve Furber and I, showed how making things over-complex led to exceedingly long implementation times with loads of bugs in the implementation, and showed that however hard you tried to approach what compiler writers claimed they wanted, you couldn't satisfy them (no, I never did use a VAX). And an 8MHz 32016 was completely trounced in performance terms by a 4MHz 6502...

Lmno 22:21, 27 Nov 2004 (UTC)

I don't believe the story that said that Acorn wanted to license the 286 core for the simple reason that the business model of licensing cores had not been established at that time. I suspect that Herman may been mixing up the story of Active Book. It is true that poor interrupt latency was one of the main reasons that Acorn could not adopt cores such as the NS32016 or 68K. The BBC micros used pseudo-DMA (ie interrupts) for handling the disk, and the long interrupt latency of the micro-programmed cores would have necessitated a DMA controller, which would have increased costs unacceptably. Going back to Active Book, the ARM2as, the first fully static (and therefore low-power) ARM was created for the Active Book, Herman's start-up. But when AT&T acquired it they were forced to switch to the Hobbit processor. About the same time, Apple switched from Hobbit to ARM.

--Ashleystevens 12:47, 3 January 2007 (UTC)

Piccolo

ARM created a DSP coprocessor to ARM called Piccolo. The architecture was fairly innovative, for instance by using the ARM as data(address) generator and instruction feeder. While information is svailable on the net it is sparse. Stranger still it is nearly absent on ARM's own web pages. My own attempts to get more information and a license when it was announced was met with a silence. An addition on Piccolo would complement the other coprocessors listed and would hopefully explain what happened.

— Preceding unsigned comment added by 85.164.112.1 (talk) 16:52, 1 July 2005 (UTC)

XScale and ARM926 "more numerous"

I suspect the text "XScale and ARM926 processors are ARMv5TE, and are now more numerous than the StrongARM, ARM925T and ARM7TDMI based ARMv4 processors." was intended to apply to the Windows smartphone market?

According to ARM figures , in Q2 2006, 36% of royalties were accounted to ARM9-family, of which 11 percentage points were ARM926EJ-S. No comment is made on how the other 25 points of this 36% are split (e.g. between v4T ARM9TDMI-based cores and v5TE ARM9E-based cores), or how the 64% splits between the other core families (i.e. ARM7, ARM9, ARM10, ARM11, SecurCore, and Cortex). Ptoboley (Ptoboley) 15:55, 4 January 2007 (UTC)

PS3 Date Controversy

It has been suggest that older verions of the ARM SYSCON cpus had errata such that the CPUs believed incorrectly that 2010 was a leap year and may be partially responsible for non slim versions of the Playstation 3 not being able to function properly beginning on 3/1/2010. "The ARM SYSCON CPU that is used to power up the front panel of the ps3, that is responsible for doing things like sleep mode, eject, RTC etc. Is an old batch that sony picked up from the shelf like other manufacturers that has that calendar year bug regarding feburary 29th on certain periods. Causing the ps3 system clock and the real time clock to desync, messing up security measures like Digital Rights management software and sometimes games that relies on clocks for whatever reason. As well as signing up to the playstation network… This CPU is always on even when your PS3 isn’t plugged

This is the one of the same type of CPUs that is powering up mobile devices like zune and blackberries, they have been affected with this bug, so they done some software patches. A syscon update can also fix this problem

The Slims ps3s aren’t affected because they use a newer up to date revision on the syscon cpu that fixes this bug.

[WARNING: will void your warranty, may be best to wait for official solution from Sony] - A quick way to fix this is to remove the RTC battery for at least 5-10 min and plug it back in, you will see the date and time reset, and voila… "}}

Obviously, by doing this I've started a small scale edit war. So we need to find a consensus. My main opinion is that this is not relevant to the article - the ARM microcontroller is just a building block of the playstation 3 (and a gazillion of other devices). If this section has a place, I think it is on the PS3 article itself. Cochonfou (talk) 06:58, 3 March 2010 (UTC)

• I agree, but someone please fix the horrible grammar first. 67.64.66.99 (talk) 11:56, 3 March 2010 (UTC)

67.214.81.162 (talk) 03:22, 5 March 2010 (UTC)I was the one that added the original section and have decided not worth the effort to fight for this as it did last only one day. It was an ARM issue that caused the problem and downed 20 million PS3s and the architecture deserves the hit in some way. As for grammar I agree. I copied a widely available description of the problem by some engineer who wrote hurriedly over IRC (who might not speak english natively). The issue was just pathetic all around and shows the state of QA in this megacorp outsourcing era.

GNU/Linux

This article uses the expression GNU/Linux, is that really necessary? I'm aware of the GNU/Linux controversy, but I didn't get the impression that wiki had decided to switch to that naming convention. Tweisbach (talk) 09:17, 18 March 2010 (UTC)

Moreover Android OS is generally not considered GNU/Linux, since there is little (if any) GNU userland. Even the C standard library is non-GNU. 89.139.172.33 (talk) 21:16, 24 April 2010 (UTC)

iPhone ARM Confirmation?

An iPhone was disassembled mere hours after the official release. It does in fact seem to have some sort of ARM processor. I'm not an expert, but I thought I'd pass on the info.

The iPad has an apple-branded ARM cpu in it, as per http://www.bit-tech.net/news/2010/01/28/apple-creates-own-cpu-to-power-ipad/ —Preceding unsigned comment added by 129.97.195.236 (talk) 17:01, 28 January 2010 (UTC)

That article cites various articles which are purely speculative. I think we can be pretty much certain that the A4 is an ARM-based device but there's nothing that makes that a definite statement yet. We certainly don't know for certain which ARM core is in it. Bjrice (talk) 10:41, 29 January 2010 (UTC)

If it were a stock chip, wouldn't it say ARM on it, and not have Apple's branding and codename on it? I'm using ( http://www.ifixit.com/blog/?p=2258 ) as my primary source here. —Preceding unsigned comment added by 74.112.44.121 (talk) 14:46, 29 January 2010 (UTC)

Unfortunately that evidence is inconclusive because Apple is known to put its own branding on various third party chips for no other apparent reason than to make them more difficult to be recognized, as seen here. Mushroom (Talk) 17:07, 29 January 2010 (UTC)

Furthermore, IIRC the markings on the devices used in the iPhone and iPod touch don't mention ARM either. There's no such thing as a "stock" ARM CPU as the CPUs are always provided as core designs that are incorporated into SoCs. Bjrice (talk) 22:14, 31 January 2010 (UTC)

New information points towards the A4 being a heavily modified Cortex 8 [5] I am the same user who started this paragraph. —Preceding unsigned comment added by 173.33.44.9 (talk) 15:16, 1 March 2010 (UTC)

I'll admit I didn't read through all of the comments but I'll just make it clear. The iPhone and iPad run on a similar ARM-based system. Th Apple A4 SoC has a Cortex A8 CPU. The design of the A4 itself has many similarities with the Samsung Hummingbird, but the Hummingbird has a faster GPU and double the RAM. TMV943 (talk) 04:58, 9 September 2010 (UTC)

Application info

I think it's all over the place, how about we just shorten it to SoCs that implement the CPU instead of listing every device that uses a SoC that uses the CPU TMV943 (talk) 04:59, 9 September 2010 (UTC)

Yes, I was thinking a similar thing myself. Soon the list will become far too big and unwieldy to manage, nobody will be bothered to read it and it will lose its value. HumphreyW (talk) 05:14, 9 September 2010 (UTC)

Cortex-A15 does not exist

The news from ARM about the new Cortex-A15 core is all well and good. But please don't insert it in the article. The CPU does not yet exist, it is purely speculative and subject to change or cancellation. Most of the technology that is required to manufacture it is not yet available either. Wait until one of the licensees actually manages to make one and proves that it is possible before inserting it into the article. HumphreyW (talk) 01:24, 11 September 2010 (UTC)

I strongly disagree with this. Future products are allowed, and there are examples of such. In this particular case, being as ARM Holdings licences out technology to manufacturers, this exists now in the context of "their" products (assuming the A15 is actually ready for licensing?!). Although Wikipedia:What's in, what's out is irrelevant, it contains the applicable wisdom...

Future products that meet all four of the following criteria: In. Dpbsmith (talk) 8:48 pm, 16 August 2004, Monday (6 years, 27 days ago) (UTC+1)

• are so notable as to be topics of legitimate mainstream news items;
• are the product of companies that are so notable that they already have their own Wikipedia articles;
• have a large quantity of rich, interesting, publicly-known detail, justifying an entire article (rather than a mention in the article about their developer);
• are of such economic importance that Wikipedia's mention cannot in itself have any significant promotional effect, and cannot credibly be the motive for inserting the article. That is: Wikipedia is not a vehicle for creating "buzz."

Lastly, on a practical level, you would probably need to protect this page to prevent inclusion. Widefox (talk) 13:44, 11 September 2010 (UTC)

How would you suggest it be mentioned in the article? I think the existing table is not the right place because that would suggest that it is a current product. Perhaps a new section for upcoming product(s) with the boiler-plate notice about being a future prediction and is subject to change etc.? HumphreyW (talk) 14:06, 11 September 2010 (UTC)

I can't easily find any products using the Cortex A5 core, which is also in the table. Should we drop that, too?

I'm a little torn (and biased, since I put in the reference to the A15). On the one hand, every time ARM (or Intel) issues a press release, that doesn't warrant inclusion into the article. On the other hand, the A15 is real, even if it's not in silicon yet. TI has announced that they are the first licensee [6]. Notice it doesn't say "will be" the first licensee, it says "is." It has to exist in some form or another; you can't license something that doesn't exist at all.

Since the A15 is a major step for ARM, it should be mentioned in the article. Perhaps not in the same table, as HumphreyW says, but it needs a mention. Any ideas where to fit in "future products?" Pfagerburg (talk) 01:24, 13 September 2010 (UTC)

Yes, there are licensees but that doesn't mean anything until they actually make it. It is all just marketing bluster. Besides, what is the rush to put it in the article? Can't we just wait until products start being sold? Speculative products nearly always end up different than what is planned and I think it would be better to just wait. We have no need to help out ARM with their advertising campaign, they are big enough to handle it themselves. Wikipedia is here to provide a reference, not to help generate press coverage.

But regardless, if there is such a strong desire to put it into this article then please put it outside of the main table and make it very clear that the device is purely speculative. HumphreyW (talk) 01:57, 13 September 2010 (UTC)

As mentioned above, is there any *real* Cortex-A5 silicon out there? So why keep Cortex-A5 in the table then? As of today, I don't see any difference between A5 and A15. So if we take an integrist view on this, let's be consitent and either keep both A5 and A15 or remove them both. —Preceding unsigned comment added by 88.170.80.185 (talk) 07:31, 15 September 2010 (UTC)

I would suggest that if the A5 also does not exist then it should be removed. Indeed, since there is no references for a real product, I will remove it now. Later if someone has a reference then it can be added back. HumphreyW (talk) 08:19, 15 September 2010 (UTC)

* 1. Future products are allowed, period

• 2. It is a current product anyhow!!! ...from ARM Holdings (i.e. the licensable intellectual property is the product)
• 3. I see no reason at all to be hung up on shipping products (show me the wikipedia guideline / reasoning / threshold is that?), or actual manufacture of silicone - should we censor Leonardo da Vinci's Helicopter design?
• 4. last thing I knew, the "future products" tags were deprecated
• 5. I repeat - I like the wisdom I quoted above as common sense for inclusion in articles

Widefox (talk) 11:24, 15 September 2010 (UTC)

It's not determinative, of course, but it is worth noting that there are dedicated WP pages for Intel microarchitectures as far down the road(map) as Haswell, mooted to ship in 2013 and seemingly a lot vaguer than A15 is at present. --RW Dutton (talk) 02:11, 26 September 2010 (UTC)

developed by arm or arm licensees???

This is I think every so slightly wrong. I have been looking at opencores.org and they have a lglp softcore openrisc 1200 which is sort of arm10. Now somehow I doubt there is a arm license involved. Recognize I know nothing, but I did go to this article looking for performance comparisons. Now wikipedia does have some openrisc pages and if you happen to decide it is an arm cpu, then maybe you need to get a link in. Openbsd people sometimes talk about "armish", which maybe applies here. And that might be relevant to the article in a different way. Lazy, but if you care, astar@spamcop.net. 64.130.197.122 (talk) 15:52, 31 October 2010 (UTC)

English language error?

"Prominent examples of ARM Holdings ARM processor families include the ARM7, ARM9" what does this mean? Are there supposed to be some examples of ARM holdings? Robotics1 (talk) 10:05, 31 October 2010 (UTC)

I parse that as 'families of ARM processors [from] ARM Holdings' and I've edited the article accordingly.

I also added the Apple A4 to the list of ARM processors from designers other than ARM holdings, per the refs in that article which reliably confirm that the A4 is indeed based on ARM's Cortex-A8 design (and also uses ARM's AMBA). Cheers, CWC 07:59, 20 November 2010 (UTC)

OpenSolaris is dead

I think we can remove the OpenSolaris link for now. The code is there, but it's not well tested, and since OpenSolaris is declared dead by Oracle, it will be up to the OpenIndiana guys to continue the port, and I don't think that'll happen, since OI focuses primarily on X64 and not even Sparc. Rkarlsba (talk) 16:26, 23 November 2010 (UTC)

XScale cores

I'm having difficulties finding sources which describe how many different generations of XScale cores there are, and which XScale devices have which cores. So far, this is my understanding:

• Original XScale core: 32K/32K L1 cache, possibly same as StrongARM SA-2 core under development when StrongARM technology was acquired by Intel? Used in PXA25x/26x, presumably also 802xx, IXC1100 and others?
• Bulverde: second generation core(?), "Wireless MMX" and "Wireless SpeedStep" added. Used in PXA27x, others?
• Monahans: presumably as described in 3rd Generation Intel XScale Microarchitecture Developer’s Manual [7]. L2 cache added, L1 cache tweaks, MMU changes, "Wireless MMX 2" extensions. Used in PXA3xx, others?
• The IOP348 is described [8] as have a "fourth generation" XScale core - not sure if this applies to other IOP34x (or indeed any other) devices, nor what is different about this fourth generation.

Any corrections/clarifications/additions appreciated. Letdorf (talk) 13:36, 17 November 2010 (UTC).

The original XScale core was not the SA-2 core. The SA-2 was not finished when Intel acquired StrongARM, and its design team left opted not to join Intel. Intel could not complete the SA-2 without any its original engineers so a new team was assembled to design a new ARM core, staffed by engineers who had worked on the i860 and i960. I believe I read about this in the Microprocessor Report and EE Times. Rilak (talk) 03:28, 20 November 2010 (UTC)

Presumably then, the "SA-2" referred to in this article is not same as the DEC SA-2? Regards, Letdorf (talk) 12:41, 22 November 2010 (UTC).

Actually, now that you mention it, I can't remember if DEC had ever called its SA-1 successor the SA-2. I don't have the time to research the matter, but I did find the MPR reference that I mentioned in my previous comment — it's an editorial by Linley Gwennap titled "Compaq, Intel Fight Digital Brain Drain" in the 26 Oct. 1998 issue. It does not mention a SA-2. Additionally, your edit to StrongARM that removed reference to a SA-2, based on EPW 46, might need further research, IMHO. My interpretation of the relevant statement in EPW 46 is that Intel did not refer to the SA-2 by that name in its presentation at the MPF. It's still called the SA-2, unless the SA-2 was a creation of the press. I'll look into it if I have time. Regards, Rilak (talk) 01:31, 24 November 2010 (UTC)

Yes, we probably need to find more sources to confirm or deny the official use of the "SA-2" designation by either DEC or Intel, but the EPW reference doesn't really prove anything. Regards, Letdorf (talk) 12:47, 24 November 2010 (UTC).

Products

It should be noted that many manufacturers do not make the components of their product public. I see many mistakes there, but I cannot correct them, because I have received my information confidentially. I don't think anything should be listed there without a clear reference where the information came from (A photo of the opened device showing a clearly marked circuit would of course be an excellent reference)

83.150.95.137 (talk) 12:48, 23 November 2010 (UTC)

Yes, if this information can't be found in reliable sources, then it shouldn't really be here. Letdorf (talk) 13:04, 23 November 2010 (UTC).

The clutter probably needs to be reduced to most notable application examples. As for confidential information, I don't see how correcting most obvious mistakes can do any harm, even if they cannot be attributed to sources yet. --188.123.231.4 (talk) 16:01, 28 November 2010 (UTC)

Fun Fact

ARM7 and ARM9 Are used as the Nintendo DS CPUs

--ECat200 (talk) 09:56, 15 December 2010 (UTC)

The Inquirer article on ARM history

Found an article (interview with Sophie Wilson) that might add some interesting colour to the history of the development of the ARM architecture. I'm leaving the reference here in case somebody might be interested in fleshing out history section of this article. Of particular interest is Sophie's comment that on the first test run of the ARM1 a broken track on the circuit board forced the chip to draw power through two protection diodes. This was not discovered until Steve Furber took a multimeter and started taking current measurements. Significant because it highlights ARM's strength in power efficiency. --LoneRifle (talk) 12:23, 7 January 2011 (UTC)

http://www.theinquirer.net/inquirer/feature/1687452/birth-world-beater

"ARM cores" table

This tables has got quite unwieldy due to the large lists of applications for each core. I suggest splitting the applications off into a separate table, to give a more concise and digestible overview of the ARM architectures versions and cores. Also, I'm not sure if all the XScale SoCs really need separate entries in this table - do these really all use different core implementations? Letdorf (talk) 12:59, 12 November 2010 (UTC).

This table is an excellent candidate for WP:Splitting. It would fit perfectly in Category:Lists of microprocessors. Both the main article (currently 65kB) and the table would be better off as separate pages. - Frankie1969 (talk) 09:51, 13 November 2010 (UTC)

The articles is very long, and might do good to pull the table. The clock (speed) column isn't very helpful because each IC vendor has a different maximum clock, and after installed on a PCB it might run at another clock rate. I think the right column should be split into IC Chip and Application, because currently there is a mix of both in the same column, and I think both are important information. Maybe it would be better to create another table that just lists the left 3 columns then an application column??? Sbmeirow (talk) 22:03, 13 November 2010 (UTC)

Yes, I agree we should differentiate between SoCs/ICs and end-user products where applications are concerned. I think we should still have some kind of table in this article, at least an overview of ARM architecture versions and the differences between them. Letdorf (talk) 14:22, 15 November 2010 (UTC).

Thanks to whomever split the table!

First table - We need to cleaned up the XSCALE rows (can we merge any?), and SPEED column (simplify or similar format?).

First table - We need to add a new instruction column for ARM, Thumb, Thumb2, ...

Second table - We need to split the 2nd column into IC (2nd column) and Application (3rd column).

How do you prevent the auto wrapping at the dash? I removed the '/' between some part names, but then after the column got narrower, then wikipedia did an auto wrap at the dash and other characters. If you know how to fix, then please do it.

Sbmeirow (talk) 20:21, 16 November 2010 (UTC)

I would like to see the tables with the following column order. The * means new column. Opinions?

I would like the Features column move to the right, and the speed column changed to a MIPS/MHz and maybe a max speed??? Opinions?

1ST TABLE: | ARM Family | ARM Architecture | ARM Core | Instruction Set(s) * | Cache (I/D), TCM, MMU | MIPS/MHz | Features |

2ND TABLE: | ARM Core | IC Families * | Applications * |

Sbmeirow (talk) 20:33, 16 November 2010 (UTC)

If you stand back and look at this article as a big picture, one notices two things...lots of tables...and that descriptions of key subject matter like architecture and other features are described below the table, which is after a person comes across the acronyms in the table. Thus should the tables be moved further down into the article??? Since the 2 tables are so large, should the 2nd table 'Example applications of ARM cores' be moved into a new article??? Some things to think consider and discuss. By the way, thanks for all the excellent work! Sbmeirow (talk) 22:15, 1 December 2010 (UTC)

I support the proposal to spin out the table into its own article. Jakew (talk) 12:41, 25 January 2011 (UTC)

I support too the proposition. Freewol (talk) 15:50, 3 February 2011 (UTC)

WP:Be bold...just do it. :-) 67.101.7.182 (talk) 20:22, 15 March 2011 (UTC)

 Done at List of ARM microprocessor cores. (Proposed name slightly revised to match others in the category.) I'd suggest the inbound links anchored to the table be reviewed (and will start this myself) before paring down the ARM architecture#ARM cores section per WP:SUMMARY. --Trevj (talk) 11:01, 13 June 2011 (UTC)

I decided this had better be done at the same time, to avoid content forking. --Trevj (talk) 11:31, 13 June 2011 (UTC)

There's also a redirect at ARM core, which may help. Separate redirects to individual cores without standalone articles could also be created (tagged via {{R to list entry}}). --Trevj (talk) 11:11, 13 June 2011 (UTC)

Regarding the table at ARM architecture#Example applications of ARM cores, the split tag can possibly be removed, if I've understood correctly. --Trevj (talk) 11:28, 13 June 2011 (UTC)

Actually, IMHO, the table of example applications is/was a better candidate for splitting out into a separate article than the list of ARM cores. Letdorf (talk) 19:26, 13 June 2011 (UTC).

Apologies if I missed the point... or perhaps both tables should be split out. If you think it's best, then bring it back in or I'm happy to rectify the issue myself if preferred. Thanks. --Trevj (talk) 20:06, 13 June 2011 (UTC)

Feel free to split out the example applications as well if you want. Unfortunately, I don't have time to contribute right now. However, I do think it would still be useful to have something like a brief list of the ARM core families in this article, without it going into the details included in the table you've just split out. Regards, Letdorf (talk) 20:22, 13 June 2011 (UTC).

OK, will give it a go with the other table. As for the brief list, I'm not really best qualified to write that. I can probably include a few meaningful sentences some time soon though. --Trevj (talk) 20:30, 13 June 2011 (UTC)

I don't know whether to compose the brief list from the 'ARM Family' or 'ARM Architecture' column. Perhaps simply listing ARMv1 -> ARMv7 would be sufficient. We should be wary of content forking, so I'm reluctant to include wikilinks to ARM7, etc. This would lead to a maintenance headache. --Trevj (talk) 08:51, 15 June 2011 (UTC)

As for the other table, I'll leave that until this split is tidied up. But that needn't stop anyone else from going ahead and doing it. --Trevj (talk) 08:53, 15 June 2011 (UTC)

I'm not sure when it will occur, but I would like to see the table in the "Example applications of ARM cores" section be pulled out into another article, similar to how the other table was moved. This table make the article look very messy. • Sbmeirow • Talk • 20:51, 15 June 2011 (UTC)

It won't be that difficult to do, although wil require care and take a little time. Having a look at the edit history and referring to WP:SPLIT / WP:CWW should set you on your way if you fancy giving it a go yourself. Otherwise, I expect I'll get to it shortly. --Trevj (talk) 08:46, 16 June 2011 (UTC)

 Done A few examples have been retained within the section in this article, and are currently presented as a bulleted list. However, it may be better to present as prose, which could discourage the list being extended too much - leading to a CFORK. If the chosen examples are felt to be unrepresentative, then there are probably people better qualified than me to amend things. --Trevj (talk) 13:08, 22 June 2011 (UTC)

That short list is now prose. --Trevj (talk) 05:49, 7 July 2011 (UTC)

History of the Advanced RISC Machine

You are invited to join the discussion at Talk:Acorn Computers#Split-apart. Trevj (talk) 13:57, 6 July 2011 (UTC) (Using {{pls}})

Citation not really needed...

I personally think the "citation needed" for Angstrom and iPodLinux should be removed, as it's pretty common knowledge that they run on ARM. (iPod because some iPods use ARM, Angstrom because that's basically all it run on, I believe...) — Preceding unsigned comment added by 76.173.106.107 (talk) 22:05, 1 September 2011 (UTC)

Most people have never heard of Ångström or iPodLinux (or ARM, for that matter), so I doubt it's common knowledge that they run on ARM. It's probably enough to cite support for a specific device, if it can be shown elsewhere that the device uses ARM. Maghnus (talk) 06:27, 2 September 2011 (UTC)

64-bit ARMv8 announced

Press release here. Jakew (talk) 20:53, 27 October 2011 (UTC)

Here are more details:

• Instruction Set ARchitectures (with new 64-bit details)
• ARMv8 Architecture Technical Preview

• Sbmeirow • Talk • 21:47, 27 October 2011 (UTC)

Requesting input

The popularity of the Cortex M0 and M4 are starting to take off, thus it would be easier to pick some direction before having a bunch of tiny articles. Should there be unique articles for each of the ARM Cortex families? Should there be only 3 major ARM Cortex articles instead, and redirect all sub-flavors to these 3 new articles? Requesting input at Talk:List of ARM microprocessor cores#Discusion for ARM Cortex article overhaul for comments! • Sbmeirow • Talk • 17:15, 5 December 2011 (UTC)

typo in predication para?

"which avoids the branches around the then and else clauses" shouldn't that be "which avoids the branches around the if and else clauses" ? Or am I misunderstanding something. The example just above this statement is if-else Robotics1 (talk) 23:44, 16 March 2012 (UTC)

ARM licensees: soft IP vs hard IP

It would be nice if we distinguished between soft IP and hard IP licensees. Doors5678 (talk) 13:36, 19 April 2012 (UTC)

ARMv8 documentation

Some documentation re the 64-bit ARMv8 instruction set is available here. Jakew (talk) 18:50, 17 March 2012 (UTC)

Most widely used

We have two sources for this statement:

The ARM architecture is the most widely used 32-bit instruction set architecture in numbers produced.

Both sources are ten years old. While I suspect the statment is still true, it would be nice to have an updated source. Kendall-K1 (talk) 17:16, 16 September 2012 (UTC)

Architecture vs family

We throw around the term "family" without ever defining it. It would be nice to have some discussion of what a "family" is, especially since the naming convention (ARMv5 vs ARM5) is confusing. Kendall-K1 (talk) 18:00, 16 September 2012 (UTC)

Article is way too technical to understand

I can't understand 90% of what the article's talking about, I feel as though it was written strictly for the IT crowd. Could someone simplify it for the average reader? Thanks. 70.55.109.152 (talk) 11:36, 6 November 2012 (UTC)

I've expanded the lead to give more context for understanding the significance of ARM. Is that enough? It is a techie subject, there's no getting round it. Chris55 (talk) 14:01, 9 November 2012 (UTC)

Endianness

Did I miss the section about endianness of ARM? Couldn't find it... If someone knows something about that (I don't) please improve the article; it would be nice to know whether it's little, big, middle, or bi, and how that changed across versions. Thanks! 87.153.237.56 (talk) 05:50, 6 January 2013 (UTC)

These are the ARMs I work with (embedded systems). I don't know if the following hold true on, say, an A8 or an ARM6/v3.

Cortex M4:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf

Section 2.2.6

Cortex M3:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/DUI0552A_cortex_m3_dgug.pdf

Section 2.2.6

Cortex M0:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0497a/DUI0497A_cortex_m0_r0p0_generic_ug.pdf

Section 2.2.5

Also see:

http://books.google.com/books?id=vdk4ZGRqMskC&pg=PA137&lpg=PA137&dq=endianness+ARM&source=bl&ots=UKFmtOjZ9C&sig=G1DJ2HFOItftwx824NQOGqZiopM&hl=en

http://stackoverflow.com/questions/4286671/endianness-conversion-in-arm

http://stackoverflow.com/questions/2755171/arm-assembly-converting-endianness

-Guy Macon (talk) 07:01, 6 January 2013 (UTC)

Set in the Program Status Register: "From ARMv6, bit[9] controls load and store endianness for data handling. See Instructions to change CPSR E bit on page A2-36. This bit is ignored by instruction fetches." See ARM Reference Manual A2.5.5. Chris55 (talk) 16:59, 7 January 2013 (UTC)

OS Lists

The current change (well of Dec 12) make it look like Linux now is a desktop os for ARM, but i say variante with Linux kernels are the most common embedded OS:es on ARM. Maybe we should add that back without adding a big list of ARM supporting distribution. Balp (talk) 20:57, 28 January 2013 (UTC)

I am wondering whether the time has come to start listing OSs that don't run on ARM... --Guy Macon (talk) 21:18, 28 January 2013 (UTC)

Errors in the article

In the article it is written that:

"All ARMv7 chips support the Thumb-2 instruction set. Other chips in the Cortex and ARM11 series support both "ARM instruction set state" and "Thumb-2 instruction set state""

But in the "Cortex-M3 Technical Reference Manual" it is written that:

"The processor implements the ARMv7-M architecture. This includes all the 16-bit Thumb instructions and the base 32-bit Thumb instructions. The processor cannot execute ARM instructions'."

So Cortex-M3 is from Cortex series but does not support "ARM instruction set state". I don't know how to fix this in the article. — Preceding unsigned comment added by 89.75.131.240 (talk) 17:25, 8 February 2013 (UTC)

How about this:

"All ARMv7 chips support the Thumb-2 instruction set. The Cortex-M series supports only Thumb-2, while other chips in the Cortex series, support both "ARM instruction set state" and "Thumb-2 instruction set state," as do recent versions of the ARM11 core."

(The first ARM11 core, the ARM1136, did not support Thumb-2)

- Hatster301 (talk) 00:52, 9 February 2013 (UTC)

It is a complex mess, because lots of things have evolved over time. I went through ARMv6-M and ARMv7-M reference manuals to create this section ARM_Cortex-M#Instruction_sets, thus your statement needs to be fixed. The Cortex-M0, Cortex-M0+, Cortex-M1 has the same instructions. The Cortex-M3 and Cortex-M4 have the same base instructions, then Corex-M4F add the floating-point instructions on top of them. I wrote this section ARM_Cortex-M#Overview. • Sbmeirow • Talk • 02:30, 9 February 2013 (UTC)

For what it is worth, I found this document to be useful. Commonly used extensions like NEON and VFP are easy to find info about, but things like wireless MMX or half-precision are a bit harder to get good info on. --Guy Macon (talk) 03:28, 9 February 2013 (UTC)