Ruby Embedded

Ruby'陷阱'之: '||=' 的真正展开式

rubynroll — Fri, 27 Jun 2008 20:14:52 +0800

作者: rubynroll 链接：http://rubyemb.group.javaeye.com/group/blog/208806 发表时间: 2008年06月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前一段时间,我在这里http://rubynroll.javaeye.com/blog/192547展示了一个空格带来的'陷阱', 今天又见到另一个'陷阱'(http://dablog.rubypal.com/2008/3/25/a-short-circuit-edge-case by David).

之所以为陷阱加引号, 是因为大部分情况下我们都没有机会掉进去 :)

大多数Ruby教科书在解释 "a ||= b" 这个复合操作时,都说她等效于: "a = a || b", 实际上真的如此么?

让我们在irb里面来看看:

h = Hash.new(1)  # 生成一个新的Hash,缺省值为1
=> {}
h[:x]
=> 1    # h[:x]未定义,所以返回1
h[:x] ||= 2
=> 1
h
=> {}   # 啊? '陷阱'?
h[:x] = h[:x] || 2
=> 1
h
=> {:x=>1}  # 啊!

David提到,Matz在RubyConf 2007上的解释是"a ||= b"真实的等价应该是: "a or a = b", 但是David后来认为"a || a = b"应该更恰当些.

果真的如此么? 不!

一个简单的例子可以反驳, 如果a未定义,则:

irb(main):001:0> a || a = 2
NameError: undefined local variable or method `a' for main:Object
        from (irb):1
        from :0

所以, 看来"a ||= b"正确的展开应该是: "a = b unless a"

对了么? 还是不对!

"a ||= b"表达式最终返回的是a, 而"a = b unless a"在a非真时返回nil.

所以, "a ||= b"的正确展开式应该为: "if a then a else a = b end"

想不到吧?

＝＝＝补充＝＝＝

鉴于此帖较长，且中间夹杂着不少因我的疏忽和错误造成的无谓争论，因此把最终的到的结论列在这里，免得看起来太累，或者有些人没有耐心看完而增加更多的无谓的争论。

结论如下：
1) a ||= b 不等效于: a = a || b
2) 归纳起来,准确的展开式应该是:
if defined?(a) then (a || a = b) else a = b end

特别感谢lllyq, 这个结论的credit应归于他／她。

若大家发现有更好的展开形式，欢迎讨论。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

动态模块加载和ELF Loader

rubynroll — Thu, 12 Jun 2008 13:09:17 +0800

作者: rubynroll 链接：http://rubyemb.group.javaeye.com/group/blog/202461 发表时间: 2008年06月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

很早很早以前就想在嵌入式系统上实现动态模块加载的功能了，期间走了些弯路，直到最近，才完整地在嵌入式系统上实现动态模块加载。

=== 动态模块加载的好处 ===

动态模块加载的好处很多，例如，当你升级一个系统的时候，可以只升级一个模块，而不必升级整个系统。你可以把不同的模块放在不同的介质上，并实施不同等级的保护，例如BIOS部分进行写保护。

有些系统允许用户进行二次开发，这个时候几乎一定是需要动态加载功能的，因为你不希望用户需要链接整个系统才能够进行二次开发，而且你可能希望支持多个用户模块，彼此不相互依赖，彼此不干扰。

=== Background ===

一般来说，C的编译器编译出来的代码，由以下几个重要的部分：
.code: 代码段
.data: 有初值的数据段
.bss：无初值的数据段

通常还有.rodata，是只读的数据段，在嵌入式系统中经常可以合并到.code段中.

注： .code, .data 和.bss这些段的命名不同的编译器可能会有不同。

由于不同段在实际运行的时候可能会被加载到不同的介质，例如.code和.rodata可以放在NOR FLASH上而.data,.bss放入RAM中，或者要满足所谓的scatter loading，因此编译器会努力使段可以自由移动。

但是要做到这一点，并不容易。

在代码段中运行的指令，要获取数据段中的数据，方法有：
a) 通过当前PC值＋偏移量
b) 通过绝对地址
c) 通过中间寄存器，寄存器里面：
c.1) 存放绝对地址
c.2) 偏移量

方法b通常只在CISC中存在，许多RISC机器由于指令长度受限制，并不存在方法b。

因此，从这里可以看出，要做到各段可以自由移动,有几种方法：
1) 保留一个寄存器专门用于指示数据段的起始地址
2) 运行前修改指令
3) 保留一小块数据段和代码段的相对位置不变，此片数据段作为指向实际数据段的入口表，运行前修改此表。

方法1和方法3通常会结合起来一起用，动态链接库就是用了这种技术。
方发2是一种通用的方法，实际上连接器就是这样生成可执行文件的。

=== ARM AIF ===

ARM公司的编译器有一项特殊的功能，即可以产生一种可自我重定位的可执行文件，即AIF格式。
在AIF文件中，包含了一个AIF头和一小段由编译器产生的重定位代码。运行AIF格式的文件，只需要告诉它起始地址，这段重定位代码就会负责修改余下的一些必要的信息达到重定位目的。目前还没有充分的公开的文档解释AIF内部的详细工作机制。

在我过去的一些项目中，AIF工作的很好，但是运行时外部无法获取AIF文件的更多信息，例如你无法去调用AIF映像中的某一个函数，因为你不知道它的地址。另外，AIF的执行映像中，.data必须紧跟在.code之后，对于想重定位到FLASH中执行的嵌入式系统就行不通了。

=== ELF ===

ELF文件是最常见的目标文件格式，它可能有很多扩展名，例如.o，.so,或者最终的可执行文件也是ELF。

ELF有几种：
* 可重定位
* 可动态链接
* 可执行
* 可执行＋可重定位

可执行的ELF如果没有可重定位信息，那就只能靠虚拟内存系统来支持它运行。但是对于许多嵌入式系统，有可能连MMU都不具备，因此我们只关心可重定位的ELF。（可动态链接ELF实际上也是可重定位的一种，附加很多额外信息）

有关ELF的详细信息，请参阅：http://www.skyfree.org/linux/references/ELF_Format.pdf

=== ELF Loader ===

我花了不少时间寻找小型的ELF Loader实现，但是真正适合嵌入式系统的却不多。

+Contiki OS:
在Contiki OS里面，有一个很有趣的ELF Loader实现，嗯，其实Contiki OS有很多有意思的东西 :)

+ucLinux:
ucLinux也是一个很有意思的例子。由于ucLinux没有启用虚拟内存系统，因此它在加载可执行文件的时候，就要进行重定位。为了加速重定位和减小ELF文件的体积，ucLinux提供了特殊的工具链，在产生ELF之前进行部分的“预重定位”，最后ELF中只需要携带很小体积的重定位信息。

+其它RTOS：
其它嵌入式OS，如VxWorks也实现了ELF Loader, eCos的ELF Loader看起来尚未完整。

+Linux Kernel:
哦，差点忘了一个最重要的，Linux Kernel。

Linux Kernel的模块是可以通过insmod动态地加入内核。虽然Linux的用户空间程序运行在虚拟内存中，整个内核的空间确只有一个。一些奉行micro kernel的人批评Linux的这种方式，但是一个单一空间的内核运行效率却是最高的。

在2.6内核中，模块重定位工作不再由insmod来完成，而是由内核来做所有的重定位工作。实现代码在：kernel/module.c中。

剥去那些处理特殊section的代码，Linux内核模块加载部分的代码其实是非常简单明了的，而且Linux支持数十种架构意味着你几乎不要担心架构移植的问题。

=== 结论 ===

在嵌入式系统中实现动态模块加载的技术是成熟的，可靠的，可以借鉴的开发源码的实现例子也有不少。一个参考数据：我最近在一个嵌入式RTOS上实现的ELF Loader，运行在ARM7 CPU上，从NAND FLASH中加载一个400K左右的ELF，耗时大约0.5秒。

=== THE END ===
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

可以使用Python编程的嵌入式无线模块！

rubynroll — Wed, 21 May 2008 17:45:42 +0800

作者: rubynroll 链接：http://rubyemb.group.javaeye.com/group/blog/195372 发表时间: 2008年05月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Telit 是一家专业设计和生产无线模块产品的公司，值得注意的是，它几乎在所有的最新产品中集成了嵌入式Python解释器，这样使用者就可以使用Python脚本快速地开发应用，这些Python脚本可以保存在模块内部运行，而不用另外的MCU去和模块进行AT命令交互。

想起以前在WaveCom的OpenAT平台上开发应用，那个叫郁闷....

以下链接是Telit的一个4频GSM/GPRS模块的flyer：
http://www.telit.com/module/infopool/download.php?id=166
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐