September 13, 2008

COINS 編譯器架構

[COINS] 編譯器架構是由日本文教省資助的研究計畫 (2000-2004)，目標是建構可用於研究、教育，與商業應用的編譯器系統架構，支援兩階段的 IR (intermediate representation)：
  • HIR: High-level Intermediate Representation
  • LIR: Low-level Intermediate Representation
整個系統可示意如下圖：

此編譯系統由以下元件組成：
  • parser : 轉換原始程式碼為 HIR
  • control flow / data flow analyzers
  • optimizers
  • parallelizers
  • HIR 轉 LIR
  • IR Handler (HIR manager, LIR manager, symbol manager)
  • TMD (target machine descriptions)
  • 依據 TMD 的 backend
  • 編譯過程的視覺化呈現
COINS 內部完全以 Java 語言實做，軟體授權為 ASL (Apache Software License) 2.0。架構圖如下：

以高度模組化著稱的 COINS，允許加入不同硬體平台的支援，並實做 SSA (Static Single Assignment) 與 SIMD 優化的編譯技術，同時支援 OpenMP 平行運算處理，也能透過 CoVis 這個視覺化工具，來分析原始程式碼、HIR/LIR，與 CFG (control flow graph) 的關聯，運作的快照如下：

截至目前為止，最新的釋出版本為 1.4.4.1 (Jun 23, 2008)，下載並解開後，可嘗試內建的範例程式： (需安裝 Java Runtime Environment)
jserv@venux:/tmp/coins-1.4.4.1-en$ java -cp classes coins.driver.Driver \
     -I./lang/c/include/samples \
     -coins:target=x86 -coins:assembler=as \
     ./test/c/TestBuna/hello.c
jserv@venux:/tmp/coins-1.4.4.1-en$ ./a.out 
Hello World
當追蹤編譯過程時，只要再追加以下編譯選項：
     -coins:trace=HIR.1/LIR.1/Sym.1
COINS 專案由日本諸多研究人員開發，並有豐富的 [著作發表]，來自 Hosei University, The University of Electro-Communications, Tokyo Institute of Technology, Mitsubishi Research Institute, Inc. 等單位，計畫主持人為 Ikuo Nakata 教授。
由 jserv 發表於 07:05 PM | 迴響 (5)

September 10, 2008

《The Art of Debugging》第一章開放下載


由 LinuxDevices.com 的新聞 [Free book chapter explains debugging]，得知 Norman Matloff 與 Peter Jay Salzman 的大作《The Art of Debugging》已開放下載第一章的內容，正巧就是專門探討開放源碼的偵錯除錯工具，標題為〈Some Preliminaries For Beginners And Pros〉。

除了前述的新聞內容提供的下載位址，筆者則做了一份複製 [debugging_samplechapter.pdf] (17 Mb)。這章提到三個優秀的工具：
  • GDB : 還需要多談嗎？史上最強大的跨平台 Debugger
  • DDD (Data Display Debugger)
  • Eclipse CDT (透過 GDB-MI)
撇開工具能夠協助我們達到多大的功效，不妨先看看作者在 1.3.2 段落的精湛介紹：
    Of What Value Is a Debugging Tool for the Principle of Confirmation?

    The classic debugging technique is to simply add trace code to the program to print out values of variables as the program executes, using printf() or cout statements, for example. You might ask, “Isn’t this enough? Why use a debugging tool like GDB, DDD, or Eclipse?”

    First of all, this approach requires a constant cycle of strategically adding trace code, recompiling the program, running the program and analyzing the output of the trace code, removing the trace code after the bug is fixed, and repeating these steps for each new bug that is discovered. This is highly time consuming and fatigue making. Most importantly, these actions distract you from the real task and reduce your ability to focus on the reasoning process necessary to find the bug.

    In contrast, with graphical debugging tools like DDD and Eclipse, all you have to do in order to examine the value of a variable is move the mouse pointer over an instance of that variable in the code display, and you are shown its current value. Why make yourself even wearier than necessary, for longer than necessary, during an all-night debugging session by doing this using printf() statements? Do yourself a favor and reduce the amount of time you have to spend and the tedium you need to endure by using a debugging tool.

    You also get a lot more from a debugging tool than the ability to look at variables. In many situations, a debugger can tell you the approximate location of a bug. Suppose, for example, that your program bombs or crashes with a segmentation fault, that is, a memory access error. As you will see in our sample debugging session later in this chapter, GDB/DDD/Eclipse can immediately tell you the location of the seg fault, which is typically at or near the location of the bug.

    Similarly, a debugger lets you set watchpoints that can tell you at what point during a run of the program the value of a certain variable reaches a suspect value or range. This information can be difficult to deduce by looking at the output of calls to printf().
雖然是老生常談了，但「多想兩分鐘，您可以更開心地編寫、開發程式」，稍後的段落中，即可窺見善用除錯工具，對整體開發的效益。而，現在視覺化呈現也相當優秀，何不更深入採用呢？
由 jserv 發表於 08:41 PM | 迴響 (4)

「我是軟體 -- 那些處理器教我的事」簡報上線


稍早於 [COSCUP 2008] 進行以 [我是軟體 -- 那些處理器教我的事 ] 為題的演講，簡報已上線，請見 [trap-in-processors.pdf]，搭配的範例程式碼打包為 [trap-in-processors-samples.tar.gz]。

過去我們總有個假設，就是單純的 C 語言程式碼，經過編譯後，能夠輕易在多種軟硬體平台上運作，但實際上，有太多值得我們思索的細節。近年來，透過自由軟體，以提昇產品開發時程與系統完整度，已是大勢所趨，但涉及跨平台開發，其潛藏的問題又難保不是未來系統中的未爆彈。基於這個思維，此議程以 ARM/Linux 為例，由四個簡短的 C 語言程式碼 (約十行內)，點出跨平台整合開發時，PC/x86 與 ARM 環境中迥然不同的落差，期望有助於自由軟體的廣泛應用與深入琢磨。

前述的四個範例為：
  • alignment.c - 凸顯 x86 與 ARM (或其他 RISC) 處理 data alignment 的行為落差
  • signchar.c - 指出 GNU Toolchain 即使在幾十種硬體平台有良好的支援，但具體實做卻有出入，本範例點出 C 語言中，與平台相依的實做
  • abi.c - 指出 C 語言並未涵蓋的 ABI (Application Binary Interface)，舉凡 struct/data 的長度、function calling convention 等議題，並由精簡的例子，加深聽者對這方面的警覺
  • call.c - 對於 C 語言 (及為了實做考量的擴充) 所內建的函式集來說，在實做上的呈現，依據個別硬體平台，往往有出入
採用的硬體為：
  • x86: Lenovo x60 筆記型電腦 / Pentium-M 1.8GHz / Ubuntu 8.04
  • ARM: Openmoko GTA02 (S3C244x ARM SoC) / Linux 2.6.24, glibc 2.7
當然，實際上要考量的議題太多了，像是 packed data, soft/hard floating-point, endian, data exception, cache/TLB, ... 等等，所謂「處處留心皆學問」，小弟只是試著在短短的二十分鐘內，透過簡單不過的範例，去凸顯如此的對比。在簡報中不斷出現下圖：

議程中，透過圖中女子的自白，道出的一番話：「我好天真，現在才看清，其實這一切並非只是 cross compilation 這麼單純」 ，又該是多少從業人員與開發者的感嘆呢？

ARM/Linux 是如此，其他五花八門的「處理器」，想必教了「軟體」無以言表的經驗，希望本議程能作為一個出發點，得以讓更多開發者切磋琢磨，並提昇對軟體的認知。請多指教，謝謝！
由 jserv 發表於 08:15 AM | 迴響 (6)

運用色彩點綴 UNIX 環境

幾周前參觀科博館，其中一個主題就是苗族華麗豐富的服飾。苗服研究者江碧貞在其著作《苗族服飾圖誌》中，歸納了十個特色與意義，大抵如社會地位象徵、年齡、婚姻關係標記，與傳統藝術美學等等，巧妙地透過色彩的組合，不用文字，卻能在服裝上娓娓道出，著實令人驚艷。

UNIX 的環境不消說，功能頗為強大，隨意工具的組合，都可能造成極有威力的影響，只是，終端機永遠輸出平淡質樸的文字，得多花點注意力，才不會有遺珠之憾。還好，我們有 [color wrapper] 一類的工具，可適度為強大的 UNIX 作些「彩妝」，以筆者的 GNU/Linux 來說，可呈現下圖的效果：

原本冰冷冷的文字介面，彷彿被魔法棒觸碰後，頓時生意盎然，好似文字訊息就在眼前舞動呢。
由 jserv 發表於 01:48 AM | 迴響 (5)