高中同学聚会

前天鱼头说，老头组织同学聚会。看了手机才发现老头发了短信，顺便还告诉了韩XM。
昨天早上，老头通知十点到附中门口集合，我五十七分左右到的，已经有四五个人了吧。
等了一会儿，来了十一个人。大家决定不再等了，先找个地方坐坐。
于是大家往一条街走过去。老头先去探路，回来之后，大家往一条街深处进发。
经过集体决定，一群人走进了图门烧烤。点了一些饮料之后，大家开始谈天说地。
范围无非学习、生活之类。老头提议说各人说一下各自在研究什么，将来的发展方向。随着钟诚的"说来话长……"，这个话题就此结束。
我这桌有LinS,ZhuHY,HanXM,FengCD,后来又把ZhangLW，WuH叫了过来，这样就有7个人，而老头那桌还有鱼头、DongCJ、XuMM、LiJS、ZhongC。
我们这桌大部分人基本上没怎么吃过烧烤，只有FCD好像专业一点，于是一开始点得太少，并且对于生熟程度掌握得也不怎么行……
后来又补点了一批，大部分烤的东西都有过熟的嫌疑……
饭后，大家到复旦南区打篮球。一开始12个人打全场，我在拍照。谁知道碱性电池如此之弱，充电电池拍完后，每组碱性电池大概也就撑了十几张……
于是，接下来分组打球，我也上场了……
13个人，分成4/4/5，我和ZhongC算作一个分在一组。在我们组其他成员努力之下，我们组也胜过好几次，不过体能消耗很快，迅速不支……
我有一年没打过篮球了吧……
接下来，走了3个人，剩下的人到LiJS找的地方打牌。复旦29号楼，门口挂着学生会的牌子。本来想在大厅里面打，看门老大爷说，我干脆开个房间给你们打算了。就情况看起来，貌似管得还是很松的，或许冒充一下也能混过去……
我和HanXM要去买电脑，于是早早离开了。剩下8个人2桌80分。
我们乘车到八佰伴旁的太平洋，花1个小时买了一台台式机的机箱，在麦当劳解决了晚饭，分头回家。
同学见面真令人愉悦～ 大家好像都没有什么变化，或许变化都是内在的吧……
相册可见 http://picasaweb.google.com/Henry.Hu.SH/2009#
鱼头的校内日志： http://blog.xiaonei.com/GetEntry.do?id=358491034&owner=231886837

题外话
整理照片的时候，考虑是传flickr还是Picasa。考虑到flickr容易被封，Picasa从前就传了一些，所以还是picasa。
直接用网页版传，3.4M上去还是3.4M，总共1G空间，还没我存储卡大，这不就很快满了么……
所以去找Picasa软件，看见linux版，3xM，正想下，发现下面说：包含wine，picasa，gecko…… 原来还是wine这条路么……
于是直接下windows版安装程序，只有9M…… 用wine安装运行，非常顺利啊～
传照片也很好，传上去的是1600×1200，～300K每张，也挺清楚的，还有EXIF数据。
看picasa的信息的时候，还说是用于linux的picasa…… 它检测到wine了么……

技术blog搬家完成

今天把程序完善了一下，然后重新运行。
在碰见blogger的发布限制之前，我先遇到了程序Bug……
今天往程序里面加了转移评论的功能，这个bug就是出在这个地方。有的blog是草稿，然后程序访问的时候，返回的是访问被拒绝。程序在这个页面里面找评论，于是挂了……
改了之后，重新运行，碰见了blogger的发布限制……
原打算明天再说，但是Roy的话给了我启发。
虽然单个blog有限制，但是能够开多个blog，然后把那些blog导出，再导入技术blog。
这样就解决了问题，使得整个搬家工作能够在一天内做完。
现在看起来，Blogger的限制大约是每天50贴，还算合理。但是那些搬家程序不知道是怎么混的～
另外，总结经验，以后要先尝试运行一遍，再将改动予以实行……

技术blog搬家

其实我有一个技术blog，但是没什么人去……
原来架在mblogger.cn上，但是这个地方越来越缺乏管理，用户流失严重，就是懒得搬。
话说这个也是我一开始写的blog。
这个地方基于.Text平台，提供metaWeblog接口。我打算搬到blogger。
在网上找了一下，有现成的博客搬家的地方。但是试了一下，都不能用……
比如说，http://blogmover.redv.com/，这个地方能够读出原来的blog，但是写到blogger的模块出问题了……
又如maikr，需要登录才能用，而网站挂了，于是注册不了……
最后只好自己写一个搬家程序了……
既然近期学习python，那么练一下也好。python自带xmlrpclib模块，能够和metaWeblog通讯。
尝试了一下，metaWeblog的接口还真好用，不一会儿就能够读出blog了。
话说python生产力就是高阿，随便弄一下就好了，有什么问题搜一下也能很快解决。如果…… 如果python不是用空格/缩进表示层次的话，那就更好了！
然后去研究写到blogger的方法。
这时候我发现，虽然metaWeblog基于blogger API，但是那是老的blogger API……
新的Blogger被Google整合到了GData API框架里面，于是巨麻烦无比……
Google的人们是不是太聪明了…… 总是觉得自己发明的东西比较好，不用现成的…… 然后弄出麻烦的东西，光了解就要不少时间……
还好有python的gdata库，自带了访问blogger服务的样例。
但是又有一个问题：貌似Blogger的GData访问方法被GFW掉了……
只好改了，用SSL，又耗掉一堆时间……
最后，折腾了一大堆，终于是把这个搬家程序写出来了……
但是，最后用的时候碰见问题了：

status 400
Blog has exceeded rate limit or otherwise requires word verification
for new posts

COW！ 这可怎么搬家啊……

关于A20地址线的那些事情

从前在BIOS里面见过关于A20地址线的选项，后来启动FreeDOS什么的时候好像也见过A20的事情，一直不知道是干嘛的……
后来某天看BSD loader代码的时候，看见启用A20地址线的事情…… 于是去wiki上查了一下，原来是这么回事……
8086那个时候，地址线只有20位，叫做A0~A19，也就是没有A20地址线的。2^20=1M，因此那时能够访问的内存范围是1M。
那个时候也分段，地址由段寄存器左移4位，加上基地址，得到物理地址。
段寄存器和基地址都是16位的，这样就能够访问20位的空间了。但是有个问题……
段寄存器最大FFFF，基地址也是。所以地址最大是FFFF:FFFF，但是FFFF左移四位得到FFFF0，加上FFFF，得到10FFEF，也就是FFFFF+FFF0。但是物理内存只有1M，最大物理地址范围应该是0～FFFFF，因此多了FFF0，超出了物理地址范围。
这样，访问到超出范围的时候，8086会自动做一个处理，把高位的1删掉，也就是10xxxx->xxxx，然后返回对应位置。

按理来说，这是个bug，8086应该返回个错误啥的。但是，既然这已经是事实了，有的程序就开始用这一点，来访问0～FFEF的内存范围，差不多是前64K少一些的范围。这就为日后的新CPU出了难题……

80286，80386等等更NX的处理器出现了，他们支持访问更大的内存范围。自然，10xxxx和xxxx也就指向了不同的地方。但是，跑那些用到从前bug的老程序的时候，就出问题了…… 改了10xxxx的xxxx不变，导致乱七八糟的问题……
IBM他们就脑残了一下，说，我们在A20地址线（也就是那个1的位置……）装个开关吧～ 然后又脑残一下，看见键盘控制器正好有一根线空着，就说，我们让键盘控制器来管这个开关吧～
于是，著名的Gate A20就这么产生了……
打开：输出0xd1到0x64端口，等8042（键盘控制器）空了，再输出0xdf到0x60端口

保护模式的操作系统，自然都需要访问1M以上的内存，而且不希望某一位地址一直是0。所以保护模式的操作系统启动步骤之一，就是打开A20。
但是，IBM那些人们没想到，日后有些环境需要频繁切换A20端口，而键盘控制器是如此之慢…… 他们当初认为，这个切换发生频率很低，因此慢一点没关系……

于是就有了Fast Gate A20的事情。利用0x92端口，读入之后，把第二位改成1，然后写回去，能快一点。
但这个引起了新的bug。毕竟只有某些系统支持0x92端口的这个用发，而有些系统…… 改了0x92会导致没有显示之类的，所以有危险……
后来么，intel也不爽了，就搞了个0xee端口，读打开A20，写关闭…… 速度比从前更快了……

于是，这样就有了3中方法，由慢到快。某些程序就一个一个试，试了一个验证一下。
但是，缓存又来捣乱。有的系统虽然开了A20，还是会把几个字节缓存起来，10xxxx和xxxx一样……

总的来说，A20就是个麻烦的事情，当初搞个BIOS调用之类的也就over了么…… 不过现在的新的系统，基本上都没有A20的问题了，虽然打开A20还是系统启动的必要步骤之一……
参见A20 – a pain from the past

80×86 保护模式 内存访问 学习总结

话说这个80286搞出来的保护模式，又是分段又是分页，从前没好好研究过，从来就没有搞清楚过……
家里翻到一本老教材，《微型计算机技术及应用——从16位到32位》，里面讲80386的章节，终于基本上讲清楚了……
假设现在是即分段又分页的情况……

首先，程序里面引用一个地址，其实指的都是逻辑地址。这样的引用需要两部分数据：段选择子以及段内偏移量。
然后么，段选择子基本上就放在老的段寄存器里面，不过现在是起一个索引的作用。
段选择子其实分几部分。总共16位，前13位是个索引，接下来1位指定是到LDT还是GDT里面找。最后两位是特权级。
LDT和GDT，一个是局部描述符表，一个是全局描述符表，反正是两张表，存了一大堆的段描述符。表的位置放在LDTR和GDTR两个寄存器里面。
现在研究内存访问，所以只讨论存储段描述符，每个8个字节，包括了段的开始地址（32位）、界限（20位），还有一堆标志什么的。
用前面那个索引，从LDT或GDT里面找到描述符，然后就有了段基地址。之前需要检查偏移量符合界限，以及其他各种权限之类的检查。
最后加上偏移量，我们就得到了线性地址～ 分段部分完成～

然后，线性地址有32位。把它分为3段：10位，10位，12位。
系统有一堆控制寄存器，其中，CR3里面，保存着页目录的基地址。
页目录也是一个表，每项4个字节，每个里面都有一个页表基地址…… 当然还有一堆别的东西，什么权限、标志之类的……
线性地址的第一段，10位，就是这个表的索引。把它乘以4（每项4个字节么……），加上CR3里面的基地址，就有了页表的基地址……
页表的结构也差不多，也是4个字节一项。用线性地址第二段，10位，乘以4，加上页表基地址，就有了页基地址……
最后，拿第三段，12位，加上业基地址，终于…… 我们得到了物理地址！

接下来么，做一些数学计算。
页内偏移量（线性地址第三段）有12位，2^12=4*1k=4k，和一页大小为4k吻合～
线性地址前两段，每段10位，对应的表可以有1k项。所以，经过这两级，可以索引1M个页。每个页4k那么大，所以…… 总共4G。
其实这个计算很NC对吧…… 总共32位，没有1位浪费，全都用来索引的情况下，当然可以索引2^32=4G……
然后，一个页表有多大呢？一项4字节，共1024字节，所以一个页表4k大。总共1k个页表，所以页表总共占4M那么多地方。
页目录表么，就4k大啦，比起页表也不算什么……
然后，段的界限只有20位，2^20=1M，难道一个段只有1M那么大？其实剩下的标志里面有一个粒度位G，能够指定界限以1字节还是4k为单位。
以4k为单位的时候，就能有1M*4k=4G那么大的段，这个就很完美了么～
段选择子有16位，因此最多有2^16=65536个段，真多……

然后，这样n级转换不是很慢么，所以系统里还有转换缓冲区。貌似这个区操作系统还可以控制，让哪些转换结果留在缓冲里面，这样下次碰见一个逻辑地址就不用多级转换了……
另外，程序用到段选择子的时候，必然都在6个段寄存器里。所以，每次把东西扔到段寄存器里面去，CPU就把对应的段描述符装到一个隐藏的寄存器里面，这样，大部分时间就不用去查LDT/GDT之类的了……