Last Univ. Life (24)

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

挣钱啊,没时间啊。

 

发表评论

邮箱地址不会被公开。 必填项已用*标注