看標題就知道這篇要講的當然就是學界亂象了。
因為歷史因素，資工老師有蠻多是從電機過來的。
這些老師又把錯誤的觀念 (包括出題方向) 傳授給下一代的教授，如此不斷反覆以達到誤人子弟、禍延子孫的目的 (反正是別家人的子孫)。
至於為什麼這些老師不待在電機跑來資工，這就留給大家自己想了。
本來這篇想投稿給錯誤特攻隊，
但是我也不清楚那些人的背景如何，所以還是留給自己講好了。
這些可能早就退休或是還在職的電機人跑來資工，會發生什麼事情呢？
很顯著的一個例子就是會把 computer architecture 這門課，當成 computer architecture & organization 來上，甚至是 computer organization 來上。
課名如果有 organization 也就算了，但課名明明是 architecture 卻又上 organization，那合理的判斷就是這位老師不懂什麼叫做 architecture。
根據過去的調查發現，許多電機背景的老師根本分不清楚這兩者的差異，這也許該歸功於「白算盤」這本被奉為聖經本的書所造下的孽吧。
然而這些老電機背景的教授所訓練出來的學生，如今又成為新一代的大學教授了，也因此發生了各個資工所碩士班招生考試時。
明明科目名稱是計算機結構 (computer architecture)，卻大量的出現了計算機組織 (computer organization) 的題目。
這可真是令人感到可笑又可悲，連教補習班的老師們都狂搖頭嘆息 (另一半原因是他們得一直加課教 organization 的東西)。
資工人學 computer organization 沒什麼不好，但要求資工人通曉 computer organization 就大錯特錯了。
這完全與當初把資工這個科系獨立出來的目的與精神相違，既然要這樣搞那乾脆把資工併回原科系不就好了嗎？
博士班即使硬要用「博士就應該博學多聞」的名義來測驗 computer organization 的能力，資格考的科目名稱也應當正名才是，
並不是打馬虎眼在資格考參考書上打出傳說中的「白算盤」，然後補上一句考試內容得超出書本範圍就能了事的。
「白算盤」本身就涵蓋了 computer organization，但是資格考的科目名稱明明就是 computer architecture，
那麼出題老師就不應該出 computer organization 的題目，否則學生和社會大眾也可以合理的懷疑出題老師的認知能力。
雖然涵蓋碩班入學考在內清大資工所這樣搞已經不是第一次了，但還是來貼一下今年春季清大資工博班資格考「計算機結構」的第一頁來嗆一下吧：
第一頁就來了兩大題三十分與最上方科目名稱相違的數位邏輯電路題。
您可真是幹得好啊！出題老師。
我想又會有不少資工博士生因此更加的確信這兩題的內容是與 computer architecture 有關了。
這些題目根據我以往參加碩班入學考的慣例，當然是拒絕作答。
雖然我在高職時代的「數位電子學」總是拿到 90 ~ 100 分，四技二專甄試的專業科目級分拿到 9 級分 (最高 10 級分)；
這些題目對我而言是超級送分題，但我實在是不願意違背自己的信念。
都已經有了碩士學位，卻要為了分數而配合這些掛羊頭賣狗肉的無知教授，我可是做不到的。
我已經不是高職生了 (台灣教育部把資訊科搞成跟電子科一樣，這也不是新聞了)，更不是小學生。
答案當然是有而且是一次考過。
就算沒這幾題分數我還是照樣一次就 pass 了。
這個科目在上大學前就有 40% 基礎，大學修過一次、在台中大碩聽高×在台上講了兩次 (第一次要忙著抄筆記沒空好好聽)，
碩班還因為學校不承認別間大學修的這個學分又再修一次，做的計畫又是 compiler 裡給 VLIW 架構用的 instruction scheduler，
加上資格考又有歷屆考古題和一些用來墊底的非本科系背景學生，才差那三十分就會讓我沒辦法一次考過的話，我也差不多可以去死了。
但是如果你在看到本大框內的文字前已經在想沒有考過就沒有立場說這些話，請先反問自己所謂的立場對於說這些話的必要性何在。
如果你是從重視數學及邏輯的相關科系出身的 (如應數、資訊科學、資訊工程等) 且大學時代沒修過邏輯學，我會建議你好好的去修一次，這將會對你非常有幫助。
畢竟讀完這些科系要是思考模式還是跟死老百姓無異 (死老百姓是某些邏輯學老師在學期初糾正學生觀念時用的行話)，那實在是太可惜了。
第二頁和第三頁就不貼上來了，反正遲早系上也會張貼在網路上。
第二頁開始的出題老師還不錯 (據聞資格考的題目不是單一老師出的)，蠻多和 architecture 相關的題目。
像是 2-bit dynamic predicator，給一小段 program 問 cache 的 hit/miss rate 等等，不過也還是有一些 organization 的題目。
真不曉得我們台灣的資工學生這麼多，為什麼還要持續放任這些亂七八糟的教授繼續荼毒學生。
「那麼什麼樣的題目內容才比較像是 computer architecture 的東西？」
我想一堆慘遭白目教授荼毒的白算盤中毒患者們一定會如此反問。
建議可以看看專門講 computer architecture 的書，譬如「Computer Architecture: A Quantitative Approach」這本。
相信極大多數的白算盤中毒患者翻開這本書看不到 1/4 就會發現一件驚人的事實：「原來我讀了資工這麼久，居然沒有學到真正的 computer architecture 知識！」
是的，如果一門課的課名叫 computer architecture，應該講授的是這本書裡面所講的相關知識，而非在那邊設計什麼 ALU 和 CU，以及玩電路和分析 datapath 等等。
至於課名叫做 computer architecture & organization 的課，如果不分成兩學期來開，那麼它本身其實只是兩邊各教一點皮毛的課程罷了。
不過有趣的是，碩士班入學考大部分也只考這些皮毛，然後在題目上面變花樣。
從考學生懂不懂變成考學生的解題應變能力，收進一些只會考試的碩士生來妨礙世界進步，真是可喜可賀，可喜可賀。
更有趣的是，許多學校資工系大學部號稱學過 computer architecture 的畢業生，看到 ILP (Instruction Level Parallelism) 只會發現到這個簡稱裡有「LP」兩個字而發出會心的一笑。
其它部分就可以說是一點概念都沒有，考研究所看到 Tomasulo 演算法臉就歪了，因為聽都沒有聽過。
甚至誤以為這些題目是用來保護自己學校學生的題目，殊不知這是人家學校的教授想要排除掉白算盤中毒患者跑來讀他們純正的資工所。
真不曉得這些白目又白癡的現象會繼續在學術界的資工系裡流行多少年，我想應該是不可能遏止得住了。
什麼？有資工學生看完還不知道這兩者怎麼分？
嗯，方法一，請直接查 wikipedia。
喔？不相信網路資訊只相信課本上所說的？
沒問題，有方法二，就是查書。
Stalling 先生出的那本 Computer Organization and Architecture 絕對能滿足您的需求，作者打從一開始就開門見山的講明了兩者的差異。
總之大家還是多讀書多查資料吧，光讀白算盤是會死人不是講好玩的而已。
Update: 2017-07-04
事隔十年，我現在也已經在 CPU IP 廠的 compiler team 工作快滿四年了，我的看法仍然沒有改變，不如說是更加堅信自己當時的看法是正確的。
在業界，CPU 的指令集架構，也就是 architecture 的部分，專職於這塊領域的人所負責的均為高階抽象的 architecture，背景當然是 CS 的人。
尤有甚者，在 architecture 之下還有所謂的 micro architecture，譬如我們當年學生時代學到的 data path、pipeline stages 等觀念，多被歸類於此。
這個部分相對於 CPU 架構工程師而言，算是比較低階的抽象概念，實際上的設計與 timinig 等因素息息相關，因此是由 EE 背景的 HW 部門所負責，而非 Arch 部門。
換言之，在跟業界實務銜接方面，CS 背景的人學到 micro architecture，已經具備了與 EE 背景的人合作開發 CPU 的能力，被稱為「橋樑」的部分實際位置落在這裡。
因此，學到 organization 那邊去確實撈過界太遠了，大學一年級的數位邏輯設計，或者高職的數位電子學，其實已經都涵蓋了足夠且必要的 organization 基礎，這些都已經夠了。
另一方面，因為在 CPU 被硬體部門完成之前軟體部門就應該先起跑了，特別是 toolchain 相關的部分，不可能等 CPU 都做出來了才開始動。
因此 Arch 部門還有一個任務，就是開發 ISA simulator，軟體部門的人一直到有實際的板子可以用之前 (通常超過 1 年以上)，所有的開發和測試都依賴這個 simulator。
可想而知，ISA simulator 裡面所模塑的各種功能區塊也是以抽象方式進行，最低階也頂多模擬到 micro architecture 層級，不會精細到每個 gate、MUX、decoder 等等都給你模擬出來。
實際上 CPU 架構工程師所涉及的業務範圍最底層就是到 micro architecture，不會更低了，再往下就是跨部門的干涉，這沒弄好的話可是會引起硬體部門主管的反感。
的確，當 CPU 架構工程師提出自己所構想的架構時，HW 部門很容易會說 gate count 太高、MUX 又要多好多個、timing 不夠無法達成等理由否決，因此不可以對 organization 完全沒有概念。
但是就如同我前面所說的，這些基本概念只要讀過數位邏輯設計就已經相當足夠，把這些東西再帶到研究所以上的 CS 專精領域去，只是顯得多餘罷了。
在這幾年業界的經驗告訴我：
1. 對於 CS 背景的人而言，漸漸變得模糊的是 architecture 及 micro architecture 的界線，但 CS 課程早已全包，不是什麼問題。
2. 評論當中有人提過 architecture 和 organization 的邊界隨著近年發展變得模糊，是的，沒錯，但這是以 EE 背景的人而言。
3. CS 與 EE 的人在開發 CPU 的過程中，雙方的分界線在 micro architecture，不是 organization，organization 完完全全被框在 EE 的業務範圍內，沒有模糊空間。
學者在學術界求生存的方式五花八門，但實在不該拿來迷惑學生、誤人子弟。
該去 EE 任職的學者就應該去 EE 任職，該待在 CS 任職的學者就繼續待在 CS 任職，事情就是這麼簡單。
CS 的學者應該專精於 CS 領域，又不是自己領域已經沒題目做了，CPU 架構的高階主題琳瑯滿目，又何苦逼迫自己往低階鑽？
如果真的需要藉助 EE 領域的長才，何不直接找 EE 領域的教授合作呢？
什麼都要自己來、自己學，在這個專業分工的已高度開發世界當中是不管用的，只會徒然消耗學生往本來該發展的方向鑽研的時間。
在我的學生史當中並不是沒有經歷過跨系的整合型計畫，我碩士時期參與的 UniCore 處理器開發計畫就是跨系跨實驗室的大型整合計畫。
這個計畫包含了六個子計畫，分別負責：
1. CPU 架構 (陳添福教授)
2. 編譯器及工具鏈 (張榮貴教授)
3. 作業系統 (羅習五教授)
4. 高效能低功耗算術運算單元 (葉經緯教授)
5. 參數化多媒體韌體及特製功能單元(郭峻因教授)
6. 低功率低電壓 CMOS 電路 (王進賢教授)
這個豪華陣容裡要 CS 有 CS，要 EE 有 EE，在中字輩的學校裡都能有此等規模的跨系跨實驗室合作，結果在清大裡卻沒有出現過，實在令人惋惜。
我的立場依然不變，無論是 EE 還是 CS，當中的各個領域都是要多專精就有多專精，但是要在現代完成一樣嶄新的研發，就必須分工合作。
為了分工合作，難免需要概略瞭解其它領域的一些皮毛，這些在大學課程當中也已經涵蓋了絕大多數，倘若個人有不足之處也可以去修課補足。
然而，不管是何種領域，最專精之處必然是其它領域的人所無法涉足的，畢竟所謂的專家就是長年埋頭於他人無法涉足之處，因此能夠成為該領域的專家。
而不同領域的專家們一起合作，為了使他們之間能夠溝通，做為「橋樑」的各領域皮毛知識或多或少需要涉獵，可是最不該做的就是跨過去、撈過界。
人的一生極其有限，每個專家都有著只有他們才能做到的事，為何要駐足於「其它領域的專家甚至非專家」都能輕易做到的事？這是社會資源的浪費。
在絕大多數簡單的發明老早都被做得差不多的現代，唯有專家們分工合作才能讓世界邁向更進一步的發展，妄圖自己全包已經是一種自大了。
人，只要將心力放在什麼地方，在什麼地方就必會有所長進，獲得個人的成長，但也僅止於個人。
每個人一天平等地只有 24 小時，每個人一年很平等地只有 365 天，將心力放在什麼地方，意味著相同數量的心力就從其它地方抽離。
專家，一旦將心力從自身最強且無人能與之匹敵之處抽離，跑去將心力放在人人可輕易學習之處，他個人可以得到橫向方面的成長，但縱向方面的成長勢必也怠慢下來。
的確，許多知識是相輔相成的，也許從橫向發展當中可以獲得縱向發展的突破，但這並不構成長期駐足在領域間的溝通橋樑上打混摸魚的理由。
或許在台灣的腐敗學術界要求生存必須如此做，但是學生並不是永遠待在學術界的，並不應當如此要求學生、迷惑學生，甚至誤導學生，這些都是罪惡。
能夠獨立自己一人攬下 architecture 其 organization 的專業部分，我認為這是一名優秀的 EE 學者，但並不是一名稱職的 CS 學者及教育家。
身為 CS 科班出生的 CPU 架構工程師，除了 organization 之外還有很多該加強的地方，特別是程式設計能力。
迄今我看過太多 simulator 的作者連 cycle-accurate 都搞不定，或者一搞就要搞一兩年，坦白說 CS 科班生只有這等水準實在丟臉。
以替學生的未來著想的角度來看，與其棄守自己 architecture 的專業本分去往 organization 靠攏，不如多訓練他們的基本程式設計能力。