Announcement

Collapse
No announcement yet.

Loongson Adds LoongArch Support To LibreOffice

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

  • Loongson Adds LoongArch Support To LibreOffice

    Phoronix: Loongson Adds LoongArch Support To LibreOffice

    Following GCC 12 introducing LoongArch support earlier this year, Linux 5.19 adding the initial LoongArch port, and Glibc 2.36 adding LoongArch, LibreOffice is now the latest high-profile open-source project adding support for this Chinese processor ISA that started out derived from MIPS64...

    https://www.phoronix.com/news/LibreOffice-LoongArch

  • #2
    Adding LoongArch support to the LibreOffice open-source office suite took 1,630 lines of new code with changes from the build system to hundreds of lines of new C++ code
    I expected only Assembly changes.
    On the C++ side I expected... only big/little endian fixes.. why do you have to edit C++ code to work with new architectures anyway?

    Comment


    • #3
      Chinese crap from an extremely corrupt government with ties at every big company there. Anyway, good news to the contribution.

      Comment


      • #4
        Originally posted by cl333r View Post
        I expected only Assembly changes.
        On the C++ side I expected... only big/little endian fixes.. why do you have to edit C++ code to work with new architectures anyway?
        Apparently because the original StarOffice suite used their own component model named UNO (comparable to Windows COM and UNIX CORBA) which includes a C++ ABI, and even supporting things like C++ exceptions?

        (Disclaimer: I'm the original reviewer of this port before the Loongson employee submitted it to upstream. I was surprised that so much hardcore borderline-NIH C++ was needed for an office suite, but considering the age of the project it's actually understandable.)

        Comment


        • #5
          Originally posted by timofonic View Post
          Chinese crap from an extremely corrupt government with ties at every big company there. Anyway, good news to the contribution.
          Couldn't hold your butthurt for a second, could you? 😁

          Comment


          • #6
            Originally posted by xen0n View Post

            Apparently because the original StarOffice suite used their own component model named UNO (comparable to Windows COM and UNIX CORBA) which includes a C++ ABI, and even supporting things like C++ exceptions?

            (Disclaimer: I'm the original reviewer of this port before the Loongson employee submitted it to upstream. I was surprised that so much hardcore borderline-NIH C++ was needed for an office suite, but considering the age of the project it's actually understandable.)
            How future-proof are those changes in case the the C++ WG standard committee votes on ABI changes? It's my understanding WG23 was voted against ABI breakage but it's not set as a hard goal just yet.

            Comment


            • #7
              Originally posted by RejectModernity View Post

              Couldn't hold your butthurt for a second, could you? 😁
              Oh, really?

              Comment


              • #8
                they also added LoongArch support to #t2sde Linux: https://www.youtube.com/watch?v=lwvwk6cBT2A ;-)!

                Comment


                • #9
                  Originally posted by xen0n View Post

                  Apparently because the original StarOffice suite used their own component model named UNO (comparable to Windows COM and UNIX CORBA) which includes a C++ ABI, and even supporting things like C++ exceptions?

                  (Disclaimer: I'm the original reviewer of this port before the Loongson employee submitted it to upstream. I was surprised that so much hardcore borderline-NIH C++ was needed for an office suite, but considering the age of the project it's actually understandable.)
                  Given that the changes are basically FFI glue code rather than hardware-specific, and that LoongArch is basically a MIPS knockoff, do you know why MIPS code could not be reused?

                  Comment


                  • #10
                    Originally posted by c117152 View Post

                    How future-proof are those changes in case the the C++ WG standard committee votes on ABI changes? It's my understanding WG23 was voted against ABI breakage but it's not set as a hard goal just yet.
                    I think for preserving ABI compatibility, at that time they would simply add another shim/bridge to translate between this stable UNO ABI and whatever C++ ABI the other components are using. The existing UNO bridges are already named after the (arch, OS, compiler) tuple they're supporting, so in each case the mapping should be clear and maintainable.

                    Comment

                    Working...
                    X