GCC Developers Consider Deprecating ARM64 ILP32 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67385

    GCC Developers Consider Deprecating ARM64 ILP32 Support

    Phoronix: GCC Developers Consider Deprecating ARM64 ILP32 Support

    ARM64 ILP32 is the Armv8 architecture with a 32-bit ABI rather than 64-bit -- akin to the "x32" x86 effort that never really took off on Linux. ARM64 ILP32 support never ended up making it into the mainline Linux kernel or GNU C Library but did appear within the GNU Compiler Collection. But years later and little use, GCC developers are consider deprecating ILP32 support ahead of its eventual removal...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • ayumu
    Senior Member
    • Oct 2008
    • 668

    #2
    Notably, RISC-V RV32I and RV32E have no such problem.

    It is inevitable that ARM will fall behind in tooling, against the industry standard ISA.

    Comment

    • hamishmb
      Senior Member
      • Feb 2022
      • 264

      #3
      RISC-V is not (yet) the industry standard, it's still in its infancy.

      Comment

      • Jabberwocky
        Senior Member
        • Aug 2011
        • 1211

        #4
        Originally posted by ayumu View Post
        Notably, RISC-V RV32I and RV32E have no such problem.

        It is inevitable that ARM will fall behind in tooling, against the industry standard ISA.
        I'm no ARM fan, but in the grand scheme of things this seems like a moot issue... Compared to something like segmentation that has happened in x86 and showing it's face in RISC-V.

        Comment

        • ayumu
          Senior Member
          • Oct 2008
          • 668

          #5
          Originally posted by Jabberwocky View Post
          Compared to something like segmentation that has happened in x86 and showing it's face in RISC-V.
          Let's not spread FUD. Thanks to RVA profiles,. there's no such problem as segmentation in RISC-V.

          There just is not, irrespective of how much ARM would love otherwise.

          Comment

          • brad0
            Senior Member
            • May 2012
            • 1014

            #6
            Originally posted by ayumu View Post
            It is inevitable that ARM will fall behind in tooling, against the industry standard ISA.
            That's nonsense and there is no such industry standard.

            Comment

            • juergbi
              Junior Member
              • Sep 2017
              • 5

              #7
              Originally posted by ayumu View Post
              Notably, RISC-V RV32I and RV32E have no such problem.
              That's not really comparable. 64-bit RISC-V CPUs often don't support RV32I. RV64ILP32 would be the equivalent of ARM64 ILP32.

              Comment

              • Jabberwocky
                Senior Member
                • Aug 2011
                • 1211

                #8
                Originally posted by ayumu View Post

                Let's not spread FUD. Thanks to RVA profiles,. there's no such problem as segmentation in RISC-V.

                There just is not, irrespective of how much ARM would love otherwise.
                That entire chain boils down to the trust that you have in the RISC-V Board of Directors since, with profiles or not, still have the final say. If there's large enough push back to their choices there will be segmentation. We have seen this in many industries and governments.

                You're saying I'm spreading FUD because you trust RISC-V Board of Directors 100% without looking into their background. That's a weak argument.

                I've looked at the board and seen the "eat your cake and have it too" mentality that at least 1 of 24 them are publicly and openly practicing. I'm the majority of the board will do the most possible to avoid segmentation, but there are some that value profits and are corruptible, just like any other group... not having any skepticism or scrutiny over the group that has all the power over the ISA doesn't seem wise.

                In conclusion, you trust the process 100% and I trust it ~90%. I think it's a good idea to keep an eye on it instead of just trusting bureaucracy blindly.

                Comment

                • adler187
                  Senior Member
                  • Jul 2009
                  • 120

                  #9
                  Just like x32 was a dead end, Aarch64 ILP32 mode seems to me to be a dead end too. Many ARM64 processors support 32-bit mode as well, but they run in AArch32 mode not AArch64. AArch32 is compatible with ARMv7, so existing software works with it, just like 32-bit mode on x86_64 mode runs in the traditional 32-bit protected mode and is compatible with existing software.

                  x32 and Aarch64 ILP32 mode both suffer the same compatibility problem. To support it, you need special code in the kernel, C library, the entire userland, plus compiler and assemblers, development tools, etc. And after you've done all that work, what does it buy you? For ARM you get an extra 15 GPRs and a dedicated Zero register, plus they're 64-bit wide instead of 32-bit wide; floating point registers are 128-bit wide instead of 64-bit. For ARM, you also get access to instructions on 64-bit data and all the other ISA changes between ARMv7 and ARMv8. But again, you have to rebuild the whole world to make use of it and break compatibility with existing 32-bit ARM software (unless you want to ship both ABIs).

                  Most desktop software nowadays is all 64-bit anyways and the benefits of 32-bit software don't really outweigh the costs of maintaining, building, testing, and hosting it vs just all 64-bit. The biggest benefit of 32-bit support is in compatibility with existing software, but all that is either x86 or ARMv7, anyway, so that is a detriment to both x32 and ILP32.

                  Comment

                  • adler187
                    Senior Member
                    • Jul 2009
                    • 120

                    #10
                    Originally posted by ayumu View Post
                    Notably, RISC-V RV32I and RV32E have no such problem.

                    It is inevitable that ARM will fall behind in tooling, against the industry standard ISA.
                    This is a complete nonsequitor. The whole discussion is about running 32-bit software on a 64-bit CPU, so RV32I or RV32E have essentially no bearing on this discussion.

                    RISC-V supports switching between RV32 and RV64, depending on processor support. This is equivalent to switching between 32-bit "protected mode" and 64-bit "long mode" on x86 or switching between A64 and A32 mode on Aarch64. The whole point of the ILP32 discussion is to support ILP32 mode while running in a 64-bit processor mode ie. RV64 (or long mode for x86, A64 for ARM). _Because_ RISC-V has a separate RV32 execution mode and ABI, it runs in to the same issues as ARM and x86: supporting an RV64 ILP32 mode would break compatibility with existing RV32 software. And in RISC-V's case, such an ABI would only give you access to wider registers and additional 64-bit instructions, since the number of registers and all the other things are fairly orthogonal on RV32 vs RV64.

                    Comment

                    Working...
                    X