Announcement

Collapse
No announcement yet.

Intel Is Trying To Support The x32 ABI For LLVM/Clang

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Is Trying To Support The x32 ABI For LLVM/Clang

    Phoronix: Intel Is Trying To Support The x32 ABI For LLVM/Clang

    While adoption of the Linux x32 ABI hasn't really taken off with most developers and end-users doing just fine with x86_64-compiled software, Intel is trying to get things back on track for supporting x32 by LLVM and Clang...

    http://www.phoronix.com/vr.php?view=MTczMjg

  • #2
    Why? Seriously intel, just drop your 32 bit platforms already. This is getting old.

    Comment


    • #3
      Originally posted by schmidtbag View Post
      Why? Seriously intel, just drop your 32 bit platforms already. This is getting old.
      Please, if you don't know what you're talking about, just don't talk about it... If you had even read the article you would know it's not about 32 bit platforms...

      Comment


      • #4
        Originally posted by mdias View Post
        Please, if you don't know what you're talking about, just don't talk about it... If you had even read the article you would know it's not about 32 bit platforms...
        "The Linux x32 ABI about allowing programs to take advantage of x86_64 features (and being dependent upon x86 64-bit CPUs) while using 32-bit memory pointers."

        To me, this sounds like trying to use 64 bit features on 32 bit architectures. While it doesn't explicitly say this is for 32 bit architectures, I feel that is the intended use in the long run. While I rarely mess with languages like C/C++, I don't see why (if you're on a 64 bit system) to use 32-bit pointers expecting them to use x86-64 features when you could just use 64-bit pointers. If what I'm saying is wrong then sure, it might not have been great to presume the worst, but it still doesn't change the fact that intel has been dragging 32 bit products even into 2013 and I'm getting tired of it.

        Comment


        • #5
          Originally posted by schmidtbag View Post
          "The Linux x32 ABI about allowing programs to take advantage of x86_64 features (and being dependent upon x86 64-bit CPUs) while using 32-bit memory pointers."

          To me, this sounds like trying to use 64 bit features on 32 bit architectures. While it doesn't explicitly say this is for 32 bit architectures, I feel that is the intended use in the long run. While I rarely mess with languages like C/C++, I don't see why (if you're on a 64 bit system) to use 32-bit pointers expecting them to use x86-64 features when you could just use 64-bit pointers. If what I'm saying is wrong then sure, it might not have been great to presume the worst, but it still doesn't change the fact that intel has been dragging 32 bit products even into 2013 and I'm getting tired of it.
          Exactly. I don't see any reason to keep using 32 bit architectures either. Not to mention that if it was not for AMD we would still be using 32-bit CPUs on the desktop and 64-bit only on servers ($$$$).

          Comment


          • #6
            Originally posted by schmidtbag View Post
            I don't see why (if you're on a 64 bit system) to use 32-bit pointers expecting them to use x86-64 features when you could just use 64-bit pointers.
            Since you have 64 bit of bandwith you can transfer two 32 bitspointers at a time which might make stuff faster.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              "The Linux x32 ABI about allowing programs to take advantage of x86_64 features (and being dependent upon x86 64-bit CPUs) while using 32-bit memory pointers."
              Originally posted by schmidtbag View Post
              To me, this sounds like trying to use 64 bit features on 32 bit architectures. While it doesn't explicitly say this is for 32 bit architectures, I feel that is the intended use in the long run. While I rarely mess with languages like C/C++, I don't see why (if you're on a 64 bit system) to use 32-bit pointers expecting them to use x86-64 features when you could just use 64-bit pointers.
              For some cases, the 32bit vs 64bit has some drawbacks.

              Originally posted by schmidtbag View Post
              If what I'm saying is wrong then sure, it might not have been great to presume the worst, but it still doesn't change the fact that intel has been dragging 32 bit products even into 2013 and I'm getting tired of it.
              x32 is not 32bit. You just mentioned this yourself.

              Comment


              • #8
                Originally posted by wargames View Post
                Exactly. I don't see any reason to keep using 32 bit architectures either. .
                But x32 REQUIRES A 64 BIT ARCHITECTURE.

                x32 != x86

                Comment


                • #9
                  Originally posted by doom_Oo7 View Post
                  Since you have 64 bit of bandwith you can transfer two 32 bitspointers at a time which might make stuff faster.
                  Well in that case, this is awesome.

                  Comment


                  • #10
                    Originally posted by schmidtbag View Post
                    Why? Seriously intel, just drop your 32 bit platforms already. This is getting old.
                    x32 :
                    - amd64 with 32bit pointers.
                    - i686 fixed and improved with modern features.

                    For a developer, for example, off_t and other c/c++ defines are 64 bit so you don't have to worry about 4+ GB files and don't have to (remember to) pass "_FILE_OFFSET_BITS=64" to the compiler any longer because all the problems in the x32 bit API have been fixed. I recall like 1-2 years ago Linus telling a Linux dev who submitted x32 patches to the Linux kernel to fix the x32 ABI by setting some defines to 64bit to avoid the problems currently with i686 ( "standard" x86 32 bit).

                    Comment


                    • #11
                      Memory bandwidth and latency is a major performance bottleneck these days. Usually the CPU spends a lot of time starving for data instead of executing stuff.
                      x32 ABI is useful because:
                      • As has been said, you can transfer double the pointers at a time (compared to x86_64)
                      • You can fit more data in CPU cache since you now save 4 bytes for every pointer (very good to avoid trashing data between RAM and CPU)
                      • You have a lot more (bigger) registers compared to x86
                      • Probably more I can't think of right now

                      There are applications that don't need to map more than 4GB of memory, and could get a performance boost from these benefits.

                      Comment


                      • #12
                        Originally posted by wargames View Post
                        Exactly. I don't see any reason to keep using 32 bit architectures either. Not to mention that if it was not for AMD we would still be using 32-bit CPUs on the desktop and 64-bit only on servers ($$$$).
                        Originally posted by schmidtbag View Post
                        "The Linux x32 ABI about allowing programs to take advantage of x86_64 features (and being dependent upon x86 64-bit CPUs) while using 32-bit memory pointers."

                        To me, this sounds like trying to use 64 bit features on 32 bit architectures. While it doesn't explicitly say this is for 32 bit architectures, I feel that is the intended use in the long run. While I rarely mess with languages like C/C++, I don't see why (if you're on a 64 bit system) to use 32-bit pointers expecting them to use x86-64 features when you could just use 64-bit pointers. If what I'm saying is wrong then sure, it might not have been great to presume the worst, but it still doesn't change the fact that intel has been dragging 32 bit products even into 2013 and I'm getting tired of it.
                        -- i attach you two directly because your comments deserve it --
                        Wow. You two are really just purely uneducated spam/fud posters! You don't even seem to know what you're talking about so why don't you just shut up? Your contribution in the comments in only to raise your post count and somehow be satisfied about it.

                        I don't think you will understand the explanation, but i will give one nevertheless.
                        x32 on x86_64 CPU's is a GREAT feature. It allows for developers to use 32 bit pointers instead of 64. That will save quite some space if you have an application that is very pointer heavy. It also brings back some drawbacks that you'd also have with the i386 architecture like less registers and only 4GB per process. Wait, let me repeat that otherwise you can't understand it.. 4 GIGABYTES per PROCESS. You know what that means? Per process, not for your entire linux setup. Most apps don't need that much anyway so that's just fine. It's a different situation with gaming or photo/video editing software, but those should probably not use x32 to begin with.

                        So will it really be useful? Depends on the application. If it's a computational heavy application then you should probably not use this. If you use an application with a lot of trees (that's a data storage type which you probably don't know a thing about) thus a lot of pointers then it "might" begin to be beneficial to try out x32 for reduced pointer size. Mind you, 32 bit pointers is enough room for most heavy applications. You hardly ever need the space a 64 bit pointer provides.

                        Comment


                        • #13
                          one question though

                          I keep bumping into things requiring 32bit libs on x64, propriteary things like Skype and such. I don't want any 32bit libs, does x32 mean I'll need some special libs too or can it use the 64bit libs ? If it can't use the 64bit libs I don't want it.

                          Comment


                          • #14
                            Originally posted by markg85 View Post
                            It also brings back some drawbacks that you'd also have with the i386 architecture like less registers and only 4GB per process.
                            Actually x32 has all 16 integer registers available to it. Along with all the new AVX/SSE4.1 stuff that you can only get in long mode in the processor. You get the performance benefits of the shorter pointers by giving up more than 4gb of ram per x32 process. The best part is that you can have x32 processes run along side x64 processes without any performance issues from the extra overhead of switching from long mode to the protected sub-mode for 32bit/i686 programs.

                            http://en.wikipedia.org/wiki/X32_ABI

                            Comment


                            • #15
                              Originally posted by simcop2387 View Post
                              Actually x32 has all 16 integer registers available to it. Along with all the new AVX/SSE4.1 stuff that you can only get in long mode in the processor. You get the performance benefits of the shorter pointers by giving up more than 4gb of ram per x32 process. The best part is that you can have x32 processes run along side x64 processes without any performance issues from the extra overhead of switching from long mode to the protected sub-mode for 32bit/i686 programs.

                              http://en.wikipedia.org/wiki/X32_ABI
                              ahh oops. I read that table wrong. You are completely right.

                              To clarify my last post (since i can't edit it anymore).
                              The only downside of x32 is 4GB/process. If you can even call that a downside.
                              Other then this it really looks like a wonderful technique to use.

                              I wonder if Qt already support x32.
                              /me starts searching
                              Last edited by markg85; 07-02-2014, 04:25 PM.

                              Comment

                              Working...
                              X