LoongArch作为全新指令集面临巨大的生态挑战，龙芯主要解决思路：
1、和社区合作推进开源生态。在3a5000推出时，龙芯使用闭源系统（这里的系统不仅仅指操作系统，还包括binutils、gcc、glibc、LLVM、musl、OpenJDK、Debian、QEMU等等）+开源应用为主，但他本身的闭源系统大部分是基于开源软件适配的，而开源软件版本火车一直往前跑，龙芯官方的维护人员一定没法一直追着版本列车适配的（比如GCC龙芯适配了8.3，但是后续的12.1、12.2等等版本仍然不包含LoongArch的适配代码，龙芯想要新特性就需要适配源源不断的新版本，人力成本巨大）。唯一解是拥抱开源，适配代码合入开源主线。
但开源的平台也存在规则，比如开源系统要适配海量硬件，对新硬件的适配要考虑其他硬件的兼容性。其次开源爱好者大部分对技术追求度高，要求功能以比较优雅的方式去实现。这就必然会带来冲突，龙芯原本内部修改的代码开源界不会全盘接纳，甚至对原先功能的实现逻辑提出挑战，这也导致了龙芯新旧世界的分裂。
2、推动应用厂商做兼容改造，这条路的主要困难点在于，其他商业公司为什么要配合适配。但是毕竟LoongArch属于龙芯这家商业公司，不属于全体中国人或其他商业公司主体，作为商业公司，龙芯要考虑赚钱活下去，其他公司一样要考虑这个问题。因此会导致这种市场占有率极低的硬件软件生态适配性差。当然在新创等政策性性市场，作为吃这碗饭的软件厂商，肯定要积极适配新创支持的CPU架构（还是商业逻辑的本质，适配你会带来商业利益才能驱动其他商业公司去适配）。
当然也存在少数为爱发电的商业公司，会积极响应开源或因为情怀来投入部分适配工作，但这毕竟属于少数，也不能强求。
3、x86指令翻译，x86翻译也会遇到一些问题：
（1）、x86指令的专利问题，导致龙芯目前仍然不敢开放LoongArch指令集卷2、卷3（卷2的部分向量指令和mmx、sse等指令集过于相似，可能涉及知识产权问题，也无法公布）；
（2）、翻译性能，龙芯官方也在PPT中给出了80% x86指令翻译性能。在研究近期龙芯CPU的性能时，对这个问题有一点其他看法：
讨论这个问题之前，实际上要先研究近期的6000是如何提升性能的
a、LoongArch是一种新架构，没有任何历史包袱，这就意味着龙指令集可以充分吸收目前已有架构的优点，可以对指令集做优化，删减部分效率低下的指令，同时可以使用激进的向量指令优化。LoongArch指令集比MIPS等传统指令集指令密度提升7%，并开启激进的向量优化和并行化，进一步提升LoongArch性能。
而这是传统x86、ARM指令集无法比拟的，尤其是x86，x86有极其复杂的兼容关系，再加上Windows系统极其变态的软硬件兼容性要求（比如win11可以直接运行03、04年的程序，甚至通过简单补丁，可以运行90年代的某些程序；又比如win10可以跑15年前的Q8300上。直到win11，最低指令集要求才是AVX2），这导致很多x86程序无法享受向量指令带来的性能优化，尤其是AVX/AVX2/AVX512指令。
b、3a6000使用“-mtune=la664”专属的微架构编译优化参数，可以将3a6000 spec 2006 int单核跑分从35.7（默认为-mtune=LA464）提升到40.1（-mtune=la664）；除了微架构优化，龙芯官方也可以通过进一步优化GCC，来提升性能，比如3a6000使用龙芯内部未开源的GCC版本编译的spec2006进一步提高到43分。
但是在翻译x86程序时，由于x86自身指令集复杂的兼容性问题，以及LoongArch的x86翻译指令也只兼容到SSM4，无法直接翻译AVX/AVX2/AVX512指令，会直接导致LoongArch激进的向量优化策略失效。同时并且因为x86程序不可能使用“-mtune=la664”或使用龙芯专属优化的GCC编译，导致b中的优化也失效。而这也直接导致LoongArch在翻译x86指令时，实际性能会比理论性能更低。
我们可以简单计算LoongArch翻译x86的理论性能为：100*0.80*（35.7/43）*0.93=61.7%（解释一下：80%为龙芯官方PPT说明的翻译性能，35.7/43为专属微架构或专属GCC版本优化性能，0.93为向量化带来的指令密度提升性能【这里只是算一个大概，实际上7%的指令密度提升加向量化不止7%的性能提升】）。
龙芯如果真的想靠x86翻译来解决生态问题，那么就以为着自己CPU性能要打六折（当然这个是理论性能，目前实际翻译性能应该是三折或稍多一点）。当然wine实际上也不太好用，性能也有损耗。
1、和社区合作推进开源生态。在3a5000推出时，龙芯使用闭源系统（这里的系统不仅仅指操作系统，还包括binutils、gcc、glibc、LLVM、musl、OpenJDK、Debian、QEMU等等）+开源应用为主，但他本身的闭源系统大部分是基于开源软件适配的，而开源软件版本火车一直往前跑，龙芯官方的维护人员一定没法一直追着版本列车适配的（比如GCC龙芯适配了8.3，但是后续的12.1、12.2等等版本仍然不包含LoongArch的适配代码，龙芯想要新特性就需要适配源源不断的新版本，人力成本巨大）。唯一解是拥抱开源，适配代码合入开源主线。
但开源的平台也存在规则，比如开源系统要适配海量硬件，对新硬件的适配要考虑其他硬件的兼容性。其次开源爱好者大部分对技术追求度高，要求功能以比较优雅的方式去实现。这就必然会带来冲突，龙芯原本内部修改的代码开源界不会全盘接纳，甚至对原先功能的实现逻辑提出挑战，这也导致了龙芯新旧世界的分裂。
2、推动应用厂商做兼容改造，这条路的主要困难点在于，其他商业公司为什么要配合适配。但是毕竟LoongArch属于龙芯这家商业公司，不属于全体中国人或其他商业公司主体，作为商业公司，龙芯要考虑赚钱活下去，其他公司一样要考虑这个问题。因此会导致这种市场占有率极低的硬件软件生态适配性差。当然在新创等政策性性市场，作为吃这碗饭的软件厂商，肯定要积极适配新创支持的CPU架构（还是商业逻辑的本质，适配你会带来商业利益才能驱动其他商业公司去适配）。
当然也存在少数为爱发电的商业公司，会积极响应开源或因为情怀来投入部分适配工作，但这毕竟属于少数，也不能强求。
3、x86指令翻译，x86翻译也会遇到一些问题：
（1）、x86指令的专利问题，导致龙芯目前仍然不敢开放LoongArch指令集卷2、卷3（卷2的部分向量指令和mmx、sse等指令集过于相似，可能涉及知识产权问题，也无法公布）；
（2）、翻译性能，龙芯官方也在PPT中给出了80% x86指令翻译性能。在研究近期龙芯CPU的性能时，对这个问题有一点其他看法：
讨论这个问题之前，实际上要先研究近期的6000是如何提升性能的
a、LoongArch是一种新架构，没有任何历史包袱，这就意味着龙指令集可以充分吸收目前已有架构的优点，可以对指令集做优化，删减部分效率低下的指令，同时可以使用激进的向量指令优化。LoongArch指令集比MIPS等传统指令集指令密度提升7%，并开启激进的向量优化和并行化，进一步提升LoongArch性能。
而这是传统x86、ARM指令集无法比拟的，尤其是x86，x86有极其复杂的兼容关系，再加上Windows系统极其变态的软硬件兼容性要求（比如win11可以直接运行03、04年的程序，甚至通过简单补丁，可以运行90年代的某些程序；又比如win10可以跑15年前的Q8300上。直到win11，最低指令集要求才是AVX2），这导致很多x86程序无法享受向量指令带来的性能优化，尤其是AVX/AVX2/AVX512指令。
b、3a6000使用“-mtune=la664”专属的微架构编译优化参数，可以将3a6000 spec 2006 int单核跑分从35.7（默认为-mtune=LA464）提升到40.1（-mtune=la664）；除了微架构优化，龙芯官方也可以通过进一步优化GCC，来提升性能，比如3a6000使用龙芯内部未开源的GCC版本编译的spec2006进一步提高到43分。
但是在翻译x86程序时，由于x86自身指令集复杂的兼容性问题，以及LoongArch的x86翻译指令也只兼容到SSM4，无法直接翻译AVX/AVX2/AVX512指令，会直接导致LoongArch激进的向量优化策略失效。同时并且因为x86程序不可能使用“-mtune=la664”或使用龙芯专属优化的GCC编译，导致b中的优化也失效。而这也直接导致LoongArch在翻译x86指令时，实际性能会比理论性能更低。
我们可以简单计算LoongArch翻译x86的理论性能为：100*0.80*（35.7/43）*0.93=61.7%（解释一下：80%为龙芯官方PPT说明的翻译性能，35.7/43为专属微架构或专属GCC版本优化性能，0.93为向量化带来的指令密度提升性能【这里只是算一个大概，实际上7%的指令密度提升加向量化不止7%的性能提升】）。
龙芯如果真的想靠x86翻译来解决生态问题，那么就以为着自己CPU性能要打六折（当然这个是理论性能，目前实际翻译性能应该是三折或稍多一点）。当然wine实际上也不太好用，性能也有损耗。
