Talk:ARM architecture

From Wikipedia, the free encyclopedia

Contents 1 OMAP as a branch? 2 re: edit on October 30: Originally called "Advanced RISC Machine"? 3 most used CPU architecture in the world? 4 Rewording NEON 5 80286 alternative for ACORN 6 Initiation of the ARM project 6.1 68000 6.2 32016 7 Arc 8 There should be a disambiguation page for ARM 9 Merger 10 Address bus width 11 "Many people are of the opinion that it is a very "pure" RISC implementation..." 12 Piccolo 13 A small reediting of the article is badly needed 14 Thumb-2 14.1 6502 similarity 15 Conditional code 16 Three Address Architecture? 17 volatile short 18 XScale and ARM926 "more numerous" 19 Advertising 20 The cores 21 iPhone? 22 iPhone ARM Confirmation? 23 bug in example C code 24 bug in example ASM code 25 New topic for Jazelle? 26 Strange sentence

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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.

[edit] 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)

[edit] Arc

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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] "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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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 ^[1], 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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)