This is anarchive of past discussions aboutARM architecture family.Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on thecurrent talk page.
When does a CPU Architecture become a Company Marketing Bio?
In this article, apparently. I can't tell where the discussion of ARM processors and ARM Holdings begins and ends. They are NOT the same thing. This article should focus strictly on the devices and architecture, NOT the company and it's history. There should be a separate article for the company itself. This is blatant corporate promotion.98.194.39.86 (talk)15:59, 13 July 2017 (UTC)
The 32-bit infobox was split into two infoboxes, tagged "(Cortex)" and "(Legacy)", inthis edit.@Sbmeirow: why was the infobox split (and why was the "v6-M and v7-and-later" box was tagged "(Cortex)")? I'm not convinced it needed to be split at all; yes, v7 introduced new features, but so did earlier new versions. Furthermore:
much of the stuff is duplicated in the two infoboxes;
the "Extensions" differ, but Thumb-2 and DSP, whilst only in the "Cortex" infobox, actually appeared in earlier versions of the architecture;
this page suggests that VFP also appeared in earlier versions of the architecture;
My believe is that the main developer of SVE is not just ARM, but also Fujitsu, and SVE is heavily influenced by AVX-512, by extending it further to allow variable vector length, and by Fujitsu's previous HPC processor based on Sparc architecture. I have seen many presentations by Fujitsu on SVE, and their development of their own compiler that is automatically vectorizing code to use with SVE, but I actually do not know if SVE was defined by ARM before that, or Fujitsu cooperated with ARM to develop the instruction set itself.2A02:168:F609:0:DA58:D7FF:0:F02 (talk)15:00, 16 December 2018 (UTC)
Requested Addition by Arm
Hello, I work for Arm. I would like to request an addition to this page, as it currently makes no mention of the PSA, a crucial part of the Arm architecture.
The suggested addition is:
Platform Security Architecture
Platform Security Architecture (PSA)[1] is an architecture-agnostic security framework intended to help secure Internet of Things (IoT) devices built on system-on-a-chip (SoC) processors. It was introduced by Arm in 2017[2] at the annual TechCon event[3] and will be first used on Arm Cortex-M processor cores intended for microcontroller use. The PSA includes freely available threat models and security analyses that demonstrate the process for deciding on security features[4] in common IoT products. The PSA also provides freely downloadable application programming interface (API) packages[5], architectural specifications, open-source firmware implementations, and related test suites.
In SectionARMv8.3-A: "Improved JavaScript data type conversion support (AArch64 and AArch32); e.g. the new FJCVTZS instruction sets a flag when the conversion to 32-bit signed integer is exact, excluding −0, so that the next instruction can branch in this case."
Actually the main feature for JavaScript is that one gets a result modulo 232 (e.g. useful for the bitwise operations). Even though the source mentions the flag for exactness and its usefulness for JavaScript, I couldn't find in the ECMAScript standard where this flag can be used (even though one can imagine code that may use this flag as an optimization... but probably never in practical code).Vincent Lefèvre (talk)15:58, 11 July 2019 (UTC)
A Commons file used on this page has been nominated for deletion
The following Wikimedia Commons file used on this page has been nominated for deletion:
The following is a closed discussion of arequested move.Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider amove review after discussing it on the closer's talk page. No further edits should be made to this discussion.
In the case of System/360, for example, the IBM System/360 was a family of computers; it had an instruction set architecture, defined by the IBM System/360 Principles of Operation manual. Calling that instruction set architecture the "IBM System/360 architecture" doesn't appear to be an error to me; it's a particular characteristic of line of computers. The same applies to the PDP-11 and the Unisys 2200 series, although the line of computers is theUNIVAC 1100/2200 series, and that page also covers some older UNIVAC machines with "11xx" model numbers, as well as the line that started with the 1108.
IBM System/370 covers both the family of computers and its instruction set architecture.IBM System/390 does the same.z/Architecture covers the instruction set architecture (the name of which explicitly includes the word "Architecture"); there are separate pages for 1) the microprocessors that implement it and 2) the systems built from those microprocessors.
Clipper architecture is a page that covers both the Clipper line of chips and its instruction set architecture; arguably, it should be called "Clipper (microprocessor family)". This would be similar to, for example, theVAX page, which has a section describing the instruction set, but which covers more than just the instruction set.SPARC is another such page, as areRISC-V andPowerPC.
ARM architecture covers the instruction set, with all of its different versions, profiles, "execution states" ("AArch32" and "AArch64", although they don't call them "application architectures" or whatever "AArch" is supposed to stand for), and instruction sets (AArch32, and the only execution state of pre-ARMv8-A processors, support the 32-bit ARM instruction set, called "A32" for ARMv8-A, and may also support the Thumb and Thumb-2 instructions, called "T32" for ARMv8-A - the R and M profiles are different there - and AArch64 supports the 64-bit A64 instruction set), although some of it has been moved intoAArch64. There are various pages covering ARM's and other vendors' implementations of the architecture.
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Update desperately needed
As of right now, this article describes the "now" as it was in 2011, at the latest, with ARM being described as a 32-bit architecture. It then mentions in the lead that it has beenannounced that 64-bit architecture is coming in the ARMv8-A. The entireARM architecture#64/32-bit architecture section is a series of announcement after announcement, over a period of years, of successive plans for the ARMv8-A, giving the impression that the company keeps announcing things one after another without ever actually accomplishing any of it. If these thingshave occurred, then the series of events should describe what has beenreleased; after innovations have been released, it's no longer relevant to tell us that they wereannounced. And the lead should reflect the current state of the architecture, not what it was seven years ago.Largoplazo (talk)11:54, 22 April 2018 (UTC)
I think there may be confusion over the 'announcements'; because ARM does not manufacturer chips it just designs. Perhaps the announcements are stating a design is complete, hence its part of the job is done. It could be useful to state which manufacturers have created chips based on each of the designs.Jonpatterns (talk)12:17, 22 April 2018 (UTC)
I see your point, I think, but then it would be clearer to indicate that new specs have been "released". And the lead still speaks of the 32-bit architecture as the current state of the technology.Largoplazo (talk)12:25, 22 April 2018 (UTC)
I've updated the lede to make it clear that 64-bit is now support by ARMv8. To my knowledge all the architectures feature 32bit length instructions, including ARMv8 which has 64-bit addressing and arithmetic. The only exception being the Thumb which can use 16-bit length instructions.Jonpatterns (talk)13:07, 22 April 2018 (UTC)
32-bit is still current. It's a little confusing because there are two main instruction sets, AArch32 and AArch64. When ARMv8 was released it was believed to be the new 64-bit version, keeping compatibility with AArch32 too, but some ARMv8, i.e. the later ARMv8-R are only 32-bit. That is, all the microcontrollers are still only 32-bit (Thumb is however a complication, and yes, with 16-bit instructions).comp.arch (talk)21:49, 10 October 2018 (UTC)
threeinstruction sets - A32 (the 32-bit-instruction/32-bit-data-and-addresses ISA, descended from the original ARM ISA), T32 (the variable-length-instruction/32-bit-data-and-addresses ISA, descended from Thumb and Thumb2), and A64 (the 32-bit-instruction/64-bit-data-and-addresses ISA).
The A profile of ARMv8 has, in addition, two "execution states", AArch64 and AArch32. AArch64 includes:
"The AArch64 Application Level Architecture";
"The AArch64 Instruction Set", which is A64;
"The AArch64 System Level Architecture";
and AArch32 includes:
"The AArch32 Application Level Architecture";
"The AArch32 Instruction Sets", plural, which are T32 and A32;
"The AArch32 System Level Architecture".
ARMv7-A and ARMv7-R have two instruction sets, "ARM" and "Thumb"; "Thumb" includes Thumb-2. ARMv6, apparently, is similar, but Thumb-2 is an extension.Guy Harris (talk)19:31, 12 January 2019 (UTC)
ARM64 Microsofts release of .NET 5.0 includes ARM64 support now gives their 5 million programmer base access to compile on this instruction set. If anyone out there has deeper knowledge of ARM64 instruction set now is the time to create a spinoff page describing the instruction set. TheKevlar 13:20, 15 November 2020 (UTC)
December 2020 edit
Thisedit request by an editor with a conflict of interest has now been answered.
After completing the creation of thePSA Certified page, I am looking to update outdated information elsewhere on Wikipedia. A revised version of the Platform Security Architecture subsection of this page has been rewritten and expanded [Platform Security Architecture atuser:RichardDigital47/sandbox. Please also view my userpage to read my COI declaration.RichardDigital47 (talk)21:42, 9 December 2020 (UTC)
I agree. IMHO, this should be transformed into a text saying how this evolved in the history. And perhaps list the operating systems specifically designed for ARM (with some explanations). —Vincent Lefèvre (talk)15:22, 9 May 2021 (UTC)
Conditional execution example while..do vs. do..while.
While great work was done with the gcd algorithm conversion from 'C' to assembler, the assembler variant actually implemented a do..while loop rather than the 'C' which shows a while..do loop.
The most important point here is that the GT/LT calculations were always being evaluated before the NE test was being made.
While the EQ test would mean that the comparisons would just fall through, adding the test label and a branch to test outside the loop reflects the C code far more closely. Note that the original 'else' part of the 'C' is also not reflected in the pseudocode/assembly.was implicitly baked into the assembly based upon the GT/LT flags set by the CMP.
There was a comment "(no if(a<b) needed since a!=b is checked in while condition)" which seems to have forgotten that the prior command may change the value of a. As SUBGTS/SUBLTS also tests/sets the condition registers, we only need to do the explicit CMP at the top of the code.
These edits are more congruent with the 'C', and represent more optimal code.
20040302: Your changes were incorrect. If SUBGTS is executed, you have r0 > r1 and you are doing r0 − r1, so that the condition flags that are set correspond to GT. If SUBLTS is executed, you have r1 > r0 and you are doing r1 − r0, so that the condition flags that are set also correspond to GT. Thus if r0 and r1 are different at the start of the iteration, you'll always have the condition flags that correspond to GT at the start of the next iteration, whatever the new value of r0 or r1. This is not what you want. Because r0 or r1 has changed, the comparison is always needed before doing the subtraction, in order to know which subtraction should be done (r0 − r1 or r1 − r0), and setting the condition flags with the subtraction is useless. For instance, if you do the subtraction new_r0 = old_r0 − r1 and set the condition flags, what you get is the set of flags for the comparison between old_r0 and r1; but what is needed for the next iteration is set of flags for the comparison between new_r0 and r1.
Note also that the pseudocode does not intend to reflect the algorithm written in C: the algorithm written in C is the usual one, and what is shown is that little transformation is needed to get the pseudocode, then the ARM code. —Vincent Lefèvre (talk)01:53, 17 March 2022 (UTC)
Vincent Lefèvre, With respect, I couldn't agree with you less. It's correct that I should have used SUBGT/CMP pairs - but the logic of the original code is poor, and it is always important - when converting algorithms between languages / systems to replicate the underlying algorithm.
The fact that the current code switches from a while/do to a do/while is just an error. The code should choose just one, and keep to it. The inline rationale is unreasonable.
We see in the pseudocode that the "else" has now vanished - and therefore the algorithm is NOT the same (despite the comments) ...
if(GT) a-=B; if(LT) b -= a; //unwraps to two discrete if statements.
The assembly doesn't reflect the pseudocode either.
Instead it uses something more implicit to the original C - with the else being implied by the GT/LT test (being mutually exclusive).
Likewise, no consideration has been taken for timing. SUBGT is a 3pt operation whereas CMP is a 1pt operation.
Consider the following - (1) this follows a while..do, merely by branch to While at the beginning - a one instruction cost per function call, but saves time whenever r0/r1 start equal.
(2) with the addition of a cheap CMP we reflect the IF() found in the pseudocode, and likewise can afford to do both a r0-r1 and r1-r0 in a single loop. However, it is true it only saves a single loop, so I think it would be optimal to leave it out; but to do so it would be better to rewrite the pseudocode to use an else.
; assign a to register r0, b to r1BWhile; if the loop is not entered, we can safely returnLoop:SUBGTr0,r0,r1; if "GT" (Greater Than), a = a-b. and set condition flags.; CMP r0, r1 ; saves one loop at the cost of an instruction.SUBLTr1,r1,r0; if "LT" (Less Than), b = b-a. and set condition flags.While:CMPr0,r1; compare a and b and set condition flags.BNELoop; if "NE" (Not Equal), then loopBlr; if the loop is not entered, we can safely return
20040302: It is not a conversion of an algorithm, just a Euclidean GCD directly implemented in ARM. When writing assembly code manually, we almost never seek to literally convert high-level algorithms. Instead, we seek to write optimal code directly. Even compilers do not convert C code literally; they use some known transformations to generate better code. The current code is not a do/while since the comparison is donefirst; it is just ARM-specific code that is never expressed like that in algorithms. BTW, the opposite change to what you suggest above was done in 2006, inSpecial:Diff/35616155 with the comment "Assembly code streamlined so it better reflects structure of while loop". So someone thinks that this code better represents the while loop than your code. Anyway, as I've said, I don't think that one should seek to be the closest to the C code.
Concerning the timing, this depends on the processor. What you are doing with your proposed code is actually replace a SUBGT/SUBLT sequence by an unconditional branch (the "B" on the first line) in the executed instructions. IIRC, on the early ARMs, a branch was taking 2 or 3 cycles, so that your code is no better (and potentially worse). Moreover, the current code is shorter.
I agree aboutWP:NOR. But I think that this is a common example, and one should probably be able to find a proper source. I have an old book on ARM somewhere at home; I could check when I have some time.
In particular, there areinstruction set architectures and there aremicroarchitectures. A given instruction set architecture can have implementations with a CPU cache and implementations without a CPU cache; the only way that a cache would be taken into account in the instrution set architecture would be if that architecture specified that an implementation could have a cache and, perhaps, had, for example, instructions to prefetch into a cache or to remove entries from a cache, which would be no-ops on implementations without a cache.
The microarchitecture of a given implementation might include a cache.
This page is about ARM instruction set architectures, so all it can say about CPU caches is whether any of the versions of any of those instruction set architectures have cache instructions of the sort mentioned above.
(Also, if you're editing without an account, the IP address from which you edited a Wikipedia page is in the page history, so you can't hide it.)Guy Harris (talk)20:48, 25 January 2023 (UTC)
