摘要 随着我国在处理器芯片产业的不断深化,国产指令集架构LoongArch应运而生,其发展需要相应的软件生态系统作为支撑.然而,由于指令集架构之间的差异性,开发者在适配软件项目的过程中,常需要耗费大量时间和专业知识来识别软件包中和架构相关的成分,并制定相应的移植策略.目前的指令集架构移植技术主要依赖于二进制翻译技术,虽然该项技术极大地推动了软件适配的进度,但会引入额外的性能开销,在出现错误时会增加调试难度,不能适用于所有软件系统.因此,亟需一种有效的源代码移植辅助技术,从根源上解决软件及其后续演化版本的指令集架构难题.为应对上述难题,本文建立了一种移植技术框架——ArchPorting,以助力国产指令集架构LoongArch软件的迁移适配. ArchPorting构建了多维度的指令集架构特征知识库,并能识别多种编程语言软件包中的架构相关成分.针对定位到的待适配的代码片段,利用大语言模型(large language model,LLM)的代码生成能力和架构知识库,根据基础架构知识、架构映射关系和代码迁移示例等,定制化地合成包含迁移背景知识的提示词,进而生成符合上下文语义的代码移植策略,辅助开发者完成软件适配.评估结果表明,ArchPorting在识别架构成分方面的准确率达90.5%,召回率为99.1%:生成的移植策略中,有80.29%的代码片段能够降低开发者进行软件适配的代价.综上所述, ArchPorting显著提升了软件迁移的效率和准确性,为龙架构CPU的发展提供了强有力的支持.

关键词 软件适配; LoongArch; 跨架构移植; 大语言模型; 代码生成; software adaptation; cross architecture porting; large language model; code generation

摘要 软件正在成为人类社会基础设施之一.此类软件系统兼具“复杂性”和“关键性”的特点,在其生命周期内,需求和运行环境都在频繁变化,传统软件工程方法很难为其提供有效支撑,成为当前实践中的瓶颈问题.要应对挑战,就必须“边建边用边升级”、让系统自身演化的速度跟上外部变化的速度.然而,复杂关键软件系统运行于高度管制环境,具有服务质量可信确保、信息物理社会高度融合、利益相关方众多等特点,其演化有着自身的独特规律,很难简单地照搬互联网等领域的已有实践.本文在分析复杂关键软件系统特点基础上,提出开发与运行活动紧密结合、多利益相关方共同驱动的复杂关键软件系统演化方法 TrustieEvo,阐述其需求持续管理、版本可信迭代、系统韧性增强3个方面核心使能机制,给出相应软件平台设计.方法支撑某真实复杂关键软件系统近5年的持续演化,将“用户新需求提出–软件新能力形成”需求实现周期从“年”级别提升到“周”级别,在实践中经受了高强度检验.

关键词 复杂关键软件系统; 高度管制环境; 软件演化; 软件代谢率; 软件韧性; complex mission-critical software systems; highly-regulated environment; software evolution; software metabolism rate; software resilience

摘要 在开源社区GitHub,开发者通过提交拉取请求向开源项目贡献代码.一些拉取请求可能与用户发布的问题存在链接关系,表明该拉取请求希望解决这些问题.维护拉取请求和问题之间的链接关系可以增强项目的可追溯性.然而,目前链接关系由用户人工建立.由于拉取请求和问题数量太多,人工建立链接不仅耗时费力,还可能存在遗漏.针对上述问题,本文提出一种链接建立方法 LinkFinder,通过模板过滤减少正文模板内容高度同质化的影响,从拉取请求和问题中提取语义特征和统计特征,使用深度神经网络构建匹配度计算拉取请求和问题的匹配度,得到链接问题推荐列表.本文从5个开源项目中收集了25411条链接.实验结果表明, LinkFinder的MAP达到0.434～0.774, MRR达到0.436～0.774, Top-1精确率达到0.344～0.702, Top-1召回率达到0.333～0.698, Top-1 F1分数达到0.338～0.700;相比对比方法 T-BERT, LinkFinder的MAP提升了9.01%～186.63%, MRR提升了8.86%～183.50%, Top-1精确率提升了20.21%～388.54%, Top-1召回率提升了20.34%～386.52%, Top-1F1分数提升了20.27%～389.13%.为了分析链接的价值,本文设计基于链接问题参与度的评审人推荐方法.实验结果表明,相比对比方法 RevFinder,引入候选评审人对链接问题的参与度排序对4个项目的MAP提升幅度达到3.11%～41.20%, MRR提升幅度达到2.45%～49.26%.

关键词 GitHub; 拉取请求; 问题; 链接建立; 评审人推荐; pull request; issue; link establishment; reviewer recommendation

摘要 人机物融合的新兴领域需要新型操作系统内核以支持泛在计算,对下管控海量异构硬件,对上服务动态多变应用场景.本文提出一种积木式内核架构BrickOS,可以根据使用场景灵活选择要加入内核的系统组件,同时可以选择将系统组件运行在用户态以提供较好的安全性,或者运行在共享地址空间的内核态中以提升性能.为了保障运行在相同地址空间中的系统组件的安全性, BrickOS为底层硬件的内存保护机制提供了统一的抽象,并将其用于单地址空间的内存隔离.测试结果表明BrickOS可以根据不同场景生成定制化内核,并拥有较低的进程间通信(inter-process call, IPC)开销,整体性能良好.

关键词 操作系统内核; 组件编排; 进程间通信; 内存隔离; operating system kernel; components arrangement; inter-process communication; memory isolation

摘要 人机物融合泛在计算的新场景和新模式,需要新型的操作系统,即泛在操作系统.存储管理作为泛在操作系统的一项核心功能,设计轻量化、高性能和动态可适配的存储系统是推进泛在操作系统发展的必要举措.然而,对于“端(终端设备)–边(边缘端)–云(云端)”泛在场景中普遍存在的结构化数据,传统存储解决方案存在I/O放大严重、系统体量过大和软件栈冗余等问题,难以满足泛在应用的需求.为此,本文从系统全栈的角度进行原创性探索,提出原生表存储系统.本文首先回顾了计算机系统的发展历史;之后分析泛在计算时代的新需求,总结出泛在操作系统的基本形态,并介绍最新研究成果;然后剖析了现有结构化存储方案在“端–边–云”场景下面临的挑战;进一步提出面向泛在操作系统的原生表存储系统,并从端侧和边/云侧两个场景深入分析其架构优势.最后,总结全文并展望未来发展趋势.

关键词 泛在计算; 泛在操作系统; 原生表存储; 软件栈; 端-边-云; ubiquitous computing; ubiquitous operating system; native table storage; software stack; end-edge-cloud

摘要 巨型星座是未来天基系统的一个重要发展方向.本文基于巨型星座核心共性需求以及对桌面、物联网、车联网、卫星等典型应用场景操作系统发展历程的研判,分析了应用场景需求与操作系统间的演化规律,提出了我国发展完全自主可控星云操作系统的构想和技术途径,包括架构定义、硬件载体、内核设计、安全可信,以及生态建设等方面,以满足巨型星座复杂应用场景的需求.

关键词 巨型星座; 星云操作系统; 共性需求; 应用场景; 发展思路; mega-constellation; China satellite cloud operating system; common requirements; application scenario; development research