LiveCygwinマイナーチェンジ

先週、韓国で行なったセミナーで、多少、ユーザーの混乱があったので、LiveCygwinをマイナーチェンジした。

変更は、homeディレクトリを示すエキスプローラー画面のパス設定。
従来、ルートを作成するユーザのワークパスからhomeを表示していて、これはこれで良かったのだけれど、アプリケーションからファイルをオープンしようとした時に、どこにhomeがあるのか分りにくかった。

今回の変更で、homeディレクトリに独立仮想ドライブ名を割り当てることにしたので、オープンする時にファイルを見つけやすくなる。

即時提供開始である。


追記：　安心していたら、少し失敗。
LiveCygwin.exeは、Visual C++ 2008 Express editionでコンパイルしていたが、コード生成のオプション指定をデフォルトのままにしていて、DLLがないと動かない。ライブラリをスタティックリンクしないといけなかったのだ。自分のマシンはコンパイル環境にDLLが入っていたので、これに気がつくのが遅れた。今度来る研修の人のために設定中の新しいマシンにLiveCygwinを載せて実行しようとして気がついた。

今晩(4/30)にでも修正予定。

白いMacBookがやってきた

何故、白かというと、安いからである :-)

最初にやるのは、開発環境である、Xcodeのインストール。

次は、sfl2vlをコンパイル。
コンソールを開いて、通常のようにmakeをするが、flexが勝手にunistd.hを読み込むので、コンパイルオプションに
YY_NO_UNISTD_H
を追加した。これで、普通にコンパイルが終了。

ライセンス系の構築はまだなので、とりあえず、ノンプロフィット版のみの提供となる。

インストール時には、

sudo tar xzf sfl2vlbin-darwin-unix-xxxx.tar.gz -C

と、sudoを付けて展開する。

次は、monoを入れて、.NETアプリの動作確認かな・・・
(これは慌てる必要はないけれど)

ハードウェアgeneratorとsynthesizer

FPGA CPUのサイトにJan Grayが comp.arch.fpgaに投稿した記事が出ている。

彼の定義だと、generatorは明示的にネットリストを記述したもので、synthesizerは、動作合成を共なうものということだ。Grayは高級言語から回路合成するsynthesizerに懐疑的で、必要性は薄いといっているが、これは私も同じ意見だ。これをありがたがるのは、設計において、クロックスロットを制御できないヘボい似非エンジニアくらいのものだろう。ソフトでもハードでも、まともな設計者は、データの流れ(いつ、どこに、どのように移動させるか)をコントロールすることが設計の重要ポイントであることを知っているのだ。

さて、高級言語(HLL)からの合成は、Grayが定義したような解釈が固まりつつあるように思えるが、Logic synthesisという時には、VerilogやVHDLなどの明示的にネットリストを記述する言語からのネットリスト生成もsynthesisと扱っている。(これらの言語が出始めたころの時代の問題か？)

それはともかく、UMLから、SFLのスケルトンを作るのは、ほとんど一対一対応であるが、ネットリストを記述するよりは、もう少しましなことをしているので、合成という雰囲気を持っていると解釈している。

ただし、データの流れは、100%制御可能であることが、HLL合成の連中とは異なる。

我々ロジックアーキテクトに必要なものは、データの流れを100%制御可能でありながら、記述性が高く生産性を向上できる言語なのだ。

今回の一連のUML2SFLの開発の中で、UMLクラス図は、上手に使うと、生でテキストを描くよりも、生産性が上るかもしれないと思い始めている。(余分なタイピングを減らすことができる程度ではあるが・・・)

全てをUMLに載せることもできるが、OMGのMDAのようなおかしなものにすると逆に生産性は大幅に低下すると思うので、エンジニアリングチョイスが重要である。

ArgoUMLを使ってみる

フリーで使えるUMLエディタの一つ、ArgoUMLを使ってみた。
デフォルトでは、visibilityもMultiplicityも表示しないようになっているので、セッティングから変更しておくとよい。(変更前に作成したプロジェクトにはグローバルなセッティングは反映されないので、プロジェクトセッティングを変更しないといけないようだ)。

このツール、比較的軽いし、マルチプラットフォーム(JAVA)なので便利だが、UML1.4までしか対応しない(これ自体はどうせ1.4までの機能しか使わないのでいいのだが)し、エキスポートするXMIのバージョンは、1.2らしい(というのは、xmi.versionの設定がXMIのファイル中に2箇所あり、最初のは、1.2だが、次に出てくる時に、1.4となっている？？)。

私が使う範囲では、XMIの2.Xと1.Xの違いで一番大きなものは、関連の扱いかもしれない。XMI 2.Xでは、関連はクラスの属性の一つとして扱われ、クラスを処理する時に一緒に処理できるが、1.Xでは、関連はクラスと同一階層のオブジェクトとして記述されており、クラス内には関連を持っているかどうかの情報がない。

そこで、UML2SFLでは、クラスの処理の時に、すべての関連をサーチして、処理中のクラスが関連の端に相当するかどうかを調べている。非常に大きなクラス図を描いたりすると処理性能に問題を生じるかもしれないが、UMLであまり大きな図を描くような気がしないので、とりあえずは、いいとしよう :-p
(実は、一つのクラスに複数の関連がある場合には正しく動かないかもしれないが、とりあえず、図のような単純なケースの変換は出来た)

UML2SFLをArgoUMLに対応するようにバージョンアップした。今回は、VisualBasicの部分はソースコードを同封したので、もっと使いやすいGUIが欲しい人は、勝手に変更して欲しい。 VBによるGUIに変更済

唯一無二なURI

XSLがターゲットとするXMLには、名前空間の概念がある。
名前空間は、使用にあたっては、世界中、唯一無二なURIを用いて、名前空間を定義しなくてはならない。

このURI、唯一無二でありさえすればいいのかと思いきや、その値がスタイルシートの中だけでなく、変換対象のターゲットXMLとも一致している必要がある。
(つまり、自分で作るXMLもその時の気分で名前空間を作ったりすると、XSLTのスタイルシートを作る時にはまるということだ)

SAXONを使って、UML 1.4ベースのXMIを利用できるようにしようと作業していた。
UML 1.4ベースのツールでは、UML: という、名前空間の接頭が付くケースが非常に多い。昨日、見事にはまったのが、この UML: であった。

URIが一意でありさえすればいいと思っていた私は、UML 2.1のURIを少し書き換え、適当なURIを作成して名前空間の定義としておいた。

開発を進めていくと、大きなトラブル。タグがselectを使っても、全くヒットしないのだ。

name()='UML:Class'のように明示的に比較オペレータを使えばいいのだが、XSLTの解としては、美しくない。

散々悩んだあげく、URIをターゲットのXMLモデルからコピペしてみると、なぜか動いていそう!？

名前空間はターゲットのXMLを含め、整合性が取れてないといけない。一つ勉強した :-)

uml2sflテクノロジープレビュー版公開

ここ数日、開発していたuml2sflが、MagicDrawとBoumlの二つのツールのXMIを変換できるようになったので、とりあえず、テクノロジープレビュー版として、公開する。

Boumlはフリーソフトなので(見た目はあまりパッとしないれど)、簡単にお試しできる。

IP ARCH, Inc.のホームページから、SFL関連のセクションに行ってダウンロード可能。
(Windows版のみ)

XSLTコンパイラ

XSLTプロセッサによる変換が自由にできるようになったが、XSLTプロセッサの多くはJavaで書かれていて、環境設定が面倒なことと、XSLスタイルシートを生で出すのはあまり気が進まないので、XSLTコンパイラを探してみた。

候補は、いくつかあるが、

• SourceForgeのXSLTC
• XALANのXSLTC
• Microsoft WindowsSDKのXSLTC

の3つを試してみた。結果として、Microsoftのものを常用することにした。ただ、こいつは、.NETのライブラリにコンパイルするので、.NETのツールとリンクしないとスタンドアローンでは使えない。

仕方なく、VisualBasic 2008 Expressをダウンロード・インストールすることに・・・

コンパイルしたスタンドアローンツールでSAXONで処理した結果と同じものが得られることを確認。

と、ここまでは、一段落。

次は、再配布可能で、XMIエキスポートができるUMLエディタを探さなくては・・・

UMLからSFL(その3)

またまた少し修正。
今回は、操作を変更。visibilityによって、制御入力・制御出力を切り替えていたが、privateはやはりprivateな操作としたいので、次のように修正。

• public操作: 制御入力端子
• protected操作: 制御出力端子
• private操作: proc

合わせて、procのスケルトンも生成するようにした。
自動生成したSFLファイルは、ブログに載せるには大きいので、IP ARCH, Inc.の方にアップロードしたので、参照するには、

このリンク(mm.sfl)をクリックしてほしい。

UMLからSFLへの変換(その2)

UMLからSFLへの変換だが、もう少しUMLでのLSI記述の方法を調整し、図の形にした。

これに加えて、制御出力端子のinstr_argを自動生成させる。

変換結果の長いリストを再度載せるのは、割愛するが、今回の図の方が、ハード屋には違和感がないような気がする。

ＵＭＬからSFLへの変換(XSLT編)

小型CPU m8のUML図から、SFLのスケルトンに変換するXSLTスタイルシートを作成した。

図のUMLを自動変換して得られたSFLコードを↓に示す。
データタイプのbitがちと気持ち悪いのだけれど、それ以外は、まぁまぁ、納得できそうなUIではないかと思う。

もちろん、スケルトンができて終りではなく、これが始まりなので、コアコードをどのように開発するかを検討する必要がある。OMGのMDAのように、基本クラスに演算子を全部定義するようなマネはしたくなく、もう少し賢い方法を模索中。

declare m8 {
		  instrin ack;
		  instrout mr;
		  instrout mw;
		input datain<8>;
		output addr<8>;
		output datao<8>;
	instr_arg ack ( datain );
		}

declare alu8 {
		  instrin exe;
		input op<4>;
		input inA<8>;
		input inB<8>;
		output result<8>;
	instr_arg exe ( op,inA,inB );
		}

module m8 {
		  instrin ack;
		  instrout mr;
		  instrout mw;
		input datain<8>;
		output addr<8>;
		output datao<8>;
		 reg_wr acc<8>;
		alu8 alu;
		 reg_wr pc<8>;
	instr_arg mr ( addr );
	instr_arg mw ( addr,datao );
		{
		/* common operations */
		}

		  instruct ack {
			/* instrin operation */
		}
		}

module alu8 {
		  instrin exe;
		input op<4>;
		input inA<8>;
		input inB<8>;
		output result<8>;
		{
		/* common operations */
		}
		  instruct exe {
			/* instrin operation */
		}
		}

XSLTが面白い

単なるスタイルシートだと思っていたが、けっこうプログラマブルで、今まで、DOMやSAXでゴリゴリやっていたものの多くがXSLTで書けそうな雰囲気。

まだシリアライズの部分をどうコントロールできるのか、今一つ理解が進んでいないが、これをきちんとコントロールできたら、DOMで書いている今のアプリをXSLTに置き換えようかなと思っている。
(ただ、XSLTだと、独立したアプリにはならず、必ずXSLTプロセッサと一緒に使うことになるのが、気に入らないので、最終的にどうするかは微妙だ)

XSLTプロセッサと合せてコンパイルして独立アプリケーションにできる手段があるといいのだけれど、探せばあるのか？

それにしても、XSLTを書くためのフロントエンドの言語があった方がよさそうな記述性の悪さは何とかならないかな？

W3Cの規格書は例によって読めたものじゃないので、
XSLT: Mastering XML Transformations
のようなものを参考にしていこう。

実は、1.0のXSLTだったら、ポケットリファレンスが安い。

Xslt 1.0 Pocket Reference (Pocket Reference (O'Reilly))

FPGA Startup記事追加

スペースインベーダを動かした、MIDWAY GAME PLATFORM互換システムをFPGA Startupの番外編記事として追加した。

FPGAの合成に必要な全論理ファイルもダウンロード可能であるが、当然ながら、タイトー社の著作物であるROMイメージはパッケージから除外している。

オリジナルゲームを作成したり、ゲームの研究目的に使ってもらいたい。

midway.memにプログラムを16進形式でダンプしたものを入れて、他のファイルと共に合成すると、自動的にbitファイルに設定できる(最大8kB)。

懸案となっていたサウンドであるが、いずれにせよボード上に音を出せるコネクタがないので、今回は割愛した。

説明のスライドは、海外向けのままなので、(下手糞な)英語である。

ETロボコン NXT版公式環境になる・・・

かもしれない、nxtOSEK v209を使うように、LiveCygwin-nxtOSEKをアップデートした。

209ではC++クラスライブラリが強化されたそうだ。