2015年5月10日 星期日

Javascript Worker

最近在寫一些前端的東西,深覺前.端.超.難.(yay)

接觸了HTM5 javascript 的worker ,在這裡筆記一下:

簡單來說,一般javascript的指令,都是存在一個執行緒裡執行,而worker 則可以開另一個執行緒在背景執行,就不會block住前端的UI的script,一般。
使用方法也很簡單,宣告一個worker並傳入一個檔案路徑,這個worker 就會負責執行檔案內的javascript。
要和worker 溝通,一律要經過postmessage跟onmessage 介面,postmessage會代入一個參數,可以用json寫得超級複雜,包括File, Blob, ArrayBuffer都可以傳遞;這時在對方的onmessage就會被呼叫,並包含這個物件的複製版本。
我看到的設計是這樣,在主要文件內 main.js 中,宣告worker
var worker = new Worker(“workerFile”);

在workerFile 內要定義onmessage 函式,並且用參數的command判斷執行哪個對應的函式:
this.onmessage = function(e) {
switch(e.data.command) {
case 'act1':
fun_act1(e.data.payload);
break;
}

這時候main.js就可以利用postmessage 叫worker 作事:
worker.postMessage({
command: 'act1',
payload: blahblahblah
})
worker.onmessage = function(e) {
data = e.data;
}

同樣我們在worker 裡面也可以呼叫postmessage,對方接口就是main.js 裡的onmessage,這樣就能做到雙方互相傳遞資料。
如果不想要以複製的方式傳遞資料,可以改用transferable object 的方式,減少複製成本,另外因為是多執行緒的關係,在worker 裡面,不應該去動到DOM,window, document, parent,這些都不是thread-safe。

至於更多詳細的內容,可見:
http://www.html5rocks.com/en/tutorials/workers/basics/

或者可以看worker 的spec:
https://html.spec.whatwg.org/multipage/workers.html

2015年5月6日 星期三

使用 rust 來寫極簡的嵌入式系統

最近看到一些有趣的東西:
https://github.com/JinShil/rust_arm_cortex-m_semihosted_hello_world
https://github.com/neykov/armboot

用rust 來寫嵌入式系統,感覺相當生猛,正好最近在上傳說中的jserv 大神的嵌入式系統,就想把嵌入式系統作業用到東西,用rust 實作出來,主要參考的內容包括上面的armboot,跟作業的mini-arm-os:
https://github.com/embedded2015/mini-arm-os
這裡不細講mini-arm-os的內容,自行參考當時寫的潦草的筆記:
https://yodaleeembedded2015.hackpad.com/Lab42-Note-YKuTRvCMYYx

本篇相關的原始碼請見:
https://github.com/yodalee/rust-mini-arm-os

跟armboot 類似,我用了libarm/stm32f4xx.rs(變體)跟zero/std_types這兩個lib,不使用rust std的lib:
mod zero {
  pub mod std_types;
  pub mod zero;
}
#[macro_use]
mod libarm {
  #[macro_use] pub mod stm32f1xx;
}

zero比較簡單,定義一些C 裡面用到的型態應該對應到rust 什麼型態,和rust 基本的trait 如Sized, Copy 等等,不寫的話rustc 會抱怨找不到這些trait;就像在rust_hello_world這個實作裡面,也是把這些trait 寫在main裡面,我猜這些內容和Rust 的基本設計有關,目前還不是很清楚。
libarm就比較複雜,這感覺像是作者自己寫的,針對的是stm32f4, arm-cortex m4 的硬體。理論上這裡應該是先研究stm32f4要怎麼初始化,不過我偷懶,先直接把部分的stm32f4 硬體位址修改成stm32f1 的,這樣舊的code 就可以直接搬過來XD。

Stm32f4xx.rs的內容,簡單來說就是大量的直接定義,例如裡面的RCCType,直接對應RCC register的位址,每個位址會是32 bits 的空間,可以和stm32的文件內容一一對應,下面是我針對STM32f1修改後的RCC內容:
http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf
pub struct RCCType {
  pub CR: uint32_t,
  pub CFGR: uint32_t,
  pub CIR: uint32_t,
  pub APB2RSTR: uint32_t,
  pub APB1RSTR: uint32_t,
  pub AHB1ENR: uint32_t,
  pub APB2ENR: uint32_t,
  pub APB1ENR: uint32_t,
  pub BDCR: uint32_t,
  pub CSR: uint32_t,
}

在最後面,它用函式宣告傳回對應的Type struct:
#[inline(always)]
pub fn RCC() -> &'static mut RCCType {
  unsafe {
    &mut *(RCC_BASE!() as *mut RCCType)
  }
}

而RCC_BASE!() 這個Macro,又會照上一篇提到的Macro_rule展開為:AHB1PERIPH_BASE!() + 0x3000u32
一路展開,最後得到一個32 bits integer,再轉型成RCCType 的mutable pointer,我做的修改就是把RCC, USART2, GPIO的位址換成STM32f1的。
在main 裡面就可以使用let rcc = RCC() 的方式,取得RCC的pointer,並用像C一樣的操作手法來操作對應的register位址。
例如要修改APB1ENR,啟動週邊的clock:
let rcc = RCC();
rcc.APB1ENR |= 0x00020000u32;

或是對usart2 的位址取值都沒問題:
let usart2 = USART2();
while(true) {
  while(usart2.SR & 0x0080u16 == 0) {}
  usart2.DR = 'x' as uint16_t;
}

這裡我們只輸出'x',這是因為要把text 印出來,我們需要對str 作iterate,而這個東西是定義在rust 的core lib 裡面,一般安裝後在/usr/lib/rustlib裡面只會有x86_64_unknown_linux_gnu,如果要跑arm要先自己編譯arm的lib,相關的內容可見:
http://spin.atomicobject.com/2015/02/20/rust-language-c-embedded/
這步比較麻煩先跳過,之後研究出來再另文介紹。

另一個要解決的問題則是isr_vector,這裡可以看到一種很謎樣的寫法,用link_section這個attribute,定義區段名為 .isr_vector,並設定為一個array,內含一個extern “c” fn(),如果要需要其他的ISR,則可以在後面寫更多的function,並把1改為需要的數量。
#[link_section=".isr_vector"]
pub static ISRVECTORS: [unsafe extern "C" fn(); 1] = [
  main,
];

linker script裡面,先保留一個LONG 的寬度指向初始化stack pointer,接著放isr_vector的reset handler,再放其他的.text,這樣裝置一上電就會執行main裡的內容。
.text :
{
  LONG(_stackStart); /* Initial stack pointer */
  KEEP(*(.isr_vector)) /* ISR vector entry point to main */
  *(.text)
  *(.text*)
} > FLASH

如果我們把最終執行檔反組譯,會看到其中的位址配置,0x0指向stack start,0x4 reset_handler指向位在0x08 的main。:
Disassembly of section .text:
00000000 <_ZN10ISRVECTORS20h538ad2a8e3805addk6aE-0x4>:
0: 10010000 .word 0x10010000

00000004 <_ZN10ISRVECTORS20h538ad2a8e3805addk6aE>:
4: 00000009 ....

00000008 <main>:

執行結果,會印出滿坑滿谷的 'x',我加一個條件讓它只print 100個: 

在編譯時,要向rustc 指定target,這裡有一大篇文章講相關的內容,之後分另一篇文出來介紹:
https://doc.rust-lang.org/rustc_back/target/
同樣這份rust code 裡面有用到大量的rust attribute,也就是function 前的#[attribute],這也可以另外寫一篇文……
啊感覺挖了自己一堆坑,要趕快填坑了OAO。

結語:

在這篇文我試著解釋如何用rust 撰寫嵌入式系統程式,結論當然是做得到的,但整體比C寫的原始碼複雜得多,也不像C這麼直覺,編輯libarm 也是非常麻煩的工作。
由於嵌入式系統的code 通常都不會複雜到哪裡去(唔…大概吧),發揮不出Rust的優勢,我認為比起來還是寫C會有效率得多。

2015年4月30日 星期四

Rust Macro 簡介

今天要講的是Rust Macro:
https://doc.rust-lang.org/book/macros.html
Rust 的Macro 是個有趣的功能,能讓你對function 進行擴展,最熟悉的例子大概是println!的macro 擴展。

故事是這樣子的,Rust 有相當嚴格的語法結構:函數要有同樣的特徵,每個overload function 應該存在同樣的trait 中,使用同一個trait 就能為一個function在不同的物件中進行實作。
例如在struct 那篇中:
http://yodalee.blogspot.tw/2015/02/rust-struct-impl-trait.html
我們當範例的struct Car, trait Movable,之後我們要有新的物件,只要再實作(impl) 這個trait ,就可以呼叫該function,編譯時期會對trait 型別進行檢查,但這樣造成的問題是,對不同物件想要有同樣函數實作時,可能會有大量同樣的程式碼需要重寫。

這裡可以取用Macro 來解決,Macro 會在編譯時展開成各種不同版本,可以一一對應到不同的型態上,當然這會讓含有Macro 的code 變得更難懂,因為Macro 如何實作……通常會被隱藏起來,但好好使用可以讓code 變得異常的精簡,算是有好有壞的功能,只要在使用時好好注意即可。

一般最常用到的macro ,大概像vec!,我們可以用
let x: Vec<u32> = vec![1,2,3];
像vec! 這樣的寫法可以初始化一個Vector,這就是利用Macro:
macro_rules! vec {
  ( $( $x:expr ),* ) => {
    {
    let mut temp_vec = Vec::new();
      $(
        temp_vec.push($x);
      )*
    temp_vec
    }
  };
}


每個Macro 都會由 macro_rule! 開頭,定義哪個字詞會觸發這個Macro,之後定義展開規則,這樣vec! 都會依規則展開。
下面會是(match) => ( expansion ) 的形式,編譯時match 會去比對Rust syntax tree,Macro 有一套自己的文法規則:
https://doc.rust-lang.org/reference.html#macros
規則可以像上面這樣虛擬,也可以非常明確,就是要指定某個文字內容,像這樣簡單的Macro 也是會動的:
macro_rules! foo {
  (x) => (3);
  (y) => (4);
}
fn main() {
  println!(“{}”, foo!(x));
}


同時Macro 在展開時也會檢驗是否有不match 的部分,上面的 foo!(z) 會直接回報編譯錯誤;Macro 中可以指定metavariable,以 $ 開頭,並指定它會對應什麼樣的辨識符號,我們這裡指定match rust 的expr,並以x 代稱,外層的 $(...),* 則是類似正規表示法的規則,說明我們可以match 零個或多個內部的符號。

在match 之後,原有的程式碼就會在{}, ()或 [] 內展開成expansion,可以在裡面recursive 的呼叫自己,但無法對變數進行運算,例如recursive 運算的macro rule是不行的:
($x:expr) => RECURSIVE!($x-1)
在vec 中內層的{} 則是要包括多個展開的expression,如果是上面的(x) => (3)就沒這個必要;展開之後,會依照指定的數量 $(...),* ,將內含的metavariable 展開。
所以上面的vec![1,2,3],就會展開成
temp_vec.push(1);
temp_vec.push(2);
temp_vec.push(3);

Rust 這樣的Macro 設計是基於syntax parser 的,所以不必擔心像C macro 會遇到的問題,例如:
#define FIVE(x) 5*x
FIVE(2+3)
如果是Rust 的Macro ,後面的2+3 是會直接parse 成一個expr,因此仍會正常運作,內部的$x 名稱和展開的名稱也不會有任何衝突,不用擔心C Macro字串展開後可能取用到其他變數的問題。
macro_rule! FIVE {
  ($x: expr) => (5*x)
}


在Rust 裡可以進行Macro matcher 的東西非常多,上面的expression 只是當例子,其實這些都可以寫到matcher 裡面,並有對應的要求,這裡就只羅列內容,詳細就請看文件了。
identifier: 變數名稱
path:
ty: 型別名稱,如i32
pat: pattern 像Some(x)
stmt: statement
block: {} 內的內容
item: 函式、struct 的宣告
meta: attributes
tt: token tree

這裡有另一個Macro 的例子:
https://github.com/neykov/armboot/blob/master/libarm/stm32f4xx.rs
這是用Rust 來寫stm32 嵌入式系統,類似標頭檔的內容:
可以看到RCC() 會回傳一個RCCType 的struct,而這個RCCType 會是RCCBase Macro 展開的結果,接著會是另一個Macro,一路展開下去就會得到一個u32的位址,指向RCC register 所在的記憶體位址。

另外必須要說,我記得我碰過一個Macro 展開錯誤時的bug,那個錯誤真的非常非常難找,它就指向使用Macro 的那行,送一個錯誤訊息給你,可是你根本不知道是它展開到哪裡時出了錯。
上面這些,我的觀察啦,其實不太常用到,因為程式碼要長大到一定程度,選用Macro 才會有它的效益,一般狀況下用到的機會其實不大。
但Rust 的確提供這樣的寫法,在必要的時候,Macro 可以用極簡短的code 達到非常可怕的功能。

2015年4月26日 星期日

Linker script 簡介

Linker script,就是給Linker 看的script。

Linker:
當然這樣是在講廢話,首先要先知道Linker 是什麼:在程式編譯成物件檔之後,會把所有的物件檔集合起來交給連結器(linker),Linker 會把裡面的符號位址解析出來,定下真正的位址之後,連結成可執行檔。
例如我們在一個簡單的C 程式裡,include 一個標頭檔並使用裡面的函數,或者用extern 宣告一個外部的變數,在編譯成標頭檔的時候,編譯器並不清楚最終函數和變數的真正位址,只會留下一個符號參照。
待我們把這些東西送進linker,linker就會把所有的標頭檔整理起來,把程式碼的部分整理起來、變數的部分整理起來,然後知道位址了就把位址都定上去,如果有任何無法解析的符號,就會丟出undefined reference error。

我們可以試試:
外部函數,在一個foo.h 裡宣告,並在foo.c 裡面定義:
int foo();

外部變數,在var.c 裡面定義
int var;

在main.c 裡面引用它們:
#include “foo.h”
extern int var;
int main(){
  var = 10000;
  foo();
  return 0;
}

開始編譯
gcc -c main.c
gcc -c foo.c

這樣我們就得到兩個物件檔 main.o跟foo.o,我們可以用objdump -x 把物件檔main.o的內容倒出來看看,其中有趣的就是這個:
SYMBOL TABLE:
0000000000000000 g F .text 000000000000002a main
0000000000000000 *UND* 0000000000000000 var
0000000000000000 *UND* 0000000000000000 foo RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000000000011 R_X86_64_PC32 var-0x0000000000000008
000000000000001f R_X86_64_PC32 foo-0x0000000000000004

可以看到var, foo 這兩個符號還是未定(UND, undefined),若我們此時強行連結,就會得到:
main.c:(.text+0x11): undefined reference to 'var'
main.c:(.text+0x1f): undefined reference to'foo'

必須把foo.o 跟var.o 兩個檔案一起連結才行。

--
Linker script:
好了Linker講了這麼多,那linker script 呢?

Linker script 可以讓我們對linker 下達指示,把程式、變數放在我們想要的地方,一般的gcc 都有內建的linker script,平常我們開發x86系統跟arm系統,會使用不同的gcc,就是在這些預設的設定上有所不同,要是把這團亂七八糟的東西每key一次gcc 都要重輸入就太麻煩了;可以用ld --verbose 輸出,這裡看到的是支援x86 系統的linker script ,講下去又另一段故事,先跳過不提。

我們這裡拿燒錄在STM32 硬體上的linker script 來講,linker script 可見:
https://github.com/yodalee/mini-arm-os/blob/master/02-ContextSwitch-1/os.ld

Linker 的作用,就是把輸入物件檔的section整理成到輸出檔的section,最簡單的linker script 就是用SECTIONS指令去定義section 的分佈:
SECTIONS
{
. = 0x10000;
.text : { *(.text) }
. = 0x8000000;
.data : { *(.data) }
.bss : { *(.bss) }
}

在Linker script 裡面,最要緊的就是這個符號 '.' location counter,你可以想像這是一個探針,從最終執行檔的頭掃到尾,而 '.' 這個符號就指向現在掃到的位址,你可以讀取現在這個探針的位址,也可以移動探針。
不指定的話location counter 預設會從0的位置開始放置,而這段script,先把location counter 移到0x10000,在這裡寫入.text section,再來移到0x8000000放.data 跟.bss。
這裡檔名的match 支援適度的正規表示式,像*, ?, [a-z] 都可以使用,在這裡用wildcard直接對應到所有輸入檔案的sections。
光是SECTION 就講不清的用法,把指定某檔案的Section (file.o(.data)),排除某些檔案的section (EXCLUDE_FILE)
幸運的是,通常我們都不會想不開亂改linker script,這些位置的放法要看最終執行的硬體而定,亂放不會有什麼好下場。
另外linker script 也定義一些指令,這裡列一些比較常用的:

ENTRY:
另外我們可以用ENTRY指定程式進入點的符號,不設定的話linker會試圖用預設.text 的起始點,或者用位址0的地方;在x86 預設的linker script 倒是可以看到這個預設的程式進入點:
ENTRY(_start)

既然linker script 是用來解析所有符號的,那它裡面能不能有符號,當然可以,但有一點不同,一般在C 語言裡寫一個變數的話,它會在symbol table 裡面指明一個位址,指向一個記憶體空間,可以對該位址讀值或賦值;而在linker script 裡的符號,就只是將該符號加入symbol table內,指向一個位址,但位址裡沒有內容,定義這個符號就是要取位址。
一般在linker script 裡面定義符號,都是要對記憶體特定位址作操作:
以上面的STM32 硬體為例,因為FLASH 記憶體被map 到0x00000000,RAM的資料被指向0x20000000,為了把資料從FLASH 搬到RAM 裡,在linker script 的RAM 兩端,加上了:
_sidata = .;
//in FLASH _sdata = .;
_edata = .;

等於是把當前 location counter 這根探針指向的位址,放到_sdata 這個符號裡面,所以在主程式中,就能向這樣取用RAM 的位址:
extern uint32_t _sidata;
extern uint32_t _sdata;
extern uint32_t _edata;

uint32_t *idata_begin = &_sidata;
uint32_t *data_begin = &_sdata;
uint32_t *data_end = &_edata;
while (data_begin < data_end) *data_begin++ = *idata_begin++;

注意我們用reference 去取_sdata, _edata 的位址,這是正確用法。

Linker script 還定義了PROVIDE 指令,來避免linker script 的符號跟C中相衝突,上面如果在C程式裡有_sdata的變數,linker 會丟出雙重定義錯誤,但如果是
PROVIDE(_sdata = .)
就不會有這個問題。

KEEP 指令保留某個符號不要被最佳化掉,在script 裡面isr_vector是exception handler table,如果不指定的話它會被寫到其他區段,可是它必須放在0x0的地方,因此我們用KEEP 把它保留在0x0上。

MEMORY:
Linker 預設會取用全部的記憶體,我們可以用MEMORY指令指定記憶體大小,例子中我們指定了FLASH跟RAM的輸出位置與大小:
MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 40K

} 接著我們在上面的SECTION部分,就能用 > 符號把資料寫到指定的位置
也就是例子裡,把 .text section全塞進 FLASH位址的寫法,如果整體程式碼大於指定的記憶體,linker 也會回報錯誤。

結語:
Linker 其實是個古老而複雜的東西,Linker script 裡面甚至有OVERLAY這個指令,來處理overlay 的執行檔連結,但一般來說,除非是要寫嵌入式系統,需要對執行檔的擺放位置做特別處理,否則大部分的程式都不會去改linker script,都直接用預設的組態檔下去跑就好了。

這篇只介紹了極限基本的linker script,完整內容還是請看文件。

參考內容:
Linker script document:
https://sourceware.org/binutils/docs/ld/Scripts.html

如果要知道linker如何處理位置無關符號,請見:
https://www.technovelty.org/c/position-independent-code-and-x86-64-libraries.html

2015年4月13日 星期一

用llvm 編譯嵌入式程式

最近幾天在研究嵌入式系統,玩一玩也有一些心得。
課程上所用的編譯工具是arm-none-linux-gnu toolchain,在Archlinux 下可以用如下的方式安裝:
$ yaourt -S gcc-linaro-arm-linux-gnueabihf
$ yaourt -S qemu-linaro
$ yaourt -S arm-none-eabi-gcc49-linaro
$ yaourt -S arm-none-eabi-gdb-linaro
$ ln -s /opt/gcc-linaro-arm-linux-gnueabihf/libc /usr/arm-linux-gnueabihf

不過最近心血來潮,想來試試如果用另一套編譯器 LLVM 來編譯看看,至於為什麼…好玩嘛(炸),總之這裡是設定筆記:

主要參考網址:
http://clang.llvm.org/docs/CrossCompilation.html
https://github.com/dwelch67/mbed_samples/

用上LLVM 的優勢是,它在編譯時會將程式碼轉換成與平台無關的中間表示碼(Intermediate Reprsentation, IR),再透過轉換器轉成平台相關的組合語言或是底層的機械器。不像gcc 針對不同的Host/Target的組合就是不同的執行檔和標頭檔,在編譯到不同平台時,都要先取得針對該平台的gcc 版本。
註:上面這段是譯自上面的參考網址,雖然我有點懷疑這段話,不然gcc 命令列參數那些平台相關的選項是放好看的嗎?

我嘗試的對象是mini-arm-os 00-helloworld,目標device 是STM32
https://github.com/embedded2015/mini-arm-os

前端的 c 我們先用clang 編譯為llvm IR code,用llvm 的llc 編譯為 object file,因為目前LLVM 的linker lld還在開發中,只能link x86上的elf 檔,要連結ARM 我們在link 階段還是只能用biutils 的ld,以及biutils 的objcopy,這樣看起來有點詭異,有點像換褲子結果褲子只脫一半就穿新褲子的感覺。

最後的Makefile 大概長這樣:

CC := clang
ASM := llc
LINKER := arm-none-eabi-ld
OBJCOPY := arm-none-eabi-objcopy

CCFLAGS = -Wall -target armv7m-arm-none-eabi
LLCFLAGS = -filetype=obj
LINKERSCRIPT = hello.ld

TARGET = hello.bin
all: $(TARGET)

$(TARGET): hello.c startup.c
$(CC) $(CCFLAGS) -c hello.c -o hello.bc
$(CC) $(CCFLAGS) -c startup.c -o startup.bc
$(ASM) $(LLCFLAGS) hello.bc -o hello.o
$(ASM) $(LLCFLAGS) startup.bc -o startup.o

$(LINKER) -T hello.ld startup.o hello.o -o hello.elf
$(OBJCOPY) -Obinary hello.elf hello.bin

其實重點只有在target 指定的地方,其他的就沒啥,只是這樣一看好像沒有比較方便,而且這樣根本就不是用 llvm 編譯,最重要的Link 階段還不是被 gcc 做去了= =
在lld 完成前也許還是乖乖用 gcc 吧?

對LLVM 相關介紹可以見:
http://elinux.org/images/d/d2/Elc2011_lopes.pdf
各種biutils 的替代品列表:
http://marshall.calepin.co/binutils-replacements-for-llvm.html
LLVM lld開發中,是不是該進去貢獻一下Orz:
http://lld.llvm.org/