Although ARM's license terms are covered by NDA, within the IP industry, ARM is widely known to be among the most expensive CPU cores.
Do we have any source to back this up with? Also, most expensive in relation to what, per physical core, licence fees, price/performance? It would be interesting with a more throughout analysis, as it is now it doesn't make much sense and if it can't be expanded it should be removed.
"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."  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." 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)
Removed 32-bit features in ARMv8-A "see below for exceptions"
I think I put in "see below for exceptions" that was removed . 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)
move ARM architecture to ARM instruction set