Talk:ARM architecture family

Arm is sentence case?

Resolved

 – All instances of ARM capitalized except for references to the company. 120.159.128.133 (talk) 14:06, 9 October 2020 (UTC)

I've noticed that user User:JBMagination has changed all references to "ARM" in this article to sentence-case "Arm", citing company trademark policy. Doesn't this violate MOS:TM, as most sources still use Arm capitalized as "ARM"? ViperSnake151  Talk  21:45, 22 June 2020 (UTC)

If it is, I will gladly revert it. JBMagination (talk) 21:49, 22 June 2020 (UTC)

Please at least revert the names of the chips -- the CPU was never called the 'Arm1' but the ARM1, etc. MatthewWilcox (talk) 12:44, 9 July 2020 (UTC)

@ViperSnake151: Are you thinking of MOS:TMCAPS, which says

For trademarks that are given in mixed or non-capitalization by their owners (such as adidas), follow the formatting and capitalization used by independent reliable sources.

Note, though, that Arm isn't using mixed capitalization (if by that they mean camel case or stuff such as eBay and iPod) or non-capitalization, as they're capitalizing it proper-noun-style.

(This is a bit like Sun Microsystems, where the "Sun" originally came from the Stanford University Network, for which the original SUN workstation was designed, but - as I suspect I've said about a trillion times in USENET posts :-) - they were "Sun Microsystems", not "Stanford University Network Microsystems". The change from "ARM" to "Arm" didn't happen when the company was created, so it's not exactly the same, but it might be a bit similar.) Guy Harris (talk) 22:49, 22 June 2020 (UTC)

• Re: MOS:TMCAPS ("follow the formatting and capitalization used by independent reliable sources"}. Arduino[1][2] and Raspberry Pi[3][4] use ARM. Also see [5][6][7][8][9][10][11][12][13][14][15] --Guy Macon (talk) 02:18, 23 June 2020 (UTC)

I'm not sure about this change, but I think that ARM should be retained at least in the history section to reflect the way it was written at that time. And what is used in official documents? (For instance, in France, the public institute INRIA has been deacronymized to Inria for the communication, but this has not been changed in legal texts yet.) Vincent Lefèvre (talk) 09:33, 23 June 2020 (UTC)

• Please revert. If there is a stylisation change going forward, then this can be reflected in the article, if/when the usage reaches wide-scale acceptance, ie. in the mainstream press. …The historical naming should probably remain as it has for the last ~35 years, since that is what is being reported/summarised in the majority of the article. TL;DR: ideally ARM1; or as an imperfect compromise, formatted as Arm1 could also work. —Sladen (talk) 13:40, 9 July 2020 (UTC)

• Someone has gone through with a machete changing ARM to Arm - presumably what is referred to in this section. This includes all the historical references. The Acorn RISC Machine architecture was "ARM" not "Arm". There was never an "Arm610 microprocessor". etc. etc. Almost none of the usages of "Arm" in this article make any sense whatsoever. This article is not about the company which has renamed itself, and they cannot rewrite history. You'll note that even Arm themselves use "Arm" for the company and "ARM" for the architecture and the chips - e.g. https://developer.arm.com/documentation/den0024/a/armv8-a-architecture-and-processors/armv8-a - making these Wikipedia changes even more nonsensical --Davidcx (talk) 20:37, 15 September 2020 (UTC)

Apart from anything else discussed just above, I would suggest altering the phrase "usually written as such today' to "often still written as such" NotesTracker (talk) 12:15, 20 September 2020 (UTC)

Ironically ARM make AMD's x86 insecure?

I've not yet read all the security paper saying: "The AMD Secure Processor, the gatekeeper responsible for the security of AMD processors, contains critical vulnerabilities." Note the AMD Platform Security Processor (I assume the same thing), built into their x86 CPUs, is ARM with TrustZone.

It's not clear that the ARM core and/or TrustZone (never looked to closely at it) is to blame and most reporting doesn't mention ARM but rather the non-open source code it runs. It seems it is to blame, possibly not the core running it. Be aware of that before blaming ARM here on this page; this is just FYI, and for discussion here.

Other links maybe helpful (first one where I discovered this before looking up the others):

https://www.wired.com/story/amd-backdoor-cts-labs-backlash/

https://hothardware.com/news/amd-processors-and-chipsets-ryzenfall-chimera-fallout-security-flaws

https://www.amd.com/en/technologies/security comp.arch (talk)

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 (talk) 10:48, 16 March 2022 (UTC) )

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 r1
        B    While           ; if the loop is not entered, we can safely return
Loop:   
        SUBGT  r0, 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.
        SUBLT  r1, r1, r0   ; if "LT" (Less Than), b = b-a. and set condition flags.
While:
        CMP  r0, r1         ; compare a and b and set condition flags.
        BNE  Loop           ; if "NE" (Not Equal), then loop
        B    lr             ; if the loop is not entered, we can safely return

Regardless, (and mea culpa too) ALL of this violates WP:NOR. We should be citing sources, rather than discussing code styles. (20040302 (talk) 13:49, 17 March 2022 (UTC))

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 done first; 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, in Special: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 about WP: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.

— Vincent Lefèvre (talk) 15:33, 17 March 2022 (UTC)

CPU cache?

Does the CPU have cache? Why is this not addressed in this article? Is there some systemic problem at Wikipedia?

DO NOT PUBLISH IP 61.68.121.74 (talk) 12:45, 25 January 2023 (UTC)

This is about the architecture, not the CPUs (except for the history). See Comparison of ARM processors for the processors. — Vincent Lefèvre (talk) 18:10, 25 January 2023 (UTC)

In particular, there are instruction set architectures and there are microarchitectures. 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)

No instruction set?

ARM instruction set redirects here. Wouldn't it be better to list the instructions there? This page doesn't list the instructions, and I am looking for them, so I would greatly appreciate it. Joao003 (talk) 17:18, 17 October 2023 (UTC)

It would be better not to list instructions on Wikipedia, at least for instruction sets with lots of instructions. I'm not sure whether x86 instruction listings should exist, for example.

If you want ARM instructions, go to https://developer.arm.com/architectures and look through the search results for what you want. Guy Harris (talk) 19:31, 17 October 2023 (UTC)

"No support for unaligned memory accesses in the original version of the architecture"

Is this true? Per the ARM2 data sheet (emphasis added): "A word load (LDR) should generate a word aligned address. An address offset from a word boundary will cause the data to be rotated into the register so that the addressed byte occupies bits 0 to 7. External hardware could perform a double access to memory to allow non-aligned word loads"

To me that doesn't sounds like "no support" as this article currently claims; it clearly farms the stuff of doing two 32-bit accesses and combining parts of each to external hardware but appears to offer a helping hand should the system be set up to do that — the external bus merely needs to gate each of the four bytes to ensure it presents each from the correct access, it doesn't need to rotate them into place.

I'd call this negligible support, but not "no support". 96.234.17.8 (talk) 18:19, 28 March 2024 (UTC)

I agree. That's more a special behavior than no support. I'm wondering whether this was exploited in practice. — Vincent Lefèvre (talk) 02:02, 29 March 2024 (UTC)