中国DOS联盟

"实时计算贝塞尔曲线貌似很难"

这里有个空想的方法: CPU有预取指令,我们也可以预画字体,在 CPU 空闲的时候就算,保证在使用前算完,然后真正画的时候就可以不用等待很多时间了.

Originally posted by asbai at 2006-5-26 03:37 PM:
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
关于多线程多任务的实现，记得GNU PTH（GNU出品的通用 User Mode pthrea ...

我还是怕在中断里做事,呵呵,不过据说有工业强度的 UC/OS-II 都用它, 不过书中提到移植要仔细, 否则可能会崩溃, 虽然意味着一旦调试好后,任务管理应该没有问题,但是还是让我有点怕,呵呵.

计时我就用 18.2 秒, 本来可以改, 但是保守的我还是没动它, 怕万一引起不良后果. RDTSC 自然是用不了的...

[ Last edited by jawbin on 2006-5-27 at 08:56 ]

"关键在于DOS下所有中断服务程序都是堵塞执行的"

那么只能尽力避免使用可能阻塞的例程了,是吗?

但是有时候不得不用,例如复制文件,这真是要仔细考虑的问题.也许必须牺牲一些实时性(最坏的情况下,也许通常这并不造成什么问题!)!但是这样的情况应该尽力避免.

Originally posted by jawbin at 2006-5-26 15:57:
"实时计算贝塞尔曲线貌似很难"

这里有个空想的方法: CPU有预取指令,我们也可以预画字体,在 CPU 空闲的时候就算,保证在使用前算完,然后真正 ...

光适量轮廓信息就无法完全放入基本内存了
更别说生成位图的存储开销了

而且轮廓字库最大的好处在于可以任意的旋转和缩放，妄图固定尺寸是倒退

Originally posted by jawbin at 2006-5-26 15:38:
zyl910 兄说到的图像数据量大的确是一个问题,不过如果我每次都仅仅是一个简单的操作的话,也许问题还不是很大,例如画一个 button, 也就是画几条线, 塠...

虽然在人眼中，垂直方面的两个像素是贴在一起的
但是它们实际上在不同的扫描行的，所以仍然需要内存搬运操作

除非有矢量绘图设备


PS: 就是由于上诉原因，BIOS的画线功能速度极慢，所以得自己写绘图函数

Originally posted by jawbin at 2006-5-26 15:57:
"实时计算贝塞尔曲线貌似很难"

这里有个空想的方法: CPU有预取指令,我们也可以预画字体,在 CPU 空闲的时候就算,保证在使用前算完,然后真正 ...

汗，居然想到预取，越来越跑题了。。。。

x86处理器最早提供预取指令的型号是AMD K6，提供了2条指令：prefetch 和 prefetchw。Intel从PIII开始引入预取：prefetchnta和prefetcht0/1/2。这与兄台给出的限制条件完全不符。

其次，预取指令是为程序员可以编程控制 L1/L2 高速缓存子系统与RAM子系统之间的数据交换而设计的，完全没有兄台设想的那种预计算功能（毕竟x86 CPU，除了最近出的双核型号以外只有一条指令流水）。

再次，预取指令的使用需要程序员对数据和cache line之间的对其；cache的联合方式、容量；CPU内部写缓冲区的端口数目及尺寸；BIU和北桥内存控制器队列和仲裁算法；RAM的BANK和Page数目以及其充电周期等等都有深刻的理解，否则使用预取能达到的效率提升可以忽略。

甚至在新型的配置了智能预取算法的CPU上，不佳的手工预取可能对性能产生负面影响。


PS：在兄台这种使用环境和设备都严格受限的环境中，其实不需要使用矢量字体。矢量字体最大的优势是可以自由旋转和缩放。兄台的使用环境中，貌似字体的尺寸和显示环境都是完全可以预先知道的，使用点阵字体就可以了。

而且，矢量字体在显示小字型（9～11pt）的时候，不管用什么算法，效果都会很差。所以大部分矢量子字体都带有专门为小字型优化的点阵数据或hint。例如Windows环境里菜单和按钮。

所以，使用点阵并不丢人，:D

[ Last edited by asbai on 2006-5-27 at 06:08 ]

哇,一大早来就看到两位兄台的热情回复,太幸福了!

我测试过 UCDOS 中的轮廓字体，没仔细看原理，但是速度的确非常慢。
另外，若无显存可操作的话，调用 BIOS 功能可能比较好（起码“仿佛“可以移植，之所以说“仿佛“，因为有的设备不是 VGA 兼容的，它自己提供一个库，所以最好在其上再加一层，以便上层代码一致），但是显然速度很慢，不过，若是附带一个库，它通常会提供简单的甚至稍微复杂一点功能，比如，画直线，椭圆，矩形，填充，而这时候不用考虑显存，甚至它们可能有优化版本或者选项以供选择。

“轮廓信息就无法完全放入基本内存”，理论上可以先放到外存，但是这样非常糟糕！确实是纯粹空想！

另外我说的预取其实只是说原理上相似，而当然不可能直接使用 CPU 的那个功能。所以一些字要显示之前必须自己放到预计算队列中去。其它类似可能会提高性能的可能还有分支预测，缓存等等，但是大大增加了复杂性，再一次证明仅仅是空想！

假如以“微内核“为目标，这已经走得太远了。

我认为一个普通的系统应该考虑“微内核“这样的方式，例如在系统刚开始启动的时候，可以尝试运行一个最小的可工作集来测试是否进一步将其他的全部或部分装入内存，类似但可能不是非常恰当的例子有 Windows 的安全模式，以及 Windows 预安装环境. 我想，内核不支持庞大的 Unicode，把它作为外挂样的就行了。这样可以不背负 Unicode 这个沉重的负担了（Unicode 的字库存储于外存自然可以先不考虑，但是相应的功能也是个不小的模块吧。）另外，如 asbai 兄所说，点阵可以不用这样庞大的计算，大大地节省了资源。其实我想说的是，如果认为中文字库都是负担的话，也可以不必加入“内核“，“内核“仅仅支持英文，以保持它苗条。不过，其实尽管是这样想，我还对模块动态载入没有一个清晰的想法，对可行性也无法确定。

[ Last edited by jawbin on 2006-5-27 at 09:37 ]

另外，我不喜欢 windows 程序和一些 c++ 代码的原因是通常看到看起来频繁申请和释放内存的代码，例如在非常频繁需要处理的 WM_PAINT 中，会经常创建和销毁 GDI 对象，虽然也许在内部事实上并没有对内存的申请与释放，或者有变相的行为，但是不会有什么恶劣的后果，但是，还是让我不舒服。而 c++ 的教科书以及 VS 开发环境中的示例代码通常会出现 new。我唯恐内存碎片带来的不利影响，所以，我尽可能地避免这样的情况发生，事实上，这通常是很容易做到的，不用刻意就可实现。我真地认为频繁申请与释放是一个坏习惯。不过，也是垃圾收集技术培养了这样的习惯。

但是，如 asbai 兄所说，如何律人呢？难道最后不过是个讽刺？

我避免大量使用内存的另一方法和任务分片相似，就是每次只操作 1 小片区域。例如，我抓图的时候，就每次只抓一行，把这一行写入位图文件。但任务分片却是真正的问题，也许该使用“真正的“任务管理，而不是在任务本身上变形。

[ Last edited by jawbin on 2006-5-27 at 13:44 ]

对，最大的字体都是知道的，是 32 * 56 的数字。

对了，我看 windows 系统上怎么字体小效果也还好，很大也还好，就是不大不小的时候看起来比较差，应该就是 asbai 兄上面所说的原因。

另外 Windows 系统虽然后来声称是抢先多任务，但是我还是发现实际上有被一个任务阻塞的情形，这是非常恼人的。但是，也许不能全怪 Windows, 可能一则是它本身未标为 “实时“， 二则可能当时用户给它的任务比较繁重。

[ Last edited by jawbin on 2006-5-27 at 09:34 ]

另外为了资源紧张问题，我还想过“造句“功能。具体来说，Windows 系统由于几乎不用考虑资源限制，可以看到它在使用字符串资源时并不“节俭“，随便打开一个有字符串资源的 PE 文件，可以看到其中有很多重复的词汇。所以我在想类似这样的问题：共享这些词语。例如，共享如下词汇：“磁盘“，“文件“，“访问“，“打开“，“关闭“，“成功“，“失败“。。。
然后在需要如下两个字符串的时候就不用占用两个字符串了：
“磁盘访问失败“
“文件访问失败“
但是这个句子又如何记录呢？类似原子？好像又有新问题。

另外我对“集合“很感兴趣，一个 GUI 容器可以有一个控件集合，它的元素可以由 index 来索引，也可以由字符串来索引，数据库好像也类似。非常有意思，但是，我不能考虑后者，因为我觉得那将浪费很多资源，可能他使用 hash 实现的吧。集合的优点就是很方便枚举，以及加入和去掉元素，很多情况下这很有用。

Originally posted by jawbin at 2006-5-27 09:05:
另外，我不喜欢 windows 程序和一些 c++ 代码的原因是通常看到看起来频繁申请和释放内存的代码，例如在非常频繁需要处理的 WM_PAINT 中，会经常创建和 ...

new和malloc的问题确实是经常被提起的。我的回答是：在现代操作系统中，这其实不是个问题。原因如下：

1. 标准库的内存分配函数通常会自己维护一个小堆（small heap或者叫fast heap）。当你频繁申请小型对象时，实际上它们是直接从这个小堆上分配的。“小堆”本身是一块或几块较大的内存区，主要用于避免每次内存分配时系统内核调用造成的开销。

2. 现在OS的内存管理是分页的，完全不会有碎片化的问题！（就连现在的DPMI Server都使用分页管理），这也是为什么我在说小堆作用的时候不提它有助于降低内存碎片，因为不会有碎片。

3. 堆的分配速度虽然比栈慢，但是在执行流处理或者内存复制任务时，堆的速度通常比栈快。因为编译器通常将栈中的数据做双字对其，而堆的边界一般是16字节，对其不同带来对内存总线和cache line利用率的不小差别。

4. 无论在堆中还是在栈中，最完美的内存访问优化就是不使用内存。reference counting、copy-on-write等技术就是典型为 zero-copy 发展出来的。

内存访问优化，确实是程序员说不完的话题。现代处理器最大的瓶颈应该就是内存了，典型情况下的现代PC，一次一切都非常顺利的完全内存访问周期也需要上百个CPU时钟。。。。。。貌似跑题了，呵呵

Originally posted by jawbin at 2006-5-27 09:56:
另外为了资源紧张问题，我还想过“造句“功能。具体来说，Windows 系统由于几乎不用考虑资源限制，可以看到它在使用字符串资源时并不“节俭“， ...

字典：所有数据压缩算法的基础，呵呵。问题是，即使用了字典，通常也只能节约外存，数据在放入内存做表示时通常还是要展开的。

比如用png算法压缩的图像放到显存中显示时仍然要展看成raw格式。当然也可以仅展开在屏幕区域显示的那部分，不过这样在滚屏等操作时效率很低。

我某些时候（例如，可能等同于 MS 的 GDI 堆的部分可能就会这样，此前我的时钟就是类似这样的，总之一些系统堆可能会这样处理以提高可能微乎其微的一点性能）打算使用类似的自己的"小堆", 我也不想使用栈，因为它占用目标文件的空间。即使这样的小堆也得做些工作，因为它自己当然需要在必要的时候重组。另外即使这完全不是问题，我还是不想让这么频繁的动作花费在分配和释放上，这和应该在循环中做可以在循环外做的事有什么区别呢？不过我还不想那么复杂（组织自己的小堆），我只想能安全地使用我所用的内存就够了。如果这些“现代操作系统“能运行在 8086 上的话，我是可以不用这么过虑了，呵呵。我一直不想依赖库函数或操作系统的某些可能让我养成坏习惯的“优点“。

另外，asbai 兄说的字典，其实是我想用来节约内存的，外存我已经不想太多“节俭“了，如果要考虑外存的话，那我是不会考虑 unicode, 我认为，即使汉字也可能仅仅使用个小字库，而不是 GB2312 全集。不过若真是不想节约外存的话，的确可以完全不用压缩的。所以我这个想法可能没什么用。

[ Last edited by jawbin on 2006-5-27 at 14:03 ]

跑题。。。跑远了正好远足呢