treewide: isArm -> isAarch32 #37401
treewide: isArm -> isAarch32 #37401
Conversation
Ericson2314
requested review from
peti,
grahamc,
shlevy,
dezgeg,
dtzWill and
abbradar
|
Credit to @Mistuke for showing me these docs in https://github.com/haskell/cabal/pull/5221/files#r175566986 |
|
As to comparability, my preference would be to bite the bullet on master, and add a |
lib/systems/for-meta.nix
Outdated
| @@ -7,7 +7,7 @@ in rec { | |||
| inherit (lib.systems.doubles) all mesaPlatforms; | |||
| none = []; | |||
|
|
|||
| arm = [ patterns.isArm ]; | |||
There was a problem hiding this comment.
I'll get this next if this goes through.
|
Absolutely no. Just because the ARM Ltd. marketing department decides to come up with a new name for an instruction set that had been called 'ARM' for over 25 years does not mean it's a good idea to follow. Just as well Intel's marketing calls the 32-bit x86 architecture IA-32 and nobody calls it that either. Next to everything in the open-source ecosystem calls this architecture ARM. Thumb is not relevant to the discussion since ARM and Thumb instruction encodings can transparently call into each other within the same program. It's an implementation detail that ordinary programmers don't need to care about most of the time. E.g. even if you're compiling code for those ARM microcontrollers which only support Thumb instructions, you don't use a Now for AArch64, indeed some people made the annoying decision to be different and call it The current names used in Nixpkgs are widely-used standard names. The proposed name is inventing a yet another naming convention used by nobody else. |
|
@dezgeg Should Would you object to |
|
@dezgeg What I don't understand about your argument is I didn't rename any concrete architecture. CPP is a better of your argument. Yes We, with our monorepo, are not so constrained by backwards compatibility, and again, by not defining an |
|
Ping it would be nice to wrap this up. |
|
AArch64 is definitely not ARM and should not match For one, ARM code is 99% backward compatible between architecture revisions (modulo some deprecated instructions which will trap on new chips and can typically be emulated in kernel with just a loss of performance) as in ARMv5 binaries still run fine on ARMv7 chips. While most chips that run AArch64 can also run ARM code, some chips like the Cavium ThunderX on our Hydra support only AArch64 mode. Also to bring more confusion to the mix, there are also some CPU cores labeled "ARMv8-A" that only do 32-bit mode. Second, an ARM GCC can compile code for all ARM architecture revisions just by passing and ARM and AArch64 assembly language are not at all compatible. They even the changed the comment character in the AArch64 assembler syntax. (In contrast, some x86 assembler code in the kernel works for both the i686 and x86_64, with an admittedly obnoxious amount of macros). As far as I can tell, other distros don't treat AArch64 as ARM either. In Fedora's RPM spec files, So in short, the current names+behaviour match what other distros are using. I see no reason to be diverging from them. |
|
@dezgeg this PR get's rid of |
|
Good arguments on both sides, but I must say that getting rid of isArm gets rid of a potential source of confusion. 👍 |
|
Let's take this to a vote. |
|
The names Nix and the related projects are tools. Our users are expected to write their own packages for their internal company projects or whatever. And each time when the code they wrote that used to work just fine no longer works after upgrading Nixpkgs reflects badly on those tools. So renaming things around, removing or changing behaviour of existing interfaces has a cost. Therefore it follows that such changes simply should not be done if the actual benefits of the changes are miniscule compared to the pains of the code churn. |
|
@dezgeg I think your opinion is clear. Do you see a path toward consensus? If not, it seems like a vote is the best option. |
|
Hello people. Please vote. Thumb up and down this post. |
|
The ambiguity has bit me before; I think it's a problem. Seeing as this does not change any actual triples or rename any actual architectures, and only changes a superficial nix-level binding, I see no tangible drawbacks beyond an occasional user wondering why |
|
N.B. when I rebase I will add back an |
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
| @@ -41,6 +41,9 @@ rec { | |||
|
|
|||
| isEfi = map (family: { cpu.family = family; }) | |||
| [ "x86" "arm" "aarch64" ]; | |||
|
|
|||
| # Deprecated | |||
| isArm = isAarch32; | |||
There was a problem hiding this comment.
And also for the principle of back-compat
GrahamcOfBorg
added
6.topic: stdenv
|
There seems to be a consensus by voting, in line with that previously expressed in other mediums. I've rebased and added the deprecation. |
|
@edolstra any opinions on this sorts of tree-wide mass renames? |
Ericson2314
added
6.topic: portability
|
I don't see the backward compat: Grumble. |
|
Ah is that |
|
#40154 should fix it. Sorry I forgot to include this as part of the original PR. |
samueldr
removed
the
9.needs: port to stable
This is the last package reference to isArm. isArm is deprecated after 18.03. This substitution was performed tree-wide in NixOS#37401.
This is the last reference to isArm. isArm is deprecated after 18.03. This substitution was performed tree-wide in NixOS#37401.
isArm has been deprecated for three releases. All references have been removed. Tree-wide substitution was performed in NixOS#37401 21 months ago.
Following legacy packing conventions,
isArmwas defined just for32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv81 is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
Motivation for this change
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)