A native compiler for 8-bit PIC microcontroller in Common Lisp

I presented a native compiler for 8-bit PIC microcontroller written in Common Lisp at Lisp Meet Up #27.

You can see its source code here.

Lisp Meet Up #27, 8-bit PIC マイコン用ネイティブコンパイラの作成（後編） from masayukitakagi

A list of Physics-Based Animations

Here shows a list of physics-based animations I computed and rendered, including fluid, rigid body and their coupling simulation. Movies are to be added.

Falling Rigid Bunnies
I simulated a lot of falling Stanford bunnies and rendered the result.

watch movie

Bunny-shaped fluid simulation
I simulated bunny-shaped fluid body and rendered the result.

watch movie

Rigid-fluid coupling for SPH
I simulated rigid-fluid coupling for SPH and rendered the result.

watch movie

Rigid-fluid coupling for SPH
I simulated rigid-fluid coupling for SPH and rendered the result.

watch movie

Rigid body simulation on a slope
I simulated a rigid body falling on a slope with a particle-based method.

watch movie

Falling rigid bodies
I simulated falling rigid bodies and rendered the result.

watch movie

Particle-based rigid body simulation
I simulated many colliding rigid bodies and rendered the result.

match movie

Braking wave simulation with SPH
I simulated a breaking wave with SPH and rendered the result.

watch movie

Particle-based fluid simulation in x2 scale
I computed the following fluid simualtion in x2 scale, then rendered the result.

watch movie

Particle-based fluid simulation in 3D
I computed particle-based fluid simulation in 3D and rendered the result.

watch movie

Particle-based fluid simulation
I computed particle-based fluid simulation in 2D and rendered the result.

watch movie

PIC - PIC Is a Compiler for 8-bit PIC micro controllers

PIC is a native compiler for 8-bit PIC micro controllers written in Common Lisp. The host language is a pretty small subset of ML-like language and the target language is 8-bit PIC micro controller assembly. Common Lisp is the compiler language.

Usage

Following is an example of LED blinking with PIC12F683 micro controller. init function is one of the compiler's special functions, where the micro controller's SFR(Special Function Registers) are initialized. Following main function is also the compiler's special function and program's main routine is executed here.

mdelay1 function and mdelay macro are for delaying. Note that since 8-bit PIC handles only 8-bit unsigned integers, nested loops are needed for delaying more than 255 msec (950 msec here). progn and loop are predefined macros for the compiler.

(defpic init ()
  (progn
    (setreg :gpio #x0)                  ; clera GP0-5
    (setreg :cmcon0 #x07)               ; disable comparator
    (setbank1)                          ; switch to bank 1
    (setreg :trisio #x08)               ; only GP3 is outputinputmode
    (setreg :ansel #x00)                ; disable analog IO
    (setreg :ioc #x00)                  ; disable interruption
    (setbank0)                          ; switch to bank 0
    (setreg :intcon #x00)))             ; disable interruption

(defpic main ()
  (progn
    (setreg :gpio #x20)                 ; set GP5 to high
    (mdelay 50)                         ; delay for 50 msec
    (setreg :gpio #x00)                 ; set GP5 to low
    (mdelay 950)                        ; delay for 950 msec
    (main)))                            ; repeat

(defpic mdelay1 ()
  (loop 90                              ; 90 is a magic number to delay
    0))                                 ;  for 1 msec

(defpicmacro mdelay (n)
  (unless (<= 0 n 65535)
    (error "The value ~S is invalid." n))
  (multiple-value-bind (q r) (truncate n 256)
    (if (= q 0)
        `(loop ,r (mdelay1))
        `(loop ,q (loop ,r (mdelay1))))))

Then pic-compile function compiles and outputs the complete assembly for the PIC functions to standard output. The output assembly is expected to be assembled with Microchip's MPASM assembler.

PIC> (pic-compile)
    INCLUDE"p12f683.inc"
    list p=12f683

    __CONFIG _CP_OFF & _CPD_OFF & _WDT_OFF & _BOD_ON & _IESO_OFF& _PWRTE_ON & _INTOSCIO & _MCLRE_OFF

    CBLOCK  020h
    L0,L1,L2,L3,L4,L5,L6,L7 ; local registers
    I0,I1,I2,I3,I4,I5,I6,I7 ; input registers
    SP,STMP,STK             ; stack registers
    ENDC

    ORG 0
    GOTO    MAIN
    ...
    END
; No value

For detail, please see its repository.

Swank RPC プロトコル

Swank RPC プロトコルは、SLIME と Swank との間で用いられる、テキストベースの非同期通信プロトコルです。

SLIME は、Common Lisp でアプリケーションを開発するための Emacs モードで、IDE（統合開発環境）と呼べるほど強力な機能を備えています。

SLIME には、Swank と呼ばれるバックエンドがあります。Swank は、Common Lisp プロセスにロードされ、ソケットを経由して SLIME と通信します。このとき使用されるのが、Swank RPC プロトコルです。

Swank RPC プロトコルの概観

Swank RPC プロトコルは、6文字の16進数文字列とそれに続くS式、終端の改行文字で構成されます。

000016(:return (:ok nil) 1)\n

先頭の16進数文字列は、続くS式の長さ（最後の改行文字を含む）を表します。S式は、SLIME や Swank によって読み込まれます。S式の最初の要素はメッセージの種類を表すキーワードで、残りの要素がその引数です。

メッセージには、以下のような種類があります。

• :emacs-rex
• :return
• :indentation-update
• :new-features

Swank RPC プロトコルによるS式の評価

たとえば、(+ 3 4)というS式を Swank で評価するには、以下のメッセージを送信します。

00002c(:emacs-rex (+ 3 4) "COMMON-LISP-USER" t 1)\n

最初の6文字は続くS式の長さで、改行文字を含め44文字のため、16進数で2cとなります。

メッセージの種類は :emacs-rex （Remote EXecute SEXP）で、第一引数が評価するS式、第二引数がそのときのカレントパッケージです。第三引数はS式の評価を行う Swank 側のスレッドを表し、第四引数は戻り値を受け取る継続を意味します。

S式が評価されると、Swank からは以下のようなメッセージが返信されます。

000013(:return (:ok 7) 1)

最初の6文字は、送信されたメッセージと同様にS式の長さを表し、19文字のため、16進数で13となります。

戻り値を表すメッセージは、:return です。評価に成功した場合、第一引数の最初の要素が :ok となり、二番目の要素に評価した結果の値が入ります。ここではその値は7です。第二引数は、送信されたメッセージの第四引数に含まれていた継続がそのまま返されます。

まとめ

このように、Swank RPC プロトコルでは、S式で表現されたテキストベースのメッセージが相互にやりとりされます。SLIME と Swank のやり取りの様子は、Emacs の *slime-events* バッファでみることができます。

cl-coroutine: a coroutine library for Common Lisp

CL-COROUTINE is a coroutine library for Common Lisp. It uses CL-CONT continuations library in its implementation.

https://github.com/takagi/cl-coroutine

;; define a coroutine using DEFCOROUTINE macro 
(defcoroutine example (whom) 
  (format t "First greeting to: ~A~%" whom) 
  (yield 1) 
  (format t "Second greeting to: ~A~%" whom) 
  (yield 2) 
  (format t "Third greeting to: ~A~%" whom) 
  (coexit 3) 
  (format t "No greeting to: ~A~%" whom) 
  (yield 4)) 
=> EXAMPLE 

;; make a coroutine object 
(setf coroutine (make-coroutine 'example)) 
=> a coroutine object 

;; funcall it 
(funcall coroutine "Smith") 
>> First greeting to: Smith 
=> 1 

I want your feedback. Thanks.

 

SBCL (Steel Bank Common Lisp) のビルドプロセス

SBCL のビルドプロセスの外観

Common Lisp の実装の１つである SBCL (Steel Bank Common Lisp) のビルドプロセスは、Allegro Common Lisp や LispWorks といった、イメージベースでそれ自身の上でのみビルド可能な Common Lisp 実装とは異なり、SBCL 以外の Common Lisp 実装の上でもビルドできます。それを実現するために、SBCL のビルドプロセスでは、様々なテクニックが使われています。

このエントリでは、SBCL のビルドプロセスを順を追って説明します。

host-1 ビルドステージ

まず、ホスト上にクロスコンパイラを読み込みます。SBCL のソースコードをホストコンパイラでコンパイルしロードすることで、ホスト上にクロスコンパイラを展開します。

続いて、後のステージのための前処理として、sb!fasl:genesis の読み込みと、C ヘッダファイルの出力を行います。sb!fasl:genesis は、genesis-2 ビルドステージで、'cold core' を生成するために使われます。C ヘッダファイルは、続く target-1 ビルドステージで、SBCL の実行形式を構築するのに使われます。

target-1 ビルドステージ

target-1 ビルドステージでは、大きく２つの処理が行われます。１つは、SBCL 実行形式の構築です。host-1 ビルドステージで生成された C ヘッダファイルと、その他の C ソースファイルおよびアセンブリファイルから、SBCL の実行形式を構築します。ただし、この実行形式は、この時点ではまだ動作しません。OS サービスへのインターフェイスやガベージコレクタを提供するものの、次ステージ以降で生成されるターゲットメモリイメージを含まないためです。

もう１つの処理は、ターゲットの一部として使用される Lisp ソースコードの生成です。この Lisp ソースコードは、小さな C プログラムをコンパイルおよび実行することで生成され、システム依存の定数と型に関する情報を提供します。

host-2 ビルドステージ

このステージでは、SBCL 用のオブジェクトファイル (FASL ファイル) が生成されます。オブジェクトファイルは、クロスコンパイラ版の compile-file を用いて、SBCL ソースコードを再度コンパイルすることで得られます。このとき、SBCL ソースコードの他に、host-1 ビルドステージで生成した Lisp ソースコードを併せて用いることで、クロスコンパイラ上の定数定義を、システム環境に応じたものに更新します。

genesis-2 ビルドステージ

続いて、genesis-2 ビルドステージに入ります。ここでは、host-1 で読み込んだ sb!vm:genesis を用いて、FASL ファイルのロードとメモリイメージの保存をシミュレートします。sb!vm:genesis が必要となる理由は、ホストコンパイラの load 関数では、SBCL の FASL 形式をロードできず、また、SBCL のターゲットイメージがまだ存在しないことからその load 関数を使うこともできないためです。

ここで行う処理は、次のように進みます。まず、特定の順序で擬似的に FASL ファイルをロードし、メモリイメージを展開します。次に、ターゲットのメモリ領域をバイト配列とみなし、FASL ファイルをロードしたときに起こるであろう処理をシミュレートします。この方法で実行できない処理は、ターゲットイメージの初期化関数が実行されるまで遅延されます。すべての FASL ファイルがこの方法で処理された後、メモリ領域を SBCL 実行形式が期待する形式でファイルに保存します。これで 'cold core' が生成されました。

最後に、'cold core' をメモリイメージとして、SBCL 実行形式を起動します ('cold init')。遅延されていたトップレベル・フォームの処理などは、このタイミングで実行されます。'cold init'は、助けになる Lisp デバッガが存在しないことから最もデバッグしづらいため、現在の SBCL のビルドプロセスにおいて、もっとも脆弱な箇所といえます。

target-2 ビルドステージ

SBCL のビルドプロセスの最終ステージが、target-2 ビルドステージです。まず、パッケージを最終的な名前に変更し、sb! プレフィックスを、sb- プレフィックスとします。次に、SBCL に特殊化されたバージョンの Portable Common Loops (PCL) をコンパイルし、ロードします。最後に、そうしてできた新しいメモリイメージを、output/sbcl.core として保存します。

これで、ビルドプロセスが完了しました。

まとめ

このエントリでは、SBCL のビルドプロセスを順を追って説明しました。SBCL のアプローチにもメリット・デメリットはありますが、このような仕組みでセルフ・ブートストラッピングを実現しているというのは、興味深いところです。

参考

SBCL - a Sanely-Bootstrappable Common Lisp
http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf
　

Cl-reexport: symbol reexporting library for common lisp

Cl-reexport is a library to reexport symbols which are external symbols in other packages. It is valuable when virtually construct package hierarchy on Common Lisp standard's flat package system. 

https://github.com/takagi/cl-reexport 

ASDF 3 has similar one-package-per-file facility. The structural difference between them is: 

* Virtual hierarchy packages in this context have one system definition and several packages constituting a hierarchical structure. 

* ASDF 3's one-package-per-file style has hierarchical system definitions and hierarchical packages, which are corresponding each other. 

Since ASDF 3's one-package-per-file style has not been de facto standard yet, there may be some cases where cl-reexport is useful. 

Currently requesting to Quicklisp to register. 

I want your feedback.

SLIME REPLからFinderを開くには

SLIMEからCommon Lispを使っているとき、Finderでディレクトリを開きたいことがよくあります。SLIME REPLのShortcutを使ってそれを実現してみます。

SLIME REPLのShortcut機能

SLIME REPLにはShortcutというコマンドセットがあります。Shortcutを呼び出すには、REPLプロンプトで","を押してからShortcut名を入力します。

Shortcutには、カレントディレクトリの変更などのコマンドが定義されていますが、残念ながらOS側でディレクトリを開くコマンドは定義されていません。そこで、Shortcutを独自定義して、それを使ってFinderでディレクトリを開けるようにしてみます。

Shortcutの独自定義

SLIME REPLのコードは、slime/contrib/slime-repl.elにあります。この中で、Shortcutは、defslime-repl-shortcutというマクロを使って定義されています。これを使って、ディレクトリを開くShortcutを定義することにします。

slime/内のファイルを変更したくないので、.emacsに以下のコードを追記します。

;; SLIME open-directory short cut
(defun slime-open-directory (directory)
  "open DIRECTORY with Finder"
  (interactive (list (read-directory-name "Directory: " nil nil t)))
  (let ((dir (expand-file-name directory)))
    (call-process "open" nil nil nil dir)
    (message "opened: %s" dir)))

(defslime-repl-shortcut nil ("open-directory" "open")
  (:handler 'slime-open-directory)
  (:one-liner "Open a directory with Finder"))

これで、SLIME REPLから"," + openで、任意のディレクトリをFinderを使って開くことができるようになります。

--

GHCにおいてモジュールを相互再帰させるには

ソフトウェアの設計において、モジュールを相互参照させたい状況があります。論理的にはモジュールを細かく分ければ相互参照が起きないようにできる場合でも、意味的に考えた場合にそれらを分割したくないようなときです。

このエントリでは、GHCでHaskellのコードをコンパイルする際にモジュールを相互参照させる方法を紹介します。

The Haskell 98 Reportにおける記述

Haskellの言語仕様である"The Haskell 98 Report"では、モジュールは相互再帰をしても良いとされています。

"5. Modules" in The Haskell 98 Report
... Modules may be mutually recursive. ...

ところが、GHCでHaskellのコードをコンパイルする場合、そのままではモジュールを相互参照させることができずエラーとなります。

そうご参照させたモジュールをGHCでコンパイルする場合、追加の記述が少しだけ必要になります。

GHCで相互再帰モジュールをコンパイルするには

GHCは相互再帰モジュールをサポートしていますが、それをコンパイルするには、インポートグラフの循環参照回避のために、以下が必要となります。

• SOURCEプラグマ
• hs-bootファイル

SOURCEプラグマは、import宣言においてのみ使われるプラグマです。インポートグラフが循環しないようにコンパイラにヒントを与えるためのものです。

hs-bootファイルは、対応する.hsファイルのモジュール宣言や型宣言のみを抽出して記述したファイルです。.hs-boot拡張子を与えてプログラマが用意します。上述のSOURCEプラグマが付与されたモジュールをインポートする場合、インポートされる側のモジュールについては、.hsファイルではなく.hs-bootファイルから生成される情報を参照することになります。

具体的にどのように実装するかについては、GHCユーザガイドの4.7.9. How to compile mutually recursive moduleにて詳しく記述されています。

--

ケーパビリティを使ったリソース保護機構「Capsicum」

このエントリでは、ケーパビリティを使ったリソース保護機構である「Capsicum」を紹介します。Capsicumは、まもなく正式リリースされるFreeBSD 9に搭載される予定です。

Capsicumとは？

タネンバウムの「モダンオペレーティングシステム」では、オペレーティングシステムのリソース保護機構について、以下の３つを紹介しています。

• 保護ドメイン
• アクセス制御リスト
• ケーパビリティ

これらのうち、ケーパビリティとは、改竄不可能なトークンを使ったアクセス制御ですが、これまでごく一部の研究用OSでしか実装されてきませんでした。

Capsicumとは、そのようなケーパビリティを使ったリソース保護機構を一般的なUNIXに導入しようというプロジェクトです。

Capsicumによるメリット

オペレーティングシステムのリソース保護機構については、DAC（Discretionary Access Control）やMAC(Mandatory Access Control)が広く使われていますが、これらは、１つのアプリケーションが様々な形式のリソースを扱う場合のリソース保護に向いたようには設計されていません。ここでいう様々な形式のリソースとは、たとえば、ウェブブラウザの場合、画像、動画、Flash、JavaScriptなどといったデータです。信用を受けたリソース元ではない可能性もあります。

そのような様々な形式のリソースを扱う局面おいてデータを保護するために、ウェブブラウザのChromiumでは、プロセスを複数に分けることでコンパートメント化を実現しています。ところが、この方法をとる場合、プラットフォームによってプロセス周りの仕様が変わるため、プログラマがそれぞれの環境に合わせてそれなりの量のコードを書いて実装しなければならないという問題があります。

この問題への解決策として、一般的なUNIXにケーパビリティを使ったリソース保護機構を補完的に導入しようというものが、Capsicumです。たとえば、Chromiumへのテスト実装では、わずか100行のコード追加で、コンパートメント化を実現できたといいます。

Capsicumは、FreeBSD 9に導入される予定です。12月9日にFreeBSD-9.0 RC3が公開されたので、来年の早いうちには正式リリースされるでしょう。

--

コンピュータシステムのアクセス制御における、２つの文脈

システムのアクセス制御といったとき、大きく２つの文脈に分けられます。オペレーティングシステムの分野における伝統的なアクセス制御と、企業内の情報システムにおけるアクセス制御の２つです。

後者は前者からの派生でありもちろん両者には関係性があるのですが、前者は悪意を持った攻撃者への対策という観点が主である一方、後者は複雑な組織内での適切な権限割当てという観点が大きくなっています。

オペレーティングシステムにおけるアクセス制御

タネンバウムの「モダンオペレーティングシステム」では、オペレーティングシステムのファイル保護機構は以下の３つが紹介されています。

• 保護ドメイン
• アクセス制御リスト
• ケーパビリティ

保護ドメインは任意アクセス制御(Discretionary Access Control; DAC)、アクセス制御リストは強制アクセス制御(Mandatory Access Control; MAC)ともいわれます。

DACとMAC

従来のオペレーティングシステムにおけるアクセス制御として、DACとMACがあります。

DACはもともと、ユーザをお互いから守るように設計されていました。ファイルのようなオブジェクトの所有者が、そのオブジェクトへのパーミッションを指定できるという仕組みです。パーミッションは、そのオブジェクトがアクセスされるときに、OSによってチェックされます。

ところが、DACには脆弱性があります。root権限のような特権がアクセス制御を迂回できてしまうため、システムをクラックされて特権を取得されると重要なファイルを書き換えられてしまう可能性があるのです。これは、リソースの所有者とそのリソースへのアクセス権限設定者が分離されていないことによる問題です。

MACは、そういったDACの弱点を補い、システムのセキュリティポリシーを強化するよう設計されました。システム管理者がポリシーを決め、そのポリシーがOSのカーネルのあちこちに埋め込まれたフックによってチェックされます。

ケーパビリティ

DACやMACは、リソースに対してセキュリティレベルを設定するという考え方に基づく仕組みです。一方、プロセスに対して最小限のアクセス権限を与えることでシステムの安全性を高めるという考え方があります。それがケーパビリティです。

たとえば、UNIXにおけるプロセスには、一般ユーザ権限で動くものと特権で動くものがあります。もし、特権で動いているプロセスに脆弱性があった場合、不正な操作によりプロセスが持っている権限を取得されてしまう可能性があるのです。

この問題を解決する方法がケーパビリティです。特権をさらに細分化したケーパビリティと呼ばれる単位で取り扱えるようにし、プロセスに最小限のケーパビリティのみを与えて必要な処理のみを行わせるというものです。

この仕組みにより、もしプロセスに脆弱性がありそれが悪用されたとしても、そのプロセスが必要とする最小限のケーパビリティしか奪われないため、被害の範囲を狭めることが可能になります。プロセスが自らジェイルに入るようなものです。

ケーパビリティはこれまで、一部のセキュアOSでのみ使われていましが、最近の動きとして、Capsicumというケーパビリティ機構がFreeBSD 9に搭載されます。あらゆるシステムがインターネットに繋がれるようになる中、予期せぬ脆弱性からシステムを守るため、ケーパビリティのような保護機構の必要性が高まっているといえます。

企業内の情報システムにおけるアクセス制御

1990年ごろまで、軍事システムでMACが利用される一方、企業や行政組織ではMACではなくDACが適しているとされていました。しかし、DACには上述の脆弱性が存在します。企業や行政組織でITシステムが広く使われるようになるにつれ、それらの組織でも情報セキュリティがより重要となりました。

そんな中、DACの脆弱性を補いつつも、企業や行政組織でも運用が可能なアクセス制御の仕組みとして、ロールベースアクセス制御(Role-based Access Control; RBAC)が考えだされました。

DACやMACでは、アクセス制御の主体は個々のユーザやグループ、対象はファイルのような具体的なリソースでした。一方、RBACでは、パーミッションはユーザやグループではなく「役割（ロール）」について付与され、ユーザやグループはそれらの「役割」に紐づけられます。また、対象も具体的なリソースではなくそれらのリソースに対して一連の操作を行う「オペレーション」となります。

このように、「役割」や「オペレーション」といった、一段抽象度を上げた概念に対してアクセス制御を行うことで、RBACでは、企業および行政組織のポリシーや構造に合わせた柔軟な、しかし集中的なコントロールを可能としています。企業や行政組織での実運用が重視されているのがポイントです。


--

Compiling the Particle-based Simulation Description Language

On the former entry, I described simple N-Body simulation in the Particle-based Simulation Description Language as a embedded DSL and executed it with interpreter. In this entry, I introduce compiling and demonstrate it.

Implementation

The Particle-based Simulation Description Language is compiled to Haskell using Template Haskell, a GHC extension to Haskell that adds compile-time metaprogramming facilities.

With this transformation, a code corresponding to the N-Body simulation code written in plain Haskell on the former entry is produced, then it is compiled with GHC Haskell compiler.

In other words, the host language is the Particle-based Simulation Description Language and the target language is Haskell, though there is no clear line between the host and target languages because it is a embedded DSL.

Codes

Here the codes are, with the interpreter introduced on the former entry together, arranged as a module.

The structure of the module is as below:

- Examples/
- SimulationDSL/
  - SimulationDSL.hs
  - SimulationDSL/
    - Compiler/
    - Data/
    - Interpreter/
    - Language/
    - Test/

Execution

To execute, compile CompilerRun.hs in Examples directory and run the output file as below:

$ cd Examples
$ ghc -i../SimulationDSL --make -O2 CompilerRun.hs
$ ./CompilerRun

Performance

Comparing performance on three codes:

• with compiler - CompilerRun
• in plain Haskell - NBody
• with interpreter - InterpreterRun

The performance:

$ time ./CompilerRun > /dev/null

real 0m0.949s
user 0m0.927s
sys 0m0.011s

$ time ./NBody > /dev/null

real 0m0.972s
user 0m0.950s
sys 0m0.011s

$ time ./InterpreterRun > /dev/null
real 0m2.932s
user 0m2.906s
sys 0m0.022s

As chart:


As intended, the same performance to the code in plain Haskell is given with compiler, which is 2x-3x faster than with interpreter.

Conclusion

In this entry, I introduced compiling the Particle-based Simulation Description Language to Haskell and showed improvement in performance of simple N-Body simulation.

While this time I chose Haskell as the target language for this embedded DSL, it is also possible to compile it to C adapting OpenMP or CUDA with parallel computation.


--

粒子ベースシミュレーション記述言語のコンパイル

前回のエントリでは、粒子ベースシミュレーション記述言語を使ってN-Body（多体問題）シミュレーションを記述し、それをインタプリタとして実行しました。

今回は、それをコンパイルして実行するようにしたので紹介します。

実装方針

実装の方法としては、Template Haskellを使ってDSLをHaskellのコードに変換しています。この展開によって、前回のエントリでHaskellで直接書いた場合と同様のコードを生成し、さらにghcでコンパイルしています。

つまり、ホスト言語が粒子ベースシミュレーション記述言語、ターゲット言語がHaskellということになります。もっとも、組み込みDSLなので明確な線引きがあるわけではありませんが。

コード

コードはこちらに置いてあります。前回のインタプリタとあわせて、モジュールとして整理しました。

モジュールの構成は以下のようになっています。

- Examples/          実行例をまとめています
- SimulationDSL/
  - SimulationDSL.hs   モジュール外へのエクスポート
  - SimulationDSL/
    - Compiler/        コンパイラに関するコード
    - Data/            基本的なデータ構造
    - Interpreter/     インタプリタに関するコード
    - Language/        シミュレーション記述言語の構文と解釈
    - Test/            テストを追加していく予定

実行方法

以下のように、ExamplesフォルダのCompilerRun.hsをコンパイルし、ファイルを実行します。

$ cd Examples
$ ghc -i../SimulationDSL --make -O2 CompilerRun.hs
$ ./CompilerRun

実行効率の確認

実行速度を、以下について比べてみます

• コンパイラを使った場合 - CompilerRun
• Haskellで直接書いた場合 - NBody
• インタプリタを使った場合 - InterpreterRun

実行速度は以下のようになりました。

$ time ./CompilerRun > /dev/null

real 0m0.949s
user 0m0.927s
sys 0m0.011s

$ time ./NBody > /dev/null

real 0m0.972s
user 0m0.950s
sys 0m0.011s

$ time ./InterpreterRun > /dev/null
real 0m2.932s
user 0m2.906s
sys 0m0.022s

グラフにすると以下のようになります。



狙い通り、コンパイラを使った場合は、インタプリタのx2〜x3の速度、つまり、Haskellで直接書いた場合と同等の速さで動いています。

まとめ

このエントリでは、粒子ベースシミュレーション記述言語をHaskellにコンパイルしました。その結果、実行速度が改善されたことを示しました。

今回は組み込みDSLとしてターゲット言語をHaskellにしましたが、Cにコンパイルすることや、さらにOpenMPやCUDAに対応させて並列計算を可能にすることも検討しています。

また、HackageDBにAccelerateという配列をCUDAで計算するライブラリがあるようなので、これを使う方法もありそうです。

逆の方向として、粒子ベースシミュレーション記述言語の表現力を強化することも考えられます。

• 境界条件の指定
• 効率的な近傍探索のサポート
• 例外処理
• デバッガ
• プロファイラ
• 階層構造の導入（剛体シミュレーション）
• ドメインの導入（固液連成）

ラグランジュ的表現とオイラー的表現

この言語はラグランジュ的な表現を記述することができます。一方、オイラー的な表現を記述することはできません。

有限差分法や有限要素法、あるいは格子ガス法や格子ボルツマン法といった、格子およびメッシュをベースにした表現を使ったシミュレーションを記述するには、また別の言語モデルを設計することになるでしょう。

関連エントリ

このエントリに関連するページです。

粒子法シミュレーション記述言語によるn-Body(多体問題)シミュレーション
粒子法シミュレーションを記述するための言語を設計中
【まとめ】埋め込みDSL関係の論文(1)
【まとめ】埋め込みDSL関係の論文(2)

まとめページ

粒子法(SPH)のプログラムを解説したシリーズです。ソースコードも公開しています。

粒子法(SPH)のプログラム一覧

シミュレーションの結果をレンダリングして作った動画です。流体シミュレーションや剛体シミュレーションの動画を見ることができます。

動画の一覧

【まとめ】CG、シミュレーション関係の論文
【論文】Particle-Based Fluid Simulation ...
【論文】Two-way Coupling of Fluids to ...

そのほかの論文まとめ（準備中）

--

N-Body simulation using the Particle Simulation Description Language

On the former entry (in Japanese), a free-fall simulation on point mass is shown as a starting point towards designing a language to describe particle simulation, or SPH.

On this entry, I introduce a improved Language and demonstrate N-Body Simulation on point mass using it.

Describing N-Body Simulation

N-Body simulation is represented in mathematical formula as below:



where xi, vi, ai and fi are position, velocity, acceleration and force on point mass i, respectively.

With the introduced language, as embedded DSL in Haskell, this simulation can be described as below:

nBody =
  do define         "x" (integral (var "v" <*> dt))
     define         "v" (integral (var "a" <*> dt))
     defineWithType "a" (var "f" </> m) ExpTypeVector
     define         "f"
                    (let r = norm (var' "x" <-> var "x")
                         k = m <*> m <*> g </> r </> r
                         n = (var' "x" <-> var "x") </> r
                     in sigma (k <*> n))
     initialConditionV "x" x0
  where dt = constantS 0.01
        m  = constantS 1
        g  = constantS 9.8
        x0 = V.fromList [ (0,0,0), (2,0,0), (0,2,0) ]

Explanation

define declaration defines an equation on physical amount on point mass i.

defineWithType declaration also defines an equation on physical amount, instructing type with it. When we use define declaration, the type of the equation we define is inferred with other equations. On the other hand, if the type can not be inferred, we must instruct it using defineWithType declaration. The types we can use are Scalar and Vector for now.

initialConditionV declaration is to give the initial condition of the physical amount defined with a "integral" expression. The last letter "V" means that the physical amount has Vector type. As the argument of it, an array of Vector is given as the initial condition of the position "x". Besides, the initial condition of the velocity "v" can be omitted, and an array of zero vector is given implicitly.

integral expression means integration, calculated explicitly inside the module.

var expression and var' expression are variables indicated by the symbol given as its argument. var' expression must be in a sigma expression. The difference in var and var' is described in the next paragraph.

sigma expression means summation of the calculated result of its operand expression on point mass j excluding itself. In the operand, var "x" means xi and var' "x" means xj.

dt, m and g are constant values lifted with the constantS function. The last letter "S" shows that the constant has Scalar type.

Execution

The nBody defined in the code can be evaluated as below:

main = mapM_ (printRow . flip machineRegisterValueV "x")
     $ take 100 $ runSimMachine nBody

* for the whole code, see Simulation.hs in GitHub

About performance efficiency

For now, this language is implemented as interpreter, so the performance of codes written in it is not very fast. I've compared it with the similar N-Body simulation code written in plain Haskell (see NBody.hs in GitHub). The result is below. Simulation is in the language and NBody in plain Haskell.

$ time ./Simulation > /dev/null

real    0m2.900s
user    0m2.869s
sys     0m0.020s

$ time ./NBody > /dev/null 

real    0m0.846s
user    0m0.829s
sys     0m0.011s

The program in the language is x1/3 - x1/4 as fast as in plain Haskell.

To improve the performance, using Template Haskell, we can compile, in the broad sense, the language to plain Haskell and make it work more efficiently. Also, compiling it to generate C or CUDA code would be pretty nice :)

--

粒子法シミュレーション記述言語によるn-Body(多体問題)シミュレーション

以前のエントリでは、粒子法シミュレーションを記述するための言語として、まず１つの質点についての自由落下を記述できるようにしてシミュレーションする例を示しました。

今回は、それを進めて、複数質点についてのn-Bodyシミュレーションを記述できるようにしたので紹介します。

n-Bodyシミュレーションの記述

n-Bodyシミュレーションを、数式で以下の様に表現した場合を考えます。



ここで、xi, vi, ai, fiは、それぞれ、ある質点iの位置、速度、加速度、力です。mは質点の質量、gは重力定数です。質点の質量はすべての質点について同じとします。

提案する言語を使うと、このシミュレーションを、以下のようにHaskellの組み込みDSLとして記述できます。

nBody =
  do define         "x" (integral (var "v" <*> dt))
     define         "v" (integral (var "a" <*> dt))
     defineWithType "a" (var "f" </> m) ExpTypeVector
     define         "f"
                    (let r = norm (var' "x" <-> var "x")
                         k = m <*> m <*> g </> r </> r
                         n = (var' "x" <-> var "x") </> r
                     in sigma (k <*> n))
     initialConditionV "x" x0
  where dt = constantS 0.01
        m  = constantS 1
        g  = constantS 9.8
        x0 = V.fromList [ (0,0,0), (2,0,0), (0,2,0) ]

記述の説明

"define"によって、ある質点iの物理量について方程式を定義しています。

"defineWithType"は、"define"と同じように物理量を定義しますが、併せて型を指定する点が異なります。"define"を使った場合には、その式の型は他の式から推論されますが、他の式から型を推論できない場合には、"defineWithType"を使って型も併せて指定します。現在使える型は、スカラーとベクトルの２種類です。

"initialConditionV"は、integralを使って定義された物理量の初期条件を与えるためのものです。最後の"V"は、その物理量の型がベクトルであることを示しています。引数として、ベクトルの配列を渡しています。速度vについては初期条件が省略されており、その場合は0ベクトルが使われます。

"integral"は、積分を表します。内部では陽解法で計算しています。

"var", "var'"は、引数で与えたシンボルで表される変数です。var'はsigmaの中でのみ使うことができます。varとvar'の違いについては、以下のsigmaの中で説明します。

"sigma"は、自身を除いた質点jについてオペランドの式を計算した値の合計です。オペランド中の var "x" がxiを、var' "x" がxjを表します。iが一定で、jをi以外の各質点について変えた場合の値を合計したものを返します。

dt、m、gといった定数は、constantS関数でリフトさせて使います。最後の"S"は、その定数がスカラーであることを示しています。

実行

上記で定義したnBodyを、以下のようにrunSimMachine関数に渡すことで計算します。

main = mapM_ (printRow . flip machineRegisterValueV "x")
     $ take 100 $ runSimMachine nBody

※コード全体についてはこちらを見てください

実行速度について

現時点では、この言語はインタプリタとして実装されているため、実行速度はあまり速くありません。

同じシミュレーションをHaskellで直接書いた場合(ソースコード)と速度を比較すると、以下のようになりました。SimLangがこの言語、NBodyがHaskellで直接書いた場合です。

$ time ./SimLang > /dev/null

real    0m2.900s
user    0m2.869s
sys     0m0.020s

$ time ./NBody > /dev/null 

real    0m0.846s
user    0m0.829s
sys     0m0.011s

Haskellで直接書いた場合に比べて、1/3〜1/4の速度になっています。

実行速度については、Temlate Haskellを使って、Haskellで直接書いた場合と同等のコードに（広義の）コンパイルすることで効率化できます。

課題

現時点での実装には、以下のような課題があります。

• 0割算などの例外処理
• デバッグのしやすさ、記述にエラーがあったときのメッセージの改善

ロードマップ

今後のロードマップとして以下のようなことを考えています。

• より強力な型推論
• Template Haskellによる（広義の）コンパイル
• テスト
• 設計の解説
• 組み込みDSLや言語抽象についての解説
• SPHの記述（分岐や近傍探索の導入）
• 剛体シミュレーションの記述（階層表現の導入）
• 固液連成シミュレーションの記述（ドメインの導入）
• ベンチマーク

関連エントリ

このエントリに関連するページです。

粒子法シミュレーションを記述するための言語を設計中
【まとめ】埋め込みDSL関係の論文(1)
【まとめ】埋め込みDSL関係の論文(2)

まとめページ

粒子法(SPH)のプログラムを解説したシリーズです。ソースコードも公開しています。

粒子法(SPH)のプログラム一覧

シミュレーションの結果をレンダリングして作った動画です。流体シミュレーションや剛体シミュレーションの動画を見ることができます。

動画の一覧

【まとめ】CG、シミュレーション関係の論文
【論文】Particle-Based Fluid Simulation ...
【論文】Two-way Coupling of Fluids to ...

そのほかの論文まとめ（準備中）

--

このブログのGitHubレポジトリを作りました

このブログのGitHubのレポジトリを作りました。

blog-codes@GitHub

これまでのブログエントリで公開していたコードを、GitHubのレポジトリに移しました。

粒子法のプログラム第１回（概要）

sph.cpp - GitHub

エントリはこちら。粒子法のプログラムを解説しています。論文や本の数式をプログラムに落とすところやパラメータの設定が分かるよう、ソースコードも合わせて公開しています。

Haskell、OCamlでSPH法

sph.hs - GitHub
sph.ml - GitHub
sph.cpp - GitHub

エントリはこちら。粒子法のコードを、Haskell、OCaml、C++で書いて比較しています。

【OCaml】スタンフォードバニーの読み込みライブラリ

PlyReader.ml - GitHub
PlyReader.mli - GitHub

エントリはこちら。OCamlで、スタンフォードバニーの読み込みライブラリを書きました。

粒子法シミュレーションを記述するための言語を設計中

Simulation.hs - GitHub

エントリはこちら。粒子法シミュレーションを記述するための言語を考えており、それを紹介しています。

CPUキャッシュによるプログラム高速化の例

code1.c - GitHub
code2.c - GitHub

エントリはこちら。CPUのキャッシュメモリを使うで、プログラムの実行性能をあげることができます。キャッシュメモリを活用することでどの程度性能が向上するのかを紹介しています。


--

Acceleration of programs using CPU caches effectively

Effective use of CPU caches make the performance of programs improved. This entry shows how much improvement is given with effective use of CPU caches.

Motivation

Computer data storages have hierarchy which consists of registers, cache, main memory and so on, distinguished by response time. Registers and cache memory are smaller but faster than main memory.

CPUs can directly operate registers only. So, between registers and main memory, there is about x100 gap in access speed, and to fill the gap, CPUs have cache memory inside. With effectively using CPU cache, we can improve the performance of programs.

However, programmers can not make CPUs directly to use the cache memory in the way they want, so they must write programs considering how the CPUs read/write the data on the memory to indicate CPUs indirectly how to use the cache.

* SPARC64 VIIIfx used in the K computer of RIKEN in Japan has "sector cache" functionality and programmers can directly indicate it how to use the cache. With sector cache, the cache in a CPU is divided in two sectors and programmers can instruct which sector they use to store data.

This entry demonstrates an example of performance improvement using CPU cache effectively.

Example

I show the optimization in efficiency of a program which computes the multiplication of 1000x1000 matrices using cache blocking technique.

The code before optimized (code1.c):

#include <stdio.h>
#include <stdlib.h>
 
#define N 1000
 
int main ()
{
  double A[N][N], B[N][N], C[N][N];
  int i, j, k;
  
  // initialize the matrices
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      {
        A[i][j] = 1.0;
        B[i][j] = 1.0;
        C[i][j] = 0.0;
      }
  
  // matrix multiplication
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      for (k = 0; k < N; k++ )
        C[i][j] += A[i][k] * B[k][j];
  
  printf ( "%f\n", C[0][0] );
  
  return 0;
}

I rewrite this code as below with cache blocking (code2.c). Of course, the result of multiplication is same as to that of code1.c.

$ cat code2.c
#include <stdio.h>
#include <stdlib.h>
 
#define N 1000
 
int main ()
{
  double A[N][N], B[N][N], C[N][N];
  int i, j, k;
  
  // initialize the matrices
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      {
        A[i][j] = 1.0;
        B[i][j] = 1.0;
        C[i][j] = 0.0;
      }
  
  // matrix multiplication
  int ibl = 100;
  int ib, jb, kb;
  for (ib=0; ib<N; ib+=ibl)
    for (jb=0; jb<N; jb+=ibl)
      for (kb=0; kb<N; kb+=ibl)
        for (i=ib; i<ib+ibl; i++)
          for (j=jb; j<jb+ibl; j++)
            for (k=kb; k<kb+ibl; k++)
              C[i][j] += A[i][k] * B[k][j];
  
  printf ( "%f\n", C[0][0] );
  
  return 0;
}

Demonstration

The times taken to execute the unoptimized code and the optimized code are as below respectively:

$ gcc -Wl,-stack_size,1000000000 -O2 -o code1 code1.c
$ time ./code1 > /dev/null

real    0m7.595s
user    0m7.494s
sys     0m0.035s

$ gcc -Wl,-stack_size,1000000000 -O2 -o code2 code2.c
$ time ./code2 > /dev/null

real    0m2.509s
user    0m2.462s
sys     0m0.030s

* The -Wl option is to designate ld to allocate large arrays on the stack

The result represented as a chart:



Cache blocking improve the performance by about x3.

Comparing the performance as the size of cache blocking

Next, I show how the performance changes as the size of block. I changed the size of the block to 100, 200, 250, 500, then timed to calculation.

As a chart:


With the block size of 500, the performance degrades massively, which represents that the expansion of the block size leads to overflow of data from the cache.

The bytes of the 500x500 sized block is 2MB, with double typed array, so, considering other programs running in background, it agrees with the CPU cache size of my computer :)

--

CPUキャッシュによるプログラム高速化の例

CPUのキャッシュメモリを使うで、プログラムの実行性能をあげることができます。このエントリでは、キャッシュメモリを活用することでどの程度性能が向上するのか見てみます。

動機

コンピュータの記憶領域は、レジスタ、キャッシュメモリ、メインメモリなどからなる階層構造になっています。レジスタやキャッシュメモリはメインメモリより容量が小さいものの、非常に高速です。

CPUが直接触れるのはレジスタのみです。レジスタとメインメモリでは、データアクセスの速度に約100倍の差があり、その差を埋める目的で、CPU内部にキャッシュメモリがあります。キャッシュメモリを活用できれば、プログラムの実装性能を大きく高めることができます。

ただし、基本的に、CPUがどのようにキャッシュメモリを使うのかをプログラマが直接指示することはできません。なので、キャッシュメモリを活用するには、CPUがどのようにメモリ上のデータを使うのかを考慮したプログラムを書くことで間接的にキャッシュメモリを使うことになります。

※理化学研究所の京で使われているSPARC64 VIIIfxにはセクタキャッシュという機構があり、プログラマがキャッシュを制御できます。セクタキャッシュを使うと、キャッシュメモリを２つの領域に分割し、データごとにキャッシュに使う領域をプログラマが指定できます。

このエントリでは、キャッシュメモリを活用することで、実際にどの程度性能が向上するのか、一例を見てみます。

サンプルコード

1000×1000行列の積を求めるプログラムについて、キャッシュブロック化によって実行性能を最適化します。

以下が、最適化前のCのコードです。(code1.c)

#include <stdio.h>
#include <stdlib.h>
 
#define N 1000
 
int main ()
{
  double A[N][N], B[N][N], C[N][N];
  int i, j, k;
  
  // initialize the matrices
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      {
        A[i][j] = 1.0;
        B[i][j] = 1.0;
        C[i][j] = 0.0;
      }
  
  // matrix multiplication
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      for (k = 0; k < N; k++ )
        C[i][j] += A[i][k] * B[k][j];
  
  printf ( "%f\n", C[0][0] );
  
  return 0;
}

これを、キャッシュブロック化によって以下のコードに書き換えます(code2.c)。もちろん、計算の結果そのものは変わりません。

$ cat code2.c
#include <stdio.h>
#include <stdlib.h>
 
#define N 1000
 
int main ()
{
  double A[N][N], B[N][N], C[N][N];
  int i, j, k;
  
  // initialize the matrices
  for ( i = 0; i < N; i++ )
    for ( j = 0; j < N; j++ )
      {
        A[i][j] = 1.0;
        B[i][j] = 1.0;
        C[i][j] = 0.0;
      }
  
  // matrix multiplication
  int ibl = 100;
  int ib, jb, kb;
  for (ib=0; ib<N; ib+=ibl)
    for (jb=0; jb<N; jb+=ibl)
      for (kb=0; kb<N; kb+=ibl)
        for (i=ib; i<ib+ibl; i++)
          for (j=jb; j<jb+ibl; j++)
            for (k=kb; k<kb+ibl; k++)
              C[i][j] += A[i][k] * B[k][j];
  
  printf ( "%f\n", C[0][0] );
  
  return 0;
}

実行

最適化前、最適化後それぞれについて、実行にかかる時間は以下のようになりました。

$ gcc -Wl,-stack_size,1000000000 -O2 -o code1 code1.c
$ time ./code1 > /dev/null

real    0m7.595s
user    0m7.494s
sys     0m0.035s

$ gcc -Wl,-stack_size,1000000000 -O2 -o code2 code2.c
$ time ./code2 > /dev/null

real    0m2.509s
user    0m2.462s
sys     0m0.030s

※大きな配列をスタック上に確保するために、ldにオプションを渡してスタックサイズを大きくしています

グラフにすると以下のようになります。



キャッシュブロック化によって、約３倍の性能向上が得られました。

ブロックサイズによる性能比較

次に、ブロック化のサイズによって性能がどのように変わるかを調べてみます。ブロック化のサイズを100、200、250、500に変えて、実行時間を計ると、以下のようになりました。

100 : 2.311s
200 : 2.390s
250 : 2.509s
500 : 6.588s

※ブロック化のサイズの単位は、配列の要素数です。バイト数に直すと、double型の配列なので8を掛けたものになります

グラフにすると、以下のようになります。


ブロック化のサイズが500になると、急激に性能が悪化しています。このことから、ブロック化のサイズが大きくなりキャッシュにデータが収まらなくなった様子が分かります。

500×500のブロックのデータ量が2MBなので、このプログラム以外が動いていることも勘案すると、使っている環境のCPUの持つキャッシュメモリサイズと一致した結果といえます。


--

Common Lispでの、依存関係を考慮したファイルロード

Common Lispにおいて、asdfを使って、依存関係を考慮してプロジェクトの構成ファイルをロードする方法をまとめました。

動機

よっぽど小さなプログラムでない限り、プログラムの規模が大きくなってくると、ファイルを複数に分けることになります。

困ったことに、Common Lispには、依存関係をみて必要なファイルをロードする機能がありません。なので、ファイルを複数に分けると、必要なファイルを１つ１つロードするはめになります。

asdfを使うことで、ファイルの依存関係をみて必要なファイルを１度にロードすることができます。

asdfとは？

asdfは、"Another System Definition Facility"の略で、Common Lispプログラムを１つの「モジュール」として管理し、読み込むことができるツールです。現在はASDF2が広く使われています。

makeや、JavaのAntに相当するもので、PerlのCPANやRubyのRubyGemsの１つ下のレイヤに位置づけられます。CPANやRubyGemsにあたるものとしては、asdf-installがあります。

例

以下のような「sample」プロジェクトがあるとします。

sample
 - caller.lisp  ;; callee.lispで定義されている関数を使う
 - callee.lisp  ;; caller.lispから呼ばれる
 - sample.asd   ;; asdfモジュール定義ファイル

各ファイルの内容は以下のようになっています。

$ cat caller.lisp
(in-package :common-lisp)

(defpackage sample.caller
  (:use :common-lisp
        :sample.callee))
(in-package :sample.caller)

(hello-world)

$ cat callee.lisp 
(in-package :common-lisp)

(defpackage sample.callee
  (:use :common-lisp)
  (:export :hello-world))
(in-package :sample.callee)

(defun hello-world ()
  (print "Hello, World!"))

$ cat sample.asd 
(defsystem "sample"
  :components ((:file "callee")
               (:file "caller"))
  :serial t)

sample.asdがasdfから参照されるように設定し、common lispを起動します。

以下の関数を評価することで、sampleプロジェクトをロードすることができます。sample.asdの:serialオプションによって、ファイルの依存関係を考慮した形でファイルがロードされます。

(asdf:load-system 'sample)

--

TPPと混合診療の関係を簡単にまとめ

TPPと混合診療の関係を簡単に調べてみたので、そのまとめ。

重要なポイントとして、TPPによるアメリカの狙いの最も大きなものの１つが、サービス（金融）の自由化によって日本の個人資産を喰うこと。これは間違いない。わざわざサービス（金融）を後から捩じ込むだけのボリュームがあるターゲットは、日本だけだから。

アメリカ観点（混合診療を解禁しろ派）

混合診療解禁
→皆保険枠と混合診療枠ができる
→混合診療枠が医療保険のターゲット
→医療保険のノウハウを持っているのはアメリカの保険会社
→アメリカの保険会社はウマウマ

ref. http://haetarou.web.fc2.com/TPP/TPP_Kaisetu.html

※サービス（金融）はもともとTPPには入っておらず、アメリカが後から追加したもの。間違いなく、日本の個人資産を喰おうと狙っている

医師会観点（混合診療を解禁するな派）

混合診療解禁
→「政府は、財政難を理由に、保険の給付範囲を見直そうとしている」
→「混合診療を認めることによって、現在健康保険で見ている療養までも『保険外』とする」
→高額な診療が保険外になる
→高額な診療を受ける患者が減る
→医者の取り分が減る。困る

※医者は、国の医療費からたくさん診療費をもらいたい

ref. http://www.med.or.jp/nichikara/kongouqa/

厚生労働省観点（混合診療を解禁しろ派）

建前上、財政健全化したい
→医療費を減らしたい
→混合診療を解禁することによって、保険対象を減らすことで、医療費を減らす

※現状では、混合診療を認めていないため、その分手厚く保険対象にしてある

--