Loongson Adds LoongArch Support To LibreOffice

[phoronix]

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

[cl333r]

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?

[timofonic]

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

[xen0n]

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.)

[RejectModernity]

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? 😁

[c117152]

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.

[timofonic]

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

Oh, really?

[rene]

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

[archkde]

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?

[xen0n]

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.