字句解析としてのLex

コンパイラの本に必ずといっていいほど取り上げられる、字句解析プログラムLex、sfl2vlもこれを使って字句解析をしているけれど、実はLexは、かなりレベルの低い字句解析しかできない。具体的には、これは、モードをもったパターンマッチングしかできないといっても過言ではない。
sfl2vlでは、状況に応じて、Lexのモードでは対応できない部分をCのコードで文法を解析しつつ、字句解析のモードを決定するという回りくどいやり方をしている。

もともと、C言語では、すべての識別子はコンパイル単位で一意でなくてはならないという縛りがあったので、Lexのやり方で十分だったが、もう少し複雑な構造を持つ言語では、Lexの仕組みだけでは無理がある。

今回、ちょっと困ったのが、名前付きの引数渡しをサポートするときに、サブモジュールの制御入力起動において、例えば、
alu.exec(fun=ADD, inA=PC, inB=0x01)
というような記述をしたいという場合、ここで、名前は、サブモジュール内の名前を用いる必要があり、シンボルテーブルはサブモジュールのものを参照するのが正当だが、Lexで状況に応じてシンボルテーブルを切り替えるには、文法を深く解析することになり、あまりストレートではない。

Lex側で、全部のシンボルを文脈を無視して、単にシンボルとして扱い、それをYaccに渡すと、こんどは、Yaccが一つ先のトークンまでしか見ないという制限があって、文法の曖昧さが解消できない。

やはり、Lexを捨てて、独自に字句解析した方が素直な気がするが。。毎回、この手の問題にぶつかるたびに思うが、なかなか踏み切れないものだ。

とりあえず、名前付き引数はサブモジュールの呼び出しでは使えないことにしておく。 ;-d

【不定期連載】 UMLで16ビットCPUを作ろう：第6回 メモリリクエスト制御

EUからBIUへのメモリ要求は、メモリアラインに関係なく、命令の必要とする幅でバイト読み出しだったりワード読み出しだったりする。

これ自体は、アラインフリーであるx86では当然であるが、物理メモリにアクセスするときには、問題なのだ。たとえば奇数番地からワードで読むというのは一度にはできない。

そこで、EUからのリクエストを物理メモリ要求に変換するリクエスト制御をBIUのサブモジュールとして作る。ついでながら、ここでは、メモリ要求を発生させるので、BIU内のすべてのメモリバストランザクションをここに集中させて、アービトレーションの役割を負わせよう。

つまり、バストランザクションとして必要となる、メモリ（EUの命令アクセスと、BIUの命令プリフェッチ）ならびに、IO要求を、ここで取りまとめて、物理バスにコマンドを出す。

もちろん、サブモジュールから直接ピンが出るのではないので、上位のモジュールを仲介する必要がある。そのため、本来ならば、サブモジュールに引っ張ってこなくてもよい信号まで入っているけれど、モジュールの切り分けは仮想的なものであり、物理的なピン数の制約条件が生まれるわけではないので、読みやすさ優先としておく。

---

UML的には、もしかしたら、関連をうまく使うと、直接ピンを外部にインタフェースする表現方法を取れるかもしれないが、まだ整理し切れていないので、これは、後日の検討としておく。

【不定期連載】 UMLで16ビットCPUを作ろう：第5回 命令プリフェッチキュー

分岐命令でフラッシュする命令プリフェッチキューを、BIUのサブモジュールとして作成する。なるべく細かな機能単位でモジュール化しておいたほうが、設計の見通しは良くなる（はず）。

プリフェッチ用のIPは、通常のIPと別として、プリフェッチモジュールからメモリのリクエストを上げるようにする。

BIUが奇数番地のIPを持つときには、プリフェッチは初回はバイト読み出しで、2回目以降をワード読み出しとする。

プリフェッチモジュールはデータが用意できたら、QueueReadyとともに、先頭データを出力し、データを受け渡すごとに、1バイトずつ新しいデータに更新する。

【不定期連載】 UMLで16ビットCPUを作ろう：第4回 BIUのインタフェース検討

EUとBIUの機能を考えつつ、BIUとCPUコアのインタフェースを検討する。

一番、大きな検討課題は、x86では、ワードアクセスを奇数番地からスタートでき、その場合、２つのメモリトランザクションを起こして、まとめた16ビットのワードデータを命令が利用できる部分だ。このEUからは、単にワードかバイトの要求として、この部分をBIUで吸収する。こうしておけば、後日、BIUのマイナーチェンジで、8ビットバスオンリーのCPUも作成できる。

もう一つの検討課題は、命令プリフェッチである。ここに分岐予測を入れたくなるのであるが、まぁ、それは、後でも実装できるので、とりあえずは、CPUコアは、命令キューから1バイトずつ命令を取り出すように作っておく。

CPUコア側のつくりとしては、命令単位で取り出せた方が楽なのだけれど、BIUに命令解読はさせたくないので、一番単純に作っておこう。

という、概略の戦略を考えると、BIUのインタフェースは、図のようになる。

もちろん、実装方式は人によって違って当然であり、単なる例に過ぎないし、深く検討したわけではないので、抜けや考え落ちがあるかもしれないのは、重々承知である。

ところで、ArgoUMLは、とても便利なのだが、属性や操作を一度描いたら、その順序を交換する方法が見つからない。（ないのか？）後からきれいに整理することができた方が、設計図を描くツールとしては便利なのだが・・

【不定期連載】 UMLで16ビットCPUを作ろう：第3回 x86向け、拡張

x86は、通常のメモリIOの他に、IOアドレス空間を持つので、16bitのクラスを継承して、x86のクラスを作る。また、ソフトウェアから見えるレジスタもBIUとEUに分離して配置しよう。まだ、BIUとEUとのインタフェース仕様は決めていないので、ブランクのままだが、今後、詰めていくことにしよう。

今のクラス図は、ia16bitCPUの部分には、属性が何もなく、継承した属性しか作られないので、この形でもSFLに変換できるように、UML2SFLを多少変更。0.2.4からの対応

【不定期連載】 UMLで16ビットCPUを作ろう：第2回 入出力仕様の続き

メモリと割り込み、停止要求のトランザクションを、シーケンス図に描いてみる。が、シーケンス図は、今回初めて描くのと、ArgoUMLでの描き方がよく分からないので、シーケンス図もどきと言っておこう。

関係ないが、UML2SFLの通常のセットアップ版のインストールキットをWEBにおいた。.NETの発行は、Document and Settingsの下の奥の方にあって、分かりにくいのと、アイコンがうまく表示されないので、独自のセットアッププロジェクトを作った。

ただ、.NET Frameworkの自動ダウンロードには対応していないので、.NET Frameworkをインストール済みの人専用である。

【不定期連載】 UMLで16ビットCPUを作ろう：第1回 入出力仕様

時間があるときだけ、少しずつ進める不定期連載第1回です。
UML2SFLを用いる例題として、16ビットCPUを作ってみることにします。


第1回は、入出力仕様を決めます。アドレスビット数以外はアーキテクチャにあまり依存しない汎用的な仕様にしておきます。（アドレスは、少し多めにビット数を取っているので、多くの16ビットアーキテクチャはこの枠組みでできるのでは？）

5分くらいで、ぱっと作ったので、抜けがあるかもしれませんが・・

UMLのクラス図だと、タイミングを記述できないのが難点ですね。タイミングチャートで表すのがまっとうかと思いますが、残念ながらArgoUMLにはタイミングチャートはないので、各トランザクションの概略はシーケンスチャートで表しましょうか・・。

最近のメモリはいろいろなインタフェースのものがあって、小規模のFPGA内蔵用CPUがメモリコントローラを内蔵するのは得策ではないので、メモリコントローラへの接続に便利なようにインタフェース仕様を決めていきます。

具体的には、メモリトランザクションは、1クロックのコマンド信号にデータ・アドレスを載せて送出することにします。

一方、割り込みや、停止要求は、要求元が取り下げたり、複数の要求元から発生する可能性があるので、レベルセンシティブな信号とするのが良い方法です。

uml2sfl : 汎化の続き

汎化で関係させた親のモジュールが合成されるのは、気持ち悪いので、親のクラスをAbstractにしておけば、合成対象外とするように変更。

UMLのAbstractクラスは、クラス名を斜体で表示することになっているのだが、日本人にはなじみにくい気がする・・

ついでに、モジュールに宣言されるインスタンス類が、親のものか、自分が宣言したものかを区別できるようにコメントをつける。

uml2sfl v0.2.2からの対応。

図を変換すると、次のものができる。

// UML2SFL converter  Copyright (c) 2009 IP ARCH, Inc. All rights reserved.
// xmi  --- version 1.2 --- 
declare child {
	
	// -- grand  --
	input aa<4>;
	
}

module child {
	
	// -- grand  --
	input aa<4>;
	
	// -- parent  --
	reg atr<8>;
	
	// -- child  --
	reg atr_c<4>;
	


	/* common operations */
	{
	}

	
}

UMLの汎化をサポートしてみる(uml2sfl)

UMLの汎化は、クラスの継承とみなせる。

だけど、ハードウェアで継承をサポートするものは少ない（というか、ダイナミックに継承を行えるハードはない）ので、あまり積極的にサポートしていなかった。

ただ、CPUのように外部仕様は同じでも、内部構成をいろいろと実験的に変えられるような設計をするときに、毎回、共通のピンの記述をするのはばかばかしいので、汎化をサポートし、上位クラスのリソース継承をすることにした。

uml2sfl v0.2.0からのサポート

図のUMLをSFLに変換した結果は、ここ。

とりあえず、一応それらしく動いている。

uml 2 sfl 初期値の設定

UML2SFL V0.1.3から、レジスタの初期値を設定できるようにした。
図のクラス図から、下記のような初期化宣言つきのregを作成する。

module regtest {
reg regx<8> = 0x55;