本帖最后由 MJK2012 于 2012-03-18 15:21 编辑
最近的OS研究到了使用一种怎样的语言去构建内核的程度.
自从上次设计了HAL(Hardware Abstraction Layer)之后,
我发现即使是硬件驱动代码, 也不需要一定用C写什么的.
对于我考虑的OS的特征来说, 用C写异步代码, 是一件很痛苦的事.
如果可以使用我自己的直接支持异步函数的语言来写, 那么就完美了.
一开始, 我是打算这样的, 先写一个语言解释转换器, 把我设计的语言, 先转换为C代码, 然后再编译 .
但是我发现用这种方式, 会导致多个代码文件, 多个模块, 如何链接, 如何整合的问题.
现在基于C的ObJ文件, 也无法存放语言的类型META信息..
而且我还要实现dll机制, 这会很麻烦, (麻烦在要搞dll编译工具..)
后来我想通了, 为什么操作系统就不能用 '脚本' 来写 ??
即, 源代码直接放在系统核心文件夹里, 系统在加载的时候, 一边编译代码, 一边运行..
这有点太夸张了点 , 因为编译代码, 是一件很花时间的时呢.
但是, 我觉得这个世界的发展速度, 慢慢让编译时间的问题, 变成不是问题了.
一个系统, 它的代码量, 是远远不如计算机的发展速度的 .
也就是, 20年前, 编译同样的代码要100秒的话, 10年前只需要1秒, 而现在, 只需要0.1秒 .
现在实现一个程序, 即使代码量就算是以前的10倍也好, 但是编译时间也是以前的1/10而已.
而且, 部署源代码编译后再执行的方案, 就是Java/DotNet的方法!
只不过, Java/DotNet放的是IL, 是一种已经排版好的中间代码而已.
这个, 就反而证实了, 无论是放源代码也好, 放IL也好, 都是可行的方案.
那么, 这个方案对比纯粹用C写的方案, 缺点是 :
1 - 编译需要时间 , 这个影响着系统启动速度 , 也影响着程序启动速度 , 但是不影响程序运行速度.
2 - 由于编译时间问题 , 导致不能用复杂的算法对代码进行优化 , 编译出的字节码, 会比C语言差一点.
缓解编译速度, 加快运行速度的方式 :
1 - 关键代码,VM的实现,始终要用C写, C代码占较多的CPU比例, VM的性能问题占的比例没那么大.
(就好像一般操作系统, 关键的用ASM写, 不关键的用C写一样. 性能与系统的健壮性, 始终需要平衡)
2 - 可以像Java/DotNet那样实现IL, 加上混淆工具, 可实现保护代码, 加快编译速度.
这个方案带来的好处, 也是显然易见的 :
1 - VM内可以带上对象边界检查机制, 不会再出现指针造成的越界出错 .
2 - VM自带内存回收机制, 程序员再也不需要去维护对象的生命期了. 编写代码容易多了, 而且不会产生内存泄露.
3 - 限定VM语言的特征, 能实现一次编写代码, 多个环境下运行.
用VM做操作系统, 好处是有的,
目前也有Java/DotNet做的操作系统, 但是.. 它们好像到现在都没有什么气息啊.. 都是实验室的产物..
今天我也完成了对VM里的并发GC的实现的设计方案.
这个方案, 可以让所有的任务, 都不需要暂停的情况下, 就能进行垃圾回收. 不会影响实时任务的执行.
(要注意并发回收与并行回收的区别. 并行回收只是说用多个CPU来同时做回收而已, 只有实现了并发回收才不会暂停其他任务)
根据我在网上搜索回来的信息, 并发GC并不是新鲜事, 但是Java/DotNet都还没有采用.
我猜原因是, 并发回收是需要消耗更多的CPU的, 他们不愿意引入这个机制.
而我设计的OS, 目标是实时任务. 在我考虑的系统中, CPU永远不是问题, 关键是解决'延迟'问题.
也就是说, 在有数据到达, 需要处理的时候, 各种任务应该专心去做这些事情, 最短时间内完成任务逻辑.
而系统, 则是在空闲的时候, 才开始去整理资源, 花更多CPU去维护好环境.
这个概念, 可以比喻成 '豹子操作系统' .
豹子, 是短跑高手, 长跑就歇菜咯....
短跑高手的意义是, 给定你一个任务, 能超快地执行完毕. 然后允许用更长的时间进行休息.
现在这个OS的机制也是这样. 它专注于超高性能的IO吞吐量. 而CPU不是瓶颈.
它会使用更多的CPU, 但是会让所有的IO请求能在更短的时间内得到处理.
暂时的想法, 写到这里先.
|
免费注册
发表于 2012-03-18 14:48
