arceos/tour/* 添加对其他架构
(aarch64/x86_64/loongarch)
的支持arceos/tour 下新增一些例子, 体现 ArceOS 特定功能,
如图形显示功能/文件系统功能/新调度算法功能#[naked] 更改为 #[unsafe(naked)].
裸函数使得编译器不会为函数生成序言和尾声代码(比如保存/恢复寄存器,
设置栈帧等), 操作系统开发的部分场景要求完全控制寄存器细节
同时将 asm! 改为 naked_asm!.
裸函数内一般没有 Rust 代码, 因为会隐含地依赖序言和尾声,
所以几乎都是内联汇编代码
naked_asm!
不支持伪指令和宏(虽然我不知道为什么原来这里要写伪指令, 可能是和 arm
统一?), 所以要把那一段全部改写成 RISC-V 汇编, 好在代码量比较少,
如果多了我还真想不出什么方便的方法
…以下计划仅供参考, 不必全部完成,
我估计这计划我得弄到大三结束才能弄完来着 更不要因此有压力
你更应关注的是 current state 的稳定性与质量, 而非整体的计划与进度
无论是学习计划还是玩的计划均不以完成为目的, 以尽可能多地体验和接触为目的, 同时训练和适应学习状态
事实上, 唯一必要的反而是”不以计划完成为目的, 尽可能体验当下”这一点的训练.
从另一个角度来讲, 进度上的最优解也是”不以进度为目的”的心态才能达到的方案.
在实际的程序设计中(模拟数学或现实系统),
操作(过程)要应用到的数据往往不是一个单独的基本类型数据,
而是多个基本类型数据复合起来的: 例如分数是由分子和分母确定起来的,
单一的分子和分母都不能称为分数.
而将分子和分母以某种方式复合起来比单独管理分子和分母具有更强的可读性,
减少了编码中的精力消耗;
同时加强分子和分母之间的关系(分子和分母的关系应当强于这两个符号之于别的数据的关系)也符合某种(哲学上的)道理.
为此, 我们需要构造一种抽象使得这两个数据被复合起来:
这就是复合数据的需求: 将数据定义为一组适当的选择函数和构造函数, 以及为了使得这些过程成为一套合法表示, 它们就必须满足一组特定的条件.
在 lisp (SICP 使用 scheme 方言) 中有如下体现:
之前 我们说到系统从其功能实现上的目的是: 管理各种硬件资源,实现隔离并发与虚拟化. 但是站在一般用户的角度来说, 一个操作系统要有良好的生态, 支持应用程序才能被广泛使用. 而应用程序是由编程语言开发的, 这就要求操作系统能够支持一些语言(特别对于C语言)的标准库.
oscamp 第三节阶段总结. 由于部分操作系统原理性质的内容在二阶段中已经学过了, 因此总结主要针对两部分:
ArceOS 的优势区间在于快速针对特定领域构建出一个最合适的内核, 主要解决的痛点就是”从头开发一个操作系统太繁琐”, 而”现成的方案并不完全适用于应用场景”. 一些操作系统的可扩展性通过内核编译选项或者配置文件来实现, 但是这种方法无法在更深层次修改组装一个操作系统内核, 因此 ArceOS 采用了组件化的方案灵活组装某些功能.