April 27, 2009
0xlab 開幕!

愛因斯坦說過:「對一個人來說,所斯望的不是別的,而僅僅是他能全力以赴和獻身於一種美好事業」,今天,台灣有一小群工程背景的朋友,憑恃著如此的信念,打算為台灣的資訊產業,作些事情,所以成立了 [
0xlab]。愛因斯坦又說:「信念最好能由經驗和明晰的思想來支持」,我們的成員則根基於過去參與自由軟體 / 開放原始碼專案的協同開發經驗,以及對追求理想和真善美的堅持,透過 [
0xlab] 這個嶄新的嘗試,將原本散落各地的開發資源,集中起來一同打拼,目前為止的成員有 8 位,依序是 Erin, Jeremy, John, Jserv, Julian, Olv, Thinker, Tick。每個人各有其專擅的領域,我們希望以團隊的優勢提供完整戰力,為軟體界做出些許貢獻,以技術的方式來愛台灣!
個人一直認為,工程師若要愛台灣,最好的方式,就是強化本職學能,無論是軟硬體技術,使其累積、成長,進而提升到更高的層次。今天,2009 年 4 月 27 號,是 0xlab 的誕生日,專注於推動硬體廠商與開放軟體社群的聯繫,成為軟硬體整合方案提供者,讓更多基於開放軟體的裝置走入日常生活。
由 jserv 發表於
07:49 AM
|
迴響 (20)
April 21, 2009
「窮得只剩下 Compiler -- 淺談編譯技術的革命」簡報上線
上週末,在 OSDC.tw 分享 [
窮得只剩下 Compiler -- 淺談編譯技術的革命] 的演講,著眼於運算模式已大幅改觀的今日,編譯器技術是如何悄悄走入我們的生活 (不誇張,事實如此),而開放原始碼的世界,又是如何透過編譯器技術的突破,再造巔峰。試看,當今我們的資訊建設中,軟體開發可說清一色為 framework-driven,而硬體則是 SIMD/vectorization, Cell, muticore/SMP 等等嶄新技術的普及實現,從 PS3 遊戲機、手機、Netbook,到大型交易系統,都引入這些突破,此時,如何更多元、更安全、更有效率地使用硬體資訊技術,就成為關鍵的軟體議題。當編譯器技術走入新的層次時,就需要更強大且多元的 Toolkit,而我們選定 [
LLVM] (Low Level Virtual Machine),當我們已知曉整個典範移轉 (paradigm shift) 的衝擊,就思考 LLVM 這樣的嶄新架構能給予我們哪些突破限制的可能性
本議題刻意迴避深奧的編譯器與計算理論,從應用的角度切入,探討何以 cross-compiler, Just-In-Time compiler, virtual machine 等等老玩意,大幅改變今日資訊系統的樣貌,而透過 LLVM 一類的技術,又如何巧妙的進行資訊技術的「雜交」(cross-over),從而給予重大的突破。結尾則引用王陽明牧師在《窮得只剩下錢》一書的話語:
「人生兩條路:『生活的幸福』不等於 『生命的幸福』,兩樣幸福我們都需要」
期許同為技術從業人員的我們,唯有不斷追求新知,並認真反省資訊技術如何更有效率且深入的解決問題,才能更掌握「幸福」,畢竟,技術永遠不是真正的限制,只有我們的想像力箝制一時,但從歷史的經驗來看,人類往往很快又可突圍前進,特別是開放原始碼技術蓬勃發展的今日,軟體建設得以快速累積、爆炸成長。最後,感謝抽空前來指教的朋友,此議程顯然相當「硬」,但見到台下幾乎坐滿捧場的聽眾時,著實興奮良久,而有幾位朋友在會後提出頗多相當不錯的問題,小弟預計在稍後的 blog 中一併回覆,歡迎交流,謝謝!
由 jserv 發表於
09:09 PM
|
迴響 (3)
April 17, 2009
人生是沒有畢業的學校

基於個人情感因素,一直很排斥新竹科學園區,但為了參與國家級計畫的機會,隻身來到孤寂的竹科,儘管夜半無人私語時,常常噙著淚水入睡,面對漫漫長夜的惡夢。負笈北上,來到這所高級學府,一半是承諾,一半是自我考驗。
2001 年開始,台灣推廣「矽導計畫」(SiSoft),第一階段任務順利完成後,成為中國大陸與韓國仿效對象,而為拉大差距,矽導計畫推進第二階段,推行「台灣心計畫」與創新結盟機制 SIPP (SoC Innovative Product Partnership) 兩大策略性計畫。透過「台灣心推動計畫」,已順利成立 [
晶心科技],可望協助台灣突破「無心 IC」現況,也就是,過去台灣雖在半導體產業鏈獨步全球,但缺乏嵌入式核心處理器
、對 SoC 架構,及相關週邊軟體選擇的主導性。
晶心科技於 2005 上半年成立,總部設於新竹科學園區的矽導科技研發中心,初期資本額七億元,來自國家矽導計畫的資金大約一半,另外,智原 (Faraday) 與聯發科也有投資。曾服務於智原科技擔任 CPU 設計架構長一職、目前是晶心科技技術長暨研發副總經理的蘇泓萌博士,如此描述公司的創立:
「2004 年,由於矽導計畫中有一個支持國內自行設計 CPU 的『台灣心計畫』,智原和聯發科的團隊便共同提案去申請。案子通過後,我們得到來自矽導計畫的投資基金,晶心科技便在這樣的情況下成立了。」
公司成立之初相當艱辛,因為從指令集 (ISA)、CPU 到系統軟體都得重新開始,避開專利議題,歷經兩年多的開發,晶心科技終於在 2007 年底,正式推出命名為 Andes (Architecture for New-Generation Digital Engines) Core 的核心 IP 產品,及相關開發工具軟體 AndeSight / AndESLive,目前的員工數量已有一百出頭。關於這個新創的 CPU 技術細節,可參考 [
電子工程專輯] 的新聞稿,相當榮幸的,在晶心科技尚無任何一行軟體程式碼的草創時刻,我就受邀參與面試,儘管當時緣份未到,但心頭一直惦記著這群默默執行「台灣心計畫」的偉大工程團隊。
晶心 Andes Core 有三個產品方向:
- N12 系列:適用於多功能化的商用及通訊產品市場,包括 smart phone, Digital TV, IPTV, SetTop Box 等等應用,同時也提供 SMP 架構。整體效能相當於 ARM 11
- N10 系列:具備特殊的功率節省特性,其精簡的配置,可應用在包括 MCU、儲存裝置、玩具等應用。整體效能相當於 ARM9
- N9 系列:較 N10 更低階的系列
在基礎建設有了成果後,晶心目前以 GNU/Linux 為主要研發方向,同時提供 Nucleus RTOS 的移植,規劃適用於建構 MID, NetBook, Thin Client, Android 的平台。在 90 奈米製程與平台的 SoC 規格下,CPU 最快可達 667 MHz,DDR2 部分,控制器可支援到 2GB,足以應付多種應用,搭配的 GPU 可支援到 1920x1080 的解析度。相當榮幸的,小弟雖然加入較晚,但恰好對 GNU Toolchains porting, Linux Kernel, 以及其上相關的軟體,貢獻了微薄的力量,協助奠基於新創 RISC 架構之上的軟體解決方案,作為晶片產品差異化的關鍵特徵。
日前甫達到個人階段性目標,在這所高級學府,取得短期訓練班的「修課證明」,不過,正如 一句名言所云:「人生是沒有畢業的學校」,無論在技術上,抑或情感上,這僅是一個里程碑,人生學習之路仍相當漫長,而我也欣然接受未來的挑戰。一一與晶心科技的工作夥伴道別之際,我沒有忘記這段訓練給予我的充實與豐碩的體驗,謝謝蘇博士、王博士、蕭永慶前輩,及所有的同事們,雖然我沒有受過高等教育,但仍給予自我肯定的機會。我從來沒有放棄過十年前選擇就讀資訊工程系時,支持自己的信念:
「台灣人當然能設計出世界一流的資訊系統,寫出世界一流的軟體」
這段歷程,無疑給我極大的鼓舞。
由 jserv 發表於
09:10 PM
|
迴響 (7)
April 16, 2009
演講:實做輕量級 RTOS 網路堆疊
本月 (Apr) 24 日 (週五),小弟將應國立中央大學通訊系陳彥文教授的邀約,分享主題為「實做輕量級 RTOS 網路堆疊」(Implementing Lightweight Network Stack in RTOS) 的演講,以下是相關的資訊:
- 簡介: 自 1950 年代後期,紅外線遙控器 (IR) 技術推出,而到世紀末,已變成基本配備,其可靠、簡單和廉價等特性獲得廣泛的好評,解釋何以大多數消費性電子業者仍採用這種古老的光學技術,來實現它們的產品和用戶間的介面,同時也刺激吾人所知的 Bluetooth 與 ZigBee 技術現身,應用範疇涉及手錶、醫療感測器及運動器材,或是自動控制設備等等。當這些電子設備已與我們的生活息息相關,延續 TCP/IP 網路成熟的技術與資源,就成為一個重要議題,本議程試圖探討如何以兼顧硬體之低成本與高可靠度的前提下,於 RTOS 上建構可用之網路堆疊,並陳述面臨的技術挑戰。
- 提綱:
- Bell 定律:每十年運算型態的移轉
- RTOS 與嵌入式裝置的角色
- 實現 TCP/IP 的難題
- 回歸現實:剪裁與調適
- 技術討論
- 時間: 4/24 (週五) 上午 9:00~12:00
- 地點: E1-101 (通訊館) 地圖: http://www.ce.ncu.edu.tw/ncuce_map.png
很榮幸能分享過去開發 RTOS 並導入實務應用的經驗,可說是 2007 年底,小弟發表 [
Jamei RTOS] 的開發過程中,曾觸及若干系統等級的議題,趁這個機會,將實做輕量級 TCP/IP network stack 的經驗獨立探討,又得考量到 RTOS,使這個議題稍微複雜且有挑戰性。今年一月份,小弟將 Jamei RTOS 重新實做,整理為 [
CuRT] 這個精簡易懂的 RTOS 實做,現在則補上 lightweight TCP/IP,對於有心探索系統運作者,應該是個合適的資訊。期待您的指教,謝謝!
由 jserv 發表於
08:42 PM
|
迴響 (1)
April 08, 2009
MP3 專利議題與自由軟體
去年十月的演講 [
考量到自由軟體授權的軟體系統規劃] 特別提醒到一個事實:軟體本體是電腦程式,但伴隨著作權 (聲明)、法律與合理專利使用 (執行的行為)。考量點即是掌握 copyright holder 的行使權利的範圍,並依據通行的 Law 來解釋其「具體行為」,以此觀點去思考 GNU GPL 一類的自由軟體授權條款。現實是殘酷的,作為一個自由軟體開發者,偶爾也得 [
醉 coding],妄想可寫出 patent-free 的程式碼。VM (Virtual Machine) 領域的專利不少,而多媒體就更不用說,在美妙的 MP3 音樂旋律背後,有多少齷齪的事呢?姑且不論危害有多大,自由軟體開發早已受到影響,不時成為有心人攻訐的手法。
去年底,[
Openmoko.com] 就陷入 MP3 專利的危機,被一家握有 MPEG 技術專利的義大利公司 [
Sisvel] (Società Italiana per lo Sviluppo dell'Elettronica) 控訴侵權,在業界,Sisve 因壟斷 MPEG 而聞名,之前的知名官司就是 Sisve 與 SanDisk 對簿公堂。作為一個開放原始碼的計畫,openmoko.org 背負了頗無奈的指控,畢竟,真正出貨的時候,openmoko.com 僅提供硬體裝置,以及 boot loader (採用 u-boot) 在內的基本軟體,使用者依據喜好,燒錄 (flashing) 多樣的系統映像檔案 (image file) 到 NAND flash 儲存裝置中,可以是 Linux 為基礎的 Android, Qtopia, X11/Gtk+,甚至,還能將 FreeBSD 或 NetBSD 放進去跑。原本是美事一樁,但,問題出在,openmoko.com 販售的裝置並非單純的「開發板」(DevBoard, EVM),而是貨真價實的手機,通過 FCC 認證,無論你是否接受,這就是一款手機,即電子商品,Sisve 自然也注意到是否有機會去「警告」。
openmoko 的軟體設計很多元,但基本上會透過 mp3/mpeg audio 來播放系統音效,而在電子商品中實現如此的功能,就該獲得握有 MPEG 專利的廠商同意,否則即造成侵權行為。對來自 Sisvel 的威脅,openmoko.com 的工程 VP -- Wolfgang Spraul 在去年底宣佈 Openmoko 徹下網站的軟體下載,稍後將 mpeg 相關的 playback 程式與資料移除後,再行上線。這就是去年曾在 openmoko 喧騰一時的新聞,儘管,現在 openmoko 已宣佈放棄手機設計製造的業務。
在不揭露機密資料的前提下,實做與散佈 (redistribute) 自由軟體,原則上是合理的,但,實務上,卻有太多該留意的議題,就像本文提及的 MP3 專利,Sisvel 公司要求在該公司專利的涵蓋範圍內,所有的電子裝置若要內建 MP3/MP2 的 playback 功能,需要付費取得該公司的授權許可,即便是在 .mp3 的檔案沒有版權爭議的前提下 (比方說自行錄製的 MP3 音樂輸出),重點是「播放 MPEG 多媒體技術」的行為。我們也可以見到,自由軟體發展至今的二十五個年頭,不適當的專利箝制了自由軟體的廣泛應用,本文提及的 openmoko 專案,雖然以硬體獲利,但「MPEG playback」實際上僅是某個非必要的功能,但這就造成有心者控訴的漏洞。
Google Android 開放原始碼平台內建 OpenCore 多媒體框架 (multimedia framework),等同於 GStreamer 的地位,最早稱為 PacketVideo。PacketVideo 是一家公司的名稱,而 OpenCore 是這套多媒體框架的軟體名稱,一套完整的 C++ framework,包含兩大方面:
- PVPlayer -- 提供媒體播放器的功能:Audio/Video 的 playback
- PVAuthor -- 提供媒體流記錄的功能:Audio/Video 的紀錄與靜態圖像擷取
如此的「行為」顯然在 Sisvel 公司聲明的專利生效範圍內,為了避免爭議,Google 開發團隊必須準備一份免責聲明 (disclaimers) [
出處]:
THIS IS NOT A GRANT OF PATENT RIGHTS.
Google makes no representation or warranty that the codecs for which
source code is made available hereunder are unencumbered by
third-party patents. Those intending to use this source code in
hardware or software products are advised that implementations of
these codecs, including in open source software or shareware, may
require patent licenses from the relevant patent holders.
善意提醒使用 Android 平台的廠商與個人,Google 不擔保透過 OpenCore 多媒體框架所進行的行為,包含 MPEG audio playback 等等,相關的法律議題非 Google 能掌控,也就是所謂的「請自重」,同樣的道理,即是自由軟體實務應用的重要考量點。
由 jserv 發表於
05:46 AM
|
迴響 (2)
April 07, 2009
編譯器技術的革新:談移動平台的機會
本文並不打算談及深入的技術,只是用一個實例,解釋網友詢問小弟在 [
OSDC.tw] 的 [
窮得只剩下 Compiler -- 淺談編譯技術的革命] 議程的著眼點。編譯器技術從1960 年代發展至今,已是電腦科學最成熟的基礎之一,且不斷地成長與蛻變,而透過 open source,GCC 與 [
LLVM] (Low Level Virtual Machine) 計畫獲得空前的成功,累積了驚人的編譯器技術。儘管 parser 是 compiler 的關鍵技術,但今日,我們會著重於打通任督二脈的技術展現,過去耳熟能詳卻貌似獨立的項目,比方說 virtual machine, binary translator, JIT compiler, HotSpot JVM, FDO (Feedback-Directed Optimization), ... 等等,如今好似整合了金庸書中的武功精髓、淬湅出武術菁華,形成一套獨到的武功系統,透過 LLVM 一類的整合性技術而一瀉千里。
幾年前,知名的遊戲設計公司 [
id Software] 在該公司靈魂人物 John Carmack 的主導下,將 Doom (毀滅戰士) 核心的遊戲引擎以 GNU GPL 開放授權釋出,自此廣泛的平台移植與功能強化就展開。早期的 Doom GPL 程式碼被 Sam Lantinga 移植到 SDL 圖形函式庫,藉由 SDL 優異的可攜性,眾多硬體環境得以運行 Doom 遊戲,儘管遊戲的資料檔並非自由軟體。另一方面,現在最火熱的移動平台,就屬 Google Android 開放源碼平台,為了迴避 Sun Microsystems 對 Java 的控制權 (logo + patent),該平台整合大部分 Apache [
Harmony] 專案的成果,建立了一套貌似 Java 語言但執行環境大異於 Java 的嶄新虛擬機器 -- Dalvik,將原本 stack-based VM 轉換為 register-based VM,不過本文不打算探討技術細節,總之,Android 的程式設計來說,Java 是唯一可用的程式語言,搭配 Android framework / class library,不然就是透過 JNI 去呼叫 C/C++ 撰寫的動態函式庫。作為一個 [
慣 C 魔人],筆者反覆思考,是否能將以 C 語言搭配 SDL 函式庫撰寫的 Doom,透過編譯器轉換為 Android 平台可運作的 Dalvik bytecode 呢?此舉不僅讓 C/C++ 程式跨平台執行,還為移動平台提供了新的附加價值,於是,筆者就開始一系列的 hacking,現在有初步的成果,請參考以下螢幕快照:

這可不是紙老虎或單純貼圖,電動玩具當然是設計來玩的:

此一貨真價實的 Android 應用程式自然透過編譯器技術而來,筆者採用新興的 LLVM 編譯器架構,建構一套 Dalvik bytecode backend,並使用 llvm-gcc frontend,示意圖如下:

對 LLVM 來說,筆者的更動不過只是小菜一碟,但卻巧妙的串連起來,這過程並無專門的 C/C++ 轉 Dalvik VM bytecode translator,而是透過 LLVM IR (中間表示),具體就是 "bitcode",由一個虛擬的硬體指令集的組合語言來呈現,示意如下圖:

而在 backend 的 Code generator 當然就是 Dalvik bytecode,Android 官方網頁已給予充分的文件說明,本文不贅述。不過,光如此的轉換手法,Doom 還是不能直接運作於 Android,因為需要 SDL 與圖形系統的支援。如稍早 [
淺談 Google Skia 圖形處理引擎] 一文提及,Android 的核心圖形技術就透過 Skia,並包裝於 framework 中,我們需要作適度的任務轉包,不過工作量不大,基本上就是找到 canvas,就可在畫布上呈現,自然 Doom 就可以把玩了。
那麼,LLVM IR 是如何表達的呢?我們看看以下 C 程式片段:
int mul_add(int x, int y, int z) { return x * y + z; }
我們定義了在多媒體領域常見的乘加操作,函式名稱為 "mul_add",轉換為 LLVM IR 則是:
define i32 @mul_add(i32 %x, i32 %y, i32 %z) {
entry:
%tmp = mul i32 %x, %y
%tmp2 = add i32 %tmp, %z
ret i32 %tmp2
}
一旦有了 IR,就可對 compiler 的核心作多元的操作,各式 optimizer 即可引入,只要有合適的 backend,即可輸出特定平台的機械碼,甚至是 C code,這一系列的變形有相當多種可能,畢竟,技術都在那了,唯一的極限就是人類的想像力,詳情會在筆者的「窮得只剩下 Compiler -- 淺談編譯技術的革命」議程探討,這裡就賣個關子,當然屆時會作更生動的體驗。
編譯器技術如此有趣且多元,為什麼不玩玩呢? :-)
由 jserv 發表於
01:37 AM
|
迴響 (6)