Talk:ARM architecture family/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Samsung - Really 64-bit?

"The first ARMv8-A SoC from Samsung is the Exynos 5433" - looking at the ref it's actually used in 32-bit mode and thought to never will be used in 64-bit mode. Now, if the software is not available to enable it but they could later (even if they might not) then it is ARMv8-A. But academically, if you could only run it in 32-bit mode (maybe for hardware reasons? seems might be the reason from the ref), is it then really the first 64-bit ARMv8-A from Samsung, big.LITTLE or not? comp.arch (talk) 20:34, 17 September 2014 (UTC)

It depends on the point of view. But I've added the fact that it will run only in 32-bit mode. Vincent Lefèvre (talk) 00:54, 18 September 2014 (UTC)

Please define core

The following sentences seem inconsistent: "ARM Holdings develops the instruction set and architecture for ARM-based products, but does not manufacture products. The company periodically releases updates to its cores." Cores are hardware, aren't they? Could a subject matter expert please define core and ensure the word is used consistently in the article? 3dimen (talk) 02:56, 4 October 2014 (UTC)

"Cores are hardware, aren't they?" Not necessarily. Guy Harris (talk) 06:38, 4 October 2014 (UTC)

The "cores" are designs/plans, not the finished hardware. It's like an architect designing a building interior and selling it to multiple clients, each of which can design their own front, back, roof, etc before actually building it. Does that help? --Imroy (talk) 13:33, 4 October 2014 (UTC)

Cores can be purely "software", in case of ARM Cortex-M1 (only this one core?), for an FPGA. comp.arch (talk) 11:26, 6 October 2014 (UTC)

Vulcan first threaded ARM? Only transactional support missing? Branch prediction - what makes for fast?

See my edit and most recent there. Anything to add there/simplify?

It seems ARM is closing the performance gap - "90% of Hawell" for a single thread (w/lower power, more throughput). ARM can have more cores than x86 (how many more?) and more than Power(PC), SPARC, MIPS (what else is there mainstream..)? Did Tilera kind of not make it (compared to ARM)? - acquired in July for $50 million in cash..

With the new simple 64-bit arch it seems ARM learned from it's mistakes and others. x86, Power, SPARC (others?) had threading, if I'm not misunderstanding Vulcan has that. x86 and Power have transaction support - still do not see that (or L4 cache (support)) in ARM. Could be added? Anything else missing from ARM? Anything that makes it slower?

Newest Intel's x86 is impressive (45 MB cache) and increased single-threaded performance. I assume with same cache amount ARM could be made as fast? comp.arch (talk) 16:09, 10 October 2014 (UTC)

Odd number of cores - literally

Apple A8X and at least transistor count has been updated to three core confuguration based on benchmark data[1]. Is this a first (for ARM) for non-heterogenous (unlike Infineon TriCore). Any reason Linux/Android couldn't work in an unusual config like this? comp.arch (talk) 22:17, 22 October 2014 (UTC)

History/background paragraph

The final sentences of the History paragraph are badly composed and need clarification or additional information. Who contacted Hermann Hauser - Furber or Wilson? Have there been any interviews with either Furber or Wilson to corroborate or elaborate on the information provided, perhaps by some incarnation of the media such as a documentary or television program? — Preceding unsigned comment added by 71.92.215.28 (talk) 05:14, 2 January 2015 (UTC)

Advanced RISC Machines not Acorn RISC Machines

The article says that when they spun off from Acorn, they called themselves Acorn RISC Machines. No they didn't -- I remember quite clearly that they changed the name to Advanced RISC Machines at that point, before later becoming simply ARM. I can't find a suitable source for that. Anybody? Farry (talk) 07:48, 8 April 2015 (UTC)

Fixed, with sources taken from ARM Holdings. Guy Harris (talk) 17:28, 8 April 2015 (UTC)

"Bit width" in this table is misleading

The "bit width" column in this table is misleading: it conflates the issue of the bit-width of the physical address bus with the bit-width of core processor registers and datapaths.

For example, early ARM devices only had 26-bit physical address lines (~64 million addresses) but I believe they had 32-bit registers and ALU just as do more modern processors with a 32-bit physical address bus (~4 billion addresses). The "26/32" description in the table doesn't convey this clearly.

The change that occurred in ARMv8 is of a different nature: most of the general-purpose registers and datapaths became 64-bit in this revision. The physical address lines are still only 48 bits in ARM's reference designs (see page 4).

I propose to remove the physical address width from the table entirely, since it's not really a constraint for any of the real systems out there, and instead to clearly list the 32/64-bit datapath differences which are what's actually relevant to most software.

Comments? —Moxfyre (ǝɹʎℲxoɯ | contrib) 07:47, 16 July 2015 (UTC)

arm syntax highlighting lost

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'arm' was unfortunately dropped, as can be seen with the plain text formatting on this page and others. If you want specialised 'arm' syntax highlight support again, it will need to be added to Pygments. I have put up a patch for 'arm' to fall back to using the 'asm' handler, which renders OK for the basic syntax I have tested. If there are any oddities with arm syntax which dont work with 'asm' handler, please let me know. John Vandenberg ^(chat) 11:19, 12 July 2015 (UTC)

Patch has been merged, so lang="arm" now renders using lang="asm". John Vandenberg ^(chat) 01:01, 23 July 2015 (UTC)

Link register (R14) is "GPR"

About this edit. I've wandered what best explains, GPR (that the infobox template uses), or number of registers (architectural..).

The LR (or R14) is a GPR (fully, at least when I programmed ARM2 assembly..). You could use it in leaf-code. Only a branch overwrote.

The SP (or R13) is actually also "GPR". This changed in ARMv8. Using it is complicated.. as you loose the stack.. so not recommended..

The PC (R15) is of course NOT a "GPR", but is a register..

Are you trying to conform across articles or just making right. A lot of stuff online says wrongly 16 GPR (I believe official documentation avoids that and says registers, higher numbers look better..). comp.arch (talk) 19:29, 19 August 2015 (UTC)

LR/R14: presumably if you use it as a GPR in a leaf routine, you've saved its value, so that you can return from the leaf routine.

SP/R13: The ARMv8-A manual says, in E1.2.3 "The general-purpose registers, and the PC, in AArch32 state":

In the AArch32 Application level view, a PE has:

• Fifteen general-purpose 32-bit registers, R0 to R14, of which R13 and R14 have alternative names reflecting how they are, or can be, used:

- R13 is usually identified as SP.

- R14 is usually identified as LR.

• The PC (program counter), that can be described as R15.

The specialized uses of the SP (R13), LR (R14), and PC (R15) are:

SP, the stack pointer

The PE uses SP as a pointer to the active stack.

In the T32 instruction set, some instructions cannot access SP, and for most T32 instructions ARM deprecates using SP as a general-purpose register. The only T32 instructions for which the use of SP is not deprecated are those designed to use SP as a stack pointer.

The A32 instruction set provides more general access to the SP, and it can be used as a general-purpose register. However, ARM deprecates the use of SP for any purpose other than as a stack pointer.

-------Note--------------

• Using SP for any purpose other than as a stack pointer is likely to break the requirements of operating systems, debuggers, and other software systems, causing them to malfunction.
• Before ARMv8, for most T32 instructions, using SP as a general-purpose register was UNPREDICTABLE. In ARMv8, most of these uses of SP behave predictably, but are deprecated by ARM. The instruction descriptions give more information.

so SP/R13 is not 100% a GPR, at least not in the Thumb/T32 instruction set.

PC/R15: presumably you meant "The PC (R15) is of course *not* a "GPR", but is a register.."

So that's R0-R12 and R14 fully usable as GPRs, for 14 GPRs, and R13 *mostly* usable as a GPR (the "Using SP for any purpose other than as a stack pointer" applies even to ISAs where there *is* no dedicated stack pointer - it's a software convention, not a hardware restriction - but there are, apparently, hardware limitations in Thumb/T32), so *maybe* 15 as per ARM's introductory statement. Guy Harris (talk) 20:28, 19 August 2015 (UTC)

Right, fixed. Actually, I'm an idiot, I was off by one (for practically useful GPRs), thinking you where. Or was I? Should you count GPRs from the view of the machine, or what is most convenient for the programmer? As I said the SP (only a convention/alias, for R13, and technically you could use any register you like for a stack instead of R13, or have two etc.) wasn't anything special, at least in the pre-Thumb I knew (never programmed ARM assembly after ARM2, just try to keep up). If you want to discount it as a GPR, feel free to change back to GPR 14× and delete this thread as it's more embarrassing than the English (not my native language or an excuse) typos in edit summaries I can't fix (I try to fix all my errors, wish I could fix those too)..

You know more than me, all CPUs/languages built for, I'm familiar with use of a stack (or two), but are there languages or CPUs with no stack (use)? At least recursion wasn't always supported, so maybe you didn't need a stack? You could also preserve the SP to use in leaf routines, but that get's kind of ridiculous.. If you consider the SP "non-essential" or preservable, you can actually justify 15×.. Note also the SP is banked, so this doesn't interfere with kernel calls (SWI when I used ARM). Maybe using all 15 is more practical in kernel space. The infobox is a little constraining to explain such trivia, might not even be worthy of the article? comp.arch (talk) 09:13, 20 August 2015 (UTC)

I suppose that if some time-critical loop needs 15 registers, it is possible to save SP to some fixed memory location and retrieve it after the loop. Then SP/R13 can be used like any other GPR. So, 15 GPR's. Vincent Lefèvre (talk) 18:19, 20 August 2015 (UTC)

On A32, yes; to quote the ARMv8-A manual section E1.2.3, "The general-purpose registers, and the PC, in AArch32 state":

The A32 instruction set provides more general access to the SP, and it can be used as a general-purpose register.

On T32, no; to further quote that section:

In the T32 instruction set, some instructions cannot access SP, and for most T32 instructions ARM deprecates using SP as a general-purpose register. The only T32 instructions for which the use of SP is not deprecated are those designed to use SP as a stack pointer.

and

Before ARMv8, for most T32 instructions, using SP as a general-purpose register was UNPREDICTABLE. In ARMv8, most of these uses of SP behave predictably, but are deprecated by ARM. The instruction descriptions give more information.

As ARM didn't use the names "A32" and "T32" prior to the ARMv8-A manual, I'm not sure how we should refer to "32-bit ARM"/A32 and "Thumb/Thumb-2"/T32, but we should probably treat the ARM architectures as having three instruction sets - A64, A32, and T32, or whatever we want to call them - in this article and elsewhere. Guy Harris (talk) 19:44, 20 August 2015 (UTC)

But T32 is a different instruction set. One would need to differentiate A32 and T32. This is similar to 64-bit x86, which still support the 32-bit ISA as well. What if a new ARM instruction set were added (just like T32 was added at some point), where only R0-R7 would be supported as GPR's? Would you reduce the number of GPR's of such a processor to 8? Vincent Lefèvre (talk) 12:03, 21 August 2015 (UTC)

Yes, that's my point - there are three separate instruction sets in the ARMv8-A version of the architecture, and two in at least some other versions; you can't say how many GPRs are in the ARM architecture, or even in the 32-bit ARM architecture. You can say that the A64 instruction set has 31, A32 has 15, and T32 has 14. I might not call the latter two just "A32" and "T32", however, as, whilst those names are used in the ARMv8-A manual, the ARMv7-AR manual speaks of "the ARM instruction set" and "the Thumb instruction set" (which includes "Thumb-2 technology", so they don't speak of "Thumb-2" as an instruction set). The latter manual says that:

In the application level view, an ARM processor has:

• thirteen general-purpose 32-bit registers, R0 to R12
• three 32-bit registers with special uses, SP, LR, and PC, that can be described as R13 to R15.

and later says that the SP, whilst not usable as a GPR in Thumb, is usable as a GPR in ARM and that "When software does not require the LR for linking, it can use it for other purposes."

The ARMv7-M manual says it only supports Thumb.

And if ARM decided that three instruction sets isn't enough, and the XYZZY32 instruction set only supported R0-R7, we'd then say "31 for A64, 15 for A32, 14 for T32, 8 for XYZZY32". Guy Harris (talk) 19:07, 21 August 2015 (UTC)

Right, Vincent, what I had in mind, but this breaks some assumptions, at least most programmers have. From the view of the machine, the SP is GPR - period (except T32..), but the programmer, it certainly isn't :) I see the official docs say 15 so, I guess we stick with that. I'm not sure what compilers do, but I doubt, they reuse SP in this way, while they might and probably do reuse the LR. It was just a trivia question for me, and Harris, about language support (old ones). No need to answer that or add in the article. Still is anything on this worthy there? Or just too much trivia? People can just look up the official docs (or this talk page) and might do/already have. comp.arch (talk) 09:32, 21 August 2015 (UTC)

What a compiler does doesn't matter here. What matters is the processor alone, without considering the OS or some official API. There are processors (e.g. SPARC) / OS where some GPR's are reserved for special purpose by compilers, a bit like SP and LR on ARM. For instance, for SPARC, it is said 31 GPR's (as %r0 = 0). But %r14, %r15, %r30, %r31 have special meanings for compilers: https://en.wikibooks.org/wiki/SPARC_Assembly/SPARC_Details Vincent Lefèvre (talk) 12:03, 21 August 2015 (UTC)

Exactly. Guy Harris (talk) 19:10, 21 August 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on ARM architecture. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20150816084839/http://www.arm.com/miscPDFs/14128.pdf to http://www.arm.com/miscPDFs/14128.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 16:37, 28 August 2015 (UTC)

Wrong Wayback Machine link chosen (unfortunately, a bot might have difficulty discovering that). I fixed that, and also make the reference use {{cite web}}. Guy Harris (talk) 17:30, 28 August 2015 (UTC)

Originally acorn, later advanced

The following edits to ARM architecture by 78.90.51.68[2] and by 78.90.51.68[3] make it clear that they are from the same editor.

The edits attempt to introduce a factual error. The original name was Acorn RISC Machine, and was later changed to Advanced RISC Machine when the ARM architecture began to be used by non-Acorn Computers. --Guy Macon (talk) 15:31, 4 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on ARM architecture. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20121202034334/http://www.opensolaris.org/os/project/osarm/ to http://opensolaris.org/os/project/osarm/

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 18:58, 27 February 2016 (UTC)

Worked, although it was an archived version of a redirected page, so I changed both the original and Wayback Machine URLs to point to the target of the redirection. Guy Harris (talk) 20:17, 27 February 2016 (UTC)

Screenshot image copyright violation?

Unless I'm missing something, this edit removes an image for being a "copyvio image" whereas this edit to iOS reverts to a version that uses that same removed image instead of another image deemed to be a copyright violation.

So is the iOS 9 home screen image in question a copyvio image or not? Neither of the two images in question have, on their information pages, any claim of a copyright violation not covered by "fair use"; they have "non-free image rationales" for some pages - they don't have "non-free image rationales" for the pages from which they were removed; is that the issue here? Guy Harris (talk) 16:28, 12 September 2016 (UTC)

Reads well

Hello all,

I just read this Wiki article, to get a heads-up on ARM and I would like to say how well it scans (there are a few minor points) and how informative it is; some good work is behind this. CPES (talk) 10:51, 5 October 2016 (UTC)

"by far the most aggressive 64-bit ARM chip"; "like IBM;s work on Power 8" according to Hot Chips organizer; possibly made for Inspur to replace Itanium?

http://www.eetimes.com/document.asp?doc_id=1327526

"using 64 custom ARMv8 cores that will run at up to 2 GHz at 28nm. It can issue up to four instructions per cycle to hit up to 512 GFlops. The massive chip consumes 120W and fits in a 640mm2 die with about 3,000 pins. [..]
The so-called Mars design surpasses existing high-end ARM-based server chips such as the 48-core ThunderX now sampling from Cavium and a high-end part still in the works at Broadcom. In February EZchip said it will ship a 100-core ARMv8 made in a 28nm process, but it may not ship until 2017. [..]
“My God, who knew…this is by far the most aggressive 64-bit ARM chip to be announced – it’s just awesome, and it was definitely the surprise of this event,” said Nathan Brookwood, principal of Insight64 [..]
Hot Chips organizers were surprised to get a paper proposal from Phytium, a company they had not heard from previously. It had accepted several papers in the past from a China government- and university-backed team building the so-called Godson processor. [..]
Ralph Wittig, a Hot Chips organizer. “When we got the Phytium paper we heard from ARM they were confident the startup was doing real stuff…their external memory modules are like IBM;s work on Power 8…we were highly impressed as a program committee,” Wittig said."

http://www.nextplatform.com/2015/08/25/inside-chinas-homegrown-64-core-arm-big-iron-chip/

"specifically that it will be working on two classes of ARM-based processors: one aimed at scale-up machines and another one aimed at scale-out machines used in hyperscale and cloud computing. Zhang referred to the former as “mainframe servers” and the latter as “Internet servers,” [..]
The two families of processors that are under development by Phytium are called Mars and Earth. Mars is the one aimed at high-end, scale up architectures that are typified by mainframes, Unix servers based on RISC or Itanium engines, and the bigger Xeon E7 machines that have auxiliary chipsets from Hewlett-Packard, SGI, Lenovo, and a few others. As you can see from the chart above, the Mars ARM processors are aimed at systems that need to access large chunks of memory and have high bandwidth into memory and I/O to run workloads across coherent memory that spans lots of processor sockets. [..]
The Mars ARM server chips are based on a core design called Xiaomi, which is also the name of the world’s third largest smartphone maker [..]
the basic overview of the Mars processor, which is compatible with the 64-bit ARMv8 architecture and which presumably means that Phytium is a full licensee of the ARM architecture like [..]
The interesting thing about the Mars design, aside from the fact that it has 64 cores on a single die, is a set of features called the cache and memory chips, or CMC. This name implies that the CMCs are external to the Mars die, but they are not. [..]
which weaves together four banks of L3 cache memory with a total of [error, should say 128 MB here, as above?] and 2 MB extra for ECC data scrubbing. [..]
and also sport 128-bit SIMD instructions. Add it all up, and the Mars chip delivers about 512 gigaflops of peak double precision floating point performance and a memory bandwidth of 204 GB/sec [..]
On early benchmark tests, the Mars chip was able to do about 10 GB/sec on the STREAM Triad memory bandwidth test with eight cores activated and scaled up linearly to around 80 GB/sec of bandwidth with all 64 cores on the die humming. On the SPEC_CPU2006_base processor benchmarks, the Mars chip has a rating of 19.2 on integer math and 17.8 on floating point math running a single copy of the benchmark. If you fire up 64 copies of the benchmark and run the SPEC_CPU20006_rate tests on the Mars chip, it gets a rating of 672 on integer math and 585 on floating point math. [..]
This follow-on Mars core will have a more aggressive branch predictor, multithreading, more aggressive instruction-level parallelism, and a wider SIMD unit. The power efficiency will also be increased, memory bandwidth will be boosted, and more RAS features will be added. [..]
It does not look like Phytium is interested in building its own systems, but rather wants to sell its Mars and Earth ARM processors to others who do make machines to sell to customers. Inspur [biggest in China above Dell and Lenovo in revenue] has invested in an Itanium-based big iron machine called the K1 that runs the K-UX variant of Red Hat Enterprise Linux, and the company must be looking around for an indigenous alternative to Itanium with that processor clearly being sunsetted by Intel and Hewlett-Packard."

http://www.nextplatform.com/2016/01/06/arm-servers-throwing-down-the-25-percent-share-gauntlet/

"The Chinese government invested heavily in developing the “Godson” variant of MIPS [..]
(The Godson chips are interesting in that they can emulate X86 and ARM instructions.) China is investing in a variant of the Power8 processor through Suzhou PowerCore [..]
For the moment, there are on the order of hundreds of serious proofs of concept using 64-bit ARM servers, according to [..]
“There are a lot of seed units and there is a lot of testing, but I would not say that anyone has done anything at any kind of scale,” says Eastwood, referring to the ARM server shipments thus far. “So this 25 percent share in only five years’ time by ARM is a pretty bold statement. People wanted to paint ARM into the microserver corner, but microservers never really took off and the fact that there are 64-bit chips now changes the equation a bit. If you add up hyperscale, HPC, and China, that is probably more than half of the unit volumes in the server market – China is the second biggest market and maybe not quite 20 percent of shipments, hyperscalers are about 30 percent, and HPC is 15 percent to 20 percent. If you eliminate the overlap, you get pretty close to 50 percent of total worldwide shipments in these three areas.” [..]
So now all that the ARM collective has to do is get half of those three slices mentioned above and it can hit its 25 percent share target. [..]
What you can also see is that most of IBM’s [businesses] drop into the Others category that is shrinking fast in China. IBM has bet big that China will bet behind OpenPower, but Phytium is betting that ARM has a better chance." comp.arch (talk) 18:52, 8 October 2016 (UTC)

FYI: ARMv8.3-A (complex number instructions..), first 10 nm server (and smartphone) CPU, and e.g. questions

A. I added info in ARMv8.3-A. The basic info I copied, but after semicommas, my wording of reading sources.

I find much of it intriguing, and more (only here on talk).

First 10-nm server processor, is an ARM[4] Have they just surpassed Intel (at least for density; we'll see about performance). [I believe Samsung Galaxy S8 also is 10 nm.] Is there a loophole? can Intel's 14 nm be better than 10 nm (all things else equal..)?

B. I have to look more into the cache info.. anyone can clarify, add to it?

C. Anyone know of how if such restricted (or any at all) support in included by other [mainstream] CPUs. I can see how the rotates help, for exact 90 degress.. but really for arbitrary, not too helpful(?).

D. "Table 3-2 Supported ARM architectures"[5] tells me there are a lot more than I thought, e.g. "6S-M ARMv6 microcontroller profile with OS extensions." and "7E-M" but no ARMv6Z that I believe is an error at Raspberry Pi page (or about a chip, not an arch.).

Since there are separate 8.2-A.64 and 8.2-A.64.crypto (and similar for e.g. 8.3-A.64), it implies to me that the crypto instructions are optional. Maybe, and probably, all chips however support them. Is "optional" to much trivia to mention [then] IF true (seems the table is explicit)? Am I reading this wrong, this if from "fromelf" command with e.g. "--disassemble" option, so maybe it's just saying when you actually used crypto instructions..? comp.arch (talk) 22:30, 21 April 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on ARM architecture. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20061004150423/http://www.arm.com/miscPDFs/3822.pdf to http://www.arm.com/miscPDFs/3822.pdf
• Corrected formatting/usage for http://hub.opensolaris.org/bin/view/Project%2Bosarm/WebHome

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:02, 24 June 2017 (UTC)

FYI: mobile ARM (Exynos) in supercomputer prototype

I added in its article: "Samsung Exynos 5 Dual has been used in a 2015 prototype supercomputer, while the end-product will use a chip meant for servers from another vendor."

Add this in some ARM (even applies to Mali) related article? Or not, since prototype with Exynos is kind of trivia, however "The University of Michigan is deploying a $3.5 million “big data” compute cluster powered by Cavium’s ARM ThunderX SoC."[6] seems like non-trivia, and might already go in? Wait and see if in TOP500 November listing? comp.arch (talk) 17:28, 10 November 2017 (UTC)

References

Confusing architecture and implementation

ARM6 was an implementation. DEC licensed the ARMv4 architecture, not the ARM6 implementation of the ARMv3 architecture.

For history, see the introductions in van Someren and Atack's "The ARM RISC Chip" or Jaggar's "ARM Architecture Reference Manual" (v4). 206.80.4.98 (talk) 00:07, 19 December 2017 (UTC)

Fixed. Guy Harris (talk) 03:17, 19 December 2017 (UTC)

'Computer security' category

@Vincent Lefèvre: The article should be in the 'Computer security' category as it details the security measures the ARM architecture provides in the ARM architecture#Security extensions section. Jonpatterns (talk) 17:09, 29 December 2017 (UTC)

This is just a small section, and AFAIK, other processors also have their own security extensions. Or is there anything that makes the ARM architecture particular for computer security? What do the other think? Vincent Lefèvre (talk) 18:40, 29 December 2017 (UTC)