Talk:ARM architecture family/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4

Awkward wording

In the introduction, “ARM processors require significantly fewer transistors than processors that would typically be found in a traditional computer.” right after boasting how ARM is now the dominant (i.e. typical) computer now. What is meant by traditional? This still needs to be stated succinctly, so perhaps a more specific word is needed while keeping the sentence. "Previous", "earlier", "competing"? RISC isn't a new idea anymore and this architecture dates to 1985, so history of RISC is really history. Maybe it can just refer to vague benefits and link to the article on RISC? —Długosz (talk) 05:18, 7 March 2013 (UTC)

Maybe just write "desktop computer"? -Zoon van Zaal (talk) 23:31, 4 April 2013 (UTC)

ThumbEE deprecation

ARM is going to deprecate the Thumbee instruction set. I added what detail I could and put it into a new section. I would like to see it expanded as to why they are doing this as Java bytecodes are going to rely heavily on this. This indicates a new partnership with Oracle, owner of Java. Nodekeeper (talk) 18:42, 11 August 2013 (UTC)

Naming..

Look at this article:

http://9to5mac.com/2013/08/25/apple-said-to-have-tested-64-bit-a7-chips-for-iphone-5s-31-speed-increases-reported/

Notice anything missing? Like "ARM" and "Cortex"? I guess you have really gone mainstream when they stop using your full name... :) --Guy Macon (talk) 10:41, 26 August 2013 (UTC)

You mean the 'A7' bit? That's a reference to the next in Apple's Ax series of SoC's, not the ARM Cortex-A7 MPCore. --Imroy (talk) 19:38, 26 August 2013 (UTC)

Big.LITTLE article

Please see the article name discussion in the ARM-related Talk:Big.LITTLE article. Thanks. • Sbmeirow • Talk • 01:11, 6 August 2013 (UTC)

The discussion is still happening at Talk:big.LITTLE. • Sbmeirow • Talk • 13:55, 6 September 2013 (UTC)

Proposed merge with ARMhf

WP:DICTDEF Widefox; talk 13:20, 29 May 2013 (UTC)

  • Support merge. If fleshed out a bit, ARMhf would make a nice paragraph in the ARM architecture article, but there isn't enough material on the topic to justify a standalone article. --Guy Macon (talk) 14:16, 29 May 2013 (UTC)
  • Support. The page already has a section on Floating point (VFP) and it seems from here that it's becoming standard to use armel/armhf to distinguish the two calling conventions so the section should mention both. (There's currently a non-specific disambiguation for armel) Chris55 (talk) 08:51, 9 June 2013 (UTC)
  • Support. • Sbmeirow • Talk • 01:10, 6 August 2013 (UTC)
  • Oppose There is a reason why this is a separate article, even though it is just a "stub" right now. It is inaccurate to point to WP:DICTDEF. Note, If ARMh was to be accurately described like other sections of the ARM architecture currently are, then it would indeed be a full length article and not just a paragraph mention. To get an idea of what such an article would look like, See this entry on Debian's webpage. Original editor may have known this. So if it is merged, at some point in the future some other editor will come along and un-merge it into it's own article. Technically speaking, VFP should be merged into ARMh. But this really is like pulling a thread on a sweater, the whole ARM article is messy, overly long, and hard to read. In part due to ARM's complexity. It needs to look like how the TV show articles on wikipedia are, which are excellent imho. They have small introductory paragraphs which have links going to more in depth articles. The ARM article is ripe for such a treatment. Nodekeeper (talk) 16:21, 11 August 2013 (UTC)
Could you detail why, and the inaccuracy. It is fine that in future if it grows it can be spun out. BUT, as it stands today, there's not enough content or sources to justify a standalone article. See WP:Summary style#Subarticle deletion. Widefox; talk 09:50, 12 September 2013 (UTC)

Refactor business related - licensees and architecture(s)

Hi, thanks to Mr. Harris for cleaning up licensees: https://en.wikipedia.org/wiki/ARM_architecture#Licensees

I was about to to this, already changed https://en.wikipedia.org/wiki/ARM_Holdings

and then realized now, these are all business related matters and should be there and not here. Anyone disagree? comp.arch (talk) 00:41, 16 September 2013 (UTC)

I was thinking the exact same thing earlier today. I agree 10^10^100%. Guy Harris (talk) 05:04, 16 September 2013 (UTC)
(And, yes, given that AArch64 seems to cross the threshold for "not just a straightforward 64-bit stretch of a 32-bit architecture", just as x86-64 does, perhaps either the page should be retitled and should give more information about AArch64 or AArch64 should get its own page.) Guy Harris (talk) 05:11, 16 September 2013 (UTC)
  • Agree to present such business related stuff as licensees, etc. at ARM Holdings, rather than here at ARM architecture, per WP:DUE. Personally, I'd wait a week or more before doing so, in order that others have time to find this discussion too. -- Trevj (talk) 07:23, 16 September 2013 (UTC)

Note, we should still leave ARM architectural licence, here especially if we can say anything about the (incompatible? ARMv7s) changes in derivaties. The technical stuff. But mention it and companies (and regular licensees) in ARM Holdings (or elsehere?). I dislike keeping a (growing) list of companies here that is duplicate and must then be maintained twice. Still should we mention any (major) here? I think not (any non-architectural at least), but a link to them might be appropriate. comp.arch (talk) 11:50, 16 September 2013 (UTC)

Perhaps there's scope for List of ARM architecture licensees or similar, per WP:LISTN - although to offer truly encyclopedic content, defining the scope of the list would require a bit of thought. -- Trevj (talk) 09:03, 17 September 2013 (UTC)

Done (for now, busy on other things). Moved to ARM Holdings. I thinks it might be ok there (and here). A better/explicit link to ARM Holding sub-section on architectural licencing at least (and back)? More could be don't here getting rid of business related stuff (all company names?). I think we should allow some (in lead)? Firsts, so the list will not grow - not major players. comp.arch (talk) 11:02, 17 September 2013 (UTC)

Not sure what to do about:

"Fabless licensees, who wish to integrate an ARM core into their own chip design, are usually only interested in acquiring a ready-to-manufacture verified IP core. For these customers, ARM delivers a gate netlist description of the chosen ARM core, along with an abstracted simulation model and test programs to aid design integration and verification. More ambitious customers, including integrated device manufacturers (IDM) and foundry operators, choose to acquire the processor IP in synthesizable RTL (Verilog) form. With the synthesizable RTL, the customer has the ability to perform architectural level optimisations and extensions. This allows the designer to achieve exotic design goals not otherwise possible with an unmodified netlist (high clock speed, very low power consumption, instruction set extensions, etc.). While ARM does not grant the licensee the right to resell the ARM architecture itself, licensees may freely sell manufactured product such as chip devices, evaluation boards, complete systems. Merchant foundries can be a special case; not only are they allowed to sell finished silicon containing ARM cores, they generally hold the right to re-manufacture ARM cores for other customers."

It's still in ARM Holdings and is kind of technical but borderline, especially the rest of that section, if peoble feel it should be readded here, then meybe it sould be removed there. Or duplication is ok? comp.arch (talk) 14:04, 17 September 2013 (UTC)

ARMv8 (64-bit) barrell shifter? And dropped features in general

In 32-bit ARM section I added See below (for differences). There are the new (positive) things. We should mention the negative, as in what was taken out (still probably a positive thing). For least sureprise of asm programmers, right? Of course it's all in the ARMv7-A compatibility. I recall reading (on comp.arch) about the barrell shifter (in every instruction) not being a good idea. Was it dropped? Can't find the ARM ARM now (without registering). ROL can't mean the same thing there would have to be a 64-bit and 32-bit version. Prediction was dropped, what else am I forgetting? comp.arch (talk) 14:20, 17 September 2013 (UTC)

(Apple's) ARMv7s and ARMv8s don't redirect here or anywhere

I haven't seen links yet but see this a lot. What are the differences between ARMv7(-A) and "ARMv7s"? Is it an ISA superset (more instructions) or even a subset? Is the ISA the same but still a custom arch? or might it just be an error and refer to their SoC (and it's GPU in general)? I think this should be documented somewhere in Wikipedia, (and) probably (mentioned) here. comp.arch (talk) 15:31, 17 September 2013 (UTC)

This came up somewhere a short while ago, and I looked at the LLVM source, and perhaps I misread it in my quick read, but it appeared that "armv7s" is like "ppc7400" - specifying it to the compiler doesn't allow it to generate added instructions or prevent it from generating removed instructions, it just affects which ARMv7-A code it generates, because some code sequences that are better on Cortex cores are worse on Swift cores and vice versa.
I'm guessing "s" stands for "Swift"; they also have "v7f" and "v7k", and the lines for them in Mountain Lion's /usr/include/mach/machine.h are
   #define CPU_SUBTYPE_ARM_V7F             ((cpu_subtype_t) 10) /* Cortex A9 */
   #define CPU_SUBTYPE_ARM_V7K             ((cpu_subtype_t) 12) /* Kirkwood40 */
I'm guessing "Kirkwood" is Marvell's line of Kirkwood processors; I don't know whether Apple uses them for anything or not.
Mach-O supports specifying a CPU type, with, for example, x86 and ARM being CPU types (with one CPU type bit specifying 32-bit vs. 64-bit), but also a CPU subtype. The CPU subtypes specify particular processors or processor families; there's an "ALL" subtype which, I guess, means "runs on all subtypes". The subtype can either specify "we need this particular processor type because we use features only it has" or "we're optimized for this particular processor type; the code will run on other processor types but it might not run as well". Guy Harris (talk) 18:30, 17 September 2013 (UTC)
"armv7s" also specifies a particular set of standard ARM features that Swift has, such as VFPv4. Guy Harris (talk) 18:45, 17 September 2013 (UTC)

Renamed article to "ARM architectures" (plural) and instruction encoding: Mixed

Hope noone objects. I and Mr. Harris concurr that ARMv7 and ARMv8 are distinct. Maybe we should split in two articles (later). I see no reason to do that now. Pretty sure ARMv7 is not considered legacy by ARM Holdings (?) - it will always (the ISA) live on in ARMv8 at least, but to say that there is only one, ARMv8, current is clearly wrong. The Infobox (for software at least) should describe the current version. Not sure how many are current or should be described there..

I know the original ARM had fixed 32-bit encoding, I know, very fond of the Acorn Archimedes, haven't programmed ARMv2 assembly in a while.. but should Fixed encoding be taken out of the Infobox? Should historical details be there? It stopped being Fixed when Thumb got mandatory, when exactly was that? comp.arch (talk) 11:28, 18 September 2013 (UTC)

Help: Architectural license and other types (how many)

This need to happen fast. My cleanup didn't go over well. Stuff in ARM Holdings that was unsourced for a long time got deleted after going to its rightful place "ARM Holdings". See recent changes there and comment on my talk page.

Copied from ARM Holdings talk page, discuss the technical here and business related there if you have to. Try not to dublicate discussion too much in both places. I'm trying my best to find citations, but could need some help..

Not sure what the language in the press releases are for an architectural license. I see that I've been wrong in putting Cavium an a regular core category:

https://en.wikipedia.org/w/index.php?title=ARM_Holdings&diff=573660919&oldid=573660653

I wasn't sure until seeing "full custom cores" in the linked Project Thunder page.

Note how the lanuage is different from that of the Broadcom press release: "Broadcom has licensed the ARMv7 and ARMv8 architectures. The agreement will enable Broadcom to develop and build its own processors based on the ARM® architecture." [This means the cores not, SoC around non-custom ARM cores?]

This seems to imply architectural license. Note they have been making their own "custom SoC with ARMv7-non-custom-core(?)" for much longer. Is Cavium in the same category, with respect to ARMv8 (can you even have a license (either core or arch.) to ARMv8 and not ARMv7 (or lower). Is there some key words to look for that we can put in the comment?

I'll also put this in the ARM Architecture talk-page. Please if this is too technical to discuss here to it there. Not sure if only Business types edit this page (till recently). Discuss Business stuff related to ths here, like maybe how many types are there. Arch. (for specific archs. (always including lower?) and core (individual cores) categories? comp.arch (talk) 16:31, 19 September 2013 (UTC)

this does sound very technical. The article is about the company rather than the technology and needs to be intelligible to the layman. Best wishes. Dormskirk (talk) 21:01, 19 September 2013 (UTC)
Maybe you only edit ARM Holdings, not ARM architecture. The stuff you deleted has been there for a long time and is uncontroversial I thought. I just moved here since list of companies is not technical but business stuff. Citations would be better I agree. I didn't write the text just moved it. Some of it had citations above. Licensing is business related, and the two types, what part sounds very technical? The part in the talk page. That's just FYI. Or the stuff in the article itself? I tried to eliminate the technical stuff there.

Moved discussion to Talk-page:ARM_Architecture. comp.arch (talk) 21:39, 19 September 2013 (UTC)

Changing article name and ARM8 and ARM7 redirects

Hi, first

1. I've changed redirect before, just can't remember how.. Was going to redirect ARM8 to this article (or ARMv8?) and ARM7 similarily. Thought this should do: ARM8&redirect=no

People will no doubt mistake ARM8 for ARMv8. ARM8 and 7 the processors not the architectures are really old. Anyone think this is a bad idea? I say just do it, the redirects aren't even that helpful now. Can somone just do this for me.

2. I changed the lead to "The ARM architectures are".. and no one objected. Hopefully poeple are happy with the change and some others I did (might have fone overboard with the Infobox though - how old is not current? And should not be there?). I think there is actually a rule that says the lead should start refering to the page title and I changed accordingly but got reverted:

https://en.wikipedia.org/w/index.php?title=Talk%3AARM_architecture&diff=573523707&oldid=573484505

The reason given, I think doesn't apply, it's not like Horse and Horses, more like the exceptions to the rule, Zeno's paradoxes and The Beatles. Someone objects or will revert the revert to my change? comp.arch (talk) 14:52, 19 September 2013 (UTC)

ARM7 article already exists, so you can't just repoint ARM7 here without a bigger discussion, notifications, and voting. Since ARM Holdings were morons when they created the naming of the architectures and cores, thus we are left with the mess of similar numbers meaning different things. It would be better to rename every ARM related article, but that would not be an easy task. • Sbmeirow • Talk • 16:02, 19 September 2013 (UTC)
Ok, sorry, didn't notice. It seemed to be pointless but it that was just ARM8. I just thought it would be helpful and uncontriversial but maybe it is not in the case of ARM8 at least. Anyway was just trying to help and doesn't matter much to me. comp.arch (talk) 20:58, 19 September 2013 (UTC)
Since you only mention ARM7 are you ok with nr. 2 the name change to "ARM architectures" (I want to change that and vote if necessary) and ARM8->ARMv8 as a spelling-error redirect? Clearly nr. 2 was not uncontriversial, but I think as I said based on a misunderstanding about the rules. Do people think there is only one (current) architecture? Then the lead should describe ARMv8 (and the Infobox) and ARMv7 is deprecated (except as "part" of ARMv7)? I assume ARM will continue selling ARMv7 only cores/licences? comp.arch (talk) 21:05, 19 September 2013 (UTC)
As long as processors that only implement the 32-bit versions of ARM are still being made, I'd call them current architectures. Heck, IA-32 is still a current architecture, as Intel are still selling 32-bit-only x86 processors. Guy Harris (talk) 21:51, 19 September 2013 (UTC)
32-bit is current, but it seems ARM Holdings only markets (licences) Cortex and newer. Of course we should document older also (maybe not in Infobox if too cluttered). Older are however still manufactured (eg. Raspberry Pi/Broadcom oldest core/arch that I know of (not looked into the microcontroller arch. sitation)) since the manufacturing part of a license is perpeptual. comp.arch (talk) 16:29, 21 September 2013 (UTC)

ARM8 is now unused (eliminated two places where used that link to generic list List of ARM microprocessor cores). I think anticipating misspellings of ARM8 in search box we should change ARM8 redirect to redirect (to ARMv8) ARM Architechture. Leave ARM7 alone. ARM8 change doesn't seem to warrant a vote? Nobody has commented further, however I can't figure out how to change myself.

https://en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=ARM8&namespace= comp.arch (talk) 16:49, 21 September 2013 (UTC)

Chips with ARM7TDMI and ARM9E cores are still be manufactured. I've seen a few new ARM9E core based chips come out in the last year. There are still mountains of not very old products that used this stuff too, so you better not remove this stuff! • Sbmeirow • Talk • 20:06, 21 September 2013 (UTC)
The right way to handle this, at least for ARM7, is the way I did it just now on the ARM7 page - put a hatnote at the top saying that the page is about the ARM7 family of processors, and that if you want to know about the ARMv7 instruction set architecture, go to ARM architecture.
If there were a page for the ARM8 cores, that would be the right thing to do for ARM8 as well. For now, if ARM8 were made to redirect here, there should probably be a similar hatnote redirecting people interested in the ARM8 core to List of ARM microprocessor cores; if somebody later creates a page for it, that page should have a hatnote similar to the ARM7 one. Guy Harris (talk) 00:32, 22 September 2013 (UTC)
Since there is no ARM8 page (and maybe not notable, at least I'm not goint to add one), could someone make ARM8 redirect to "this" page (that is also about ARM8 cores not just ARMv8 arch.), If ARM8 core page is later added then the redirect can be changed to that (with a hatnote). comp.arch (talk) 12:11, 23 September 2013 (UTC)

Name of the article

This has been changed (twice) to ARM architectures. The first time it was reverted by MatthiasPaul who pointed out, quite reasonably, that Wikipedia prefers singular titles. Now it has been done without any discussion. Is there any overwhelming reason to use the plural? I notice, for instance that IBM System/360 architecture is singular despite the Model 67 doing a 24-bit to 32-bit extension. Chris55 (talk) 09:01, 3 October 2013 (UTC)

It is referred with singular title in all literature I have ever read about ARM. The fact that it has multiple architecture versions does not make it many architectures. I'll likely revert the weird page move. jni (talk) 09:17, 3 October 2013 (UTC)
Ditto for PowerPC in the text of the article: PowerPC (an acronym for Performance Optimization With Enhanced RISC – Performance Computing, sometimes abbreviated as PPC) is a RISC instruction set architecture [...]. And for SPARC. Even when there are several versions, architecture is in singular in general. So, that's another reason why the title should also remain singular. Vincent Lefèvre (talk) 09:18, 3 October 2013 (UTC)
I'm not too familiar with System/360 architecture, but as was said it was a (simple I guess) extension to 32-bit. ARM has similar with 26->32 bits. MIPS has had an simple extension to 64-bits as the other examples above I think. ARM is different. ARMv8 (at least AArch64) is a new quite separate ISA (unlike the above extensions). It is reflected in beeing handled separatly in the Linux kernel with an argument about it from ARM people to Linux Torvalds if I recall. This page rename can always be renamed back (or article split in two(?)). I don't see we have to hurry if we want to discuss first. If reverted shouldn't the lead, changes be "reverted" too? And for discussion I posted a section above but didn't get any replies. comp.arch (talk) 09:38, 3 October 2013 (UTC)
I know about AArch32 compatibility (no plans of being dropped (?) but could be I guess). Still it's only for userspace, how can ARMv8 be the same architecture if it will not boot old kernels? The have similarities yes, but more than versions in my view. Are you sure ARM refers to all of ARM architectures in singulars or only each example? I would think some of the microcontoller versions without full 32-bit ISA support and "Memory protection unit" (or even not that?) and not full MMU and maybe other differences would also not be plain versions. comp.arch (talk) 09:44, 3 October 2013 (UTC)
I think you're missing the point. The Chimpanzee article doesn't have a plural despite the fact that there are two different species of the animal (&c). And if I remember rightly that far back, I think Model 67 caused a total rewrite of nearly all their software! At least these days it's mainly a matter of recompiling. Chris55 (talk) 10:54, 3 October 2013 (UTC)
Hmmm. Chimpanzee should be renamed to plural since they are a class of two extant species, maybe I'll take that battle there later. The two species are not binary compatible (different species) unlike the Horse where they are (just differenct subspecies). This is the same argument I'm making. If you want to argue that everything except ARMv8-A is extinct (not extant) I might agree that the article name should only reflect that (and not history). comp.arch (talk) 11:51, 3 October 2013 (UTC)
While the the biological example seems to fall under WP:PLURAL#Exceptions it is not done like that. Maybe (Wikipedia) biologists don't recognice the exception. Since all redirects are now broken and nobody seems to support me in that eg. ARMv8-A and the older but still marketed ARMv7-A and especially the (forgotten?) ARMv7-R and ARMv7-M are separate architectures, that as as class fall under WP:PLURAL#Exceptions, feel free to change the name of the article back - for the time being. I will present more proof that they are separate architectures here, if needed, for a vote to keep the plural. comp.arch (talk) 12:52, 3 October 2013 (UTC)
  • No, revert to singular. WP is strongly against plural names and much better cases than this have been rejected. There are multiple ARMs, and it could be said that each one was a distinct "architecture". If we had an article that looked a lot like a list, then "ARM architectures" (pl.) might be a good name for it. However what we have instead is an article on the over-riding architecture and the principles that have remained consistent throughout the ARM concept. To quote, "The ARM core has remained essentially the same size throughout these changes. " This should remain singular.
Trout as well for "Requested at WP:RM as uncontroversial", as a repeated previous move is hardly uncontroversial, nor is a move against the singular names policy and I can't even find it listed at RM. Andy Dingley (talk) 13:06, 3 October 2013 (UTC)
I am with Andy Dingley on this one. Something like Motorola's 6800 and 68000 could be fairly described as two different architectures, but ARM is best described as different variations of a single architecture. --Guy Macon (talk) 18:16, 3 October 2013 (UTC)
"The ARM core has remained essentially the same size throughout these changes." refers to ARMv2/1? - up to ARMv6 and size. However ARMv8 is differenct. Better quote for ARMv7 "profiles/variants" would be "Profiles are allowed to subset the architecture. For example, the ARMv6-M profile (used by the Cortex M0 / M0+ / M1) is a subset of the ARMv7-M profile which supports fewer instructions." Is a sub-setted with a differenct ISA still the same architecture? comp.arch (talk) 19:11, 3 October 2013 (UTC)
  • Singular. Per WP:SINGULAR we should normally use the singular form. There are some exceptions, but I don't see them applying here, at least not strongly. So far, the singular form is the most common one, and this isn't a list type article (simply listing classes of architectures).
I just reverted this back to the singular form a second time, as there was no prior discussion or consensus to move and the move was erroneously tagged as "uncontroversial" although a similar move had been reverted a couple of days ago already. Also, the redirects haven't been fixed up.
At some stage we might consider splitting out the various implementations into separate articles. For this to be a smooth process, consider more linking through logical redirects to anchors rather than to physical section headers. --Matthiaspaul (talk) 19:03, 3 October 2013 (UTC)
Thanks (really, because of the double redirects, I assumed in my request for a technical move that it would just work). Do people just disagree that there are more than one architecture (2-4 in fact) or that they qualify for WP:PLURAL#Exceptions: "Articles on groups or classes of specific things". I didn't realize WP strongly opposed plurar, assumed first" reverter just didn't know of the exception. comp.arch (talk) 19:32, 3 October 2013 (UTC)
Well, if we look at various Wikipedia pages for instruction set architectures/instruction set architecture families, there's no single pattern.
  • For x86, there's an x86 page, which says "The term x86 denotes a family of backward compatible instruction set architectures...", so it is written from the point of view of there being a family of architectures. They don't explicitly enumerate the family members there. IA-32 and x86-64 are two of the members; to some extent, the ISA of the 8086/8088 and the ISA of the 80286 are similar, but I'd say the addition of the MMU is a somewhat significant change. There aren't separate pages for each of the minor additions to IA-32 (e.g., conditional moves), although for major extensions such as MMX and various flavors of SSE.
  • For System/3x0, there's a page for IBM System/360 architecture, for IBM System/370, for ESA/390 (and I've suggested a page for the common stuff between all those generations), and for z/Architecture. There's currently no page for the family of ISAs; I'm not sure which ISA changes count as evolution and which are big enough to count as new-but-related architectures. S/360 -> S/370 probably counts from the "what the OS sees" point of view, especially with the addition of a paging MMU, and S/370 -> S/370-XA probably counts as that was visible to user-mode code, and ESA/390 -> z/Architecture probably counts as it's the 64-bitification of S/3x0.
  • For 68k, there's a Motorola 68000 family page, and pages for individual processors; one instruction set change was the change to not ignore the upper 8 bits of addresses (similar to the S/370 -> S/370-XA change, but without the compatibility mode, so it caused some gastric distress amongst Mac programmers), which was in the 68012 (not much used, as far as I know) but became significant with the 68020, another was a bunch of new instructions and addressing modes in the 68020, and the third was the simplification in ColdFire.
  • For the various flavors of the {POWER,PowerPC/Power ISA} architecture, there's IBM POWER Architecture and PowerPC; those are described as separate ISAs, although there is a large common binary-compatible subset that they share.
  • For MIPS, there's a MIPS architecture page which discusses all the variants, mostly speaking of them as just versions, including both 32-bit and 64-bit variants, although they then speak of the MIPS32 and MIPS64 instruction sets, plural.
  • For SPARC, there's a SPARC page, which speaks just of versions, including v9, which is the 64-bit version.
  • For PA-RISC, there's a PA-RISC page, which just speaks of a single instruction set, including both the 32-bit 1.x and 64-bit 2.0 versions.
I could see a 32-bit -> 64-bit transition as making a new-but-related instruction set, especially if there are other changes (as is the case for x86 and ARM, but not for most RISC ISAs, and, I think, not for S/3x0 -> z/Architecture). I could see arguments being made for a new-but-related instruction set if the older version explicitly ignores upper bits of addresses (S/3x0, 68k, ARM). My personal inclination might be to treat them all as families, rather than single ISAs; some might have separate pages for the major changes, others might not, depending on the size of the changes. In the case of ARM, I might separate 32-bit and 64-bit ARM, but not separate anything else. Guy Harris (talk) 20:39, 3 October 2013 (UTC)
Thanks for the excellent summary. "Separate 32-bit and 64-bit ARM", - you mean architectures (not necessarily pages (that can come later in my view if we want))? See next section for my family proposal. There can be a family of two right? However I don't agree, ARMs "sub-setted" "architectures" or "architecture profiles" ARMv7-R and ARMv7-M should not be overlooked. Architecture is not (only) the same are ISA. They are a subset of the ISA and don't have MMU but have someting extra also, right?
"Separate 32-bit and 64-bit ARM" - I meant separate pages, just as IA-32 and x86-64 have separate pages, and the various 32-bit flavors of S/3x0 and z/Architecture have separate pages. That doesn't mean they're not part of the same family, it just means they're different enough that they deserve separate pages (which I think is definitely the case for x86 and ARM, given the significant architectural differences, such as doubling the number of GPRs; I'm not sure about z/Architecture, or any of the RISC architectures other than ARM, where, for example, they didn't change the number of GPRs, just made them twice as wide, although z/Architecture did increase the number of floating-point registers).
I view -A, -R, and -M as "profiles", similar to the server vs. embedded for Power Architecture (the ISA formerly known as PowerPC :-)) I'd "separate" them by discussing them as different profiles, but I'm not sure I'd "separate" them by giving them separate pages. Guy Harris (talk) 00:04, 4 October 2013 (UTC)
  • Singular. A Wikipedia article should deal with only one subject. Then there are two cases. Either different ARM architectures (or architecture versions) are related and they can be seen as variants of some architecture in the general sense; and the title should be singular. Or you have unrelated ARM architectures, in which case they should be treated in different articles (each with a title in singular for the corresponding architecture), and there would be a small page ARM architectures (plural) whose only purpose is to provide links to these articles on the different architectures. Vincent Lefèvre (talk) 19:36, 3 October 2013 (UTC)

Intel Makes 14nm ARM for Altera

No mention of FPGAs on this page. That in itself is probably noteworthy. I'm not sure if this is to believed [Intel Makes 14nm ARM for Altera] saw first here [Intel to Fab Altera FPGAs with ARM IP]. Put in lead? comp.arch (talk) 12:50, 31 October 2013 (UTC)

Split article? Changed redirects ARMv7 and ARMv6

ARMv8* redirects are already pointing to 64-bit part. Changed 32-bit ones to 32-bit part. Since the new Infoboxes (nice), maybe it's time (soon? I will not do it on a whim) to split up article in two. Can discuss now but really just FYI for the redirects. I've also changed some (non-Apple A7) articles to point to ARMv7. I'm split on the issue myself, good in a way to have "one" article to maintain.. comp.arch (talk) 11:33, 1 November 2013 (UTC)

A little soon. The 64-bit sections doesn't have that much in them. • Sbmeirow • Talk • 13:47, 1 November 2013 (UTC)

Infobox Overhaul

I split up the one infobox into multiple infoboxes, similar to how I did it in Keystone Pipeline article, because putting everything into one infobox is very confusing. Since the Table of Contents is very long in this article, there is lots of white space along the right side, thus doesn't cause any layout conflicts. I thought about adding a 4th infobox for legacy 32-bit architectures, but haven't done it yet (still TBD). The other way that I considered do it is "one infobox per architecture", but I thought it might grow out of control along the right side. Thoughts? If there is a better way to split the infobox, please suggest your ideas! • Sbmeirow • Talk • 22:06, 29 October 2013 (UTC)

I added a couple more infoboxes. The 32-bit (obsolete) group isn't very significant, but they are different because they don't have any 16-bit Thumb/Thumb2 instructions. The 32-bit (legacy) group is significant, because they have Thumb instructions and this is the group that was greatly used during the ARM expansion into portable devices, like Gameboy and MP3 players. If there are too many infoboxes, then delete the "obsolete" group, but please keep the "legacy" group. We might be able to merge some of this information into the table near the top of the article. Anyway, some things to think about... • Sbmeirow • Talk • 03:24, 30 October 2013 (UTC)
I do think these infoboxes are getting out of control at the top of the article. On some layouts (e.g. iPad app) the list of boxes stretches into the history section or is quite off-putting. Since they mostly apply to specific sections of the article, may I suggest they are put there: e.g. 32 bit in the 32 bit section. (Policy for infoboxes states it's up to the talk page.) This will also be useful preparation if the page is split up sometime in the future. Chris55 (talk) 16:37, 31 October 2013 (UTC)
I removed the oldest infobox that contained ARMv4, ARMv3, ARMv2. The only reason the iPad app infobox is so darn long is the screen capture photo is BIG. Infoboxes going down into the article isn't unusual at all, see the tens-of-thousands of city articles and thousands of school articles. The article is about ARM architectures, which there are many variations, thus they can't easily be refined down into a tiny infobox. The Table of Contents of this article is long, thus there is LOTS of unused white space on the rights side, so these infoboxes are not currently causing a layout problem. • Sbmeirow • Talk • 21:42, 31 October 2013 (UTC)
Yes, it's one way to use the white space, but I still think the infoboxes for the individual systems are more useful opposite their appropriate sections. Saying that other articles are worse isn't an argument. Chris55 (talk) 18:23, 2 November 2013 (UTC)

Missing floating-point information

Please add floating point details about ARM Cortex-M4F, ARM Cortex-R4F, ARM Cortex-R5F, ARM Cortex-R7F to ARM_architecture#Floating-point_.28VFP.29 section. Thanks. • Sbmeirow • Talk • 10:37, 8 November 2013 (UTC)

MPCore in name

I noticed that "Cortex-A12" was already available just not including MPCore in it's name. Anyone know why MP core is only part of the A15 and ARM Cortex™-A7 MPCore™? Guess it's because they are newer and a gnage in policy. Some of the other are also multi-core (or can be). SHOULD wikipedia have MPCORE in the names where ARM has them and not otherwise? I guess a redirect might be in order for with/without as an alternative. comp.arch (talk) 14:25, 8 November 2013 (UTC)

It's not just those two. Googling for
mpcore site:arm.com
found ARM11 MPCore, Cortex-A9 spoken of as "Cortex-A9 MPCore" at least once, and Cortex-A5 MPCore.
But I'd say that if ARM never uses MPCore for a given design, Wikipedia shouldn't, either. If ARM uses it some of the time, we should have a redirect so we support both names; if they use it all the time, perhaps there should still be a redirect for the name without the "MPCore", for convenience.Guy Harris (talk) 20:08, 8 November 2013 (UTC)
I'm not so sure we should include MPCore in the names when linking (or even in the article names?), it makes texts longer and most websites ignore this retail. ARM Holdings website is very inconsistent on this. Technical manuals (website) are better it seems. [1]: "ARM documentation set for the ARM Cortex-A family of processors, including the ARM Cortex-A15 MPCore, ARM Cortex-A9 MPCore, ARM Cortex-A9 single core, ARM Cortex-A8, ARM Cortex-A7 MPCore, and ARM Cortex-A5 processors." Anyway, this really only means that the core is multi-core capable (could even be just dual?), right? Note sometimes as for A15 they are still used as single-core (right?). However A9 seems special with MPCore and not version listed (similar to different ARM11 verions) unlike the A15. On some pages they don't even start with it (seems marketing not doing it's job?) "The ARM Cortex™-A9 processor [...] Cortex-A9 MPCore" or even it's completely missing (and doesn't show up in Google) except in the pictures ("ARM CoreSight Multicore Debug and Trace" = MPCore?). comp.arch (talk) 23:40, 8 November 2013 (UTC)
Agree, rename article! ARM.com doesn't even use it in their high-level marketing descriptions. http://www.arm.com/products/processors/cortex-a/index.php unless you look at on another tab http://www.arm.com/products/processors/cortex-a/index.php?tab=Multicore • Sbmeirow • Talk • 08:30, 9 November 2013 (UTC)

New name change proposal: ARM architecture family

This is maybe the simple solution I overlooked. Similiar to Motorola 68000 family. This sidesteps the WP:PLURAL issue vs. WP:SINGULAR. I will not "just do this" (TM) name change myself this time (at least not right away).. If people agree that ARMv8-A and ARMv7-*, ARMv6 etc. are a family then I think we are set. People need not even agree that they are distinct architectures that are not fully forward or backward compatible. comp.arch (talk) 21:40, 3 October 2013 (UTC)

NO, because ARM Holdings clearly has been calling it architecture for a very long time! It should be either "ARM architecture" or plural "ARM architectures", but nothing else. • Sbmeirow • Talk • 04:14, 4 October 2013 (UTC)
OK. I see now that family is official Motorola term, don't know about x86 using family in thair article page (not title), anyway x86 isn't offical I think either.. I just didn't want to call it the ARM architecture zoo that it is.. :) They do however call it profiles (or architectures (plural)) but that would also be plural.. comp.arch (talk) 09:09, 4 October 2013 (UTC)
"Profiles" probably refers to -A/-R/-M (hey, did they do that deliberately? :-)), not to the v[1-8] versioning. The v[1-8] versioning is similar to the SPARC versioning (v1-6 never got released, v7 was the first released version, v8 added multiply and divide instructions, v9 went 64-bit), the PA-RISC versioning (1.0 was the first release, 1.1 doubled the number of floating-point registers and may have made other changes, 2.0 went 64-bit), and the PowerPC/Power ISA versioning (I'm not sure what the different versions did, but Media:PowerISA-evolution.svg seems to imply that 2.0 might have been the first publicly-documented 64-bit version - PowerPC AS isn't fully documented, and has some features used in systems running IBM i, such as tag bits and decimal-arithmetic assist instructions). x86 doesn't have version numbers, and I don't know whether "architecture level" numbers were introduced into S/3x0 with S/390 or with z/Architecture (S/390 might be considered ARCHLVL 1, but I don't know whether that happened before z/Architecture was introduced, with its initial ARCHLVL being 2). Profiles are similar to the "server" vs. "embedded" profiles for PowerPC. Guy Harris (talk) 09:30, 4 October 2013 (UTC)
NO, because everyone else besides ARM Holdings has been calling it architecture for a very long time! Wikipedia is not a place to invent your own classification schemes or naming conventions, instead an encyclopedia should conform to what reliable sources report and leave it to that. It is irrelevant whether or not your own taxonomy/terminology/naming convention/typology is an improvement to what current computer architecture literature uses. jni (talk) 08:02, 4 October 2013 (UTC)
Support: There isn't one single ARM architecture. Clearer disambiguation from just "ARM" in general, the word "Arm", or ARM Holdings. ViperSnake151  Talk  21:47, 29 October 2013 (UTC)
NO, because the ARM technical position is clear, there is a single ARM architecture, that has gone through multiple versions. v8 just happens to add a major change, support for a 64-bit Execution state, currently only in the A-profile. Fundamentally, the move from ARMv7 to ARMv8 is no different to the move from ARMv6 to ARMv7. — Preceding unsigned comment added by 92.29.251.205 (talk) 17:32, 23 November 2013 (UTC)

FYI: ARMv6-M and ARMv7-M will redirect to ARM Cortex-M

ARMv6-M redirects here but ARMv7-M nowhere. I was thinking of linking to ARM Cortex-M. It just feels like both should for consistency. Or both here. I only ask here because the target is here and I'm not sure if a change of redirect should (in general) be discussed in the target page (or on the ARMv6-M redirect talk page. I'm guessing no one reads that.. :) ) Note how this affects Apple M7. Please speak up if you want it/the redirects to link to this page. comp.arch (talk) 12:49, 6 December 2013 (UTC)

I don't have a problem with it. Just now I created the ARMv7E-M redirect and pointed it at its new anchor. How does "what" affect Apple M7??? • Sbmeirow • Talk • 21:48, 6 December 2013 (UTC)
I suspect he means "the infobox in the Apple M7 page says the architecture is "ARMv7-M" but that's a link to the ARM architecture page, and should probably be a link to the ARMv7-M page now that it exists (as a redirect)", given that he made exactly that change to the Apple M7 page. Guy Harris (talk) 00:02, 7 December 2013 (UTC)
Wouldn't ARMv6-M and ARMv7-M be considered "ARM architectures"? And, if so, should not they be described here, rather than in the pages for particular families of implementations of those architectures (even if those implementations are designed by the creator of the ISAs)? Guy Harris (talk) 18:47, 6 December 2013 (UTC)
Yes, but it's a good place to point the redirects until they get expanded in this article, then can be pointed back here. Actually each of the incremental architectures should be expanded in this article. • Sbmeirow • Talk • 22:47, 6 December 2013 (UTC)

Removed 32-bit features in ARMv8-A "see below for exceptions"

I think I put in "see below for exceptions" that was removed [2]. I meant to point to ARMv8-A. The processor modes (and more) are "gone". I put in quotes because 32-bit code (and some? processor modes) is still supported for userspace. Maybe we should add all of the "exceptions". And they really are exceptions if 32-bit support is not included (I think its optional..). comp.arch (talk) 18:57, 12 January 2014 (UTC)

Hello there! Any chances for providing a reference describing that? — Dsimic (talk) 19:02, 12 January 2014 (UTC)

32-bit (optional) in ARMv8?

"ARMv8 features two architectural states: AArch32 and AArch64. Designs that implement both states can switch/interleave between the two states on exception boundaries. In other words, despite A64 being a new ISA you’ll still be able to run old code alongside it. As always, in order to support both you need an OS with support for A64. You can’t run A64 code on an A32 OS. It is also possible to do an A64/AArch64-only design, which is something some server players are considering where backwards compatibility isn’t such a big deal." [3] I was thinking of adding "possible to do an A64/AArch64-only design..". Of course it's possible and I could add it as Anantech is a (usually) reliable source. Would you think it is actually allowed by the license and even if, should it be added? Maybe not about the architecture unless they say it's optional. In general what subsets are allowed? And I've seen people say 64-bit registers are slow, such as for addition and others arguing no as 32-bit addition is possible. I could look this up but people might be thinking og AArch32 then. comp.arch (talk) 13:26, 16 December 2013 (UTC)

You can license pretty much any subset or superset, although ARM Holdings might turn you down if your idea is really stupid or hurts some other licensee by purposely introducing incompatibility. To my way of thinking, we should wait until we see an actual shipping 64-bit-only ARM. --Guy Macon (talk) 19:58, 16 December 2013 (UTC)
I found from an Nvidia CTO (now at Google): "As an architecture licensee, the thing to remember is that you can tweak an ARM core to change its performance, but you can't change the architecture one lick. You have to conform to the ISA, and they are quite disciplined about that."[4] If below is correct (that AArch64-only is an allowed subset) then this is not a contradiction. comp.arch (talk) 13:26, 16 December 2013 (UTC)
Table D1-87, "Supported combinations of Exception levels and Execution state", of the current version of the ARMv8 manual (to become a "registered ARM customer" allowed to access the architecture manuals, you just need to sign up for an account at arm.com), seems to allow a combination in which no exception level - including EL0, i.e. "user mode" - supports AArch32, so it appears that they do allow, and license, 64-bit-only implementations of ARMv8.
As for people who "say 64-bit registers are slow, such as for addition", I'd like to know what they're talking about. I suppose an implementation with a 32-bit adder or adders, requiring two cycles to add two 64-bit numbers, might have 64-bit addition slower than 32-bit addition, but an implementation with 64-bit adder(s) should add two 64-bit numbers in the same time as it takes to add two 32-bit numbers. It might take more effort to make an adder fast the more bits the adder has, but I really doubt that you're going to find many 64-bit processors for any architecture where 64-bit arithmetic is slower than 32-bit arithmetic; 64-bit numbers take more memory (so you might require more physical memory to avoid paging, and might have a bigger cache footprint with them), but that's another matter. Guy Harris (talk) 20:46, 16 December 2013 (UTC)
What I meant (maybe not other people) was that 64-bit is inherantly harder, maybe not by much for addition (more so for multiplaction). The Pentium 4 was faster (more GHz) but had to use tricks to get there ("double pumped"?, my memory is fading..). Transistor density is higher now and probably tricks are not needed anymore? Are there any instruction that have 64 and 32 bit variants? Yes for load/store I think, "no"/unneccesary for arithmetic? The closest that I can think of is SIMD, those registers are bigger but no calculation on more that 64 bits (or double precision?)? comp.arch (talk) 19:10, 12 January 2014 (UTC)
"What I meant (maybe not other people) was that 64-bit is inherantly harder, maybe not by much for addition (more so for multiplaction)." A 64-bit adder or multiplier requires more transistors and probably requires more work on the part of the designer in order to do the addition or, especially, the multiplication in a given amount of time; I don't know whether any 64-bit processors have separate 32-bit adders or multipliers that can finish faster.
The Pentium 4 had a high clock rate that didn't always result in higher performance; that had little to do with 64-bit, except perhaps that the later Pentium 4s with x86-64 support were, I think, claimed by some to still have 32-bit data paths and thus to have to take two cycles to process 64-bit integers and addresses; I don't know whether those claims were true or not.
"Are there any instruction that have 64 and 32 bit variants? Yes for load/store I think, "no"/unneccesary for arithmetic?" Multiple variants (8-bit, 16-bit, 32-bit, and 64-bit) are obviously necessary in non-load/store architectures such as x86 (including x86-64) and System/3x0 (including z/Architecture). The load/store Power ISA (formerly known as PowerPC, renamed to match Power Architecture) has only one form of addition (which works differently in 64-bit and 32-bit mode), but has both 32x32->32 and 64x64->64 multiply instructions and both 32/32->32 and 64/64->64 divide instructions. Guy Harris (talk) 20:08, 12 January 2014 (UTC)

move ARM architecture to ARM instruction set

It is an instruction set. Articles targeting microarchitectures are List of ARM cores, List of applications of ARM cores, ARM big.LITTLE, Comparison of current ARM cores, AMULET microprocessor, Amber (processor core) and of course Template:ARM-based chips ScotXW (talk) 11:34, 9 March 2014 (UTC)

I'm against the renaming, as the article is describing much more than just the ARM instruction set. — Dsimic (talk | contribs) 21:59, 9 March 2014 (UTC)
"Architecture" doesn't always mean "microarchitecture"; there's a reason why the term "instruction set architecture" is commonly used. Guy Harris (talk) 22:19, 9 March 2014 (UTC)
I'm against renaming this article for similar reasons as User:Dsimic and User talk:Guy Harris. • Sbmeirow • Talk • 02:16, 10 March 2014 (UTC)
Only if you move the AArch instruction set out, because it is an ARM architecture, but is a very different instruction set.Carewolf (talk) 10:20, 15 March 2014 (UTC)

L0, L3 (transparent) cache

Comparison of current ARM cores, says L0. I'll let that slide, maybe. Would there really be any different to L1? I know it's direct mapped and smaller. I assume it's all transparent. I'm not familiar with the cache instrunctions in ARM. IA64/Itanium has some L3 instructions if I recall. I guess no such advanced stuff (for levels) in ARM. comp.arch (talk) 16:27, 31 March 2014 (UTC)

"STORM Open Soft Core" ARMv3, ARMv4, ARMv5?

It was put under ARMv3, but OLDER documentation than what I cited mentioned ARM9 and ARM9. That are ARMv3 or even higher. Newer doc but still old (newest that I found) said ARMv2. Maybe that would indicate full compatibility with ARMv2. Didn't see anything about 26bit vs. 32bit. I do not remember "Abort" in ARMv2. Where would you put it? Not move from ARMv3? comp.arch (talk) 14:51, 1 April 2014 (UTC)

clearly false claim

the article states "In 2005, about 98% of all mobile phones sold used at least one ARM processor". there is a cited source, but this claim is obviously false. as far as i know, no mobile phone other than smartphones uses ARM, and smartphones were not close to being 98% of mobile phones sold in 2005, or, indeed, today. (according to [5], smartphones were less than 10% of mobile phones sold in 2008). this claim should be removed, because the cited source is clearly unreliable. at the least, "mobile phones" should be changed to "smartphones", but this will require some reliable source. peace - קיפודנחש (aka kipod) (talk) 15:51, 5 April 2014 (UTC)

OK, which feature phones use or used no processor (not even the simplest of microcontrollers) and, of the remaining feature phones, what processor did they use? I, at least, would not be surprised to hear that a lot of them used ARM processors of some sort. (Just because something has an ARM - or other - processor in it, that doesn't mean it can run third-party applications.) Guy Harris (talk) 17:04, 5 April 2014 (UTC)
Only the first generation (and 0G) was analog. I would assume all digital phones use at least a microcontroller. Not saying all or most of the oldest digital used ARM, but I would not be surpriced as ARM is old. I googled and it's very hard to find info about the most popular phone(s) (individually, Samsung alone sold much more (not multiplying by cores..) last year, collectively, than Nokia 1100, and almost all smartphones use ARM) as nobody cared about kind of processor (but you can find the most popular Nokia 1100 at $16 in China "one core"). The third(?) Nokia 3210 [has an ARM-based microcontroller]. [See also]. My old Sony Ericson (my first GSM) similar to Sony Ericsson W580 (I forget), used Java and I'm pretty sure uses an ARM. First?/all Symbian phones with ARM? What are they a billion combined? List of best-selling mobile phones. comp.arch (talk) 18:23, 5 April 2014 (UTC)
Do you have a reference to the statement or not? Until 2007 Texas Instrument UPPxM were used in most Nokia feature phones S30/S40. Sony Ericson had their own stuff, and I am sure many of the old boys had as well (Motorola with Freescale for instance) Carewolf (talk) 23:45, 5 April 2014 (UTC)
Probably no contradiction. From the link I posted: "Texas Instruments MAD2PRI Microcontroller (ARM Based)" in Nokia 3210. This article is about the technical side of the architectures mostly. I moved most of the "business stuff" to ARM Holdings a while ago. They design the architectures but manufacture no chips. All these do: [[6]]. Some (TI at least) also have their own DSP ("CPU") or designs at least (for baseband?). DSPs can even be in the same chip as ARM CPU designs so counting chips/manufactures is not clear-cut. UPPxM seems to be for baseband. ARM is not in that business I think. Didn't look into these chips, but seems they are not ARM CPUs, however baseband has been on separate chips in the past from the CPU (and that might have been ARM then) but lately its been combined in as SoC chip with ARM core(s). Does this clear everything up? comp.arch (talk) 00:24, 6 April 2014 (UTC)
According to this TI page from 2007 (the era of the UPP8M), the "digital baseband" processor is also the processor for many UI functions (it's connected to the display, the touchscreen, and the camera, for example). Their TCS1110 GSM chipset page from 2007 has the digital baseband chip including an ARM7 processor. Guy Harris (talk) 06:34, 6 April 2014 (UTC)
And the QSC6010 processor mentioned on the researchinchina.com link includes a High-performance ARM926EJ-S microprocessor core with memory management unit (MMU). So I suspect that when User:קיפודנחש says "as far as i know, no mobile phone other than smartphones uses ARM", that merely reflects his or her lack of knowledge, and that the notion that the claim that "In 2005, about 98% of all mobile phones sold used at least one ARM processor" is "clearly false" or "obviously false" is, itself, clearly false and obviously false. Guy Harris (talk) 06:46, 6 April 2014 (UTC)

move to ARM instruction set(s)

Because ARM is a family of instruction sets. There is an article covering microarchitectures: List of ARM cores User:ScotXWt@lk 17:52, 16 April 2014 (UTC)

Makes no sense, and it's been already discussed in the move ARM architecture to ARM instruction set thread above. — Dsimic (talk | contribs) 18:01, 16 April 2014 (UTC)
There are instruction set architectures and there are microarchitectures. This page is about the former. Guy Harris (talk) 18:09, 16 April 2014 (UTC)
Yes, I am aware of that, and as you can see, even the article instruction set architecture has been moved to instruction set. Maybe to avoid avoidable confusion? I am also aware of the fact, the microarchitecture is a term coined by Intel. I hope it's not a problem? How would you call EPIC or VLIW, RISC and CISC? User:ScotXWt@lk 19:01, 16 April 2014 (UTC)
I don't see anything in the history of instruction set architecture, instruction set architectures, or instruction set to indicate any such move. Instruction set was created on 5 April 2002‎. Instruction set architectures was created on 25 February 2002 - or perhaps 25 January 2002 - by the User:Conversion script bot; it was turned into a redirect to instruction set on 31 July 2002. Perhaps the page existed before the conversion in question, and its history is unavailable. Instruction set was created on 17 April 2002 as a redirect to instruction set.
I'm not sure when the term "instruction set architecture" was first used. [IBM's "Introduction to IBM System/360 Architecture" student text speaks of the System/360 "architecture", without "instruction set" preceding it. The IBM 704 manual speaks of "a complete set of instructions", although it doesn't use "instruction set"; perhaps the notion of an "instruction set architecture" rather than just an "instruction set" dates back to the earliest families of compatible computers, with "instruction set architecture" indicating that the specification for the instruction set is independent of the various machines that implement that instruction set.
ARM, at least, refers to ARMv8-A as an "architecture", and, in the URL for their page for ARMv8-A, uses the term "instruction set architecture", so it is not unreasonable to refer to ARMvN as "architectures".
I'm not sure why the fact that Intel coined the term "microarchitecture" would matter at all here.
I would call EPIC, VLIW, RISC, and CISC "instruction set architecture design philosophies" or "instruction set design philosophies". They are not instruction set architectures, as there are several different CISC ISAs, several different RISC ISAs, and several different VLIW ISAs (and, had Itanium done better, there might be several different ISAs labeled "EPIC"). They are also not microarchitectures, as, for most RISC and CISC ISAs, there are several different microarchitectures implementing each of them.

FYI: Benchmark and ARM64 vs ARMv8 vs ARMv8-A vs AArch64 (and AArch32)

FYI: "The tests where Denver seems to falter are those that show CPU floating point and CPU integer performance, but this can be explained by the use of 2 cores instead of 4.

The RAM test, meanwhile, left everything in the dust, and you can be sure that multitasking will be better on tablets than ever before.

As for the actual specs, they are still vague, but the benchmark shows the top clock speed of the CPU cores being of 3 GHz, not the max 2.5 GHz that everyone expected."

The 64-bit 2-core K1 benchmarks less than half of 32-bit 4-core K1 in CPU (something..). Strange (maybe clock freq. explains), while "RAM"(something..) is more than double despite half the cores * twise the bits. Much else is similar. Don't believe any of this should be in this article, maybe elsewere related to Nvidia. For an actual question:

Ubuntu 14.04 now at last supports "ARM64" (and "Power", "not" PowerPC). ARMv8-A is a mouthful.. and in addition I prefix with 64-bit. I've been using ARMv8-A, as ARMv8 isn't always 64-bit (ARMv8-R). Would you use that (or even AArch64 or A64..) or ARM64, would that fall under WP:COMMONNAME? Do not like all article, not just ARM-specific, to be inconsistent. comp.arch (talk) 12:13, 23 April 2014 (UTC)

See this revert. "Nobody" online/vendors (eg. Ubuntu/Cannonical) is using AArch64. ARM64 seems to be the WP:COMMONNAME. I've been using ARMv8-A, that is an architecture that includes AArch64 and AArch32, that is 64/32-bit. AArch64 is only 64-bit and is not a good substitute I think. When thinking about it ARMv8-A is not good either for other than my previous reasons - there will be ARMv9, that will also be 64-bit with some minor upgrades, I guess. I've been using ARMv7 (where ARMv6 is not supported). While all pre-ARMv7 are the "same" 32-bit Architecture as ARMv7 in some sense they are not, they are new backward compatible versions (but not vise versa). comp.arch (talk) 17:22, 23 April 2014 (UTC)
Speaking of your revert to "List of CPU architectures", your original edit said "ARMv8-A". ARMv8-A is more like a microarchitecture, rather than architecture. Like all the ARMv7 variants that implement mostly the same instruction set: they are not distinct architectures.
I'm fine with calling it either AArch64 or ARM64. But I still take issue with your usage of "64/32-bit". Unlike the x86-64 transition, the AArch64 architecture was completely redesigned and is very different from 32-bit ARM. It is not a superset of the 32-bit variant. I believe it's more accurate to list it simply as "64-bit". Future ARM processors will eventually drop support for old 32-bit code. -- intgr [talk] 23:32, 23 April 2014 (UTC)
A microarchitecture is an internal processor design. ARMv8-A does NOT specify an internal processor design, so, no, ARMv8-A is not even remotely like a microarchitecture. Guy Harris (talk) 03:29, 24 April 2014 (UTC)
Alright, but that's unrelated to the issue here. I'm saying that it doesn't make sense to list ARMv8-A (or ARMv7-M, ARMv7E-M, ARMv7-R, ARMv7-A, ARMv8-R) on the List of CPU architectures article. The fact that ARMv8-A supports two instruction sets does not make it a distinct ISA. I believe that AArch64 (sometimes called ARM64) is the proper 64-bit architecture and that it should not be said to be "32/64-bit". -- intgr [talk] 12:25, 24 April 2014 (UTC)
Yes, ARMv8-A is not a microarchitecture, it's an architecture. Just as "ARM" usually means the family or umbrella for ARMv1-ARMv7 (or even including ARMv8*), we need to agree what to use for ARMv8-A+. I like ARM64 for that as a synonym for now. If/when we get ARMv9 then ARM64 would cover that. If AArch32 is dropped I'm not sure it would be a problem. Yes, AArch64 is an architecture and ARMv7 (and ARMv6 etc.) is an archtecture, but ARMv8-A is also an architecture that happens to include two architectures/ISAs.. that is including AArch32 (a synonym almost for ARMv7). Right, only AArch64 might survive at some point in the distant future, but would that fall under WP:CRYSTAL. In this page all versions are listed as architectures (in table) but also grouped as two. In the other I would only list two as a high level overview. comp.arch (talk) 20:43, 24 April 2014 (UTC)
Yes, AArch64 is only 64-bit. ARMv8-A is 64/32-bit, and ARM64 if that is a synonym. As the only 64-bit version is ARMv8-A in two ARM cores and A7 and maybe more, that all include AArch32, ARMv8-A is 64/32-bit. The only thing dropped so far from ARMv8-A is AArch64 in ARMv8-R. I wish they would just have called it ARMv8b or ARMv7.5.. I'm not really sure what the difference is, does it have some of AArch64? AArch32 is optional? Are there any AArch64-only implementations? Then ARM64 would be ambigious.. comp.arch (talk) 20:52, 24 April 2014 (UTC)

FYI: AMD's K12 ARM-derived core

Would this source be considered reliable ("I/O ring around the edges of the chip and the last-level cache"):

These two CPU microarchitectures will be, in the words of CTO Mark Papermaster, "sister cores." (Papermaster came to AMD from Apple, and he managed to lure CPU architect Jim Keller from Apple, too, shortly after Keller led the development of Apple's own 64-bit ARM core.) Keller explained during this morning's Q&A session that the new cores will share more than just pin compatibility. He said they will be "compatible at the pin level and inside." That likely means that the ARM and x86 SoCs based on these new cores will share the same internal plumbing—things like the I/O ring around the edges of the chip and the last-level cache. AMD's design teams will then be able to fit, say, four ARM cores or four x86 cores into the space on the interior section of the chip.
Presumably, these sister x86 and ARM cores will perform about the same, but they evidently are not just two variants of the same microarchitecture adapted to different ISAs. Keller was very complimentary about the ARMv8 ISA in his talk, saying it has more registers and "a proper three-operand instruction set." He noted that ARMv8 doesn't require the same instruction decoding hardware as an x86 processor, leaving more room to concentrate on performance. Keller even outright said that "the way we built ARM is a little different from x86" because it "has a bigger engine." I take that to mean AMD's ARM-compatible microarchitecture is somewhat wider than its sister, x86-compatible core. We'll have to see how that difference translates into performance in the long run.

Is it appropriate to include K12 in the article (not violating WP:CRYSTAL)? Pin compatible with x86 seems only natural for AMD and not that big of a deal for end-users. [Could continue with speculation and slightly of-topic questions here or on my talk page if people want it there.] Note also that AMD estimates ARM to be number two after x86 in revenue, not far behind. comp.arch (talk) 15:01, 6 May 2014 (UTC)

Nobody commented. I'll just add K12. Their "ambidextrous" business model involves hedging their bets and selling x86 and ARM but not in the same processor. Could you however have two sockets and use both in the same machine? Or swap the main/only x86 out for ARM (would the BIOS not be a problem?) There might not be much of a market for that, or point with having both in the same system? There however an x86 out from AMD with Cortex A5 [7] that I'm not sure if is usable for anything other that it's indended security purpose. comp.arch (talk) 14:15, 12 May 2014 (UTC)

FYI: Combined ARM and x86 in one AMD chip.. speculated, [socket-compatible for either confirmed]

As I talked about above, I'm not the only to forsee this: "the final piece of the puzzle that AMD didn’t mention — an SoC architecture that we ultimately believe could combine ARM and x86 hardware on the same die" [8]. Probably too soon to mention in the article. Also an interesting paper: "The ISA being RISC or CISC seems irrelevant", pointed to in comments to the article by its author. comp.arch (talk) 14:08, 23 May 2014 (UTC)

Hardwired zero register?

Processor register: ARMv8-A: "In addition, register r31 is the stack pointer or hardwired to 0". I've found sources saying this but not official ones (or did I overlook it?) [9]. In general in architectures hardwired zero "registers" of course reads as zero, I wander what happens when "writing" them, do they generally ignore or trap? Not really a problem for me to know, assemblers probably do not allow it. In the case of ARM, writing could change the SP, or as I suspect "hardwired-zero" is just bad reporting that was just assumed (and got repeated). ARMv8-A has special instructions for procedure calls that affect SP but can it also be read as a general register? comp.arch (talk) 11:59, 23 May 2014 (UTC)

The official source is the "ARM® Architecture Reference Manual ARMv8, for ARMv8-A architecture profile", which you can get to by
  1. registering for an account on arm.com;
  2. going to the document index, opening "ARM Architecture", opening "Reference Manuals", selecting the "ARMv8-A Reference Manual", and acting as if by registering for an account on arm.com that you are now a "registered ARM customer", which, apparently, you would be.
It seems to be saying that there are 31 GPRs (unlike ARM/MIPS/SPARC, where the documentation says there are 32 bit one of them is wired to 0) and that a register number of 31 means "stack pointer" in some instructions and "hardwired zero" in other instructions, with the assembler, presumably, only letting you say "SP" or "WSP" in the instructions where it means "stack pointer" and only letting you say "XZR" or "WZR" in the instructions where it means "zero register". See "General-purpose register file and the stack pointer" in the manual.
"I wander what happens when "writing" them, do they generally ignore or trap?" Generally, ignore. This can be used if, for whatever reason, you want to discard the result of an arithmetic operation, for example. "assemblers probably do not allow it." As I remember, they're quite happy to let you write to %g0 on SPARC, for example.
"In the case of ARM, writing could change the SP, or as I suspect "hardwired-zero" is just bad reporting that was just assumed (and got repeated)." Nope; see above. It's a bit weird, which is why I guess they say "31 registers"; what happens if you read from or write to register 31 depends on the instruction - it might fetch or modify the stack pointer, or it might fetch 0 and discard the data being written. Guy Harris (talk) 19:12, 23 May 2014 (UTC)

Confusing sentence in lead

Companies that produce ARM products include Apple, Nvidia, Qualcomm, Rockchip, Samsung Electronics, and Texas Instruments. Apple first implemented the ARMv8-A architecture in the Apple A7 chip in the iPhone 5S.

The use of the word "produce" is a little strange when, if I'm not mistaken, only Samsung and TI have fabs. If it is meant to be "companies that design chips using ARM architecture" then surely the list would be longer, in which case would mean it wouldn't warrant inclusion in the lead. It would probably be best to just skip it, if it must be included merely state the largest producer or designer (and state it as such) if such figures are available. Also the second line is bizarre - it's an article about ARM, who cares when Apple first used a particular version of their architecture?

I know, be bold but figured I'd post here first. Saves arguments later. 178.78.89.165 (talk) 01:14, 6 June 2014 (UTC)

I would say Apple should be mentioned somehow for sure. The 64/32-bit ARMv8-A is a new architecture, not a minor (or major) update as all versions before. Apple's iPhone 5S is the first one to use the architecture. And so far only? [At least in consumer (non-server) products. There are some server versions now, not sure those processors are yet in any products.] I would also say making the chips (fabbing) is less important than co-designing? Apple seems to have at least co-designed their versions of ARMv8-A (and ARMv7) - have modified microarchitectures. So does Qualcomm with a version of ARMv7 with Krait. Nvidia will do similar with ARMv8-A, but will first use a stock core. I believe they only have stock cores of older versions of ARM, but they have one with one extra lowpower core. I'm not the right person to ask how much design goes into that - not sure the "core" is changed. I believe all others use stock cores? comp.arch (talk) 21:23, 16 June 2014 (UTC)
Apple certainly deserve a mention in the history section if nowhere else: ARM Holdings was a joint venture with Apple and the company might never have prospered without them. The others came much later. Chris55 (talk) 11:51, 17 June 2014 (UTC)

Are Thumb only (eg. Cortex-M) still the "ARM architecture"? And emulating others in general

In a way it is unfair to say they're "ARM" as they do not have the full 32-bit instruction encodings in a technical sense. In a Wikipedia sense and as for mindshare.. we should say they are "ARM"(?). But I wander what would happen if you tried to run full 32-bit instructions on them, would you get an abort and could trap and emulate the instructions in software? (Is that in general what happens in all (newer) ARMs?) Note, all of them also have some 32-bit encodings. At least it would be useful for the lower cost ones to emulate the fuller ones? Would this trapping require OS support (microcontrollers might not have one.. but could have this/a small one?) I know emulating a more powerful one might not make much sense as would be slow, but might sometimes be ok if you only have binaries, not just assembly (or C code).

Are these Thumb* only ARM's assembly compatible with full ARM, while not binary compatible? If you take the full 32-bit assembly code, does the assembler just change certain 32-bit instructions to a sequence of 16-bit? If not, it could be done..? I vaguely remember them doing something like this, but maybe only to support the full thumb/Thumb2 on those who do not have full Thumb? I guess if they can to that then also for full 32-bit; Except if you really use to many registers(?) then you are really talking about a compiler.. Maybe it would be useful for code that doesn't use to more than 8 registers? Do the microcontrollers not have more than 8? This article (and ARM Cortex-M) could be clearer on that at least.. The encoding doesn't allow for more than 8 in general, but are there other instructions to access more as I may recall..?

The ARM microcontrollers are already used to emulate others (in a different way), at least the 4-bit Saturn. Anyone know of other examples 8051? PIC (the manufacturer "moved" from PIC to ARM, but not emulating?) x86..? comp.arch (talk) 11:56, 25 June 2014 (UTC)

Number of transistors (estimate)

[Continued from section above..] The original ARM was about 20,000 transistors, any idea if Thumb-only would (have to) take more? Much more, anyone know how many they have? I know they can have more features, but none have an MMU (just as the original ARM) and no cache, all all extra features seem to be optional. Any idea how expensive in transistor the extra features are, such as MPU (vs MMU) or Bit Banding? And none available with a cache? comp.arch (talk) 11:56, 25 June 2014 (UTC)

Most popular unqualified?

"most popular 32-bit one in embedded systems". I know 8-bit (eg. PIC) and other non-ARM are popular. As the smallest ARMs are now like a grain of dust without packaging it doesn't make sense to me to use 8 or 16 bit for size reasons (or maybe not cost, even ARM has open source implementation of older versions). Numbers might be hard to come by (for others; www.50billionchips.com for ARM), but could it be the most popular embedded period, by now? And even just most popular? ARM-based OSes probably have the largest installed base by (about) now, counting Android plus iOS or even maybe just Android. I know some (realtime) systems might have more than one (8-bit) core but so do non-realtime Android. comp.arch (talk) 13:21, 23 April 2014 (UTC)

ARM is easily the "number 1" embedded processor. The number of ARM as primary processor in smartphones is small compared to overall ARM count. Since ARM is a core, it's also embedded in IC chips that aren't known as microcontroller chips, such as 802.11 wireless chips, which some use an internal ARM to do the high-level work, so it makes it harder to determine a total ARM count. The best source for total numbers is ARM Holdings at arm.com. • Sbmeirow • Talk • 17:45, 23 April 2014 (UTC)
IF it's numer 1 embedded processor, regardless of bitness, it's probably the number one period. Anyone know of another type of processor with over 50 billion processors? Intel? AMD? Fair to combine them, x86? And x86-64? Not sure what is the post popular embedded arch. but it is probably not x86 (although it is also used). What was the last known most popular processor (embedded or not)? I don't like to say ARM is most popular unless it is true, and preferably that I can source it. I don't like to get reverted and people arguing here. Would 50billionchips.com do as a source? It striclty doesn't say most popular (I think), would challengers have to point to more popular of just say "not in source"? comp.arch (talk) 18:59, 23 April 2014 (UTC)
"What is the most popular embedded architecture"? Possibly ARM, possibly Intel 8051 and successors, possibly something else (but I suspect not). Guy Harris (talk) 21:30, 23 April 2014 (UTC)
"If you are making 10 million power supplies, it may be necessary to use an 8051 processor at 40 cents each, despite the additional engineering effort it takes to implement a phase-locked-loop in software."[10]
Would that be about the lowest cost CPU? Assuming that and ALL ARM's cost just average $1, 125 billion or more have to have been sold of 8051 or any other architecture or all dirt-cheap microcontrollers combined to sell for more in dollars. Would those volumes be credible? [The market would be split among many 8-bits, how many popular approx?] I think I'll claim ARM most popular and see if it sticks.. comp.arch (talk) 22:12, 23 April 2014 (UTC)
By volume is 50 billion credible for others or combined? comp.arch (talk) 22:40, 23 April 2014 (UTC)
"April 2002 the billionth personal computer was shipped. The second billion mark was supposedly reached in 2007."[11] Assuming 3 billion by now x86, it would have to sell on average 16,6 times higher than ARM to make more money. Assuming average x86 CPU $200, gives $12 for ARM (but includes microcontrollers). comp.arch (talk) 22:52, 23 April 2014 (UTC)
You can get an ARM-based NXP LPC810 for $0.50 at quantity 10,000 or $0.84 for quantity Q100, see Mouser. • Sbmeirow • Talk • 23:30, 23 April 2014 (UTC)
Hmm, that low.. thanks. Anyone know approx price range for ARM microcontrollers and for non-microcontrollers? And any guess about how many of the 50 billion are microcontrollers? As none of the 8-bit architectures have use for other than microcontrollers (by now or ever, the same ones) I guess they are all cheap, any guess at the top (and bottom) price? And same for 16-bit and would they sell in big volumes? comp.arch (talk) 23:52, 23 April 2014 (UTC)
"Would that be about the lowest cost CPU? " No. "Most popular" would be about the highest volume CPU, regardless of the cost. The lower cost of implementations of a given instruction set architecture might make it more popular than architectures with more expensive implementations, but popularity means "how many", not "how cheap". Guy Harris (talk) 03:33, 24 April 2014 (UTC)
8-bit processors are now probably of use only for microcontrollers; "ever" is another matter - there was a time when most personal computers had 8-bit processors. But we're asking about now, not "ever".
So the relevant questions are "how many ARM cores get sold per year?", "how many 8051 cores get sold per year?" and, if there are any conceivable competitors to ARM and 8051 in the "most popular ISA" competition, "how many cores implementing them get sold per year?" Guy Harris (talk) 03:41, 24 April 2014 (UTC)
If per year, my guess is that ARM is most popular (that is by volume) for sure in recent years. ARM has the advantage of embedded plus other uses. [Well maybe you want to count Android as embedded.] x86 has embedded uses, would it be used much that way by now? MIPS also, but mostly now. 8051 would only be embedded. The 8-bits I remember, Z80 and 6502 where popular but not microcontrollers and hardly much used now. I was thinking most popular ever, comulative over the years but per year or since some point is also interesting and easier to estimate. Would you think 8051 end similar would still be popular in recent years? comp.arch (talk) 20:13, 24 April 2014 (UTC)
"Would that be about the lowest cost CPU?" was about would 8051 be the lowest cost CPU, if not anyone know which one is lowest cost or lower than 40 cents (in volume). I was just assuming the lowest cost CPU(s)/ISA would probably be most popular for embedded. I'm just not sure where to start Googling for a potentially more popular CPU. And estimating most "popular", as in selling most in dollars seems to have been misguided, probably not ARM (yet) and difficult to estimate as usually not sold separately. comp.arch (talk) 20:25, 24 April 2014 (UTC)
Excellent questions, Guy Harris, and ones I think Wikipedia articles should answer. I recently added[12] such information to the PIC microcontroller article.
I would really like similar referenced numbers for other popular architectures added to their respective Wikipedia articles.
I agree with comp.arch that it is unnecessary and misleading for the article to state that something is "the number 1 embedded processor" when it is actually "the number 1 processor" without qualification.
I would really like sources to confirm or deny the statements Sbmeirow made claiming "ARM is easily the "number 1" embedded processor. The number of ARM as primary processor in smartphones is small compared to overall ARM count."
This ARM architecture article already references "The Two Percent Solution" (2002) which states 8-bit processors, selling over 3 billion new chips per year, outsold 32-bit and 64-bit processors combined by over 5 to 1. That seems to contradict Sbmeirow's statements, but I wouldn't be surprised if things have changed since 2002 -- can anyone find more recent data from a reliable source?
Do 4-bit CPUs still outsell 32-bit CPUs in unit volume?[13]
Since Microchip was the number 5 microcontroller manufacturer in 2009 (number 4 in 2010 after after NEC and Renesas merged in 2010)[14], and as far as I can tell all of the top 10 processor manufacturers sell mostly 8-bit processors, it seems likely to me that there still exists at least one 8 bit processor architecture that outsells any one 32 bit processor architecture.
As long as our sources use the qualifier "most popular 32-bit processor", and our sources seem to be saying that 8-bit processors outsell ARM processors in any given year, I think this article should also use the qualifier "32-bit" or "at least 32 bits" or similar. --DavidCary (talk) 02:53, 18 June 2014 (UTC)
As you can see from Figure 3 in "The Two Percent Solution", 4-bit are way behind 8-bit, because I assume they had no advantage on them (in 2002). I assume they will not gain any ground, while 32-bit has (for embedded). For the same reason 32-bit should be growing at the expense of 8-bit (and 16-bit)? Following the money, who sells more in dollars seems to be easier that figuring out who sels most quantity. And you can't rely on only one manufacturer for any architecture and I'm not sure where to start looking, but I expect ARM to be the most produced architecture, with no DSP selling more or any other processor architecture except maybe a handful of candidates in the 8-bit category. Two or three to look into? comp.arch (talk) 11:32, 18 June 2014 (UTC)
I did some checking that surpriced me in several ways (4-bit CPUs no longer sold it seems). Ordering by Unit price gives you $0.34800 as the lowest but it isn't! The lowest priced ARM there I could find is at $0.62 if you buy a SINGLE unit down to 0.36400 at quantity of 3,880+.[15] I found no 8051 there lower priced. The lowest cost microcontroller I've found so far is a PIC at $0.42 down to 0.31 at quantity 5000+. PIC microcontroller: "By 2013, Microchip was shipping over one billion PIC microcontrollers every year", but 10 billion ARM chips where sold in 2013. Are there clones of PIC (that sell in numbers)? Even being cheaper/est(?) doesn't seem to help to sell more than ARM. Is there anyone much lower priced than this 15% cheaper one? Maybe I'm comparing apples to oranges? Just looked at price and assumed you would pay more for ARM as you get more, do you get less? Anything important you can't get with an ARM (or if similar spec, are they then much more expensive)? "8-bit MCUs are the only MCUs that are readily available in PDIP packages"[16][17] comp.arch (talk) 15:53, 18 June 2014 (UTC)
The smallest ARM Cortex-M0 and Cortex-M0+ have become very cheap in the last year, and likely will replace large numbers of 8-bit and 16-bit microcontrollers. NXP LPC8xx, Cypress PSoC4, ST STM32F0xx families are all very cheap. • Sbmeirow • Talk • 18:27, 18 June 2014 (UTC)
Does anyone have a problem with me changing the article to not qualify ARM being the most popular architecture, as there are 10 billion processors a year (not sure about cumulative - then 50 billion ARM)? In 2009, the 8-bit segment (the only contender (left)), was about as big as the 32-bit one (the much faster growing segment), is very fragmented (in it 8051 at 65% of 8-bit seems not enough) while the 32-bit segment is much less so (ARM 75%). See also: Talk:List of common microcontrollers#Which microcontroller (architecture)would be most popular? And which dead? comp.arch (talk) 15:48, 23 June 2014 (UTC)
I'm a little confused -- there's one reference in the article for 10 billion ARM-powered chips shipped in 2013; but I see other references[18][19] that seem to indicate about 4 billion 32-bit MCUs shipped in 2013, out of 17 million total units.[20] Doesn't that imply that ARM sales must have been less than 4 billion in 2013?
If you can find a reference that supports the ARM being the most popular architecture, please add it to the article.
Meanwhile, as long all the references we have so far qualify it as the most popular 32-bit architecture, then why don't we say that?
Thank you for pointing out to me, with a link, that ARM processors have now fallen under $1. I find that fascinating.
Even with ARM processors practically free, there are still a few situations where it makes sense to use something other than ARM.
Rather than list them here, I went ahead and stuck some of them into the microprocessor article,[21] with a reference that lists a few more reasons.
I agree -- Talk:List of common microcontrollers is a better place to continue this discussion. --DavidCary (talk) 08:17, 28 June 2014 (UTC)

I did the math, in dollars ARM processor (not all, excluding at least standalone microcontrollers - not included on non-microcontroller chips) took at least 41.0% (most likely half way up to, but at most 45.3%) of the amount the whole of the x86 (non-embedded..) market sells for (possibly even Intel's number include Itanium..). ARM and x86 (and Itanium?) take up almost all of the CPU market, making ARM approaching a third fast.[22]

This CPU market as a whole is divided: 27.4% ARM plus Freescale and TI (2.9% combined in ARM and what? PowerPC for Freescale and? TI what in addition to ARM?), Intel 68% and AMD 4.8% (x86 and some Itanium?). VIA tiny (not in top 10, Itanium if included in Intel for sure larger I assume).

Note 1, this is not the whole of "ARM" market, they sell a lot in embedded, I would think a lot more than x86 (neither in these numbers). Note 2, I assume you can't or they don't exclude GPUs and non-ARM stuff from the numbers (don't know for sure, maybe not?) - Intel wouldn't(?). Note 3, this does not disprove ARM most popular, gives it great credibility unless the average ARM chip costs less than (conservatively) 37.6% of average Intel/AMD x86 (may be calculating this wrong, or 40.2% of Intel CPUs). Note as the numbers for Intel/AMD include servers CPUs etc. we are not talking just Atom/tablet CPUs.

Qualcomm gained 29% in a year, in dollars just over double of the AMD loss in x86 market..

When ARM embedded is added, ARM might sell most in dollars, have to find my numbers again for ARM and would need numbers for rest of embedded in dollars.. (assume not many x86 there anymore..) comp.arch (talk)

Multi-threaded ARMs - and custom in general

How difficult is it to do a custom version of ARM (like Apple's A7) and multi-threading in particular (seems more invasive/difficult). And how much (all?) is changed in the most custom versions? I hardly believed all when that was mentioned..

ARM has no multihreaded (SMT/"hyperthreaded") ARM version core that I know of. I started looking as most others have gone that route. I found (include somehow in this article - too soon?):

"Broadcom said in October it will roll out SoCs with quad-threaded, quad-issue, out-of-order cores made in a FinFET process, presumably the 14/16 nm node. That process won't be broadly available from foundries until sometime next year"[23]

"Broadcom is designing a custom quad-issue, quad-threaded, out-of-order ARMv8 processor that Gwennap expects will "raise the bar" in single and multi-core performance. The core will power SoCs aimed at server, comms, storage, and security systems. The fact the core is being designed in a 16 nm FinFET process suggests first parts may not ship until late 2014."[24]

"ARM used the event to describe enhancements to the Corelink interconnect for creating multicore ARM SoCs. In a keynote at the event, Gwennap said limits in memory bandwidth and pinouts remain the chief bottleneck for comms SoCs."

"The PowerPC still dominates in today's comms chips, followed by the x86 and MIPS. ARM only has "a toehold" today and could take five to ten years to rise up the ranks"[see chart, but note this is on comm chips, not about the full market; any reason ARM (even 32-bit) can't dominate this market?]

Probably non-ARM(?): "Taiwan-based Andes described its N1337 core [..] Separately, Andes unveiled FlashFetch a technique for handling repeated code sequences to reduce power and increase performance on flash-based MCUs using just 9,000 additional gates. For flash running at a quarter the host CPU speed, performance is improved from 54 to 120 percent while cutting power use of the flash in half"


"AMD's Hierofalcon will pack four to eight 64-bit ARM Cortex A57 CPU cores along with 10GBase-KR Ethernet and PCI Express Gen 3 links, targeting communications and storage systems. The 28nm device will go up against Intel's 22nm Rangeley"[25]

"The same thing is happening at Freescale and Broadcom -- all the major embedded guys are moving toward ARM," at the expense of MIPS and PowerPC."48-core SoCs ARM chips - two chips can be connected for 96 cores. comp.arch (talk) 11:47, 30 June 2014 (UTC)

What is an "extension"?

The article contains several times the word "extension", but its meaning is not clear. In pre-ARMv8, extensions were implemented via the coprocessor interface. But in ARMv8, I would say that, for instance, VFP is no longer an extension since VFP has always been there in this version (ditto for some other technologies). — Vincent Lefèvre (talk) 15:55, 21 August 2014 (UTC)

Well VFP is not versioned in ARMv8 as there is only one version there. It is however strictly optional. And I just found out the Cryptography Engine is also strictly optional. And 32-bit AArch32 backward-compatible ISA. What that means, I guess, is just that things such as these could be left out of the silicon chip (but are in all current and proposed implementation I think. FPGAs?), but hardly ever would (network chips have been mentioned; ARMv8-R actually leaves out the non-optional (in ARMv8-A) 64-bit stuff though.. but it isn't strictly the same architecture as ARMv8-A), and if you would try do use the associated instructions (you can check first to make sure they exist in control registers) you will get an illegal instruction (could possibly be trapped and handled?). All these things in ARMv8 are optional, but the word extension there is maybe not appropriate. For ARMv7 some things are also always included, only an extension in the sense of addition to say ARMv6. The first ARM2 had a coprocessor interface for some extensions such as usable for (but not limited to) floating-point. That interface in defined in the instruction set, but it seems to me it has mostly not/never? actually been used to control an external coprocessor - it has been on the same die. [Then there are new instructions, "extensions" if you will or defined in new versions of architectures that do not use the coprocessor interface.] comp.arch (talk) 12:11, 22 August 2014 (UTC)
Note: by "version", I meant ARMv8 (as opposed to ARMv7, ARMv6, etc.).
If a feature is well-specified and has some official status, I don't think that "extension" is the right word, even if it can be optional. For instance, many standards have optional features, but one doesn't say that these are extensions. IMHO, an "extension" has a connotation of (1) being specified/provided by third-party, or (2) being absent from the initial specification (e.g. of ARMv8, if one is talking about ARMv8), or (3) possibly using an interface designed for (1) and/or (2) — in this latter case, the word "extension" would refer here more to the way the feature is implemented than to the feature itself.
Vincent Lefèvre (talk) 20:45, 22 August 2014 (UTC)

ARM in baseband and in cars (and IoT/RFID?)

Besides having usually many cores (for eg. Android), baseband usually (always?) has a RTOS and a separate CPU - actually a microcontroller but most often (always?) on the same SoC - that can be ARM Cortex-R as of 2011[26] Any idea how common that is? First of, is it always (in most, recent phones) software defined radio (that is did pure ASIC stop being uses long ago? 2G?). I think Broadcomm is big in this, would they use ARM for it? Would ARM's rule (much of the market)?

Microcontrollers in cars have grown in numbers for years. That is the biggest users of uC (or about). Renesas is big in engine control(and they also sell ARM in cars), but most manufacturers have switched to making ARM. Not sure how many uC are needed for the engine itself, but even if non-ARM (Renesas) is more popular there is that 1 out of 70-300?

IoT might not be big yet to challenge ARM (or could most go with ARM). But there are huge numbers of RFIDs. I'm just not sure they have uC. Not passive ones? Active? Maybe, but only passive is huge in numbers. I only used number I would find regarding ARM popularity and assume the take RFID into account if needed. Would they mauke not do that and not think if them as an uC market? Anyway, might not matter if that market is divided among CPU archs, and even if not. How big is that market? Anyone guess? Not bigger in dollar or popularity I guess. comp.arch (talk) 20:59, 24 July 2014 (UTC)

What relevance has all this to the article? Your link about baseband seems just 'another application' of ARM. The production of ARM chips is several orders of magnitude greater than the number of cars produced worldwide and most RFIDs are passive devices. Chris55 (talk) 11:46, 25 July 2014 (UTC)
Sorry, just want to be really sure RFIDs do not put "ARM most popular" in question. For "most popular microcontroller architecture" (not just most popular 32-bit), how popular they are in cars are critical as a big segment. All smartphones have baseband and if say some non-ARM were dominant in that segment would also puts same into question (I think I can safely assume x86 in not more popular there in in embedded in general uC). Just trying to get a picture/know where to look for sources. ARM seems to be most popular however you slice it (and soon most sold also in dollars). comp.arch (talk) 12:12, 25 July 2014 (UTC)
Sounds like you're doing OR. But as for baseband processors, a quick look shows that at least half the manufacturers in the article use ARM so you may have some difficulty knocking it off its perch. I assume some companies still produce 4 and 8-bit processors but I'm not sure it's the same market. And do you know what worldwide vehicle production is? A mere 87m. Chris55 (talk) 15:45, 25 July 2014 (UTC)
Yes, OR - but ok to confirm (and really hard to get numbers, at least on 4-bits - the "underground"-market). 87m×50=4.3 billion microcontrollers in cars is a huge number (and for sure?) the biggest market for microcontrollers.[27]. Even if ARM had half of that if would be huge. "The first car to use a microprocessor was the 1978 Cadillac Seville. The chip, a modified 6802"[28] (an 8-bit - makes 4-bit unlikely in cars). For Luxury cars: "the number of microcontrollers has leveled off at about 100 per automobile, and prices for those microcontrollers have dropped rapidly" (see in comment for Nov 2013 ref I couldn't post because of protection filter). Midrange in developed market has about $350/3=$167 worth of Application processors (MCUs) - ARMs much?. comp.arch (talk) 16:48, 25 July 2014 (UTC)
I've never owned a luxury car, though I've driven in a few. But I'd dispute your "makes 4-bit unlikely in cars". The most important issue in cars is reliability and that is inversely proportional to the number of states (to some power). So keeping things simple is highly important. And if there are 100/car, I'd bet most are 4- or 8-bit or less. Chris55 (talk) 22:58, 25 July 2014 (UTC)
A bit of-topic, but sources I put here and all I've seen say 8-, 16- and 32-bit. Just as TV remote controls use (maybe not even anymore?, not just the fancy ones) I can see 4-bit in car remotes. I meant unlikely, not as in not a single one, but at least very few in numbers. Still I'm compsci (not electrical engineer - only wannabe) and not disputing reliably argument (but seems wrong for 4-/8-bit that I've seen) personally, but 4-bits are not sold anymore except of-the-radar (in Asia made in old process) and the automotive manufacturers I checked (eg. Renesas) do not sell them. comp.arch (talk) 18:57, 26 July 2014 (UTC)
Of topic: "for baseband processors, a quick look shows that at least half the manufacturers in the article use ARM", I couldn't really see that from the article. If you meant the RTOS listed, than the support ARM but also MIPS and PowerPC. And the list might not be complete.. But for the manufactures actually it's a "two horse race" (only for LTE?)[29] and I can't really see what RTOS use or if they use ARM. Another way is looking at what Apple and Samsung do and you are pretty much covered. Both use ARM but would the broadband also? I assume using MIPS or PoerPC for that could work but really no reason why to do that (on same SoC?) Excluding Intel is ok, maybe they'll use x86 (that nobody else seems to do) in their otherwise x86 chips?! comp.arch (talk) 19:20, 26 July 2014 (UTC)
"production of ARM chips" is 10 billion, not far of car uC figure. And I assume but do not know ARM might count cores, not chips to inflate numbers. Would like to know how many chips and cores and the division of uC to non-uC. And how many Cortex-R (that are a tailor-fit and targetted at cars). comp.arch (talk) 19:04, 26 July 2014 (UTC)
I think that Talk:List of common microcontrollers is a better place for this discussion of the popularity of 4-bit, 8-bit, 16-bit, and 32-bit chips. --DavidCary (talk) 02:29, 25 August 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:ARM_architecture_family/Archive_2&oldid=1083498550"