C# bitwise 處理筆記談 editing... 2014/12/26

撰寫模擬器在程式方面的處理中bitwise是極重要的一塊,bitwise處理的是以位元單位為主的相關運算,跟一般多數程式會碰到的情況有點差異(一般程式處理的多是一個完整的變數或是物件,而 bitwise 處理的僅是一個變數中某幾個所構成的位元).

bitwise運用比重重的相關程式還包括像是內嵌開發或是影音編解碼(處理資料串流)等等.

每一種程式語言的特性會有那麼一點不同,不過bitwise的運算符號通常是大同小異( | , & , >> ,<< , ^ , ~ ) , 只是需要注意到有可能會因為不同語言的特性(甚至連編譯器實作與編譯參數都有可能在很細微的地方而有不同),導致這些bitwise的運算會有意外的結果,這點需要非常注意,由於現在的開發工具是C#,因此會以C#為範本來做介紹.

所謂的不同特性,包括像是資料形別的大小.處理SIGNED與UNSIGNED的轉換.轉型.溢位處理等等.是否是強型類別等等,這些東西保險起見最好都要跑過程式驗證一下.

處理器模擬

處理器模擬其實跟記憶體模擬處理那塊綁得很密,但撇開記憶體處裡那塊不談,單純談模擬CPU的一點感想.

還是老話一句,程式技巧並不是成功的最關鍵,而是硬體觀念,撰寫CPU模擬處理其實對沒有硬相關背景的人來說有點硬(悟性高的人例外...),我想對於有接觸過微處理機控制.組語撰寫的人會比較容易上手些,真的需要對每一個指令都瞭若指掌,才能正確用程式描述出行為.

以我撰寫Z80來說,剛寫好後,以為沒啥問題,結果跑起來錯誤一堆(雖然最後修正了),而撰寫中的6502也很怕因為觀念的不正確,導致撰寫出錯誤的CODE.

6502有許多定址模式,很容易混淆,或是錯誤處理,雖然指令很少(56個).暫存器也很少( X . Y . A . PC . SP . STATUS ) , 但每個指令可能有不只一個定址模式的資料處理方式(因此會有151個不同的opcode,但沒塞滿8bit指令最多256個可能),相比於Z80可能更要細心注意 ( z80是暫存器多不少,每個指令用不同的暫存器,就有不同的處理與opcode,但很多人會把用function的方式去處理,把暫存器當成是變數,這樣就減少了很多程式碼的量就是).

最大的關鍵我想還是在於資料如何正確地去解讀,好比說signed或是unsinged的處理不能混淆,以及 carry . overflow 的行為和處理等等,都是很小但卻影響到正確的細節.

即使有了正確的硬體觀念,你對於你所使用的語言特性也需要深入些去理解(特別在bitwise這塊),否則會出現不是預期的結果,越高階的語言雖然越方便,但細節怎麼處理就越含糊,常常好幾次出現錯誤,是因為我撰寫出來的code跑起來並不是我以為的那樣,追下去才知道問題.

總之考驗的是你的細心.硬體了解.和對於程式語言工具bitwise相關處理了解的夠不夠透徹.

關於模擬器的撰寫

模擬器的撰寫困難點並不是在於程式設計本身(當然前提是你也必須有最基本的程式設計能力..不然根本不可能),而是在於去特澈了解一個遊戲主機的硬體行為,這牽涉到很多硬體的運作觀念,以及硬體描述文件的閱讀能力,先不談各遊戲主機的特性,如果你對基礎計算機硬體運作觀念不夠多,就很難去理解遊戲主機的硬體,而一款模擬器模擬的好不好或是夠不夠正確,取決於硬體了解的深不深.觀念夠不夠正確,去做出正確的實作,程式設計能力影響性倒沒這個關鍵,頂多是會影響到執行的效能(程式架構或是寫法有沒有效率之類的問題).

而模擬器的撰寫又分成很多種程度上的能力,最厲害的是在完全沒有文件參考的情況下,利用利用破解或是分析技巧反推運作原則(通常是不得以,只能這樣,因為硬體SPEC不一定會找得到),是非常厲害或是專業的人才可能做到,其次是有文件,閱讀文件後去撰寫出,最後是一方面閱讀文件.一方面也去研究別人所撰寫的專案兩方並行,來寫出自己的模擬器程式或是移植別人的專案(進而修改或是加強),另外模擬器要撰寫出來即使是寫出來,模擬出的正確程度.功能夠不夠完善,中間的落差又非常大,寫出一些簡單結構的模擬器,是一回事,但要寫得好又是一回事,最後看你挑戰的是什麼樣的模擬器,早期遊戲主機結構相對簡單,CPU也比較簡單,越近期的主機架構越複雜,需要的運算效能越高.

如果你可以不靠文件,直接利用破解或是分析,撰寫出近幾年來的模擬器,這幾乎是駭客中相當高的境界(神中之神),如果你可以靠文件全靠自己寫出模擬器,那代表你在硬體觀念上或是理解能力上有相當不錯的能力,如果你是靠文件和別人的程式的參考寫出模擬器,最少代表你是一個有相當 [熱情] 的人.

總而言之,寫出跟沒寫出來,是一個層次的差別,寫出來又分用什麼方式寫出來.以及寫得夠不夠完善,中間差距非常大.