Hacking at 0xlab

Development Progress Summary about 0xlab

2012-01-05T01:18:00.005+08:00

Last two months, I was so honored and delighted to be invited as the speaker at Embedded Linux Conference Europe and droidcon.NL. I shared the progress about our development and various improvements for Anroid Open Source Project. As the developer at Linaro, 0xlab already contributes some fundamental works, and these eventually become the base for further collaborations. The topic of the presentation is "Develop Community-based Android Distribution and Upstreaming experience", and you can check out the presentation material as following:

Develop Community-based Android Distribution and Upstreaming Experience

View more presentations by 0xlab

Recently, we are quietly improving the performance of Android ICS (4.0.x) and submitting patches to CyanogenMod as community collaboration. Most of them are merged in CyanogenMod, and we are moving forward in more areas to enhance Android software stack.

Look forward to your feedback and the opportunities to work with each other.

0xlab 一年來的開發狀態更新

2011-08-14T15:04:00.009+08:00

忙碌的日子總是過得比較快，這一年來，0xlab 歷經頗多轉變，主要有以下三方面：

技術涵蓋：為了加速 Android 系統整合與優化，我們建構了若干工具與提供一些創新的方法，比方說快速啟動 Android，詳情可見 0xlab::Technology
與知名專案與開源團隊的合作：除了過去已合作的 android-x86 與 CyanogenMod 專案外 (主要是 Graphics 與 ARM 相關效能優化)，我們也投入 Linaro 的開發，建立 Android platform 與 LAVA (Linaro Automated Validation Architecture) 的基礎
建立與主要 SoC 廠商的聯繫及協同開發：與兩家重要的 SoC 廠商 (排名 Top 20 半導體公司) 密切合作開發，在 Android 的基礎上，透過若干開源的創新，加強 SoC 競爭力，並導入產品設計

即使比過往忙碌，不過我們仍持續貢獻於開放原始碼的世界，以下是從去年發表「簡介 0xlab 新的開放原始碼專案」之後的更新：

0xdroid :作為 0xlab 的 Android 參考優化與客製化設計，其成果不僅為 Beagleboard 社群所熟知，許多內部的改進也廣泛用於 CyanogenMod，間接使許多裝置與公司團體受惠。可參考 0xdroid::Roadmap 以得知細部的演進，簡單來說，在高解析度的環境，提昇了 Android 使用者體驗 (software curosr, on-screen keyboard, launcher)，另外就是進一步的 ARM 優化，從 skia, zlib, libcore, libc, 到 libagl (libGLES_android) 都有
0xbench : 仍是截至目前為止，我們所知的最完整 Android 開放原始碼系統效能評測工具，與上個版本相較，追加了 Web/JavaScript 效能評測、LAVA 的資料格式 (bundle)、重新啟用 libMicro 等等，詳情可見 0xbench::Benchmarks
Linaro : 經 ARM 的支持，0xlab 投入 Linaro 開發，共同為改善開發原始碼軟體品質而努力。我們涉及的項目稍微繁雜些，從整合 Linaro toolchain、改善 Android runtime、強化 LAVA 的整合，到多媒體驗證都有
aster : 全名是 "Android System Testing Environment and Runtime"，著眼於 Android 系統中許多無法透過 API 呼叫所作的 black-box test，一旦 adb daemon 正常啟動後，這個系統就可依據指定的 test case 去逐一執行並驗證，此系統也允許使用者編輯操作案例
Android 快速開機: 利用優化過的 ARM hibernation (suspend-to-disk)，大幅縮減 Android 系統從 HW reset 到使用者得以操作的時間，可參考展示影片 "Android Fast Booting with CarHome"，相關的原始碼也一併釋出，可見 0xlab-kernel，儘管仍有頗大的進步空間，但這是完全可運作且開源的解決方案
AMBER : 這是我們提供的第一個完整的應用系統，概念非常簡單，考量到現有 Android 裝置相當多元，可能是手機、筆記型電腦、平板電腦、電子書，或者數位電子，這之間要進行媒體 (media/content) 的交換往往很沒效率，而且使用者還得被繁複且多樣的多媒體格式所困擾，若無適度的轉換，通常就無法在手機或者較陽春的平板上播放。我們提出的解法，就是將動作縮減為 "push" 與 "pull"，自動偵測媒體的格式與屬性，無論在近距 (家用或小範圍) 或遠距 (透過雲端或者防火牆)，挑選最合適的途徑，讓使用者盡情觀賞與交換。同樣的，這也是開放原始碼，內建於 0xdroid
Toolchain : 除了改善 Linaro Toolchain for Android 外，我們還改善了 Android ELF prelink，大幅縮減執行時期需要解析的 ELF 符號數量，也縮減了載入時間，近期內會提交到 AOSP
Android Open Source Project : 已被 Google Android 計畫正式收錄 37 個修改/貢獻

其他項目就要看合作夥伴的狀況了，先提到這邊。歡迎透過以下方式，與我們聯繫與交流：

Twitter: http://twitter.com/0xlab
郵件論壇: 0xlab-devel (系統開發) ; 0xlab-discuss (一般討論)
YouTube: http://www.youtube.com/0xlab
有源碼有真相: gitorious, github

一如過往，我們今年也會在台灣最大的開放原始碼研討會 COSCUP 發布最新的專案與社群計畫，期待您的指教，謝謝！

0xlab 在 OSDC.tw 2011 的議程分享

2011-02-07T11:40:00.014+08:00

在台灣，一年一度的開放原始碼盛會 OSDC.tw 即將於今年三月 26 與 27 兩日舉辦，而 0xlab 除了很榮幸能成為 OSDC.tw 贊助單位之外，也有五位開發者獲邀分享若干技術議程，以下摘錄的演講摘要：

講題： The meaning of open
講者： John Lee
摘要： Open source can be a culture, a belief, a hobby, a profession, and many things else. Now it can also be a business model. 0xlab has been trying to build a bridge between companies and open source communities for almost two years. We believe that by creating an ecosystem around open source technologies, we can help it growing stronger in Taiwan. This session is about our idea, our vision, and our progress.

講題： Build Programming Language Runtime by LLVM
講者： Jim Huang (jserv)
摘要：在 OSDC 2009 的〈窮得只剩下 Compiler -- 淺談編譯技術的革命〉議程，提及編譯器相關的技術獲得空前的成功，而在運算型態多元的今日，如何跨越語言的藩籬卻又得兼顧底層平台的效能與安全，即是當前的重要課題。本議程將探討如何打造架構於 LLVM Compiler Infrastructure 的程式語言執行環境，並分析傳統編譯/解譯式語言到當紅的動態程式語言在引入於移動平台時，值得深入探索的技術細節。

講題： Rloader, alternative technology to achieve fast boot time for ARM Linux
講者： Matt Hsu
摘要： To reduce boot time for embedded device, you can optimize from different aspects, such as bootloader, kernel, and applications. But this usually needs to do optimization on specific application. Instead, Rloader can provide _generic_ solution to achieve fast boot time without changing your application.

講題： SVG+Javascript meets Embedded Systems
講者： Thinker Li
摘要： After two years of work, MadButterfly, a SVG based GUI environment, had made a breakthrough. It suports Javascript to improve efficiency for developing embedded systems. In late 2010, we also improve our code with OpenVG, an HW acceleration API, to provide high-performance GUI. This talk would demonstrate an efficient way for developing an embedded system with GUI, and provide high quality and performance GUI output with a low-Hz platform at the same time.

講題： Gallium3D - Mesa's new driver model
講者： Chia-I Wu (olv)
摘要：做為 Linux 系統主要的開放源始碼 3D 驅動程式，在 GPU 應用範圍越來越廣泛的同時，傳統的 Mesa driver model 已逐漸不敷使用。本議程將簡介 Mesa 新提出的 Gallium3D 架構，理解何以 Gallium3D 能夠幫助開發者更快地去支援新的硬體、作業系統與繪圖 API 。

依據慣例，屆時我們也會發布最近的開發成果，期待您的蒞臨指教，謝謝！

0xlab 的客製化 Android toolchain

2010-11-16T15:55:00.003+08:00

有鑑於 Google 的 Android toolchain 開發團隊雖然活躍提交修改/貢獻到 GCC 與 binutils，但受限於 Android 原始碼釋出的慣例，總是要等待頗長的時間，才有機會使用到新的 GNU Toolchain 改善或者新功能，所以，0xlab 開發者就準備一份客製化的版本，請參考以下網址：

http://downloads.0xlab.org/toolchain/armv5te/

目前提供 gcc-4.4.3 與 gcc-4.4.4 兩個版本，前者是取自 Google Android 的原始碼分支，提供 ICF (Identical Comdat/Code Folding) 與 LIPO (Lightweight IPO) 等優化機制，而 gcc-4.4.4 的版本則是 0xlab 升級到新的程式基礎，並加入必要的修正。原始程式碼與 Toolchain 建構系統可參考 GIT: android-toolchain。不久的將來，我們將會全面移轉到 Linaro toolchain，也會一併發布 gcc-4.4 與 gcc-4.5 的 Android toolchain。

加速 Android 的動態連結

2010-10-19T21:52:00.005+08:00

就如人們所熟悉，Android 底層運作 Dalvik 虛擬機器，在 C Library 層面採用衍生自 NetBSD libc 的 bionic。與過往的 Java 為基礎的操作環境 (OE; Operating Environment，如 Transvirtual 的 PocketLinux / XOE) 不同的是，每個 VM instance 均為獨立的 Linux process，且由 Zygote 所「孵化」。就系統的角度來說，縱使底層對 system library 做了 prelink (透過工具 build/tools/apriori)，但因語言實做的特性，需頻繁經由 JNI 去存取底層服務，也就是說，有大量的 dlopen()/dlsym() 操作，這些均無法透過 prelink 來縮減載入時間。

在 COSCUP 2010 的議程「打造特製的 Android Toolchain」中，小弟介紹了 0xlab 近來的幾項嘗試與改進項目，除了 GNU Toolchain (採用 gcc-4.4.4 搭配一系列的修改) 之外，就包含 Android bionic libc 與 prelink 的修改，企圖引入 DT_GNU_HASH 的機制 (也稱為 gnu hashstyle，或 gnu hash)，以加速 Android 的動態連結。現在基礎工作大致完畢，陸續提交到 AOSP (Android Open Source Project) 的 Code Review，應該會納入 Android Gingerbread 以及後續的版本中。實驗平台採用 Qualcomm MSM7x25 (arm1136j-s)，平均縮減 26% 的 ELF 動態連結時間，這對所有的 Android Activity (Java 程式) 與需要額外作 dlopen() 處理的系統函式庫，如 Qualcomm 的 camera HAL/service 或 Opencore/DSP，均可適用。

這過程中，讓小弟學習到頗多，從一開始的分析 (透過 oprofile 與開啟 bionic 裡頭 linker 的除錯資訊)，觀察到 Android 的動態連結處理，有點類似 OpenOffice 所面臨的議題，於是嘗試引入 DT_GNU_HASH。背景知識可參考以下文獻：

LWN 清晰的介紹文章 "Optimizing Linker Load Times"，涵蓋四項 linker 參數背後的處理機制: -Wl,-O1, -Bdirect Linking, dynsor, gnu hashstyle (Precomputed Hash Values)
Ali Bahrami 的 blog 文章 "GNU Hash ELF Sections" 與 "The Cost Of ELF Symbol Hashing"，淺顯易懂
glibc 維護者 Ulrich Drepper 的論文 "How To Write Shared Libraries" (不要被 How To 字眼騙了，其實頗深入)，廣泛探討從歷史因素到 DSO 運作機制，以及 GNU Hackers 如何參照 Sun Microsystems 過往的改良機制，重新實做出 gnu hashstyle

gnu hashstyle 採用 Daniel J Bernstein 提出的 hash function，Jakub Jelinek 做了分析，比較原本 ELF hash:


The number of collisions in the 537403 symbols is:
name  2sym collision # 3sym collision # more than 3sym collision #
sysv            1749                5
libiberty         42
dcache            37
djb2              29
sdbm              39
djb3              31
rot              337               39                         61
sax               34
fnv               40
oat               30

sysv 那項是原本的 hash function，而 djb2 則是 GNU Toolchain 採用的方案。就現有自由軟體的實做來看，包含 glibc, uClibc, dietlibc (前三者支援 GNU/Linux), FreeBSD libc 均提供 gnu hashstyle 的支援，但 Android 未正式在 bionic 提供。需留意的是，prelink 方案總是比 gnu hashstyle 帶來更快的動態連結時間，但付出的代價 (空間) 較高，而且不若後者有彈性。

簡介 0xlab 新的開放原始碼專案

2010-09-01T01:47:00.007+08:00

我們在今年八月中旬的 COSCUP 研討會中，很榮幸地向與會的朋友介紹 0xlab 若干新的開放原始碼專案，本文稍作整理回顧。0xdroid 是 0xlab 最早的一項整合性開放原始碼專案，目的是建構於 Beagleboard 開放的硬體之上，提供 Android 的參考實做環境，經過一年多的累積，裡頭的成果被帶到不同的移動裝置中，比方說手機與 Tablet。今年二月份，有幸在 Mobile World Congress 2010 展示基於 Android 的移動裝置，Tieto 也在 TI OMAP3 平台展示 0xdroid，這些都讓我們更有信心，擴展到多元的應用。

這半年間，延續 0xdroid 的經驗，我們發展 / 貢獻以下專案：

0xRobocat : 與 CATCAN 合作的專案，目的是打造一組控制伺服馬達與相關零組件的軟體框架，可提供給 Android 或 GNU/Linux 使用，以 Apache License 2.0 授權釋出。除了用於打造機器人外 (是真的可走動的 "Android")，本專案可用於 Android 裝置 (如手機) 的自動測試
0xBench : 有鑑於 Android 上的系統效能評比程式，不是不完整，就是非開放原始碼，所以我們決定重新打造一個。0xBench 可從 C 函式庫/系統呼叫的層面，一路從 Dalvik VM 評測到 Android framework，仍持續擴充，並且我們提供 Web service，允許貢獻評測的結果，用互動的方式來分析。程式主體是 Apache License 2.0 授權
android-toolchain : 0xlab 特製的 GNU Toolchain，以 Android team 的成果為基礎，整合來自 Linaro Toolchain Working Group 的改善。這些主要是 GNU GPLv3 授權
Android Open Source Project (AOSP) : 提交 0xlab 過去在 TI OMAP 與 Qualcomm 72xx 平台的一些修改，經過公開的 Review 機制，慢慢整合到 AOSP
CyanogenMod : 社群版本的 Android，在 Nexus One, HTC Dream 等裝置有相當優越的表現，收錄若干來自 0xlab 的改良，比方說 Bluetooth HID profile

除了以上的開放原始碼專案，我們內部正進行一個基於 Android 的新型態應用，未來也會將相關的專案程式碼，以開放原始碼的形式釋出，完整的列表可參考 0xlab Projects。至於 AOSP，我們現有更改的項目是：

build - 調整 Android build system、修正工具程式的瑕疵
bionic - 提供 ARM optimizations，針對 ARMv6/ARMv7
PixelFlinger - 基本的 refactoring，以及 ARM 實做的改良
libpng / libz - 利用 GCC visibility，進一步縮減 code size
elfcopy - ELF 工具的調整
bionic / apriori / build - 支援 DT_GNU_HASH，加快動態連結的速度
toolchain - 加強 build system 的彈性

以上，歡迎舊雨新知給我們支持與指教，謝謝。

0xlab 在 COSCUP 2010 的議程分享

2010-08-02T02:33:00.004+08:00

一年一度的「COSCUP / 開源人年會」即將於八月 14 與 15 兩日舉辦，因為今年與 GNOME 亞洲峰會合辦，造成空前的盛大。0xlab 除了很榮幸能成為 COSCUP 贊助單位之外，也有四位開發者獲邀分享若干技術議程，以下摘錄 COSCUP 的演講摘要：
講題：Android Game Engine 比較

講者： walkingice (0xlab)

摘要：隨著 Android的蓬勃發展，遊戲亦如雨後春筍般冒出。避免重複造輪子，勢必要藉助現有的遊戲引擎，讓遊戲開發者可以專注在遊戲的最核心價值 — 樂趣

講題：Be "Android"

講者： tick (0xlab), matt (0xlab)
摘要：將 0xdroid 打造成為機器人平台。Robocat 是為 0xdroid 所設計的機器人控制系統，此議程將從硬體架構、系統設計、函式庫及應用程式等不同層面切入，介紹如何打造自己的 ”Android”

講題：打造特製的 Android Toolchain

講者：Jim Huang "jserv" (0xlab)
摘要：探討 0xlab 近來的實驗，從修改 Android 的 GNU Toolchain 到提供 source-to-source compiler，提出若干基於特定需求，從而發展的編譯器技術的新應用

涵蓋 Android Toolchain, Robot, Android Gaming 開發，依據慣例，屆時我們也會發布最近的成果，期待您的蒞臨指教，謝謝！

在 Android/Dalvik 環境引入 precompiled class 的實驗

2010-05-26T01:01:00.004+08:00

延續筆者去年的紀錄「當 Compiler 遇上 Mobile」，最近我們又獲得一些進展，是在 Android 的 Dalvik 虛擬機器環境中，引入 pre-compiled class 的實驗，除了可改善執行時期的效能、記憶體使用量外，另外就是避免在「反組譯並修改 Android 應用程式實例」一文可見的資訊保護議題。

其實十幾年前，在 Java 平台中就有相當多團隊提出可行的方案，而世界上第一個開放原始碼的 Kaffe 虛擬機器專案，早在 1999 年即提出實做 "Kaffe/GCJ integration"，成功地將 GCJ (GCC for Java) 自 Java class/source 編譯得到的機械碼，當作 pre-compiled shared library，讓 Kaffee VM 讀取，預期可有效改善執行效能並縮減起始時間。GNU Classpath 專案主持人 Mark Wielaard 在 LWN 的文章 "GCJ - past, present, and future" 提到相關的歷史與技術背景，最早可回溯到 Cygnus solutions 時期 (RedHat 尚未併購) 的 GCJ 計畫提案 -- "A Gcc-based Java Implementation"。

為了降低實做的複雜度，筆者最早採用 LLVM 與 IcedTea 作為系統框架，不過一直到今年春節，整體進度還是陷入膠著的狀態。現在則引入 Java2C 搭配 PGO (Profile-Guided Optimization) 與統計模型，嘗試分析運行於 Dalvik VM 的 Android activity / system server，佔用系統資源最頻繁的項目，並預先編譯 (pre-compile) 這些 class/method，居中透過 JNI (Java Native Interface) 讓 Dalvik VM 存取。不過，實務上來說，不是將所有 class/method 都編譯為原生機械碼，就會帶來效能提昇，相反地，後者往往讓系統陷入更差的效能。目前 Eclair 裡面的 Dalvik VM 雖然沒有完整的 JIT compiler，但其 fast interpreter for ARM 的確做了頗多 threaded interpreter 的改進，考量到 I-cache, paging, 與 branch prediction，若我們不思量 Java / Android Dalvik 應用程式的執行時期行為，只是一味作編譯轉換，很可能只是編譯極少被執行，或者完全不會被執行到的程式碼，因此加重執行時期的負擔，而最該被優化的部份，受限於不完整的 source-to-source 轉換，有顧此失彼的疑慮。

於是，找出系統中最該被優化的部份，並考量到正確性與相容度，就是我們的首要研究議題，筆者採用知名的 SciMark 2.0 作為量化分析的指標。以下是在 Qualcomm MSM7x25 硬體平台 (arm1136j-s) 的效能評比，ARM11 的時脈是 528 MHz，ARM Linux 版本為 2.6.29.6-0xlab：
由上可見，在 SciMark 2.0 的各項評比中，Pre-compiled class 執行效能都較 Android Dalvik fast interpreter for ARM 給予一定程度的改良，並且透過 FDO (Feedback Directed Optimization)，大多可進一步給予提昇。這僅是初步的整合實驗數據，還需要更多分析與進行實做。

反組譯並修改 Android 應用程式實例

2010-05-21T22:08:00.016+08:00

為了某個實驗的動機，我們評估反編譯 Android 應用程式的可行性，本文即是筆者的心得與實際的範例，僅供參考。就筆者的認知，目前還沒有針對 Android 的 DEX to Java source 反編譯工具，可實際處理一般的 Android 應用程式，多半要繞幾圈，還會得到不甚理想的結果，不過，smali 這個反組譯工具，已是可用了，只是得對付類似 Jasmin 語法的 Dalvik 組合語言。筆者打包了 smali 與 Frozen Bubble for Android，作為示範：

http://0xlab.org/~jserv/dex-dis-example.tar.bz2

在 GNU/Linux 環境中，首先取得 Android SDK，這裡採用 Eclair/2.1，工具執行檔的路徑是 android-sdk-linux_86/tools，將此路徑放入 $PATH 環境變數，如此一來，就可以操作 adb, aapt, apkbuilder 一類的工具程式。筆者提供的套件已包含 Frozen Bubble 執行檔，檔名為 "FrozenBubble-orig.apk"。一旦 Android emulator 啟動後，即可安裝進去執行：(後續的操作也需要 Emulator 持續開啟)

$ adb install -r FrozenBubble-orig.apk

以下是執行畫面：
當然，沒必要讓筆者置喙談如何玩這個經典遊戲，不過我們倒是想更改原本的行為。在進行之前，我們先來複習 Android APK 的建立，參考 "How to build Android application package (.apk) from the command line using the SDK tools + continuously integrated using CruiseControl." 一文，我們可從以下圖表知悉細部的流程：

假設我們完全無法取得原始程式碼，該如何進行呢？沒錯，就透過 smali，簡化繁瑣的流程，筆者包裝為 Makefile，所以只要先解開並反組譯：

$ make extract

這時候會看到兩個目錄：

smali-src : 存放反組譯的程式檔輸出
workspace : 原本 Frozen Bubble 的 Android resource files

二話不說，當然是觀察反組譯的結果：

smali-src$ find
./org/jfedor/frozenbubble/FrozenBubble.smali
./org/jfedor/frozenbubble/R$id.smali
./org/jfedor/frozenbubble/GameView.smali
./org/jfedor/frozenbubble/SoundManager.smali
./org/jfedor/frozenbubble/LaunchBubbleSprite.smali
./org/jfedor/frozenbubble/Compressor.smali
./org/jfedor/frozenbubble/R$attr.smali
./org/jfedor/frozenbubble/BubbleFont.smali
./org/jfedor/frozenbubble/PenguinSprite.smali
./org/jfedor/frozenbubble/GameView$GameThread.smali
./org/jfedor/frozenbubble/BubbleSprite.smali./org/jfedor/frozenbubble/R$string.smali
./org/jfedor/frozenbubble/R$drawable.smali
./org/jfedor/frozenbubble/ImageSprite.smali
./org/jfedor/frozenbubble/BubbleManager.smali
./org/jfedor/frozenbubble/GameScreen.smali
./org/jfedor/frozenbubble/R.smali
./org/jfedor/frozenbubble/R$layout.smali
./org/jfedor/frozenbubble/BmpWrap.smali./org/jfedor/frozenbubble/FrozenGame.smali
./org/jfedor/frozenbubble/Sprite.smali
./org/jfedor/frozenbubble/LevelManager.smali
./org/jfedor/frozenbubble/R$raw.smali

就忠實地依據 Java package 的方式呈現，檔名結尾是 ".smali"。筆者的修改目標是，讓一開始的關卡 (Level) 從第一關直接跳躍到第五關。在 smali 原始程式碼 (注意：這完全不同於 Java 原始程式碼，而是極為貼近 Dalvik VM 所接受的 DEX 檔案的組合語言形式) 搜尋 "Level" 字眼，可發現主要的分佈就落於兩個檔案：

./org/jfedor/frozenbubble/GameView$GameThread.smali
./org/jfedor/frozenbubble/LevelManager.smali

前者就是 org/jfedor/frozenbubble/GameView.java 的編譯輸出，因為是 inner class，獨立編譯出 org/jfedor/frozenbubble/GameView.class$GameThread.smali，由這個 class 命名方式大概就可猜出其重要性，基本上只要能夠控制此 class 的實做，就掌握此 Android 應用程式的行為。而 class LevelManager 顧名思義，看來掌握了遊戲進行的程序控制。先觀察其 method 列表：

smali-src$ grep "\.method" org/jfedor/frozenbubble/LevelManager.smali
.method public constructor <init>([BI)V
.method private getLevel(Ljava/lang/String;)[[B
.method public getCurrentLevel()[[B
.method public getLevelIndex()I
.method public goToFirstLevel()V
.method public goToNextLevel()V.method public restoreState(Landroid/os/Bundle;)V
.method public saveState(Landroid/os/Bundle;)V

倘若我們以 "goToFirstLevel" 一類的關鍵字，在 org/jfedor/frozenbubble/GameView$GameThread.smali 檔案中搜尋，可找出有具體的呼叫行為：

smali-src$ grep -r goToFirstLevel *
org/jfedor/frozenbubble/GameView$GameThread.smali: invoke-virtual {v2}, Lorg/jfedor/frozenbubble/LevelManager;->goToFirstLevel()V
org/jfedor/frozenbubble/LevelManager.smali:.method public goToFirstLevel()V

由此更確定我們之前的猜想。其中組合語言寫為以下：

move-object/from16 v0, p0

iget-object v0, v0, Lorg/jfedor/frozenbubble/GameView$GameThread;->mLevelManager:Lorg/jfedor/frozenbubble/LevelManager;

move-object v2, v0

invoke-virtual {v2}, Lorg/jfedor/frozenbubble/LevelManager;->goToFirstLevel()V

不要被貌似複雜的語法嚇到了，基本上掌握 Java 程式語言的原則 "Everything is Object" (不過仍有提供 primitive type)，組合語言仍會作 Java Object 的實體化 (instantialization)，Dalvik 本身是 Register-based Virtual Machine，而扣除 static/class method 外，Java 中所有的 method invocation 多為 virtual function (對應於 C++ 的觀點，才能更具體用機械方式思考)，所以組合語言的指令為 "invoke-virtual" (注意有連字號，此與 Java bytecode 不同)，"{v2}" 表示第一受者的 Register，此為 Object 本體。接著，與 Java bytecode 一樣，"Lorg/jfedor/frozenbubble/LevelManager;" 就表示 Java 層面的 class "org.jfedor.frozenbubble.LevelManager"，字母 "L" 即為 class 的識別，而 "->" 就很直觀了，自然是 method invocation，所以連貫來看，這一段組合語言的 Java 意思為：

objectLevelManager.goToFirstLevel();

其中 objectLevelManager 是一個 class LevelManager 的實例/實體 (instance)。倘若需要在 method invocation 時，帶入參數，那麼前述的 "{v2}" 一般會被替換為 "{v0, v1, v2, ...} 的 register 列表。關於詳細的狀況，可參考 Dalvik 非官方說明，另外 smali 的 wiki 也提供一些範例，可多加利用。

回到筆者剛剛設定的目標，我們既然知道 class org.jfedor.frozenbubble.GameView$GameThread 掌控了程式處理邏輯，自然一堆變數的傳遞、method 呼叫，都在此進行，那我們先試著用 "level" 字串去搜尋，想辦法找出常數定義，後者在 Dalvik 中，會集中保存於 constant pool 中，而 smali 的組合語言寫法大致是 "const" 開頭的宣告，端看其類型而定。以程式追蹤的目的來說，我們專注於以下兩種：

const-string : primitive string (不同於 java.lang.String) 表示
const/4 : 長度為 4 bytes (32 bit) 的整數表示

字串何其多，依據之前的推測來說，我們要找接近 "LevelManager" 字眼的組合語言程式碼，道理很明顯，從一般 Java programmer 的寫作邏輯去反推。經過一番搜尋，我們找到以下的反組譯程式碼： (位於檔案 org/jfedor/frozenbubble/GameView$GameThread.smali中)

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25 move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4 invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

在上述程式碼列表中，"Lorg/jfedor/frozenbubble/LevelManager;-><init>" 表示呼叫 class LevelManager 的 constructor，也就是 "<init>"。注意到 method invocation 方式就不同了，是 "invoke-direct"，表示 class constructor，而這之前要有 "new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;" 的組合語言指令宣告。

前面談過「倘若需要在 method invocation 時，帶入參數，一般會被替換為 "{v0, v1, v2, ...} 的 register 列表」這樣的概念，我們可推知，Register v1 與 v2 就是實際上 class org.jfedor.frozenbubble.LevelManager 的 constructor 參數。就程式設計的邏輯來看，class GameView 就是依據某個流程，要求 LevelManager 去改變狀態，所以這裡的兩個參數，其實就是初始值，非常的重要。

與 Register v1 相關的組合語言指令有這幾行：(用粗體字標示)

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

顯然，Register v1 還被帶入到 android.content.Shared.Preference.getInt() method，而更早以前，其內含值被設定為 Register v3 的值，也就是常數字串 (const-string) "level"，這好像與我們的焦點不同。另外，像是 Register v22 這個編號較大的 register，表示 local variable，這點需要多留意，因為 Java 程式設計的規範來說，往往會將程式切割為若干 method，而 method 實做體中，又有極多的 local variable，於是往往可從組合語言反推 Java 原始碼的型態。

那麼，看看 Register v2 吧，同樣用粗體字標示相關的指令：

const-string v3, "level"
const/4 v4, 0x0
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

這個 Register v4 的內含值 "0x0" 會指派到 Register v2 中，而讓我們似乎找到方向了，回頭看看 class org.jfedor.frozenbubble.LevelManager 的 constructor 宣告方式： (之前 grep 結果的第一行)

smali-src$ grep "\.method" org/jfedor/frozenbubble/LevelManager.smali
.method public constructor <init>([BI)V

其中 "public" 是 ACL (存取權限) 的宣告，而 constructor 的符號規範為 "<init>"，注意到括號 "(" 與 ")" 裡面的兩個大寫字母，表示接受兩個參數，對應的型態為：

B : byte
I : int

在 Java 與 Dalvik virtual machine 皆以同樣的形式作宣告，看到這裡，我們實在忍不住要動手修改了，當然，一切都是實驗性質。既然一開啟遊戲，畫面就顯示 Level 1，表示 LevelManager 一開始接受的 level 參數會是 "0"，然後依據 GameView 的邏輯，逐一升級或中斷遊戲進行，那麼，如果要讓遊戲一起動就是 Level 5，是不是要把內含值改為 0x4 即可？也就是 "invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V" 的 Register v2 當時內含值該為 0x4，不就任務達成了嗎？想到此，不禁會心一笑。

不過，回顧稍早 Register v2 的相關程式碼輸出，其中有兩行需要留意 (以粗體字為主)：

invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
move/from16 v2, p4

"p4" 用以保存 method invocation 之後的回傳值，顯然，Register v2 受到 p4 的指派，也就是被更動為 android.content.Shared.Preference.getInt() method 的回傳值，這存在不確定性，於是，我們乾脆一口氣改掉： (修改的部份會用井字號 "#" 作註解)

# Modified from 0x0 to 0x4"
const/4 v4, 0x4
move-object/from16 v0, v25
move-object v1, v3
move v2, v4
# Modified: removed the following 2 lines
# invoke-interface {v0, v1, v2}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
# move-result p4
new-instance v3, Lorg/jfedor/frozenbubble/LevelManager;
move-object v0, v3
move-object/from16 v1, v22
# Modified: removed the following 1 line
# move/from16 v2, p4
invoke-direct {v0, v1, v2}, Lorg/jfedor/frozenbubble/LevelManager;-><init>([BI)V

改好程式，當然要驗證，回到上一層目錄，透過 smali 提供的組譯器，重新產生 Dalvik DEX 輸出，為了簡化流程，筆者把 smali, apkbuilder, aapt, adb install 都一次整合進去，所以會直接讓 Android Emulator 生效，來看看我們的戰果吧：
注意到左下角，這表示我們成功了，完全不用取得 Java 原始程式碼，就可以作反組譯並且修改的動作。

Android Toolchain 原始程式碼尋寶

2010-05-04T11:21:00.003+08:00

很多人從事 Android 移植，但連 Android Toolchain 都自行維護者，相對就少多了。筆者過去有幸在「台灣心」計畫中，從事建構於台灣自主 CPU 的軟體開發，嘗試從零到有，將 Android 移植到 Andes NDS32 架構，就涉及到 Toolchain 的更動。而維護 0xdroid 與對應 0xlab 的 GNU Toolchain，不免會迷失於眾多的原始程式碼，只好靜下心慢慢探索，沒想到因此挖掘到頗多「寶物」，本文簡記備忘使用。

Google 工程師 Jing Yu 於 Jan 18, 2010 提交一份修改 "Bring gcc-4.4.0 to up-to-date"，讓人摸不著頭緒，不過其對於 GCC 的 architecture 更動，追加了新項目，可參見檔案 gcc-4.4.0/gcc/config/linux-grtev1.h 。以下節錄開頭註解：

/* Definitions for Linux-based GRTE (Google RunTime Environment) version 1.
Copyright (C) 2009 Free Software Foundation, Inc.
Contributed by Chris Demetriou.

This file is part of GCC.

這個以 Linux 為基礎的 GRTE 到底是什麼呢？沒獲得解答，只好在其 gcc spec 檔中探索，以下是相關的描述：

/* When GRTE links statically, it needs its NSS and resolver libraries
linked in as well. Note that when linking statically, these are
enclosed in a group by LINK_GCC_C_SEQUENCE_SPEC. */
#undef LINUX_GRTE_EXTRA_SPECS
#define LINUX_GRTE_EXTRA_SPECS \
{ "libc", "%{static:%(libc_static);:-lc}" }, \
{ "libc_p", "%{static:%(libc_p_static);:-lc_p}" }, \
{ "libc_static", \
"-lc -lnss_borg -lnss_cache -lnss_dns -lnss_files -lresolv" }, \
{ "libc_p_static", \
"-lc_p -lnss_borg_p -lnss_cache_p -lnss_dns_p -lnss_files_p -lresolv_p" },

這裡的 libc 看來是獨立的 C Library 實做，比較有趣的是 libnss 的部份。libnss 可透過外部的 module 作擴充，比方說 libnss-ldap 就是 "NSS module for using LDAP as a naming service"，而前述 gcc spec 提及當進行靜態編譯時，需要將所需的 module 一併連結，那麼，這系列 libnss_ 開頭的函式庫，顯然就是 GRTE (Google RunTime Environment) 所需的基礎建設。來看看有哪些特別的：

libnss_borg
libnss_cache

或許後者可從名稱猜出一些端倪，但這個 "libnss_borg" 實在是太詭異 (Borg in Star Trek?)，跟 GRTE 一樣神秘，我們只好等待 Google 大神給我們一些驚喜。

另外，Android Benchmark Suite 2.0.0 已公開釋出，可參見 benchmark.git，值得一書的是，內建了 FDO (Feedback Directed Optimization) 的編譯、測試，與效能評估機制。

0xdroid 正式支援 DevKit8000 開發板

2010-03-10T12:15:00.006+08:00

沈寂的一段時間，現在 0xdroid 又恢復活躍的開發。正如稍早在 0xlab-devel 郵件討論區提及 "Return back to open source world"，我們陸續將之前開發的成果，貢獻到自由軟體的世界，環繞在 0xdroid 的項目有：

對 Beagleboard 一貫的完整支援，不只是將 Android 運作起來，還要提昇整體的效能與可用性
除了支援 Beagleboard 外，對 DevKit8000 也有充分的支援
擴充 esuit 並整合 Android CTS (Compatibility Test Suite) 與 Sikuli，提供涵蓋 board-level, API-level, Application-specific 的自動測試框架
對 Android 為基礎的系統作全面性的功能、效能，與可靠度評比，以及整合上述的自動測試框架，以驗證量化系統的品質

在 kanru 的努力與若干網友的貢獻 (hychen, Fred, itszero) 下，現在對 DevKit8000 的支援已加入到 GIT repository，以下是執行時期的照片：
(0xdroid 的桌面與 Launcher)
(調整為直式顯示，符合原本 Android 的預期輸出假設)
目前支援 Android Donut 與 Eclair，在 0xdroid 即是 beagle-donut 與 beagle-eclair，需要搭配最新的 0xlab-kernel，對 DevKit8000 週邊做出更好的支援。以下是簡要的功能特徵描述：

支援 DevKit8000 特有週邊：Ethernet, LCD panel / touchscreen, keypad
提供對應的使用者介面 (UI) 設定程式，包含 Ethernet 與 Touchscrren calibration UI
延續之前 0xdroid 在 TI OMAP3 平台的效能改善成果

近期內我們將會釋出新的 image installer，並持續改善 TI OMAP3 平台的 Android Eclair，而在今年的 OSDC.tw 研討會上，有個針對 0xdroid 的議程，歡迎前來指教，也希望對 0xlab 一系列開放原始碼專案有興趣的朋友，可來 0xlab-devel 郵件討論區參與討論，謝謝！

libacc : Android 2.0 內建的輕量級 C Compiler

2009-12-09T16:53:00.005+08:00

Android 2.0 (Eclair) 原始程式碼已於一個月前釋出，在目錄 system/core 下有個 libacc 的子項目，這是開發者修改自 Fabrice Bellard 的大作 OTCC (Obfuscated Tiny C Compiler)，以 C++ 與 Android 的執行時期函式庫重寫。libacc 的功能是提供給 Android 2.0 的 RenderScript 一個 C-like 語法的描述，如此一來，開發者可撰寫高效能的視覺效果與動畫，不過這部份並未完成，詳情可參考 "Android renderscript, more info' and an example application" 一文。

關於 libacc 的整合部份，可參考 frameworks/base/libs/rs 目錄下的兩個檔案：

rsScriptC.cpp
rsScriptC_Lib.cpp

筆者準備了一份可單獨執行於 GNU/Linux 環境的套件："libacc.tar.bz2"，除去 Android 的相依性並補上 Makefile，測試方式如下：

libacc$ make
g++ -I./include -DHAVE_PTHREADS -c acc.cpp
gcc -I./include -DHAVE_PTHREADS -c hashmap.c
gcc -I./include -DHAVE_PTHREADS -c logd_write.c
g++ -I./include -DHAVE_PTHREADS -c tests/main.cpp
g++ -I./include -DHAVE_PTHREADS -c tests/runtimeTest.cpp
g++ -o main \
  acc.o \
  hashmap.o \
  logd_write.o \
  main.o \
  -ldl
g++ -o runtimeTest \
  acc.o \
  hashmap.o \
  logd_write.o \
  runtimeTest.o \
  -ldl

libacc 的 Code generator 支援以下硬體架構：

x86 / IA32
x86_64
ARMv5

以 IA32 的環境為例，可透過測試程式來驗證 libacc： (參數 -R 表示作執行的動作)

libacc$ ./main -R tests/data/hello.c
Executing compiled code:
Hello, world
result: 0

其中 tests/data/hello.c 的內容為：

libacc$ cat tests/data/hello.c
int main() {
printf("Hello, world\n");
return 0;
}

若平台是 ARM 的話，還可以支援反組譯輸出，libacc 是 RenderScript 背後很重要的基礎建設，允許動態編譯 Android Graphics 的 RenderScript，輸出成機械碼並執行。參考檔案 tests/runtimeTest.cpp 可得知 RenderScript 的寫法，整個 libacc 可內嵌於程式中，比方說：

const char* text = "void op_int(int a);\n"
   "void op_float12(float a, float b, float c, float d,\n"                   
   "           float e, float f, float g, float h,\n"
   "           float i, float j, float k, float l);\n"
   "void script() {\n"
   "  globalVar += 3;\n"
   "  op_int(123);\n"
   "  op_float12(1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0);\n"
   "}\n";

這個字串經過 libacc 的函式呼叫後，可得到以下的編譯與執行結果：

libacc$ ./runtimeTest
Executing script:
op_int(123)
op_float12(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)
After script globalVar = 20

目錄 tests 還包含可在 Android 環境執行的自動測試 Python script。

在 0xdroid 充分發揮 Beagleboard/OMAP3 的硬體特性

2009-09-18T14:38:00.006+08:00

最近 0xlab 的開發者持續改善 0xdroid，在 gitorious 的團隊排名維持在前五名的活躍程度，除了稍早提及針對 ARMv7 與底層軟體架構的改進外，0xdroid 也加入了對 Beagleboard / TI OMAP3 硬體更充分的支援。現在與多媒體處理相關的架構圖可參考以下：

紅色的部份是 Android 的 framework 層面 (Media framework, Media server)，而藍色則是實做 framework 所需服務的元件 (如 OpenCore)，剩下綠色的地方自然是 0xlab 關注、與硬體平台相關的元件，這裡簡要列出：

libaudio : 透過 ALSA 處理 Audio In/Out，針對 TI OMAP3 平台做了調整
libcamera : 以 V4L2 (Video For Linux) API 為基礎，提供上層 Android framework 對 camera 所需的硬體支援。透過 TI OMAP3 平台的 video overlays 作 preview 影像處理，並善用 TI DSP 的能力作 JPEG 處理
libopencorehw : 銜接 OpenCore，允許透過 TI OMAP3 平台的 video overlay 作高效能顯示處理
liboverlay : 讓 libcamera 與 libopencorehw 共用的 video overlay 操作模組
TI DSP / OMX : 透過 OpenMAX 標準介面，使用 TI DSP 實做的硬體多媒體 codec 運算
FFmpeg / OMX : 透過 OpenMAX 標準介面，使用針對 ARMv7/NEON 優化的硬體多媒體 codec 運算，這部份採納 FFmpeg 的基礎

目前上述的硬體特有的元件已有初步實做，待驗證與調整 HAL 後，就會陸續整合到 0xdroid 的公開 repository，至於開發相關的議題，可到 0xlab 的郵件討論群組 0xlab-devel 交流，謝謝。

在 Beagleboard 上比較 Dalvik 與 CVM-jit 的效能

2009-08-25T10:54:00.005+08:00

前文「對 String 操作的改進」與「Android Dalvik VM vs. Java VM」談及基於 CVM 引擎的 Java VM 與 Dalvik 的效能差異後，最近 0xlab 內部也因為挑選硬體平台，持續分析 Embedded CaffeineMark 一類量化效能的報告。參考的硬體組態是 OMAP3/ARMv7 500 MHz，粗略的效能評比如下圖：

Dalvik 取自 0xdroid (cupcake + backported from donut)，而 CVM-jit 則源自 phoneME CVM svn r19264，整體分數為：

Dalvik VM : 1034
CVM + jit : 7526

CVM 的組態設定：

cached constant
cached constant inlining
array init bounds check elimination
Hardware fpu = NEON
AAPCS

當然 Just-In-Time compiler 不是萬靈丹，從上述效能評比可發現，CVM 在若干地方做了重要的微調，比方說透過 CNI 實做若干 class library 的關鍵 method，以及善用硬體 floating-point 操作 (注意：本組態未引入 ARMv6 與 ARMv7 的 Thumb2/Thumb-EE 指令集)。儘管 Android 團隊中 Dalvik 開發者 fadden 在郵件討論群組談及：

Four String methods -- charAt, compareTo, equals, and length -- are
"inlined" by the VM, and are not going to get much faster.

There are probably a few others that could benefit from this
treatment, but I'm guessing that most string-centric processing in
Java will likely be dominated by the cost of String allocations. (The
above weren't inlined because of a measured performance need -- the
inlining was an experiment that needed a test subject.)

Dalvik 理論上可施加這些優化技術 (string allocation / native method inlining)，不過目前開放的實做中，尚未引入 (至少在 donut branch 中)。即便在保持 pure interpreter 的架構下，現有 class library 與 GC (garbage collector) 仍可作些調整，以改善 Android 的應用程式執行效能與 (圖形應用導向的) 使用者互動反應表現。

SDL 在 Android SurfaceFlinger 的初步移植

2009-08-13T22:37:00.004+08:00

本日仍在追蹤 0xdroid 的穩定性與效能議題，進行壓力測試時，順便將知名的 SDL 函式庫移植到 Android window system，更具體來說，就是允許在 Android Surface Manager (SurfaceFlinger) 上運作 SDL 應用程式，背景知識請參考 0xlab 圖形處理達人 olv 的簡報 "Introduction to Android Window System" (PDF)。依據 olv 提供的範例 SurfaceFlinger 操作程式，libSDL 可很快地加上 Android video backend，接著透過 libui 的 EventHub 取得來自 Linux input subsystem 的事件。現在初步的移植成果可參考下圖：
上圖展示一個以 SDL 撰寫的 NES 任天堂模擬器，顯示更新於新建立的 Android Surface 上，筆者將該 Android surface 的起始座標位置挪到 (100, 100)，並設定其半透明度值，載入筆者最愛的泡泡龍 (Bubble Bobble) 遊戲 ROM。目前僅算堪用的狀態，未來要考慮到 Android Surface 限制 color space 為 RGB565 (針對 16-bit depth 顯示所做的優化限制)，勢必得在 libSDL 引入若干 color space 轉換的繁瑣運算，可透過 ARM NEON 一類的硬體加速機制去改善效能。

對 String 操作的改進

2009-08-13T04:40:00.004+08:00

之前的文章「Android Dalvik VM vs. Java VM」提及純 interpreter 的 Dalvik VM 與具備 Just-In-Time compiler 的 JBend JVM (基於 CVM 引擎) 的效能比較，以修改過的 Embedded CaffeineMark 作為量化的依據，可發現 String 測試項目差了一個數量級 (491 vs. 5109)，整體的分數是 1:4.18 (1811:433)。稍早 ansoncat 做了初步分析：

「這部分應該是由於在 CVM 中，使用了 CNI 來實作 String class 的重要操作 ... 因為 String 的分數拉高了平均，其它 benchmark 的效能差異會比平均分數的差異大的多」

目前 0xdroid 在不更動 Dalvik VM 實做的前提 (後續再談改進的途徑)，對 bionic libc 的 string 相關函式作調整，移植來自 CodeSourcery/ARM 的 ARMv7 Thumb2 優化實做，就 micro-benchmark 的角度來說，效能改進約有 25% (初步分析，要考慮到不同的環境配置)，但整合到 Android/Dalvik 的表現又是如何呢？筆者的實驗結果如下： (score 大者為佳)

測試環境是 Beagleboard (500MHz) 運作 0xdroid，以 ARMv7 GNU Toolchain 編譯，"armv7" 是 bionic 更動前的數據，而 "armv7-opt" 則是更動後的表現。很顯然發現，String 一項的改進大幅受到壓抑 (score = 1898:2140)，致使兩者最終僅有些微的落差，可見 JNI 帶來 overhead 的著實不小。又，大部分應用程式的效能瓶頸往往在於圖形處理、系統資源的調度、檔案讀寫等 I/O 操作，所以現階段我們的想法是儘量調整 native 的部份，針對 ARM core 與 SoC 的特性作調整，並提出可行的輕量級 native method invocation 實做。

強化 Android 的 shell

2009-08-13T03:33:00.004+08:00

Android 預設的 shell 就是 /system/bin/sh 這個 process，移植自 NetBSD 早期的 sh 程式，原本功能算是完整，但被 Android 開發團隊移去相當多功能，致使在 shell 下的操作苦不堪言，只好透過 adb 作遠端指令的下達，但問題是，移植 Android 的平台在初期往往缺乏有效的連線機制，又需要作些調整與嘗試，實在很不方便。所以筆者就在 0xlab 最近釋出的 0xdroid 專案上，引入來自 Busybox 的 ash 實做，試著保持相近的 footprint 的前提下，提供更多的功能。

因此，我們有以下考量：

必須動態連結到 bionic libc
簡化 Busybox 的實做，修改 libbb 與對應的 applet
保有 bash 相容模式, Line edit, history, readline 等 Busybox 特徵

稍早，0xlab 的成員 walkingice 就做了評估與實驗，讓整個 Busybox 得以動態連結到 bionic libc 並確保功能可運作，這部份有很多 hacking，暫時不談。現在這些更動已初步提交到 system/core repository。在 0xdroid 的 beagle-cupcake branch 下，相關的 ash 設定組態如下：

CONFIG_ASH_BASH_COMPAT
CONFIG_ASH_READ_NCHARS
CONFIG_ASH_READ_TIMEOUT
CONFIG_ASH_ALIAS
CONFIG_ASH_GETOPTS
CONFIG_ASH_BUILTIN_ECHO
CONFIG_ASH_OPTIMIZE_FOR_SIZE
CONFIG_ASH_EXPAND_PRMT

佔用的磁碟空間：

[build_host]$ ls -lh system/bin/{ash,sh}
87K 2009-08-13 02:24 system/bin/ash
98K 2009-08-13 01:15 system/bin/sh

佔用的記憶體空間：

[beagleboard] # ps
USER     PID   PPID  VSIZE RSS   WCHAN    PC         NAME
root     1     0     300   192   c00b2394 0000ca6c S /init
root     777   1     736   324   c0057648 afe0c3fc S /system/bin/sh
root     835   777   744   356   c0057648 afe0c3fc S /system/bin/ash

可以發現，新引入的 /system/bin/ash 佔用的磁碟與記憶體空間相似，但功能完整度卻大不相同，後者允許我們回顧歷史指令並編輯，以及在 Embedded Linux 熟悉的操作環境。目前 ash 的移植還有很多調整改進的空間，不過算是堪用了，可在 init.rc 檔案中，將預設的 shell 指定為 /system/bin/ash。

提供給 Beagleboard 的 Image Installer

2009-08-08T21:45:00.007+08:00

這幾周，0xlab 的開發者都在準備新的 Android distribution，標的平台是 Beagleboard，可望在 COSCUP 到來前釋出，過程中順便寫了一個簡單易用的 Image Installer，可從 SD card 開機並將可運作的 Android system image 植入 Beagleboard 之上的 NAND flash，而不必依據繁瑣的流程，才能體驗我們的新創作。目前已有初步成果，可參見下圖：
已實做的特徵有：

僅需要放置單一檔案 (uImage.bin) 到 VFAT 格式的 SD card 中，在 Beagleboard 插入 SD 開機進入 Image Installer，即有簡單俐落的 UI
整個 Image Installer (kernel + busybox + file system + MTD tools + UI) 佔用不到 2Mb 的空間
預設讀取 SD card 裡頭的 android_beagle.ubi 與 0xkernel-beagle.bin 兩個檔案，自動寫入 NAND flash，並設定必要的 u-boot 環境參數。放置 image 檔案的動作可在多數的作業系統平台下進行，舉凡 MS-Windows, GNU/Linux, Mac OS X 等等，只要支援 VFAT 與 SD/MMC 讀寫即可

貌似單純的 Image Installer 開發，卻折騰了好幾天，歸納有若干因素：

準備在 Beagleboard/OMAP3 環境下可最小可啟動的 Linux image，需要考慮到 device driver 間的相依性，比方說若將 USB subsystem 完全移除的話，很可能無法正常開機。又，OMAP3 內建的 MFD (Multi-Function Device) 要注意到驅動順序的議題，不然功能無法正確運作
要留意 TI OMAP3 / Beagleboard 啟動順序，即使 boot from SD，但 u-boot 與其 u-boot bootenv 很可能仍讀取自 NAND flash，這導致後續啟動的 Linux kernel 採用了預設值，致使 Image Installer 無法在預期的環境參數下啟動
ARM/Linux 啟動過程中，會試圖自一段特別的記憶體空間讀取 command line parameters，這空間稱為 ATAGS，係由 boot loader (以 Beagleboard 來說就是由 X-Loader 帶起的 u-boot) 填寫的記憶體內容，也就是所謂的 u-boot bootenv。但對 Image Installer 來說，雖然 u-boot 給予頗大的彈性，但也使得執行環境充滿不確定性

關於 ARM/Linux 的 ATAGS 實做程式碼可參考 arch/arm/boot/compressed/head.S 與 arch/arm/kernel/setup.c 兩個檔案，筆者做了簡單的 hack 以迴避：

--- android-omap.orig/arch/arm/kernel/setup.c 2009-08-08 18:40:30.000000000 +0800
+++ android-omap/arch/arm/kernel/setup.c 2009-08-08 18:43:09.000000000 +0800
@@ -613,7 +613,6 @@

static int __init parse_tag_cmdline(const struct tag *tag)
{
- strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
return 0;
}

由此可見，原本的動作是將 u-boot 對 ATAGS 寫入的資料寫入預設的 command line。至於安裝 Linux kernel image 與 root file system image 到 NAND flash 後，還得作 (NAND 裡頭的) u-boot bootenv 的編輯動作，這部份的工作原理可參考 Openmoko 開發的 Devirginator。喔，忘了說，這些惱人的限制，會在轉換到 Qi boot-loader 後迎刃而解 :)

0xlab 在 COSCUP 2009 的議程分享

2009-07-28T20:07:00.008+08:00

一年一度的「COSCUP / 開源人年會」即將於八月 15 與 16 兩日舉辦，今年的規模與議程深廣度再創新紀錄，依據公佈的議程大綱，今年大會有四個主題：

Android 和嵌入式系統
雲端運算和 Web 技術
開發者工具
使用者桌面

而 0xlab 除了很榮幸能成為 COSCUP 贊助單位之外，也有四位開發者獲邀分享若干技術議程，以下摘錄 COSCUP 的演講摘要：

講題：Android Wave Is Not Google Wave

講者：Chia-I Wu "olv" (0xlab): 摘要：; There is 3D acceleration on our laptops/netbooks. There is no reason that we cannot accelerate Android when it runs on the same devices. This talk is about 3D acceleration on Android. However, it will focus more on Mesa/DRI and focus less on Android, as the former is more open to our definitions.

講題： How Android Differs from GNU/Linux? And How can we FIX it?

講者： walkingice (0xlab)

摘要：

Android is indeed an open platform and large-scale open source project, which is amazing, but it excludes some well-known free and open source software such as glibc. This talk is about to share the experience about migrating from traditional GNU/Linux to Android. Also, 0xlab introduces some non-trivial modifications in order to leverage existing native Linux software into Android.

講題： Happy Build with OpenEmbedded

講者： tick (0xlab)
摘要：: Openembedded is a flexible and powerful autobuild system. It helps us porting different distributions to different hardwares without too much pain. I'd like to introduce the OpenEmbedded system via creating a tiny distribution and running it on a real embedded system. I will use beagleboard to demonstrate the image. If you have beagleboard, you can take that and play at the same time.

講題：Linux Virtualization Goes Mobile

講者：Jim Huang "jserv" (0xlab)
摘要：: Although the concept of virtualization has existed since the 1960s, the applications become mature and diverse recently. the term "hypervisor" is referred to the original goal: providing a virtualization layer that strictly isolates virtual machines from each other for security and reliability purposes, that meets the requirement of rich mobile devices nowadays. the talk covers running operating systems in isolated run-time environments on a single hardware platform, and what we can benefit from it: flexible system configurations, legal/contractual liability, secure designs, etc.

涵蓋 Android 3D、Android / Embedded Linux 開發，與 Linux virtualization 等等，屆時我們也會發布最近幾個月的成果，期待您的蒞臨指教，謝謝！

Android/Beagle 效能改善簡記

2009-07-13T11:13:00.007+08:00

以圖表展現前文「在 Android/OMAP 展現硬體加速的 OpenGL|ES 與影片播放」與「針對 ARMv7 優化的 Android」所提到的效能改善，可參見以下：

分析若干繪圖操作：

302700 bytes memcpy
512x512 unmodified texture, 512x512 blit
512x512 unmodified texture, 512x512 blit (x2)
512x512 modified texture, 512x512 blit

baseline 是原本 Android on Beagle 的移植，而 hardware-opt 則是運用 ARM NEON 指令集與硬體 OpenGL|ES 加速，基準 baseline 302700 bytes memcpy 時間為 1373 us，整體時間越短越佳。

在 Android/OMAP 展現硬體加速的 OpenGL|ES 與影片播放

2009-07-08T15:05:00.006+08:00

BeagleBoard 是 0xlab 內部用來驗證 ARM 硬體的參考平台，這兩個月內，我們整合了若干無線通訊大廠的 WLAN/Bluetooth 晶片組，而 TI OMAP 353x SoC 的表現著實令人驚豔。初步對 ARMv7 做了優化後，我們進一步運用 OMAP DSP 與 Display Subsystem 的特性，下圖即是在 Android 上硬體加速的 OpenGL|ES 與影片播放，
透過 DVI-HDMI 到顯示器，呈現 1024x768 的解析度，圖上方可見 Android 的狀態資訊列，而最上層就是 video overlay，而下方是 OpenGL|ES 的繪圖區，被遮蔽的最底層則為 Android surface。TI OMAP 3 整體示意圖可參考下圖：
硬體支援三個 stacked overlays，其中 Video 2 和 Video 1 overlay 提供 RGB 及 YCbCr/YUV 的 color space，搭配 TI DSP 與 ARM NEON 加速指令集，可帶來相當順暢且華麗的展現。以下是稍早所作的 OpenGL|ES 與 HW video overlay 人機介面展示影片：

beagle-gfx.avi

OpenGL|ES 由 PowerVR/Imagination Technologies 提供，搭配 OMAP2/3 嶄新的 DSS2 顯示架構，需要對 Linux kernel driver 作些調整，可參考筆者提供的套件與修改部份。當然這一切僅是基礎建設，銜接於 Android 及 ARM SoC 所需要的功夫仍相當多，期望不久的將來，我們的圖形處理達人會提出更多新玩意 :)

針對 ARMv7 優化的 Android

2009-07-01T10:41:00.003+08:00

前文「升級 Android 內建 GNU Toolchain 到 gcc 4.4」提及使用更新的編譯器平台，現在追蹤的是 gcc 4.4/4.5，不排除引入 LLVM，這些準備都是為了允許施加更多優化、展現平台的特性，而在 Android 的 build system 也需要作一些更動，至少涵蓋以下：

針對硬體平台的編譯參數
Dalvik machine-dependent interpreter implementation (mterp)
針對硬體特徵優化的關鍵軟體，如 BlueZ 中處理音訊 Bluetooth low-complexity, subband codec (SBC) 的實做

當然優化是無止盡的，我們只求在合理的工程資源，能解決夠多的技術議題即可。筆者的參考修改可見 android-armv7.patch，其中做了以下調整：

設定 gcc 編譯參數為 "-march=armv7-a -mtune=cortex-a8 -mfpu=neon"，適用於 BeagleBoard (TI OMAP 353x) 平台
額外啟動 gcc 的 Auto-vectorization 優化策略
以 ARM NEON 指令集優化 SBC 的執行效能

前期我們還是著重於泛 ARMv7 平台的優化技術，再來就是針對 SoC 平台的 DSP 與特性去作進一步處理。為了證明以上的修改發揮作用，可檢視 libjpeg 是否自動的做了 vectorized，也就是看看有無 ARM NEON 指令集的生成：

# ./prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-objdump -d \
out/target/product/generic/obj/STATIC_LIBRARIES/libjpeg_intermediates/jdmerge.o | egrep "v[add|mov]"
1d4:   f2c09012        vmov.i32        d25, #2 ; 0x00000002
1d8:   f3c01210        vmov.i32        d17, #32768     ; 0x00008000
200:   f26048a9        vadd.i32        d20, d16, d25
204:   f22069b8        vmul.i32        d6, d16, d24
208:   f26438a9        vadd.i32        d19, d20, d25
20c:   f2266821        vadd.i32        d6, d6, d17

至於 ARM NEON 指令集，這裡不贅述，可參考 ARM 官方文獻 NEON Technology。

簡報： Power Management from Linux Kernel to Android

2009-06-22T04:36:00.004+08:00

上週五 (June 19)，Matt 跟我分享 Android 之上 Power Management 的背景概念、實做，以及可改進的方向，而論及 Android 的系統架構設計時，不免得先談談 Linux PM，期待這份簡報對進行系統移植與客製化的同好有助益：

Power Management from Linux Kernel to Android

View more from Jim Huang.

授權方式採用 Creative Commons S-A 3.0，不完善與謬誤處，請多指教，謝謝！

升級 Android 內建 GNU Toolchain 到 gcc 4.4

2009-06-18T18:04:00.005+08:00

GNU GCC 4.4 已於 Apr 21, 2009 正式釋出，伴隨眾多改進、修正，與硬體平台改善，詳情可見"GCC 4.4 Release Series Changes, New Features, and Fixes"，不過 Android repository 裡頭的 prebuilt GNU Toolchain 仍停留在 gcc-4.2.1 (Release date: Jul 18, 2007)，總是有些遺憾，且讓我們動手改變。

EMBINUX™ Lab 提供一份 prebuilt GNU Toolchain for Android，參考其 git 的更動，可建立一套基於 gcc-4.4 與 binutils-2.19.1 的 toolchain，筆者準備打包好的套件： toolchain-arm-eabi-4_4_0.tar.bz2。另外，因為 gcc-4.4 對於 C/C++ 語意更加嚴格，像是應用程式對 va_list 的使用就需要調整，筆者將這些小修改整理為 migrate-gcc44.patch。以下是簡要的升級方式：

# cd mydroid
# cd prebuilt/linux-x86/toolchain
# tar jxvf toolchain-arm-eabi-4_4_0.tar.bz2
# cd ../../..
# patch -p1 < migrate-gcc44.patch

重新編譯與建構 Android 即可。需要更動的部份，列出作參考：

# diffstat migrate-gcc44.patch
core/combo/linux-arm.mk             |    2 +-
dist/sqlite3.h                      |    2 +-
envsetup.sh                         |    2 +-
pdk/ndk/samples/sample/Makefile.lib |    2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

改善 Android 中 memcpy 效能

2009-06-18T14:34:00.005+08:00

在 Android 內部實做中，有許多細節涉及大量的 memcpy() 操作，比方說將一塊使用者定義的繪圖區域傳遞給 SurfaceFlinger 管理的過程，由於得先轉換成 texture，再對應為 Surface，之間至少需要三次 memcpy。由於 BeagleBoard (TI OMAP3) 透過 HDMI 輸出 (max: 1280x1024)，居中涉及大量的繪圖操作，意味著 memcpy() 頻繁被呼叫著，對整體效能有顯著的影響，於是筆者花了一些時間分析。

Android 的 libc 實做 -- bionic -- 已包含針對 ARMv5 優化過的 memcpy()，詳情可參考 libc/arch-arm/bionic/memcpy.S，而 GNU Toolchain (glibc) 中，其實也有一份針對 ARMv5 優化過的 memcpy() 實做，也利用到 ARMv5 的 data prefetch 指令。既然我們採用 ARMv7 架構的 BeagleBoard，何不使用其引入的 NEON SIMD 加速指令集呢？以下就是在 BeagleBoard 所作的 benchmark：

數據如下：

glibc-armv5 : 181884276 B/s
bionic-armv5 : 225881095 B/s
armv7 : 269294302 B/s

參考的 ARM NEON 優化 memcpy() 實做如下： (arm-neon-memcpy.S from Måns Rullgård )

        .fpu neon                                                                          
        .text
 

        .global memcpy_neon
 

        .func   memcpy_neon
memcpy_neon:
        push            {r4-r11}
        mov             r3, r0
1:      subs            r2, r2, #128
        pld             [r1, #64]
        pld             [r1, #256]
        pld             [r1, #320]
        ldm             r1!, {r4-r11}
        vld1.64         {d0-d3},   [r1,:128]!
        vld1.64         {d4-d7},   [r1,:128]!
        vld1.64         {d16-d19}, [r1,:128]!
        stm             r3!, {r4-r11}
        vst1.64         {d0-d3},   [r3,:128]!
        vst1.64         {d4-d7},   [r3,:128]!
        vst1.64         {d16-d19}, [r3,:128]!
        bgt             1b
        pop             {r4-r11}
        bx              lr
        .endfunc

至於 SurfaceFlinger 的操作仍有優化的空間，稍後再討論。

Android Dalvik VM vs. Java VM

2009-05-10T22:04:00.008+08:00

Google Android 開發團隊為了技術自主、迴避 Java 商標爭議等考量，建構了嶄新的 Dalvik Virtual Machine，骨子裡頭仍支援 Java 程式語言，但 Dalvik VM 設計稍異於典型 JVM，網路上已有豐富的比較，本文就不贅述，筆者想探討的，則是日本 eFlow 公司最近提出的 'Android™'s Dalvik VM on "Mobile Java"'，目標就是讓原本的 Java 執行平台 (主要是 Java ME)，得以運作針對 Android Dalvik VM 設計的應用程式。日前該專案已開放原始程式碼，主體依據 GNU GPLv2，以下是相關資訊：

新聞稿： eflow Releases First Implementation of Android™'s Dalvik VM on "Mobile Java" as Open Source
專案開發主頁： android-dalvik-vm-on-java : Pure Java implementaion of Android's Dalvik virtual machine

目前的進度來說 (svn r22)，支援以下功能：

Dalvik Execution file format (.dex)
Complete Dalvik instruction set
J2ME CLDC API
Multi-thread (include synchronized block, wait and notify)

至於是否能達到 eFlow 公司 CEO -- Koichi Makabe 所預期的效益：

"We believe this implementation will particularly benefit manufacturers currently developing Android-powered devices, with a number of which we are cooperating to port the Dalvik VM to their specific hardware and software architectures. By making this implementation available today as open source, and by accelerating our porting and development efforts, we have the firm intention to make a significant contribution to the broader Android community."

這裡無從得知，不過，該專案四月底時，一併將 dalvikvm_benchmark 釋出，伴隨內部的效能分析數據，非常有意思。從裡頭的資料來看，標的硬體平台有兩個：

Google Dev Phone 1 (528MHz - Qualcomm MSM7201A)
P905i (500MHz - Panasonic UniPhier 4M + JBlend)

前者無疑就是用來比較的基準，硬體是 Qualcomm 平台，軟體組態當然是跑 Dalvik VM，運作時脈為 528 MHz。後者就相當有意思，P905i 是日本 NTT 電信的第三代手機平台，以豐富的多媒體與超長待機時間著稱，硬體採用 Panasonic UniPhier 家族，運作時脈達 500MHz，軟體方面，則內建 JBlend 這個商業 Java ME CLDC/MIDP 執行環境。儘管軟硬體組態均大相逕庭，不過研究 android-dalvik-vm-on-java 提供的內部的效能分析數據，多少有參考的價值。筆者整理為以下圖表：
綠色部份 (靠右側者) 為 Google Dev Phone 1，紅色 (靠左側者) 則是 P905i，分數越高者越佳。在同一份 benchmark 測試方式來看，兩者有極為顯著的落差，整體表現數據為：

Google Dev Phone 1 (528MHz - Qualcomm MSM7201A) :: 433
P905i (500MHz - Panasonic UniPhier 4M + JBlend) :: 1811

數字背後的意義則是，Dalvik VM 進一步優化的空間仍相當大，至於如何在 ARM11 平台，透過若干進階的技巧 (JIT, register allocation, ...)，發揮 Dalvik 這個 register-based VM 的效能，是不少研究人員關心的議題。

Android 上的原生 OpenGL/ES

2009-05-10T17:26:00.005+08:00

olv 日前在「一千零一夜之 Android Binder」一文提及：

surface manager 可以準備一塊 surface，把 surface 的 fd (一塊 ashmem 記憶體) 傳給一個 app，讓 app 可以在上面作畫。有了這層理解，我們對 android 可以有更自由的發揮，例如，可以不改一行 cairo 的程式碼，就利用 cairo 與 c++ 寫出一個會動的時鐘

而 Surface manager 顧名思義，就是管理邏輯上眾多的 surface，其底層對應於 OpenGL|ES 的實做。透過 surface 的處理，我們可讓像 fdclock 這樣原生 (native) 的 C 語言程式，透過同樣在 GNU/Linux 上原生的 Cairo 函式庫，無痛的顯示處理。這實在很吸引人，畢竟若能在 Android 平台充分重用 GNU/Linux 既有的軟體功能，會是多麼有趣的事。且讓我們思考是否能在 Android 上撰寫 C 語言的 OpenGL/ES 應用程式。

Android 已提供初步的 OpenGL/ES 封裝，實做則是透過 agl (Android OpenGL) 底層的 PixelFlinger 與 GPU。關於 Java 部份的 OpenGL APIs 操作，可參閱原始程式碼 frameworks/base/opengl/java/android/opengl/GLSurfaceView.java ，不過現在只看 C 程式的部份。動態連結函式庫必須連結到以下三者：

libEGL : OpenGL/ES APIs
libGLESv1_CM : Reference implementation
libui : Android UI framework (native)

準備好我們的程式碼之後，其建構過程如下：

$ . build/envsetup.sh
$ cd angeles-test/
$ mm
make: Entering directory `/home/jserv/Myth/mydroid'
target arm C: angeles-test <= /home/jserv/Myth/mydroid/angeles-test/demo.c
...

參考的螢幕顯示如下：

不過，在模擬器顯示的狀況會比實體遜色頗多，可見到相當嚴重的重繪動作，但基本上是可用的。

整合 GStreamer 到 Android

2009-04-29T17:25:00.004+08:00

Thinker 在「GStreamer 和 OpenMAX IL 的比較」一文提到：

GStreamer 是知名的 open source multimedia framework，相當於 Windows 下的 DirectShow 。而 OpenMAX IL 則是多家知名廠商參與制定的標準，其功能和 GStreamer 也有些類似。目前已有一些 multimedia framework 開始支援 OpenMAX IL，以使用 OpenMAX IL 相容的 component 。 OpenMAX IL 是一個 codec 的標準介面，實作該介面的 codec 可以被任何 OpenMAX IL client 所使用。目前 Android 使用的 opencore 所支援的 codec 實在很少，如果可以透過實作 OpenMAX IL 的 wrapper ，讓 FFmpeg 之類的 multimedia framework 所提供的 codec 能當成 OpenMAX IL 的 component 載入，那麼 opencore 瞬間就多出許多 codec 可以使用。

這個想法已經被 Prajnashi S 初步實現，雖然層面不同，但還是有很大的參考價值。下午將之前的程式碼升級到 Android cupcake (1.5 Release)，做了一些微調，在 target 上運作起來，先看看有哪些 plugin：

# gst-inspect-0.10
audiotestsrc: audiotestsrc: Audio test source
videotestsrc: videotestsrc: Video test source
omx: omx_dummy: OpenMAX IL dummy element
omx: omx_mpeg4dec: OpenMAX IL MPEG-4 video decoder
omx: omx_h263dec: OpenMAX IL H.263 video decoder
omx: omx_h264dec: OpenMAX IL H.264 video decoder
omx: omx_mp3dec: OpenMAX IL MP3 audio decoder
omx: omx_amrnbdec: OpenMAX IL AMR-NB audio decoder
omx: omx_amrwbdec: OpenMAX IL AMR-WB audio decoder
omx: omx_aacdec: OpenMAX IL AAC audio decoder
audioflingersink: audioflingersink: Audio Sink (AudioFlinger)
videoflip: videoflip: Video flipper
quicktime: qtdemux: QuickTime demuxer
coreelements: capsfilter: CapsFilter
coreelements: fakesrc: Fake Source
coreelements: fakesink: Fake Sink
coreelements: fdsrc: Filedescriptor Source
coreelements: fdsink: Filedescriptor Sink
coreelements: filesrc: File Source
coreelements: identity: Identity
coreelements: queue: Queue
coreelements: filesink: File Sink
coreelements: tee: Tee pipe fitting
coreelements: typefind: TypeFind
coreelements: multiqueue: MultiQueue
ffmpegcolorspace: ffmpegcolorspace: FFMPEG Colorspace converter
surfaceflingersink: surfaceflingersink: android's surface flinger sink
coreindexers: memindex: A index that stores entries in memory
videoscale: videoscale: Video scaler
staticelements: bin: Generic bin
staticelements: pipeline: Pipeline object

Total count: 12 plugins, 31 features

這表示，透過 GStreamer，Android 瞬間多了許多高品質的 plugin 與外加功能，也就能以 FFmpeg 或既有的 gst-plugins 來處理各式的多媒體資料。現在 video 的處理，可透過 Surface Flinger sink 來操作，測試方式：

# gst-launch-0.10 videotestsrc ! surfaceflingersink

以下是對應的螢幕輸出：

稍後，我們再來探討整合的議題。

0xlab 開幕！

2009-04-27T07:55:00.005+08:00

愛因斯坦說過：「對一個人來說，所斯望的不是別的，而僅僅是他能全力以赴和獻身於一種美好事業」，今天，台灣有一小群工程背景的朋友，憑恃著如此的信念，打算為台灣的資訊產業，作些事情，所以成立 0xlab。愛因斯坦又說：「信念最好能由經驗和明晰的思想來支持」，我們的成員則根基於過去參與自由軟體 / 開放原始碼專案的協同開發經驗，以及對追求理想和真善美的堅持，透過 0xlab 這個嶄新的嘗試，將原本散落各地的開發資源，集中起來一同打拼，目前為止的成員有 8 位，依序是 Erin, Jeremy, John, Jserv, Julian, Olv, Thinker, Tick。每個人各有其專擅的領域，我們希望以團隊的優勢提供完整戰力，為軟體界做出些許貢獻，以技術的方式來愛台灣！

個人一直認為，工程師若要愛台灣，最好的方式，就是強化本職學能，無論是軟硬體技術，使其累積、成長，進而提升到更高的層次。今天，2009 年 4 月 27 號，是 0xlab 的誕生日，專注於推動硬體廠商與開放軟體社群的聯繫，成為軟硬體整合方案提供者，讓更多基於開放軟體的裝置走入日常生活。

當 Compiler 遇上 Mobile

2009-04-26T03:48:00.009+08:00

過去我們很難聯想進階的編譯器 (compiler) 技術到底與移動平台何涉，但隨著基礎建設的突破，我們就該有不同的思維。

從1960 年代發展至今，編譯器技術已是電腦科學最成熟的基礎之一，不斷地成長與蛻變，而透過 open source，GNU GCC 與 LLVM (Low Level Virtual Machine) 計畫獲得空前的成功，累積了驚人的編譯器技術。儘管 parser 仍是 compiler 的關鍵技術，但今日，我們會著重於打通任督二脈的技術展現，過去耳熟能詳卻貌似獨立的項目，比方說 virtual machine, binary translator, JIT compiler, HotSpot JVM, 等等，如今好似整合了金庸書中的武功精髓、淬湅出武術菁華，形成一套獨到的武功系統，透過 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 (JVM) 轉換為 register-based VM (Dalvik VM)，而無論這裡頭有多少玄機，就 Android 的程式設計來說，Java 是唯一可用的程式語言，要不得搭配 Android framework / class library，不然就是透過 JNI 去呼叫 C/C++ 撰寫的動態函式庫。作為一個「慣 C 魔人」，筆者反覆思考，是否能將以 C 語言搭配 SDL 函式庫撰寫的 Doom，透過編譯器轉換為 Android 平台可運作的 Dalvik bytecode 呢？此舉不僅讓 C/C++ 程式跨平台執行，還為移動平台提供了新的附加價值，於是，筆者就開始一系列的 hacking，現在有初步的成果，日前已發表於 OSDC.tw 2009 的「窮得只剩下 Compiler」議程中，請參考以下螢幕快照：
這可不是紙老虎或單純貼圖，電動玩具當然是設計來玩的：
詳細的資訊可參閱發表於 OSDC.tw 的議程簡報：

View more presentations from Jim Huang.

筆者同事 luse 嘗言：「現在是一個充滿編譯器的世界，身為一個工程師，每次聽到編譯器技術，覺得深不可測 (或是腦海忽然浮現起自動機的回憶) 而輕言放棄，實著可惜」。許多人印象中艱澀的 (dynamic) Compiler 技術，其實廣泛應用於我們電腦資訊產業中，以「到處都是 Compiler」來闡述現實，一點也不為過。如此的案例多如牛毛，比方說，現在 Web 2.0 與 Mobile web browser 正火熱，為了要能改善 Web 應用程式的效能，Google 與 Apple 兩家公司的工程團隊，各自推出 V8 與 SquirrelFish Extreme 等 Just-In-Time compiler for JavaScript，而 Mozilla Foundation 更是將高速的 JavaScript 引擎當作 Mozilla 2 的重要賣點，知名的自由軟體開發者 Jim Blandy 甚至離開專業 GNU Toolchain 開發公司 CodeSourcery，加入 Mozilla Corporation，就為了致力開發 ActionMonkey (整合 Mozilla 原有 SpiderMonkey 與 Adobe 貢獻的 Tamarin)。自此，這個在瀏覽器平台的戰役，從桌面系統延續到手機，又將從手機移轉到各種不同的資訊裝置上。

而，撇開 JavaScript 執行引擎不論，實際上，連 Firefox/Mozilla 底層的向量繪圖函式庫 Cairo，也透過 JIT compiler 技術，去提昇整體繪圖的效能與使用者體驗。日前，Dan Amelang 揭露他的開發成果，可參見郵件論壇的訊息 "JIT for pixman"。pixman 是提供給 X Window System 與 Cairo 使用的 pixel-manipulation 函式庫，顧名思義，就是處理 image compositing 與 trapezoid rasterization 等操作，而在 Dan Amelang 的論文 "Jitblt: Efficient Run-time Code Generation for Digital Compositing" 給予令人振奮的突破，無疑是個極佳的突破點，我們也可預見 (dynamic) compiler 技術在更多資訊領域的廣泛應用。

當編譯器技術走入新的層次時，就需要更強大且多元的 Toolkit，LLVM 專案的出現，在整個電腦技術典範移轉 (paradigm shift) 的衝擊下，以嶄新編譯器架構、自由軟體協同開發模式，給予我們突破限制的可能性，顯然，我們可確定 LLVM 應用於 Android 應用程式開發，僅是一個牛刀小試，好戲才要登場呢。