Endless Coding & Debugging，让你有了一种淡定的气质。
—-技术部分，可以直接跳到最后看结论—-
ROB模块的设计早在十几天前就做好了，由于给Michelle讲课间断了十来天，加上比较懒，不愿意动手写代码，所以真正开始实现ROB还是从五月二号起。初始代码写了三天：毛坯用了半天+一晚上，人肉检查用了半天，前期模块独立测试用了一天。
四号下午，测试完全通过后开始进行组装测试，发现Execution Stage还没写，花了半天时间研究pipe模块，写好了Execution Stage，然后组装，测试，Linux笑着对我说：段错误
幸好我是见过世面的，不用五分钟就找到错误地点了，修改，重新编译测试，跑起来了，但是输出明显很诡异，与预期不符合。终于，我漫长的调试期到来了！
面对诡异的输出，我几乎将所有代码都review了一遍，包括前面那么多天写的代码，然而，一天一夜的徒劳。所写的ROB模块更是看了又看，我怀疑问题就是出在这里。
五月五号晚，我终于觉得这样胡乱摸索下去不是个办法，于是先停下来，干什么呢？写分析文档！把思路变成条理的文字，然后再理性地分析，顺藤摸瓜，需要什么数据测试什么数据，最后，将错误的位置定位，原因定位，把一切最小化，终于，问题集中回ROB模块了。后面就开始重点分析ROB了，包括它的输入信号、输出信号、forward信号，以及内部状态变化。经过十几个小时的奋战，终于发现问题所在：某些指令被我重复指定编号了。这一点其实在设计的时候已经考虑到了，但由于放下了十来天，有些东西没有好好记录下来，在实现的时候竟然遗漏了对这个问题的考虑。唉，花了两三天的时间，终于找出错误了！
马上写修正方案，一一推敲，最终整理出一套建议可行的方法，然后编码打补丁，两个小时搞定。测试之，hoho，一切如愿~~
—–结论—–
经过这么久的磨练，这次debug表现出来的最大特点是，我竟然一点都不心急！要知道，现在该是开始写论文的时间了！
从前遇到这种“莫名其妙”的问题，必然是废寝忘食朝思暮想，这次呢？我一边用Thinkpad看电影，一边用老旭日150调代码，喝着茶儿悠闲自在。有问题了呢也就去很冷静很镇定的分析思考，一点点解决，没有那种急躁的心情。
以前我遇到问题也许会刻意要求自己镇定，但那毕竟是刻意的。回想一下这次，竟然没有丝毫刻意！这可是连续三四天的高强度脑力劳动啊。看来这娃上境界了。。。。
下面再次强化一个被我反复验证了的、高效的做事方法：
遇到问题的时候，经过数小时甚至数天的求索未果，这个时候就要反思了，前面的求索过程是否高效？一般来说我们遇到问题的第一反应是希望迅速解决问题，但又没有安排详细的解决方案，于是总要黑灯瞎火地弄上一段时间，运气好的时候也许能迅速解决，运气不好，遇到了比较深层次问题的时候，我们就SB了，越忙越乱。此时回头一想，前面整个就是打乱仗。如何应对这种混乱状态呢？我总结的经验为：
1、你的问题是什么？你能描述清楚整个问题吗？
2、问题点在哪里？你定位到了吗？如果你不能明确回答这个问题的话，你就得冷静一下了。思考过后仍然不知道答案，那么你就需要辅助信息了。只有知道相关辅助信息，你才能正确评估你遇到的问题。
3、什么是辅助信息？举个算初中应用题的例子：为了算题，你首先必须掌握列方程的知识，列出方程后，你必须有解方程的知识。列方程、解方程的知识/方法 就是相对于解应用题问题的辅助信息。
4、一旦你发现你走不下去了，问题通常出在你缺乏相关辅助信息上。沉下心来学习吧，心急吃不了热豆腐。
5、你想到解决方案了吗？把它写出来，然后再仔细推敲。记住，一定要写下来。头脑中的东西绝对没有文字中的东西清晰。
6、如果你真的想把问题解决，请万万不要鸵鸟。
—–
我又开始想钱了=.=b
挣钱啊，没时间啊。
。
。