ttth @ ウィキ http://w.atwiki.jp/ttth/ ttth @ ウィキ ja 2009-06-07T11:00:22+09:00 1244340022 buyobuyon https://w.atwiki.jp/ttth/pages/7.html *buyobuyonのぺぇじ コンパイラ…、 ひどく汚いソースなので、不特定多数の人に見られるのは避けたい…、 とはいえアップしないわけにもいかない…。 というわけで、メンバーのみ閲覧可能のページを作成して、そちらにアップしました。 コンパイラのダウンロードは[[こちら>compiler隠しページ]]から その他のプログラムのダウンロードは[[こちら>buyobuyon サブページ]]から **残り作業 ***チェック/デバッグ ・parse error時の過不足ないメモリ解放 ***最適化 ・restore(imm in 変数)→mov(imm) ・定数レジスタの設置 ・遅延スロットとSTOREDの直後のスロットを埋める ・その他 **進行状況 ***4/30(Mo) rs232c経由でレイトレ完動しました！ 細かいところを修正し、BAUDを下げてみたら動きました。 クロック周波数を25MHzにしていることもあり、cosなどの計算で時間がかかり、 入力バッファがあふれてしまっていたようです。 バッファのサイズを今の4倍くらいにできれば、BAUDはデフォルトの値で大丈夫なのでしょうが、 さすがにそこまで余裕はなさそうでしたので…。 さすがにフローコントロール機能をつける気力は無かったので、BAUDを下げる方法をとりました。 - とりあえず、お疲れ様でした。&br()rs232c通信用に作成したファイルを&br()com_diff.ZIPにまとめてあげておきました。 -- buyobuyon (2007-05-01 19:10:13) - おつかれさまです！ -- harry (2007-05-02 12:42:35) - お疲れ様です！＆ありがとうございました！ -- yastak (2007-05-02 23:05:14) - 結局、その後、確実に動作するようになって、&br()菅原先生にも見ていただき、機材もその日のうちに返却しました。&br()&br()あと、拡張基盤(と箱)は回収されなかったので、いま預かっているのですが、&br()どなたか心優しい方、もらってください。 -- buyobuyon (2007-05-04 19:43:45) #comment(vsize=5,nsize=20,size=40) ***4/28(Sa) ええと、いくらか修正した後、実機でrs232c経由のechoが動きました。 その後、rs323cは下のビットから順に流す(リトルエンディアンって言って良いのかな？)ことに気づき、修正。 echoだと、2回ひっくり返って元に戻ってしまうので、この問題が見える形で現れないのですね…。 まだCPUへの組み込みに成功していませんので、レイトレ実行まではもう少しかかりそうです。 ***4/17(Tu) rs232cコントローラ修正中。 とりあえず、バッファへの同時アクセス問題が解消されていなかったので、修正。 それから、echoにバグ発見。STATEが0のときでBUSYが1のときに、 START信号を0にしていないので、ずっと書き込み要求が出ることになるはず。 - ちなみに、先日、テストベンチを書いてみて、&br()フリーのシミュレータで実行してみたら、&br()簡単なテストは通りました。 -- buyobuyon (2007-04-17 14:19:43) - >バッファへの同時アクセス問題&br()&br()あ、忘れてました…。申し訳ないですm(_ _)m&br() -- yastak (2007-04-17 19:00:09) - すぐ直せたので、大丈夫ですよ。&br()滅多に起こらない問題なので放置してしまっても良かったのですが…。 -- buyobuyon (2007-04-18 12:20:48) - もう一つバグを修正したらシミュレータでechoが動くようになりました。&br()&br()readの方の問題だったようです。&br()バッファから値が出てくるのを待つためのステートが抜けていたようです。&br()&br()むしろ、自分で書いたテストベンチはなぜ正しく動いているように見えたのだろう…。 -- buyobuyon (2007-04-18 16:07:27) - ・rs323cは下のビットから順に流す。&br()・echoで、write命令を発行した後、もう1クロック待つ -- buyobuyon (2007-04-27 22:40:23) ***3/19(Mo) - tsuyさ～ん、math.sを眺めてみたのですが、何か間違っていますかね？&br()確か、atan内でのlatan_loop呼び出しがインライン展開された部分に&br()変なdivが入るという話だったと思うのですが。&br()手元にあったmath.mlを新たにコンパイルしたものなので、&br()見ているmath.sそのものが違うかもしれないのですが、特に変な部分は見つからず…。 (長いので、中略) - すみません、返信が遅くなってしまいました。&br()&br()インライン展開されているということに気付いていませんでした。&br()math.mlも多分同じ定義のようですし、つじつまもあってますし、問題ないようですね。&br()早とちりというか、理解不足でお手数をおかけしました。すみません。 -- tsuy (2007-04-03 00:27:58) - いえいえ、インライン展開を実装したはずの私も、&br()最初に見たときには混乱しましたので。&br()中途半端な回数だけインライン展開したのが悪かったのかもしれませんね。 -- buyobuyon (2007-04-03 16:12:03) ***3/18(Su) ちょびちょびとコンパイラのデバッグ中。 一ヶ所、呼び出す関数を間違えていたもので、 関数適用の構造がある場合にメモリリークを生じていたようです。 ↑の問題を解決した現時点で、メモリリークは生じなさそうな感じ…。 malloc/freeの際に、間に関数を挟み、 確保したが解放していない領域の先頭アドレスを2分木に保存するようにしてみたところ、 fibやmin-rtのコンパイル終了時にはこの2分木は空でした。 もちろん他のプログラムではメモリリークを生じるかもしれませんが…。 この2分木に保存する処理を追加したときに極端に遅くなったところを見ると、 かなりの回数mallocしていたと言うことですね…。 - あぁ…、考えてみるとこの場合は、平衡木にしないなら&br()むしろリストにしておいた方が良かったかもしれませんね…。 -- buyobuyon (2007-03-18 17:51:22) - 忘れていましたが、parse errorの時にはメモリリークが生じてしまいますね…。 -- buyobuyon (2007-03-18 18:14:00) ***3/17(Sa) 皆さん、どうもお疲れ様でした。 とりあえず完動して良かったですね。 ええと、一時的にコンパイラをページから削除してあります。 実演の日までには形を変えて戻しておくつもりですが、 もしそれまでに必要なら言ってください。 ***3/14(We) Part.3 ええと、(inv (inv x))をxに、(1.0 *. x)をxに変換する最適化を実装しました。 fdiv, fsqrtの変換方法から言って、結構効果があるはずだと思ったのですが、 プログラム全体におけるfdiv, fsqrtの割合が少ないのか、あまり良い効果は得られませんでした。 実際に適用してみて、命令数が0.2%減ったくらい…。 あ、でも浮動小数点数演算ライブラリの方に適用するとある程度は効果があるかもしれません。 そういえば、math.s、fdivの符号部分に問題のある古いバージョンを使用してコンパイルしたので、 結構問題があるかもしれません。 というか、なぜそれでもレイトレがあれだけ動いているのでしょう…。 - inline展開の程度を中途半端にしたら、&br()saveの挿入部にバグが現れました。 -- buyobuyon (2007-03-15 04:13:43) - 修正しました。一つフラグを見落としていたみたいです。 -- buyobuyon (2007-03-15 04:25:40) - 違う…、何か別の要因のようです。&br()inline=256, opt=1とした時にエラーが出る…、&br()まぁ最悪そのパラメータを使わなければ良いわけですけど…。 -- buyobuyon (2007-03-15 04:33:29) - 今度こそ直りました。&br()restore+mov→restoreという変換で、&br()ちょっとしたミスをしました。 -- buyobuyon (2007-03-15 05:12:36) - >tsuyさん&br()そういえば、定数畳み込みで、(inv 定数)が&br()定数に変換されるので、今のコンパイラなら&br()/. 2.0 → *. 0.5 が自動で行われますね…。&br()すみません、気づくのが遅くて。 -- buyobuyon (2007-03-15 05:17:17) - とりあえず、&br()ループを9に、int_of_floatを切り捨てに、&br()新たなコンパイラでコンパイル、&br()という3つの変更を加えたところ、&br()&br()(104, 101) : (0, 41, 52) <--> (0, 39, 52)&br()&br()この1点だけ、色が2(以上)違う点がある、という状況になりました。 -- buyobuyon (2007-03-15 07:19:38) ***3/14(We) Part.2 ええと、朝の時点では、 総命令数：4,761,859,127 NOP数：713,139,256 でしたが、今では、 総命令数：2,293,078,714 NOP数：302,635,866 となりました…。 最適化って重要ですね…。 一応、今日実装したのは、β簡約・インライン展開・定数畳み込み・11bit即値演算の使用です。 不要定義除去は仮想マシンコード生成後(11bit即値演算への変換の直後)に行っているので、 これでMinCamlに実装されている最適化はほとんど網羅されたはずです。 (if not x then A else B → if x then B else A は未実装) SPとHPを見た感じでは、メモリはまだまだ余っていますが、既にこれ以上インライン展開しても 効果がなくなるところまでは展開したので、後は…、ifの展開ですかね…。 ちょっとすぐには実装できないような気がしますが…。 とりあえず、あとは、余裕があれば、余っているレジスタを存分に利用して、 定数のmovを減らしたいですね。何かアセンブリコードを見たら、15%くらいが movだったもので…。ちなみにNOPも15%くらいを占めています。 NOPは簡単に取り外せるものだけ何とかしますね。 ***3/14(We) Part.1 シミュレータで、総命令数などを調べたところ、 総命令数：4,761,859,127 NOP数：713,139,256 だそうです…。 最適化なしとはいえ、どうなのでしょう…。 ちなみに、スタックポインタは最小でfffa3、ヒープポインタは最大で1eb86ということで、 インライン展開などの余地は十分に残されています。 あと、レジスタは128個中、使用しているのが確か20個未満だったと思うので、 まぁ思う存分使えます。 - FEQ演算(コンパイラ内部で変換している)に問題があることに気づき、修正。&br()FSUBで2数の差ととり、cmpeqiで0と比較することにした。&br()FSUBは答えが0なら0x00000000Uを返すはずなのでこれでOKのはず…。 -- buyobuyon (2007-03-14 18:48:28) - cmpeqiでなくて、cmpeqでr0と比較でもOKですね。&br()後者にします。 -- buyobuyon (2007-03-14 18:49:43) - math.sを見ていて思ったのですが、ひょっとして関数ur_tan_loop&br()のループ回数が19回のままだったりします？&br()一番最初にあげたOCamlライブラリファイルのループ回数が19回で、&br()その後精度テストで精度が保証される最小の回数が9回であることが分かりました。&br()ということで、テストファイルとともに訂正したファイルを上げたつもりでしたが、&br()分かりにくかったようですみません。&br()OCamlでのループ回数を定めた変数large_nはur_tan_loopでしか使ってないので、&br()math.sの24行目、&br()mov r13, 19;&br()を&br()mov r13, 9;&br()にすれば修正できるかと思います。&br()勘違いorテストは100万パターンでしか行っていないので実はループ回数が足りない&br()とかだったらすみません -- tsuy (2007-03-14 19:56:36) - math.sについてですが、もとのOCaml文法で書いたライブラリで&br()定数で割る箇所が多いのですが、例えばx/.2.0とするよりもx*.0.5と&br()する方がいいですよね。ひょっとするとコンパイラの最適化でなんとか&br()なるのかもしれませんが、とりあえず書き換えてみます。 -- tsuy (2007-03-14 20:58:45) - 元のライブラリの関数ur_tanの2行目、int_of_floatがあるのですが、&br()これはmath.sの46行目のftoiのみに対応しているんですよね？&br()OCamlのint_of_floatは切捨て、ftoiは四捨五入なので、値が&br()変わってくる気がするのですが、どうなんでしょう。勘違いだったらすみません。 -- tsuy (2007-03-14 21:12:03) - すみません、上のほうの書き込み、19回なのはループ回数でなく&br()ループ用の変数ですね。 -- tsuy (2007-03-14 22:40:14) - ええと、ur_tan_loopの19の件は、&br()結局修正は必要ないということでしょうか？&br()ライブラリの方はあまり把握していないもので…。&br()&br()/. 2.0 → *. 0.5の件については…、お願いします。&br()ルール上コンパイラの最適化で書き換えるのはOKなのですが、&br()ちょっと今からだと対応しきれなさそうなので…。&br()&br()それから、int_of_float→ftoiとしています。&br()コンテストルールのint_of_floatの仕様も&br()四捨五入になっていますので…。&br()とすると、ftoiする前に0.5足したりしておいた&br()方が良いのですかね？ -- buyobuyon (2007-03-14 23:25:16) - ur_tan_loopの方は、単に言葉を間違えただけで、修正は必要です。&br()たびたびすみません。&br()ループ変数と定数の書き換えはすでに行い、tsuyの方に上げました。&br()&br()OCamlのint_of_floatを用いたライブラリでテストを通ったので、&br()やはりコンテストのライブラリは修正した方がいいかと思います。&br()四捨五入を切り捨てにするのだから0.5引くのですかね。&br()一応、上げたプログラムにその場合のコードをコメントでつけておきました。 -- tsuy (2007-03-15 00:23:31) - そうですか…。&br()今日コンパイラがいろいろと変化しましたので、&br()明日落ち着いたところで修正しますね。 -- buyobuyon (2007-03-15 00:53:34) - tsuyさん、ありがとうございます。&br()本格的な変更はあとにすることにして、&br()とりあえず試しに0.5引く処理を入れてみたのですが、&br()少し誤差が減ったようです。&br()r, g, bのいずれかが2以上違う点は&br()&br()(109, 98) : (0, 41, 75) <--> (0, 38, 71)&br()(104, 101) : (0, 41, 52) <--> (0, 39, 52)&br()&br()の2つになりました。&br()とりあえず、パラパラ漫画にしても&br()違いがわからない程度にはなっています。 -- buyobuyon (2007-03-15 01:10:42) - とりあえず、現時点での最新版の各プログラムをあげておきました。&br()&br()コンパイラとmath.hは今後変更する可能性がありますが、&br()それ以外は基本的にこのままになると思います。 -- buyobuyon (2007-03-15 02:44:46) ***3/13(Tu) ～Part.2～ レイトレを実行したら白い画像が…(画像削除済み)。何か間違えたらしいです。原因を探ってみますね。 - ↑の原因は判明しました。&br()finvsqrtを少し修正したら直りました。&br()直っても、やはり白い点3つはあいかわらずですね…。 -- buyobuyon (2007-03-13 16:49:07) - pika.sldで実行したところ、繰り上がりバグ修正前とは違って、&br()一応、正しい画像にノイズが入ったようなものが生成されました。&br()修正前は、そもそも形が違っていたので…。&br()&br()でも、今回修正したバグは頻繁には起こらないだろうと思っていたのですが、&br()修正してみたらこれだけ画像が変化したところを見ると、&br()残っている白い点やpika.sldのノイズも、気づいていない何らかのバグが&br()影響しているのかもしれません。&br()引き続き検証を続けます。 -- buyobuyon (2007-03-13 17:04:29) - とりあえず、問題はFADD/FSUBのようです。&br()FADD/FSUB以外のシミュレート関数を全てCライブラリ関数に置き換えても&br()ノイズが出ますが、逆にFADD/FSUBのみCライブラリ関数で置き換えると&br()(肉眼で観察できるような)ノイズは入りません。&br()&br()FADD/FSUBの中でも、符号が同じ値同士の加算が特に問題を引き起こしやすいようです。&br()が、符号が違う値の間での加算もわずかにノイズを発生させているようです…。 -- buyobuyon (2007-03-13 17:52:48) - 大変申し訳ありません。&br()白い点問題はFPUシミュレート関数のバグでした。&br()論理シフトの法を考慮せず、シフト量が32を超えた時には、&br()0になるものだと思いこんでいたもので、&br()指数部の差(32以上になることがある)だけシフトをするFADD/FSUB関数で&br()問題が生じていたようです。&br()&br()とりあえず、pika.sldで出力された画像には&br()肉眼で確認した範囲では問題はありませんでした。&br()&br()contest2.sldで出力された画像は、&br()境界の位置が1bitずれて、異なる色が表示されるドットが&br()1つありましたがその他には肉眼で確認できるOCaml画像との相違点は&br()ありませんでした。 -- buyobuyon (2007-03-13 21:11:48) - contest2.sldで、OCaml画像との差を調べてみました。&br()r, g, bいずれかの値が2以上違ったのは3点で、&br()(5, 32) : (31, 114, 120) <--> (82, 26, 38)&br()(7, 42) : (255, 255, 232) <--> (255, 8, 231)&br()(104, 101) : (0, 41, 52) <--> (0, 39, 52)&br()という状況でした。&br()最初の2つは色が違うのに違和感がないので、&br()たぶん境界が1ビットずれたことによる違いで、&br()最後の1つは誤差の蓄積で値が2ずれてしまったようです。&br()&br()どうなのでしょう…、もう少し何とかすべきなのでしょうかね？ -- buyobuyon (2007-03-13 22:01:15) #ref(contest2_0313.gif) ↑がうちの班のFPUの仕様に従った場合の生成画像、↓がOCamlでの生成画像 #ref(contest2_real.gif) ***3/13(Tu) ～Part.1～ 今日はまずDIV10をどうするかを決めたあと、シミュレート関数の変更を行って、 ひたすらシミュレータ上でのテストをし、白い点問題の解決策を探ります。 家で作業していますので、何かあったらここに書き込んでおいてください。 - pika.sldで実行すると、白い点とかいうレベルでなく、&br()全くうまくいかない…。&br()まだシミュレート関数が、FPUの繰り上がりバグ修正に&br()対応していないので、もしかしたらそのせいかもしれませんが&br()(そのせいであってほしいですが…)。&br()&br()とりあえず、いまさら焦っても仕方がないですし、&br()一つずつ問題を解決していきましょう。 -- buyobuyon (2007-03-13 07:34:51) - よし。print_intをインライン展開します。&br()これでdiv10不要。&br()コードは長くなるので御覚悟を。 -- buyobuyon (2007-03-13 07:52:57) - div10が無くなりました。&br()代わりにprint_intが100行近くなりました。 -- buyobuyon (2007-03-13 08:50:35) - FMULとITOFのシミュレート関数の修正終わり。 -- buyobuyon (2007-03-13 12:33:44) - 全シミュレート関数の修正終わり。&br()これから再びテストに入ります。 -- buyobuyon (2007-03-13 13:55:22) ***3/12(Mo) ～Part.2～ とりあえず、レイトレ実行に必要なプログラム達を挙げておきました。 結構量が多かったので、整理したりMakefileを作ったりするのに結構時間がかかりました。 一応、シミュレータに関してはまたすぐに次のバージョンをアップすると思います。 FPU部分とDIVに関する部分を変更する可能性があるもので。 - とりあえず、白い点は符号が等しい&br()2浮動小数点数の足し算が原因のようです。&br()いろいろためしているのですが、うまくいかず…。 -- buyobuyon (2007-03-12 16:31:10) - tsuyのページに変更したファイルをまとめた&br()fpu-sim-03-12.zipを上げておきました。 -- tsuy (2007-03-12 21:42:08) - ありがとうございます。&br()print_int中のDIV10問題が解決したら&br()シミュレート関数の変更に取りかかります。 -- buyobuyon (2007-03-13 07:06:19) ***3/12(Mo) ～Part.1～ とりあえず、FPUの変更箇所をFPUシミュレート関数に反映させて実行。 ノイズは相変わらずなので、もう一度FADD/FSUBを見直してみます。 あと、FLESSの仕様変更に伴いFISNEGを変更(-0.0が無くなったので)。 - ええと、コンパイラ・シミュレータ等、&br()調整のためにいろいろと少しずつ書き換えて、&br()レイトレを実行してみたら、出力されたファイルが&br()正しい形式のppmファイルでなくなってしまいました…。&br()&br()一番原因として可能性が高いのが、シミュレータのDIVを、&br()割る数が2のときと答えが0以上9以下のときにのみ正しい答えを返し、&br()そのほかの場合には0を返すようにしたことなのですが。&br()もしかしてどこかで想定外の使い方でDIVを使っているのかもしれません。&br()ちょっと検証してみます。&br()(たとえノイズがあっても)正常に動いたら、各プログラムをアップしますね。 -- buyobuyon (2007-03-12 09:40:44) - うん、やっぱりDIV結果の問題のようです。&br()滅多にDIVは使っていないのですが…。 -- buyobuyon (2007-03-12 09:44:39) - なんと、結果が10以上になる&quot;○÷10&quot;演算がありました…。&br()ええと…、乗算器が圧迫しているようですし、runtime.sを書き換えた方がはやいかな…。 -- buyobuyon (2007-03-12 09:48:17) - もう一声制約がかかれば実装できると思いますが…。&br()/10だとエラーがでてしまうので…。 -- yastak (2007-03-12 10:57:51) - そうですね…、ちょっと考えてみます。&br()とりあえず、10^nから10^(n-1)を生成する部分で&br()/10を使っているのですが、&br()そもそもprint_intの実装がいい加減なのでそちらを見直した方が良いかと思ってみたり。 -- buyobuyon (2007-03-12 11:05:26) ***3/11(Su) いえ、別に大した進展があったわけではないのですが、 今日になってからWiki自体にはいろいろと書き込んでいるのに、 自分のページを更新していなかったので、何となく書きこみを。 一応、FADD/FSUB/FMUL/FTOI/ITOF/FLESSの(現在の)実装を再現した関数の作成が終了しました。 ATOFとprint_floatはとりあえず諦めて、ライブラリ関数のatofとprintfを使用することにします (これらは実機で使う関数ではなくて演算ではなくてコンパイラなどが使うものだからOK)。 あとはちょっと厄介なFINVSQRTで終わりです。 - 一応、FPUシミュレート関数は全部作成し終えました。&br()fdivやfsqrtなどのFPU演算の組み合わせで表現される演算を&br()いくらか試してみたら、早速レイトレやってみますね。&br()実行に何分かかるかな…。 -- buyobuyon (2007-03-11 12:09:32) レイトレ試してみました。 何十分という単位で時間がかかると思っていたのですが、それほど遅くはなかったです。 ええと、一応ある程度正しい画像が出力されましたが、今度は肉眼でわかるノイズが3つほど入りました。 右上の球のてっぺんのあたりに白い点があるのが一番わかりやすいかと思います。 あと、その近くに少しぼやけてはいますがノイズっぽいのがあり、あと車(?)の黄緑色の部分にも 色違いの点が入っています。 とりあえず、sqrt(0)が正しく求められないなど、既に原因はわかっているものの、 デバッグには至っていないことがいくつかありますので、それらを調整してから また実行してみますね。 - とりあえず、sqrt(0)が問題では無かったようです。&br()う～ん…、では各関数を一つずつCのライブラリ関数で&br()置き換えてみてどの関数に問題があるか探ってみますね。 -- buyobuyon (2007-03-11 13:02:37) - FADDとFSUBとFMULの3つをライブラリ関数に置き換えたところ、&br()上記のノイズはなくなりました。&br()まぁ、よく使われる関数ですからね…。&br()もう少し様子を見てみますね。 -- buyobuyon (2007-03-11 13:36:45) - FADDとFSUBの2つを置き換えただけでもノイズが無くなりました。&br()原因は誤差か、バグか…。&br()さすがにつかれたので、そろそろ休みますね。 -- buyobuyon (2007-03-11 13:46:37) - シミュレート関数作成お疲れ様です。&br()昨晩ご指摘いただいた部分の書き換えと、&br()丸め方式の変更を行いました。&br()必要かどうかはわかりませんが、ソース中の&br()変更部分をメモしたchange.txtをtsuyのページ&br()に上げておきます。 -- tsuy (2007-03-11 23:43:46) - ありがとうございます、早速シミュレート関数の方も&br()書き換えておきます。 -- buyobuyon (2007-03-12 07:12:17) ***3/10(Sa) ええと、シミュレータ用に、うちの班のFPUと全く同じ出力を返す浮動小数点数演算関数を 作成しています。 コンパイラの最適化もやりたいのですが、 とりあえずはコンテストでレイトレを完動させることを優先しないといけませんし。 まぁ、これはこれで定数畳み込みで使えるので、最適化に関係ない訳でもないですし。 FPUの演算fadd/fsub/fmul/finvsqrt/fless/ftoi/itofに加えて、 せっかくなのでatof/fneg/print_floatあたり(これまでlexerではこれらのCライブラリ関数を 使用していたので、この機会に自作関数に置き換える)を実装したいと思っています。 間に合うのかどうかは不明…。 - まだ、fadd/fsubしか終わっていません。&br()とりあえず、この時点でシミュレータでレイトレ実行してみたところ、&br()結構時間がかかりました＆OCaml画像と色が違う点がかなり増えました。&br()r, g, bが1以上違う点を一応挙げておくと、&br()&br()(110, 19) : (187, 106, 255) <--> (155, 74, 228)&br()(111, 21) : (3, 170, 172) <--> (1, 169, 171)&br()(61, 25) : (27, 0, 0) <--> (21, 0, 0)&br()(55, 30) : (32, 0, 0) <--> (21, 0, 0)&br()(7, 32) : (119, 83, 84) <--> (100, 64, 65)&br()(49, 35) : (39, 0, 0) <--> (21, 0, 0)&br()(73, 43) : (255, 255, 69) <--> (242, 255, 32)&br()(59, 59) : (135, 202, 0) <--> (93, 138, 76)&br()(115, 64) : (203, 255, 0) <--> (129, 209, 0)&br()(84, 80) : (0, 144, 149) <--> (0, 132, 136)&br()(91, 83) : (252, 165, 168) <--> (250, 163, 166)&br()(104, 100) : (0, 52, 87) <--> (0, 51, 76)&br()(104, 101) : (0, 0, 0) <--> (0, 39, 52)&br()(30, 121) : (255, 0, 255) <--> (185, 0, 177)&br()(32, 122) : (189, 0, 181) <--> (185, 0, 177)&br()(33, 122) : (209, 250, 201) <--> (185, 226, 177)&br()(34, 122) : (255, 255, 255) <--> (185, 226, 177)&br()(37, 124) : (255, 30, 255) <--> (255, 15, 255)&br()(42, 125) : (255, 16, 255) <--> (255, 14, 255)&br()(50, 127) : (255, 19, 255) <--> (255, 12, 255)&br()&br()誤差で色がずれたと思われる点(rgb値の誤差小)がぼちぼち、&br()誤差で境界がずれたと思われる点(rgb値の誤差大)がたくさん、&br()といった感じでしょうか。&br()&br()一応、変な白い点が現れた、というようなことはなく、&br()肉眼で見た限りは正しい画像になっています。&br()&br()OCaml画像と自作画像とでパラパラ漫画すると、&br()違いがわかるのは1点だけで、車(?)と背景の境界が&br()1ドットずれるかずれないかの違いのようです。&br()&br()今後、他の演算も自作関数に置き換えたときに&br()どの程度誤差が増えるか気になりますね…。&br()やっぱり、FPUシミュレート関数を実装して、損はなさそうですね。&br()&br()あと問題は、全部置き換えたときに、シミュレータの速度がどれだけ下がるか…。&br()先ほど実装したFADDは、プライオリティエンコーダ部分だけで20命令くらい使うので、&br()かなり遅いです…。 -- buyobuyon (2007-03-10 23:49:55) ***3/8(Th) とりあえず昨日生成した画像は、それ自体を見ても画像に矛盾はないのですが、 正しい画像と比較すると画面中央右下部分の形が少し異なっていたので、 おそらくSLDファイル読み込み部分のバグだろうと思って眺めていたところ、 SLDファイルのlexerにバグ(負の浮動小数点数を正の値として読み込んでしまう)がありました。 修正後、新たに生成した画像が↓(削除済み)。 ちなみに、O'Camlで生成した画像が↓。 #ref(contest2_real.gif) まぁ、基本的にはOKですよね。あ、ちなみにどちらもcontest2.sldです。 一応差分をとってみたところ、ほとんどの点はrgb値の差が1以下(r, g, bそれぞれ1以下)で 済みましたが、3点だけ大きく違う点がありました。 (96, 33) : (21, 0, 0) <--> (1, 39, 64) (7, 42) : (255, 255, 232) <--> (255, 8, 231) (104, 101) : (0, 0, 0) <--> (0, 39, 52) どれもノイズというよりは、浮動小数点数演算の誤差によって、 境界が1ドットずれたために生じた違いのようなのですが(∵お隣以降の連続する点の色と一致する)、 こういうのはOKなのですかね？ ***3/8(Th) とりあえず肉眼で正常に見えるレイトレ画像を生成してもらうことを目標として、 いろいろ試行錯誤を重ねています。 SLDファイルをバイナリ形式に変換するプログラムが一番怪しいように思えたのですが、 今まで見たところではその部分には特に問題はなさそうですね。 - シミュレータのFPU部分(FPUの厳密な再現でなく、Cライブラリで代用したもの)のうち、&br()ftoiを実際のものと同じ正負対称の四捨五入型のものに変えたところ、&br()黒い部分は黒いままですが、一部消えていた模様が正しく表示されるようになりました。&br()ちなみに、invsqrtを精度が多少よいものに変えても目立った変化はありませんでした。&br()たぶん黒い部分に関しては、判定系の関数のバグが影響しているのだと思うのですが…。&br()引き続き調査を続けます。 -- buyobuyon (2007-03-08 22:23:11) - とりあえず、一つ気づいたことが。&br()&br()現在のfdivは引数が負の値の場合に問題が生じます。&br()(x /. y)→(x *. (1.0 /. y))&br()というのが現在の方針ですが、&br()(1.0 /. y)の求め方を(invsqrt (y *. y))としていたため、&br()(1.0 /. y)でなく(1.0 /. |y|)を求めてしまっていたようです。&br()&br()(sqrt x)を求める際にも上の方針で(1.0 /. x)を求めていますが、&br()こちらの場合は、x < 0の場合を考えなくて良いので問題は生じません。&br()&br()問題はどのように求めるように直せばよいかということですが、&br()効率の良い求め方がなかなか思い浮かばず…。 -- buyobuyon (2007-03-08 23:06:51) - ええと、invの求め方を修正したところ、&br()いきなり黒い部分が無くなって上のように(削除済み)なりました。&br()これであっているのかな？&br()&br()なお、先ほど述べたように、上の画像を生成したときには、&br()シミュレータのFPU部分はtsuy氏のFPUの挙動を厳密に再現したものでなく、&br()Cライブラリを適用したものを用いたので、&br()実際にはもっとノイズが入るかもしれません&br()(逆にもっときれいになるかもしれません)。 -- buyobuyon (2007-03-09 00:04:11) - 真ん中ちょっと右下部分、本来は裏側が見えるようですね。&br()何が悪いのだろう…。 -- buyobuyon (2007-03-09 00:15:32) - 昨日はどうもすみませんでしたm(_ _)m&br()&br()ぉお、それっぽい！&br()こちらもはやく実機動作確認をします～。&br()（これから学校に行きます） -- yastak (2007-03-09 09:35:33) ***3/7(We) とりあえず、[[tsuy]]さんの作成してくれたライブラリを自作コンパイラでコンパイルできる形に直し、 コンパイルして、シミュレータ上でのcos, sin, atan, floorの軽いテストを行ってみました。 ちゃんと動きましたのでご安心を。 ただ、現段階ではコンパイラが最適化処理をほとんどしてくれない上、 コンパイルしたものに対して特に手を加えていないので、効率はあまり良くないと思います。 あと1週間でどれだけ最適化処理を実装できるのやら…。 途中で、create_array関数を作成するのを忘れていることに気づき、 一応、実装し終えました。 その後、print_intに関して勘違いをしていたことに気づき (fwrite(&r, sizeof(int), 1, fp);ではなく、fprintf(fp, "%d", r);なのですね…)、 実装し直しているところです。 とりあえず、divとmulを役立てることができそうです。 - print_intでなく、print_uintにしたい…。&br()-(-2^31) = -2^31なのがちょっと嫌です…。&br()そもそもmin-rt実行時には負の値の出力はないはずなのに…。 -- buyobuyon (2007-03-07 19:30:38) - print_intは、ヘッダ書き込み時3回呼び出されるだけなので、&br()とりあえず、てきと～な実装にします。 -- buyobuyon (2007-03-07 20:46:30) - print_int、できました。&br()が、37行、div使いまくりのひどいコードです。 -- buyobuyon (2007-03-07 21:46:54) - ついに、コンパイラのバグ発見です。&br()&br()let rec compose f g =&br() let rec composed x = g (f x) in&br() composed in&br()let rec dbl x = x + x in&br()let rec inc x = x + 1 in&br()let rec dec x = x - 1 in&br()let h = compose inc (compose dbl dec) in&br()print_int (h 123)&br()&br()これを実行すると、123が出力されます。&br()これから検証してみますね。 -- buyobuyon (2007-03-07 22:31:36) - 末尾呼び出し最適化とレジスタ割り付けのバグのようです。&br()&br()リンクレジスタLRを汎用レジスタとして使用していて、&br()呼び出す関数のアドレスをLRに入れることがあるのですが、&br()それが末尾呼び出しだと、さらにそのあとで戻りアドレスをLRに書き込むので、&br()関数呼び出しが正しく行われないようですね。&br()&br()とりあえずレジスタも余っていることですし、&br()LRは原則として戻りアドレスを入れる以外の用途では使わないことにしますね。 -- buyobuyon (2007-03-07 22:53:07) - 関数呼び出し時に関数のアドレスをLRに入れておく場合に&br()問題が生じるので、その場合のみLRの使用を禁止することにしました。&br()&br()一応、この問題は解決しました。 -- buyobuyon (2007-03-07 23:32:55) - クロージャ変換にバグが。&br()関数の自由変数を見つける際に、&br()自分自身を内部で定義されたものとしてしまっていたために、&br()レジスタ割り付けの際にinternal errorが起きていました。&br()&br()それにしても、min-rtの実行には全く関係のないバグばかり見つかりますね…。 -- buyobuyon (2007-03-08 01:18:33) - あれからいろいろ試してはいるものの、新しいバグは発見されず…。&br()ちなみに、fib 40は102334155だそうです。 -- buyobuyon (2007-03-08 03:04:50) - SLDファイルをバイナリ化するプログラムを作成中。&br()完成したつもりだったのですが、ちょっとした勘違いがあって、&br()一からやり直しています。 -- buyobuyon (2007-03-08 03:48:24) - とりあえずこういう状況(画像削除済み)…、やばいっすね。 -- buyobuyon (2007-03-08 06:12:51) ***3/6(Tu) どうも、ただいま戻りました。 おかげさまで無事用事を済ましてくることができました。 ありがとうございます。 2日間何も作業をできなかったもので (その代わり、昼夜逆転していた生活のリズムが正常に戻りました！)、 明日からまた頑張っていきますので、よろしくお願いします。 - fibが引数30あたりで求まらなくなる件、原因がわかりました。&br()シミュレータのバグでもコンパイラのバグでも無かったようです。&br()バイナリコード(harryさんのアセンブラで作成したものではなく、私の手動変換で作成したもの)が&br()間違っていたようです。&br()スタックポインタSPの初期値が2^20なのに、&br()実行時にSPの値が2桁になったいたのを見た時点で気づくべきでした…。&br()&br()一応、fib 32も正しく求まったので、&br()他のプログラムも試してみて、うまくいったらmin-rtやってみますね。&br()tsuyさんのおかげで、floorもできたことですし。 -- buyobuyon (2007-03-07 01:30:39) ***3/3(Sa) おひな祭り、おめでとうございます。 コンパイラの方は、今はひたすら組み込み関数を実装しています。 - ええと、組み込むつもりの関数は組み込み終えました(入出力ライブラリはまだ)。&br()&br()xor/float_of_int/int_of_float/flessは&br()そのまま対応する命令を呼び出すだけで、その他は&br()&br()fiszero → rd := (rs AND 0x7f800000) = 0&br()fispos → rd := rs >. 0x00000000(+0.0)&br()fisneg → rd := rs <. 0x80000000(-0.0)&br()fabs → rd := rs AND 0x7fffffff&br()fhalf → rd := rs *. 0x3f000000(+0.5)&br()fneg → rd := r0 -. rs&br()fsqr → rd := rs *. rs&br()&br()という感じで実装しました。&br()fisnegに関しては、fless r1 +0.0ではなく&br()fless r1 -0.0として実装したのですが、どうですかね？&br()問題があれば前者に変えますが…&br()(むしろその方が0レジスタを利用できる点で都合が良い)。 -- buyobuyon (2007-03-04 04:38:12) - fiszeroなどのテストをしている最中にバグ発見。&br()バグとは言っても悪さはしないのですが、&br()仮想マシンコードでの不要定義除去の際に、&br()連鎖した不要定義があると一番後ろしか除去してくれません。&br()理由は明らかなので、一休みしてからなおします。 -- buyobuyon (2007-03-04 06:39:44) - 上記のバグをとりました。&br()&br()ついでに、無駄なmov(addi r2, r2, 0;みたいなもの)も&br()削除するようにしました。&br()おかげでfibが一行だけ短くなりましたが、再帰部ではなくて&br()再帰しない方の分岐の中のmovなので、あまり意味はないですね…。 -- buyobuyon (2007-03-04 08:53:03) - 外部変数やら入出力関数やらを使ったfibをシミュレータでテストをしてみました。&br()やっぱりfibの30あたりになると原因不明のエラーが出ますね。&br()スタックもヒープもあふれていないのですが…。&br()マシンコードにも特に問題はなさそうなのですが…。&br()&br()まあ、見ておきます。&br()今日はもう45:30なのでもう寝ます…。 -- buyobuyon (2007-03-04 21:38:52) #comment(vsize=5,nsize=20,size=40) ***3/1(Th) 3月に入ってしまった…。 とりあえず、適当ながらもコンパイラ係用選択課題を出して、 今のところダメ出しも来ていないので、再びコンパイラ制作に入ります。 まず、.word文を使用して、外部変数定義(globals.ml)の解析・コード生成機作りますね。 - とりあえず、globals.mlで定義された(外部)変数の型が、&br()コンパイラが推論した外部変数の型と一致するかどうか&br()チェックするのは省略しますね。 -- buyobuyon (2007-03-01 15:41:09) - とりあえず、外部変数関連の構文解析＆コード生成器が完成しました。&br()harryさん、.wordの実装、よろしくお願いします。 -- buyobuyon (2007-03-02 04:58:07) - お疲れさまです〜.wordを追加しました☆ -- harry (2007-03-02 09:00:14) - ありがとうございます。&br()&br()一応、リンカ(ただファイルを結合するだけ)と&br()プリプロセッサ(&quot;(*MINCAML*)&quot;で始まる行と&quot;open&quot;で始まる行を削除して、&br()プログラムの&quot;in 0&quot;を&quot;in ()&quot;に変えるだけ)が完成したので、&br()あとは、read_int関数などの挙動をアセンブリ言語で記述したものが完成すれば、&br()min-rtは動くはず…、正しく動くかどうかはわかりませんが…。 -- buyobuyon (2007-03-02 11:54:44) 続きは、[[buyobuyon中]]および[[buyobuyon古]]に。 2009-06-07T11:00:22+09:00 1244340022 yastak https://w.atwiki.jp/ttth/pages/6.html *　--- yastak --- とりあえず自分のページを作ってみました。 作業の進行・メモなど書いていこうと思います。 **予定概略 - レイトレ --USB通信　→　失敗…原因不明　→　通信自体はO.K.ぽい　→　完動12.5,25MHz --シリアル回路 - CPU --シリアルコントローラを組み込む - IO --rs232cのコントローラ作成　→　コード完了　→　コンパイルO.K. →　修正中　→　ModelSim用VHDL作成完了 **作業進行 ***2007.03.17 お疲れ様でした。 動作確認のためのアンケートよろしくお願いします。 私がいけないときになった場合に備えて、 トップページに必要なファイル群と使い方をまとめてあげておきました。 - rs232cのコントローラのソース(echo除く)を読んでみたのですが、&br()いくらか気になる点があります。&br()upload filesのところにアップされていたものを読んだので、&br()すでに修正済みかもしれませんが、一応気になった点を書き出しておきます。&br()全てserial.vhdに関するものです。&br()&br()・case STATE isの、when &quot;0000&quot;のところで、読み込み指令が来たときには、&quot;1111&quot;でなく&quot;1110&quot;ステートに移行すべきなのでは？&br()&br()・case STATE isの、when &quot;1011&quot;のところで、CLKCNTW = CLKSのときには、CLKCNTでなくCLKCNTWを0にすべきなのでは？&br()&br()・何カ所かRCNTやCNTが「256より大きければ」という条件文がありますが、「256以上であれば」の間違いでは？&br()&br()・非常に低い確率で、バッファへ書き込み要求と読み込み要求が同時に入ると思うのですが、その場合どちらかの要求がかき消されてしまうのでは？&br()&br()あと、そもそも、バッファのサイズって256byteで足りますかね？contest.sldのデータ全てを入れるとなると数KBくらいになりますけど…。シリアルは遅いから、バッファがあふれる前に読み出されるということでしょうか？ -- buyobuyon (2007-04-02 22:30:13) - 修正版をあげます！ -- yastak (2007-04-06 12:42:20) - う～ん…、とりあえず何も変更を加えない状態で、レイトレを実機で動かそうとしているのですが、&br()うまく動かすことができません…。何か心あたりありませんか？&br()sldppm.binは正常に動作したのですが、min-rt.binを実行すると、&br()PPMのヘッダ書き込み時に不明な文字'?'が送られてきてしまい、&br()そこでcserverの実行がストップしてしまいます…。&br()確かそんなエラーが以前にも生じたと思うのですが…。cpu0316.zipが最新版ではないということでしょうか？&br()何か25MHz版になっていないような気がするのですが…。&br()それとも私がどこか設定でミスをしているのですかね？&br()もしよろしければ、最終的にレイトレが動いたときのバージョンのVHDファイル、UCFファイルをまとめたものを&br()あげていただけるとうれしいのですが…。 -- buyobuyon (2007-04-17 18:20:04) - あ、おそらく最新版でない気がします…&br()動かすだけなら、TOPページにbitファイルだけ置いてあります。&br()最新版のファイルもこのページにあげますね！ -- yastak (2007-04-17 18:51:40) - CPU0417.lzhです。.lzhで大丈夫ですか？&br()余計なファイルも入っていますが、（.bakとか）&br()ご容赦くださいー！&br()&br()その他不要ファイルは、&br()mrsrams.vhd(mrsram.vhdは必要)&br()*_old.vhd&br()usbword.vhd&br()cpu_sim.vhd（シミュレーション時に使用）&br()imusb.vhd&br()以下rs232c用に準備していたファイル&br()（途中でコントローラに集中したので多分未完…）&br()cputopcom.vhd&br()cpucom.ucf -- yastak (2007-04-17 18:58:32) - 助かります。&br()すでにできているものをただ実機で動かすだけでも一苦労で、&br()この大変な作業を全てyastakさんに任せっきりにしていたのだなとつくづく思いました。&br()本当にありがとうございます。 -- buyobuyon (2007-04-18 12:19:18) - いやいや、作業量はみんなに比べてそんなに多くなかったと思いますよ！&br()こちらこそ仕事が遅い中見守ってくれて（？）ありがとうです(>_<) -- yastak (2007-04-21 00:20:21) #comment(vsize=2,nsize=20,size=40) ***2007.03.16 13:25 発表中ですが。 とりあえずModelSim用VHDL作成が完了してしまいました。 ModelSimが動かせないのでストール…。 ***2007.03.16 0:34 本日はお疲れ様でした。 とりあえず、ALUのWarningを見てみたところ、shiftをなくすとひとつ怪しげなWarningが消えることが判明しました。 コメントアウトして大丈夫ですかね？ だめなようなら修正を試みますー。 - 上記のWarningを1つ消すことに成功しましたー。&br()（それに意味があったかどうかは微妙です…） -- yastak (2007-03-16 01:03:04) ***2007.03.15 22:52 進捗： CPU…FPUのタイミングは良いらしい。 一部命令にタイミングなどの不備あり？→コード検討・明日テスト OUT命令はどうやら正しく動作している模様。 USBserverでは抽象画が送信されてきた… rs232cコントローラ…まずCPUかなぁと。 とりあえずecho用ファイルが書きあがっていて、コンパイルも通っているが 反応なし。原因不明…。 間に合うのかも不明。 ***2007.03.15 06:44 min-rtの[[harry]]のアセンブリが出力するようなファイルが必要になっています。 ModelSimで動かすためです。 アセンブリコードか1/0テキストのコードファイルをくださいm(_ _)m sldppm.binは、実行したもののデータが帰ってこない状況… やっぱりoutに問題がある気がします…。 SRAMからデータ読み出す回路を入れた状態でサーバを起動すると言うミスをしました。 なんだかデータを読んでいます…ｗ ちょっと休憩させてくださいー。3時間もしたら戻ってくる予定。 - buyobuyon氏のコメントと入れ違いでした。&br()&br()えと、メモリの値を比べると、&br()書いてある番地はO.K.で、&br()最初のint,floatの個数はあってました。&br()&br()ですが、具体的なint,floatの値が全然違って、&br()書き込まれた値は何故か数え上げた値になっていました。&br()（intの書かれる最初の番地 0x00000000,その次0x00000001,0x00000002,...）&br()floatも同様です…。&br()ここにも何かおかしなことが…orz -- yastak (2007-03-15 07:02:17) - そんなわけで、勝手ながら休憩します。&br()基盤等は出しっぱなしで、電源等はきっていきます。&br()拡張基盤も取り出し済みですー。&br()&br()では、後ほど！&br()色々仕事お願いしておいて恐縮ですが、&br()buyobuyon氏も休憩してください… -- yastak (2007-03-15 07:05:49) - 一応、min-rtの最新版アセンブリコードmin-rt02.sと&br()harry形式のバイナリmin-rt02.binを載せておきました。&br()というわけで、私も休みます。&br()お昼すぎに、そちらにむかうと思いますので。 -- buyobuyon (2007-03-15 07:26:54) - ありがとうございますー！&br()3時間で戻ってくると言いつつ、2時間over…。&br()寝過ごしましたorz -- yastak (2007-03-15 12:29:30) - 私のページのところにmin-rt02.sをアセンブラに入力して&br()できたコードファイル（new-code.txt)とアセンブリコード&br()のテキストファイル(new-out.txt)をアップしました。&br()new-out.txtとbuyobuyon氏のmin-rt02.binが一致&br()したので、恐らく大丈夫だと思います。 -- はりー (2007-03-15 12:42:18) ***2007.03.15 05:56 rs232cはコンパイルに失敗しています。 ピンが認識されていないみたいです。 拡張基盤をつないでいないからだと思います。 harry氏からの返事がきてからつなぐ気なので…。 （自分で通電テストはしないつもりです。回路よくわかってないので不安なのです。） 擬似USB作りました。 最初にバッファにデータを全部書き込んでおいて、 読み出し命令があったら順番に出していく、というもの。 書き込み命令は特になにもしない。（波形を観察すればいいので…） sldを01のテキスト列に書き換えるプログラムとかってありますかねぇ。 1行に8文字（1byte分）が書かれている、感じで。 因みに[[buyobuyon]]サブページのプログラムは、 yaccがなかったらしくコンパイルに失敗…。 MINGW対応yaccってあるんですかねぇ。yaccにMINGW対応も何もないんですか？ - とりあえず、SLD(バイナリ)を読み取り、&br()青と緑のグラデーションっぽい画像をppm形式で出力するプログラムができましたので、&br()このページに載せます。 -- buyobuyon (2007-03-15 06:06:43) - 審判サーバをつけた状態で、sldppm.binを実機で動かしてみてください。&br()sldデータを受け取り、そのデータをint値とfloat値に分けて&br()SRAMに書き込み、審判サーバ側には適当なppm画像を送ります。&br()SRAMの書き込まれる番地や内容は後で知らせます。 -- buyobuyon (2007-03-15 06:10:50) - あとyacc, lexに関しては、私はbisonとflexを使っています。 -- buyobuyon (2007-03-15 06:13:05) - なるほど…&br()とりあえず手っ取り早くできそうなものを手動で変換しちゃいましたｗ&br()結果が正しいか以前の問題だと思うので…。 -- yastak (2007-03-15 06:22:04) - ええと、一応、sldppm.binの実行結果(on シミュレータ, with pika.sld)を報告します。&br()まず、&br()&br()MEM[0x00000ffd] : 0x00000011&br()MEM[0x00000ffe] : 0x00000023&br()&br()ffd, ffeはメモリの番地(ワードアドレッシング)で、&br()0x00000011, 0x00000023がその値です。&br()これらの値はint値の個数とfloat値の個数に相当します。&br()&br()続いて、fff番地から100f番地まで、int値が続きます。&br()&br()MEM[0x00000fff] : 0x00000001&br()MEM[0x00001000] : 0x00000001&br()MEM[0x00001001] : 0x00000002&br()MEM[0x00001002] : 0x00000000&br()MEM[0x00001003] : 0x00000003&br()MEM[0x00001004] : 0x00000001&br()MEM[0x00001005] : 0x00000000&br()MEM[0x00001006] : 0x00000000&br()MEM[0x00001007] : 0xffffffff&br()MEM[0x00001008] : 0x00000001&br()MEM[0x00001009] : 0xffffffff&br()MEM[0x0000100a] : 0xffffffff&br()MEM[0x0000100b] : 0x00000063&br()MEM[0x0000100c] : 0x00000000&br()MEM[0x0000100d] : 0x00000001&br()MEM[0x0000100e] : 0xffffffff&br()MEM[0x0000100f] : 0xffffffff&br()&br()その後、しばらくとんで、float値が続きます。&br()&br()MEM[0x000013ff] : 0x00000000&br()MEM[0x00001400] : 0x00000000&br()MEM[0x00001401] : 0x00000000&br()MEM[0x00001402] : 0x00000000&br()MEM[0x00001403] : 0x41f00000&br()MEM[0x00001404] : 0x00000000&br()MEM[0x00001405] : 0x00000000&br()MEM[0x00001406] : 0x437f0000&br()MEM[0x00001407] : 0x00000000&br()MEM[0x00001408] : 0x42c80000&br()MEM[0x00001409] : 0x3f800000&br()MEM[0x0000140a] : 0x42c80000&br()MEM[0x0000140b] : 0x00000000&br()MEM[0x0000140c] : 0xc1f00000&br()MEM[0x0000140d] : 0x00000000&br()MEM[0x0000140e] : 0x3f800000&br()MEM[0x0000140f] : 0x3e4ccccd&br()MEM[0x00001410] : 0x42800000&br()MEM[0x00001411] : 0x00000000&br()MEM[0x00001412] : 0x437f0000&br()MEM[0x00001413] : 0x00000000&br()MEM[0x00001414] : 0x00000000&br()MEM[0x00001415] : 0x41f00000&br()MEM[0x00001416] : 0x42200000&br()MEM[0x00001417] : 0x41f00000&br()MEM[0x00001418] : 0x00000000&br()MEM[0x00001419] : 0x41200000&br()MEM[0x0000141a] : 0x00000000&br()MEM[0x0000141b] : 0x3f800000&br()MEM[0x0000141c] : 0x3f800000&br()MEM[0x0000141d] : 0x437f0000&br()MEM[0x0000141e] : 0x437f0000&br()MEM[0x0000141f] : 0x437f0000&br()MEM[0x00001420] : 0x00000000&br()MEM[0x00001421] : 0xffffffff&br()&br()一応、このデータをsldファイルの内容と照らし合わせたところ、矛盾はなさそうでした&br()(あまりまじめに見ていないので、正しいとは言い切れないのですが…)。&br()&br()審判サーバ側にはout命令でppm形式(バイナリ形式)の画像が転送されるはずです。&br()一応、はじめに0xaaを送るようになっています。 -- buyobuyon (2007-03-15 06:29:47) ***2007.03.15 03:59 引き続きテスト中です。 そういえば、rs232cのコントローラが書きあがりました。 echoテスト用の回路と、PC側のドライバ（？）も書いたので （PC側ドライバは、レイトレ用サーバをちょっと書き換えただけだけど） テストしようと思います。 あ、また.ucf忘れてた。書きます。 CPUに乗せたカウンタが動いていません。 プログラムが動こうが動くまいが、CLKで数えているのだから 動くはずなのになぁ…。 - 動きました。&br()早すぎて見えていなかったか、何らかのバグがあったか、のようです。&br()現在、のんびり動いています。 -- yastak (2007-03-15 04:10:15) - スタックとヒープはいつも同じところまで延びてきています。&br()diffをとったわけではないですが、毎回同じような感じの値になっています。&br()「どこか」で停止？しているようですね…。&br()&br()・OUT命令が、echoにはたえられるが連続書き込みに耐えられない。&br()・その他の命令に何か不備が！？&br()という可能性を考えています。&br()ModelSim上で動かすことを考えるべきか…。&br()眠くなってきた… -- yastak (2007-03-15 04:29:49) - out命令…、&br()print_int関数で、遅延スロットにout命令を入れているのですが、&br()もしかして問題あります？&br() -- buyobuyon (2007-03-15 04:31:16) - ない…と思います。 -- yastak (2007-03-15 05:08:48) - う～ん、とりあえず、sldデータを受け取って、&br()真っ黒画像を返すプログラムでも作ってみますか。&br()必要なら、受け取ったデータをSRAMに書き込むことにして…。 -- buyobuyon (2007-03-15 05:23:02) - お願いしますー。SRAMへの書き込みもよろしくです。 -- yastak (2007-03-15 05:51:36) ***2007.03.14 テスト中です。 とりあえず、審判サーバUSB版を動かしてみて、強制終了して SRAMの中身を読み出したところ、スタックに値が書かれているっぽいので 動いてはいるようですが…。 これってどれくらい時間がかかるものなんですかねぇ。 動作していることが確認できないのが微妙です…。 このあいだカウンタつけたら動かなくなったしなぁ…。 - 最新版のコンパイラで作成した実行ファイル&br()min-rt01.binをこのページにあげておきました。&br()pika.sld＆新バージョンの実行ファイルで実行すると、&br()シミュレータ上で10秒程度で終了します。 -- buyobuyon (2007-03-15 00:46:01) - ありがとうございます！&br()現在実行中ですが、10秒のわりにはなかなか終わりません…。&br()&br()とりあえず、0xaaの受け取りは完了していて、&br()データ送信も完了しているようですが…。 -- yastak (2007-03-15 01:25:50) - このページに途中で終了したときのスタックとヒープの値のファイルをUPしました。&br()ご確認頂ければ幸いですー -- yastak (2007-03-15 01:35:41) - う～ん…、これだけ見てもよくわかりません…。&br()一応、pika.sldで実行したときには、&br()実行命令数は248457579命令、&br()SPが最小になったときで0x000fff3e、&br()HPが最大になったとき(終了時)で0x00013b1fと&br()なるようなのですが。&br()カウンタはやっぱり動きませんか？ -- buyobuyon (2007-03-15 02:26:22) - カウンタテスト中です。乗せられそうな予感。&br()SPは0x000fff80,HPは0x0000fef3でした。&br()なんだか足りないですね…。 -- yastak (2007-03-15 03:33:39) ***2007.03.13 divの仕様（＠ 0<= ans < 10）を書き換えました。buyobuyon氏サンクス！ で、シリアルコントローラの概形ができあがりました。 ビッグエンディアンの場合、 送信ビット・受信ビットは「上（通常表記左側）から順」であってますよね？ 頭がこんがらがってきたー… - あっていると思います、たぶん…。&br()&br()DIVの件、お疲れ様でした。&br()一応、その仕様のDIVをシミュレータに組み込んで、&br()min-rtを実行してみたところ、&br()正常に動きましたので、今度こそ実機でも何とかなるかと…。 -- buyobuyon (2007-03-13 23:44:40) - ありがとうございます…。&br()ビッグエンディアンとリトルエンディアンはあっている気がするのに&br()考えるとぐにゃぐにゃしてくるのが憎らしいですｗ&br()&br()今後の予定は&br()USBレイトレ　→　シリアルコントローラのせる　→　シリアルレイトレ&br()という順番で進めようと思います。&br() -- yastak (2007-03-13 23:52:51) - 拡張基盤を預かっています。私のいない間に必要になってはいけないので、&br()鍵を開けたロッカーの中に入れておきます。一番下の段の奥側、620Wです。 -- tsuy (2007-03-14 22:43:33) ***2007.03.12 out命令の動作を確認しました。 現時点でのCPUファイルをUPしておきます。（FPUも混入されています） では、ご飯買いに行ってきますー！ - とりあえず、div10は無くなりました。&br()一応、&quot;div r1, r2, r3&quot;に関してもう一度仕様を確認したいのですが、&br()&br()1. r3が2のときには、r2/r3の小数点以下を切り捨てた値&br()(r2が正でも負でも、絶対値が小さくなる方向へ丸める)が返される&br()&br()2. r2, r3が正で、r2/r3が0以上10未満なら、その値の小数点以下を切り捨てた値を返す&br()&br()この2つの条件は満たされるのですよね？ -- buyobuyon (2007-03-13 08:57:26) - レイトレ実行可能ファイルraytrace.binをこのページにあげておきました。&br()DIVの使用は/2か答えが0以上10未満になるもののみに限定し、&br()また最初にout命令で外部デバイスに0xaaを送るようになっています。&br()これで実行できると良いのですが…。 -- buyobuyon (2007-03-13 10:37:38) - 2.が、違ってr2/r3は0-9までの整数値である場合に正しい答えを返す、&br()仕様にしていました…（すみません、勘違いですね…）&br()上記のように仕様を変更してみます！&br() -- yastak (2007-03-13 18:31:15) ***2007.03.11 学校に行きそびれました。申し訳ないです。 outのテストは明日の午前中に行おうと思います。 rs232c、資料をちょっと読んでみたのですが、いろいろよくわからない…。 何とか間に合うよう頑張ります… - 一つ確認なのですが、JMPL, JMPRL命令で、&br()リンクレジスタr127にPCの値が入るのは、&br()遅延スロット実行前であってます？ -- buyobuyon (2007-03-12 08:28:47) - あってますー。&br()書き込んでから、遅延スロット部の実行に移ります！ -- yastak (2007-03-12 11:12:51) - 了解です。さっきシミュレータのソースを見直している時に気になったもので。 -- buyobuyon (2007-03-12 11:51:08) ***2007.03.09 CPUの命令ですが、使わないものは省いていこうと思うのですが、いかがでしょう？ バグの元は少ない方がいいので…。 ただいま、MUL,MULH,MULI,DIVはコメントアウト済みです。 LOAD,STOREもコメントアウトしました。 - メモ：&br()LOAD,STOREのコメントアウト、微妙かも。&br()他の命令と共通動作まで消してないか確認すべし -- yastak (2007-03-10 00:36:03) - ファイルありがとうございます&br()使わせていただきます☆ -- はりー (2007-03-10 13:01:31) - あ、ごめんなさい。&br()MULとDIVは戻してください。&br()print_intで使うようになりましたので。 -- buyobuyon (2007-03-10 13:08:23) - 了解ですー。&br() -- yastak (2007-03-11 00:02:01) - DIV、入れてコンパイルしたところ、&br()「/」の演算子は、オペランドが定数or被除数が2冪でないといけない、&br()というエラーが生じてしまいました…&br()対策案&br()・何とかする&br()・FDIV,FTOIで代替&br()で、何とかする、方を検討中です… -- yastak (2007-03-11 01:17:21) - 実はよく見てみたところ、min-rt中でもDIV演算は使用されていました。&br()ただ、min-rt中では割る数が常に2なので、コンパイラの仕様として&br()割り算の引数に制限をかけ、内部でシフトに変換するというような&br()応急処理を施すことは可能です。&br()(あれ、でも被除数が負の時、割り算とシフトとで結果が違うから多少複雑か…)&br()&br()現在のprint_int内部でDIVを使う際には、割られる数・割る数はともに正で&br()かつ割り算の結果は0～9のどれかとなります。&br()といっても、あまり良い制限にはなりませんね…。&br()いいかげんな実装なので、print_intを書き直すのは構いませんが、&br()div10とか、多少制限はついても何らかの除算命令があるとうれしいです。 -- buyobuyon (2007-03-11 02:31:11) - A/2だとコンパイルが通って、&br()A/10だと通りませんでした…。&br()とりあえず、min-rtに対応はできそうですね…。&br()&br()print_intの結果が0～9であれば、&br()愚直に乗算＋比較で実装することができそうですね。&br()とりあえずやってみますー。 -- yastak (2007-03-11 22:12:57) - とりあえず、2で割る割り算と、&br()演算結果が0～9になる割り算には対応できるような実装になりました。（＝コンパイルは通りました。）&br()（18*18乗算器を13個使っていますが…大丈夫ですか？＞tsuy氏）&br()&br()制限があれば、拡張していくことは可能っぽいので、&br()その都度対応していく、ことにしたいのですが、それで大丈夫ですか？ -- yastak (2007-03-11 22:23:37) ***2007.03.09 昨日はすみませんでした…m(_ _)m 回路作成手伝えなかったかわりというわけでもないですが、 コントローラ頑張ろうと思います。 で、Fibが実機で動きました。 数え上げは40の動作を確認（40動けば他も動くだろう） 再帰は3,10,15,20で確認しました。 - harryに約束していたバイナリへの変換ファイル、&br()アップしたつもりでしてませんでした…。&br()今あげましたのでご確認を。&br()&br()因みに、成功してもエラーがあります、と表示されます。 -- yastak (2007-03-09 12:47:40) - では、out命令はそのようにお願いします。&br()in命令の方は今まで通り32bit読み込む方がこちらとしては都合が良いですが、&br()もしoutに合わせて8bit読み込みにした方がハード的に都合が良ければそれでも構いませんので。 -- buyobuyon (2007-03-09 14:34:42) - いえ、inとoutは別物なので大丈夫です～。&br()&br()その後、inの動作は確認しました。&br()が、PC側のドライバが何か変になっていて、&br()outの命令の確認ができません…&br()次回までに改善します～。今日はこの辺で…。 -- yastak (2007-03-09 14:41:54) ***2007.03.06 結局火曜ですみません…。 コンパイルしたところ、謎のクロックのエラーが（Warning）生じていて、 動きません…。 - 菅原さんに救われました。&br()無事コンパイルが通ったので、次は木曜に… -- yastak (2007-03-07 00:55:39) - 周波数について、まずは25MHzという話でしたが、&br()おそらく基盤が出来る頃までにはFPUを50MHzで&br()動かせるようになるはずなので、いきなり50MHz&br()でも大丈夫です。 -- tsuy (2007-03-08 22:53:41) - out命令のことなのですが、&br()「指定されたレジスタの値の下位8bitを、指定されたデバイスに書き込む」&br()というように仕様を変更することってできます？&br()print_int関数を修正したら、out命令で送るデータは&br()下位8bitしか意味を持たないようになってしまったもので…。 -- buyobuyon (2007-03-09 10:06:36) - それと、昨日の打ち合わせでシリアル回路について話し合って、&br()TL16C550(シリアルコントローラ)は入力が多く、&br()全ての入力について調べるのが大変で、配線も大変になるため、&br()TL16C550を使用せず、FPGAの方で直接rs232cのプロトコルを扱って&br()データをやりとりしてもらう、という方向で話が進んだのですが、いかがでしょうか。&br()(正しい説明になっているか自信がない…、ハードウェアは苦手です…)&br()直接rs232cのプロトコルを扱う分、ハードウェア係が多少大変になるとは&br()思うのですが、一方で、プロトコルがわかっているなら得体の知れないICに&br()頼るよりも直接やりとりした方がバグではまる可能性が低くて良いかなと&br()いうのもありまして。&br()配線も少なくて済んで都合が良いのですが、&br()その方向性でrs232cのコントローラの作成をお願いできますか？ -- buyobuyon (2007-03-09 10:55:34) - out命令の件はUSBについては可能です。&br()rs232cは実装がこれからなのでそのようにします。&br()&br()rs232cのコントローラは、&br()これから資料を読んで作成するのではっきりお返事できませんが、&br()その方向で頑張ってみます。 -- yastak (2007-03-09 11:49:42) ***2007.03.02 いよいよ実機のはずが、先日のバグが取れたつもりでとれていなかったので、 （原因をわかっていたはずだったのに、勘違いでした…） それを解消するのに苦戦しました…。 結局、バブルが入るときのストールのタイミングが間違っていたと言う結論。 再帰Fib、3,10,15,20の動作を確認しました。 数え上げだと40とか。（前回と同じ） 再帰で20以上は根性が足りないのでやってません。（時間かかるので…） で、肝心の実機は日曜の朝か月曜当たりの予定です。 （今日は疲れたので…orz） もしかしたら明日来るかも？ 例によって.ucfを書いていないので、それもやらなくちゃというところです。 - ごめんなさい、懺悔いたします。&br()&br()現時点で使用していない命令が結構ありまして、&br()まず、LOAD/STOREはもう一つオペランドをとる命令で代用してしまったので使っていません。&br()それから、MUL/MULH/DIV/MULIは、使ってはいますが、min-rtをコンパイルしても出てこないので、省略可能です。&br()他にも現時点で使っていない命令がいくつかありますが、&br()それらはたぶんライブラリ作成時や最適化時に使うことになると思います。&br()&br()実装してもらった後で使わないということになってしまって申し訳ないです。&br()&br()もしこれらのうちどれかを消すと解決するような問題があれば、&br()言ってください。 -- buyobuyon (2007-03-04 05:18:52) - そうだ、あと、IN, OUT命令で指定するポート番号は何番にします？ -- buyobuyon (2007-03-04 06:08:11) - どれもたいした手間をかけていないので大丈夫です☆&br()でも、使わない命令はコメントアウトした方が回路サイズ等で有利になるかもしれないですね…。&br()&br()ポート番号は、何でも構わないです～。&br()USB->1、rs232c->0とかにしてみますか？&br()（後者をまだ実装していないけど…都合の良い番号があればそれに変更してください）&br() -- yastak (2007-03-04 23:24:44) - 了解です。&br()こちらとしては、runtime.sにあるin, out命令の引数(4ヶ所)を変更すれば良いだけですので、いつでも変更はOKです。 -- buyobuyon (2007-03-07 00:38:11) ***2007.03.01 ついに3月ですね…。 てか、拡張基盤どうしましょう…。 ハードウェアの方でもコントローラ書かなくちゃ(>_<) 本日テストしてきました。 いくつかバグがあったものをとり、 再帰Fibの2,10,15の動作に成功しました。 明日はいよいよ実機！ ***2007.02.26 buyobuyon氏のページにある再帰fibをシミュレータで動作させています。 （あ、今まで出てきたシミュレータはModelSimのことでした。 今名を上げたのはソフトウェア係さんの作るシミュレータの方です。 まぎらわしいことに気づきませんでしたm(_ _)mすみません。） とりあえず10まで動きましたが、40に時間がかかりすぎです。 次に学校に行けるのは木曜日なので、木曜日にテストします。 テスト予定は、 ModelSim：再帰fib 実機：数え上げfib,再帰fib（ModelSim上で動いたら。） です。 - SPを1023に変えて行ったため、&br()スタックのスペースが足りない疑惑やらなんやらのエラーで、&br()結局40は無理でした。&br()その後修正して、15はできました。 -- yastak (2007-02-26 21:42:59) - 24に成功しました。&br()まぁ大丈夫でしょう、うん。&br()スタックのスペースは50個くらいしかつかってなかったので、&br()40もいけるのかもしれません。 -- yastak (2007-02-27 02:17:15) ***2007.02.25 シミュレータ上で数え上げのfibが動きました。 （4,10,20,30,40） 次は再帰型です。harryアセンブラよろしく！ （あと数え上げを実機でもやらなくちゃ…。） 最後のバグは、自分で書いたアセンブリに混入されていましたorz ***2007.02.23 そういえば、21日の進度報告を忘れていました。 SRAM初期化→CPU動作の流れは作れました。 fibを動かしていたのですが、プログラムカウンタの動きはいい感じなのに、 なぜか動作してなくて、どうやらALUに原因があることが発覚した、 というあたりで作業終了。 遅ればせながら、本日ALUの構造を書き換えました。 次に学校に行けるのが日曜になりそうなので、その時にテストします。 後、命令フェッチにミスがある感じがするので、 これから修正します～。 - 日曜って試験日で入校禁止だったりしませんか？ -- buyobuyon (2007-02-23 19:45:24) - 入構規制はとられるみたいだけど、&br()事務室からのメールからすると、&br()学生証あれば大丈夫だと思われます～。&br() -- yastak (2007-02-23 20:51:38) - 命令フェッチは多分大丈夫なことが判明したので修正なし…。&br()なんか、&br()おかしい？→確認→おかしくない（＋別のところがおかしいorz）&br()っていうパターンが多い気がする…。 -- yastak (2007-02-23 20:54:27) ***2007.02.21 あの、いまさらなんですけど、SRAMはエントリが1Mなので、 アドレスは（19 downto 0）の20bitです。 したがって、 「immは、上位7ビットがimm7、下位19ビットがimm19の符号つき整数」 （命令セットより）というときは、imm7の最下位ビット＋imm19としています。 レジスタからアドレスを取るときは下位20bitをとっています。 …でも、符号付にするならもう1bit多くとるべき？ ジャンプの幅が、「disp19」のところは符号コミで19bitだったりするんだけど、 （因みに符号拡張して20bitにしています） そんなに大ジャンプはしなくて良い、ってことで大丈夫ですかね…。 ***2007.02.20 part2 帰り道でタイミングの問題ではないことに気づいたので、 考え直す方向を改めまして。 SRAM擬似回路etc.を書き直しました。 また明日テストします！ ***2007.02.20 シミュレーションしてみました。 コンパイルに時間かかった（汗） どうやらSRAM擬似回路か、シミュレーション用のテストベンチに問題があるらしく、 うまくいきませんでした…。 色々直しているうちにわけのわからないことになったので、 タイミングやらなにやら、考え直してみようと思います。 （ファイル操作はどうやら問題なかったようです。） ***2007.02.18 again シミュレーション回路書き終えました。（多分） ファイル操作にやっぱりちょっと自信がないですが、 とりあえずやってみよう、という状態になったので、 2/19か2/20にやってみます。（結局週内には収まらなかったorz） ここまでのCPUファイル群をUPします。 usbword.vhdは、作ろうと思って作らなかったごみファイルです。 （消すの忘れてましたm(_ _)m） ***2007.02.18 ただ今IN命令（USB対応）を組み込み終えました。 外部デバイスはこれからrs232cの研究ですかね…。 シミュレータ、SRAM擬似回路の初期化を ファイルからSRAM擬似回路へ内容書き込み（→CPU実行） を考えていたのですが、 vhdlでのファイル操作が細やかに出来なくて微妙。 方針転換をすべきか否か…。 - 連続命令間の制約、了解です。&br()とりあえずは、STOREDと直後のLOAD/LOADD/LOADIの間に&br()NOPを挟んでおけば良いですね。&br()遅延スロット中のSTOREDも避けた方が良いか…。&br()&br()END命令は…、このまま停止状態になるので良いような気がします。 -- buyobuyon (2007-02-18 19:32:56) - Stored、よろしくお願いします。&br()&br()Endも了解しました☆ -- yastak (2007-02-18 20:36:25) ***2007.02.18 コメント返信 皆様、返信遅くなってすみません。 ☆buyobuyon氏 1．連続命令間の制約 （問題になるのは）連続する書き込みとかの話ですよね？ レジスタに関するものはないです。 現在命令の結果を書き込んでから次の命令の読み出しを行うので…。 メモリに関するものは、 読み出し→書き込み 読み出し→読み出し 書き込み→書き込み に関しては制約なしで、 書き込み→読み出し の連続になるとき、同一アドレスでない時と、 同一アドレスでも、書き込み命令がSTOREDでないなら大丈夫です。 同一アドレスで、STORED命令の直後だとおそらくまずいです。 SRAMの読み出し（アドレスを入れた2clock後にデータが出てくる）が、 「アドレスを入れたタイミングでのSRAMの内容」を読み出すときはまずくて、 「アドレスを入れた2clock後のSRAMの内容」を読み出すのなら大丈夫、 なのですが、SRAMのマニュアルからは どちらなのかよくわかりませんでした…。 （読み込み不足かもしれないのでもちょっと探してみます） でもフツウに考えたらまずそうだよね、というのがとりあえずの結論です。 遅れた割に判明しきらず申し訳ない…m(_ _)m という感じです。 2．遅延スロットが入るのは、全てのジャンプ系命令です。 因みに、コードは if 現在命令（機械語）の最上位2つ = "11" then 　　次の次のPCは現在命令の結果による（分岐） else 　　次の次のPCは現在命令+1（通常） end if; というようになっております～。 因みに、ENDがきたら回路は停止状態になるようにしていることに気づきました。 ひょっとして、リセットがくる、と言う方が正しい動作ですかね？ レイトレだけ動けばそれで良いだろうという感じで作っていたので…。 リセット、にした方がいいですかね？ ☆harry ありがとう～。 OUTだけでO.K.です！ ***2007.02.15 初期化用回路、完成しました！ これでSRAMとUSBの通信に問題はないはずです。 USBを使ったSRAM操作をまとめたファイルをあげておきます。（sram0215.zip） CPUのシミュレーション回路は、現在ちょこちょこ書き始めているところです。 （多分SRAMの初期化をする部分を書くのがちょっと手間） 今週中にはシミュレーション回路は完成して、シミュレーションができる予定。 目標はFibのシミュレーション上動作です…（すごい遅れだ汗） - 着々と進んでいるじゃないですか。&br()&br()ところで、どの命令の直後何命令が遅延スロットになるかと、&br()またその他に連続する命令間の制約などがあれば、まとめておいていただけますか？ -- buyobuyon (2007-02-15 20:12:35) - 遅延スロットは全て1つとして実装しています～。&br()それ以上必要なとき（命令実行に時間がかかるとき）にはバブル挿入で対応しています。&br()&br()命令間の制約はあまり深く考えていませんでした汗&br()整理してまとめておきますね。（土曜日までには！）&br()&br() -- yastak (2007-02-16 00:43:55) - あ、了解です。&br()こちらもしばらくレジスタ割り付けの実装で手間取っていると思うので、&br()まとめるのは時間のあるときで良いですよ。&br()&br()あともう一つ。&br()初歩的な質問で申し訳ないのですが、遅延スロットが入るのは、全てのジャンプ系命令&br()(BEQ, BNE, BGT, BGE, JMP, JMPL, JMPR, JMPRL, RET, END)&br()の直後でしたっけ？ -- buyobuyon (2007-02-16 01:00:39) - 修正部分はOUTだけでいいのかな？&br()直しました☆&br()また変更あったらどんどん言ってね -- harry (2007-02-17 13:50:16) - 返信は02.18の日記にてしますm(_ _)m -- yastak (2007-02-18 16:13:01) ***2007.02.14 ところで、中間レポートって、出題されてますっけ？ 出題予告はあったような気がしますが…。 具体情報って出てないです、よね？ （私の見落としかな汗） - 一月の中間発表を知らせるメールに出題予告がありますね&br()具体的な情報は今のところメールにも掲示にもなかったかと思います -- tsuy (2007-02-15 02:00:16) - そうかぁ。やっぱり出てないっぽいんだね。&br()ありがとう～！ -- yastak (2007-02-15 13:17:08) ***2007.02.12 皆さん元気ですか？ そういえば私は試験疲れなのか何なのか、土曜日に寝込んだのですが、 皆さんは体調大丈夫ですか？ とりあえず、初期化用回路テストを木曜日に行う予定です。 告知だけしておきます。 - 同じく、倒れていました…。&br()もう大丈夫なのですか？お大事に。 -- buyobuyon (2007-02-13 01:29:38) - 1日寝たら治りました♪&br()buyobuyon氏もお大事に！ -- yastak (2007-02-13 01:57:31) ***2007.02.11 お久しぶりです。試験お疲れ様でした。 現在CPUに外部デバイスとの接続（てかUSB操作）を組み込もうとしているところです。 それに伴って、また命令セットに変更を要求しています。 本当にすみません。主に被害を受けるだろうharryさんには今度ケーキでもおごりましょうｗ USBとの通信は1word単位になるんですけど、 それで問題ないですかね？ コンテストのサーバとの通信のreadmeに、 通信開始信号で、0xaa（1バイト）を送る、とかあったような気がしますが…。 外部デバイスの指定がほとんど必要ないと思うんで、 （USBorシリアル基盤） 即値部に「何バイト(1-4)通信する」という指定があるようにしても良いかと思うんですけど、 どうでしょう？ - とりあえず、OUT命令だけ完成させました。&br()IN命令の前に、初期化回路の完動を目指します。&br()なぜかって、動作的に似ているからです。 -- yastak (2007-02-11 18:47:01) ***2007.01.31 TOPレベルの回路を書きました。 って、接続関係書いただけだけど。 これから、シミュレーション用の回路を書いたりして、 シミュレーションします。 そういえばUSBを組み込むのを忘れていたことに気づきました。 それもやります。 ***2007.01.30 SRAMの回路、どうやらテスト回路にバグがあった模様です。 微妙に書き換えたテスト回路で行ったところ、 無事4Mの読み出しが出来ました。 初期化用回路はうまく動かなかったので、 失敗検討と書き直しを急ぎます。 ***2007.01.27 EXW書き終わりました…。 あとはトップレベルの回路を書いて、 （レイトレテスト用のUSB通信回路もかかなくちゃ？） （FPUをのせれば）完成です。 FPUの前に動作テストをしようと思います。 というところで、そろそろテスト勉強に移ります。 SRAMのテストやらなにやら残っていますが、テスト後にやりますー。 ところでみなさん、シリアル通信回路の製作、どうしましょう？ そろそろ考え始めないとまずい、ですよね…。 - あ゛…、存在自体すっかり忘れていました…。&br()どうする…、というか何をすればよいか全くわかっていなかったり…。&br()とりあえずテスト後…ですかね。 -- buyobuyon (2007-01-27 19:30:39) ***2007.01.26 part2 IFDRがほぼ書き終わった感じです。 即値の符号拡張を考えるのに億劫な気持ちになっていますｗ 単純に肩が凝ったからです。休憩してみます。 - 書き終わりました！&br()が、終了状態のことを考えていないことに気づきました。 -- yastak (2007-01-27 01:06:29) - それくらい面倒がってちゃだめだよね！&br()…追加しました。&br()ぼちぼちEXWも書いていきます。 -- yastak (2007-01-27 01:11:46) - だいぶ完成が近づいてきていますね。&br()コンパイラも頑張らないと…。 -- buyobuyon (2007-01-27 15:13:02) ***2007.01.26 CPUを書く予定が、register fileでブロックRAMの呼び出しと IFDR/EXWのアクセス競合とかで混乱していたら、 時間がいつのまにか過ぎてしまった… めげずにちょっとでも書こうと思います。 ***2007.01.25 進捗報告したら、アドバイスをもらえたので、 今度テストします。 ついでにテスト回路にちょっと改変を加えた別物をつくったり。 SRAMを模倣する回路も作ってみました。（シミュレーション用） ところで、SRAM操作が入る命令には時間がかかるけど(1clockじゃ終わらない）、 そのときにはパイプラインはバブル入れてストール、であってますよね？ って考えると、FPUに2clockとか要しても大丈夫だと思うのですが…。 ***2007.01.19 sramのファイルが大きすぎてupできませんでした…。 大きかったのは、sramから読んできたデータ(4MB)でした。 それをのぞいてupします。 そういえば、usbから4MのデータをSRAMに送り込むような 回路も必要だなぁと気づいたので、それとCPUと平行して作ります。 でもぼちぼちテスト勉強に移行するかも… ***2007.01.18 こっそり木曜日の事情聴取を期待していたけど、ないようですね…。 メール送らなきゃ。 第二次SRAMテストしました。 どうやら通った見込みです。（50MHz) 何がいけなかったのか、いまいち定かでないですが、 致命的に間違っていたところもあったので、それが主原因？ ただ、4Kbyteを読むと、最後の1bitの値が変です。 （前と同じ値…） アドレスを000...から、111...まで読んでいるのですが、 count upで読むとだめで、count downでよむと最後の1bitまで大丈夫…。 とりあえず、ここまでのファイルを固めてupします。 ***2007.01.16 下に書いた鯖落ちは、緊急メンテナンスだったようです。 SRAMの回路をちょっと書き直しました。 マイナーチェンジですが。 echo回路がまだかけておりません…。 でもまぁ、再テストしてみます。 多分明日はできないので、木曜日にやります。 あ、でも事情聴取あるんだっけ？ ***2007.01.14 一昨日はwikiがおちていたらしく、書き込めませんでしたが…。 金曜日にSRAMのテストをしました。 回路は動いているような気配を見せたのですが、 書き込み＆読み込みが出来ていないようです…。 どこができていないのかなどは詳細にはわからないので、 とりあえず、クロック速度を落とす（金曜日は50MHzでやりました）、 別のテスト回路（多分echo）を書く、などの方法で再実験したいと思います…。 ***2007.01.11 あけましておめでとうございます。 CPUのサイクル整理（の詳細化）をやっとしました。 サイクル整理って言うか、ほぼコードの構想ですけど…。 その関係で命令セットの機械語部分をちょっと書き換えさせていただきました。 アセンブリ命令は変えていないので、被害はharryに集中するかと…ごめんなさい。 レジスタの値を読み出すときに、R2,R3の部分に書かれたアドレスを機械的に与えているので 読み出し対象のレジスタはR2,R3の部分に書いてもらった方が便利だからですー。 明日はSRAMのテストをします。 本当は今日の予定でしたが…睡眠不足で挫折しました。 SRAMテストが終ったら、タイミングチャートの確認をして（自分がSRAMの動作を勘違いしていないか） IFDR,EXWの回路を書いて、とりあえずfibを動かすための準備に入ります。 予定より大分遅れてしまいました…。ちょっと焦って頑張ります。 今日はこのあと連続系のLU分解のレポートを今頃書いて、 余裕があったらIFDR,EXWをちょっと書き始めようかなぁと。 投機的実行ｗですが。分岐予測がはずれませんように。 ***2006.12.31 part2 ALUが書き終わりました。 今年中にfibも無理でした…。 年明けに急ピッチでテストなどしていく予定です…。 みなさん調子はどうですか？ - ごめんなさい、全く進んでいない感じです。 -- buyobuyon (2006-12-31 23:45:30) - パイプライン化について。言われてみれば、確かにReadを前段に含めてしまった方が良さそうですね。 -- buyobuyon (2006-12-31 23:48:34) これ以前の作業進行 [[yastak古]] 2009-06-07T11:00:02+09:00 1244340002 tsuy and buyobuyon https://w.atwiki.jp/ttth/pages/32.html **コンパイラ組み込み関数 [[tsuy]]さんのページにいろいろ書き込んでいるうちに書き込める量の限界に達してしまったので、 コンパイラに組み込んだ浮動小数点数演算関数に関して、以前私が書き込んだ部分を こちらに移動しました。 - ええと、ライブラリの件なのですが、&br()まず、浮動小数点数演算の&br()&br()atan : type(fun type(float) -> type(float))&br()cos : type(fun type(float) -> type(float))&br()sin : type(fun type(float) -> type(float))&br()&br()は完全にお任せします(とりあえずはもうできているのでしたよね)。&br()それから、&br()&br()int_of_float : type(fun type(float) -> type(int))&br()float_of_int : type(fun type(int) -> type(float))&br()fless : type(fun type(float) * type(float) -> type(bool))&br()&br()は、FPUで実装されているので、コンパイラの拡張ですぐ対応できます。&br()それから、&br()&br()fiszero : type(fun type(float) -> type(bool))&br()fispos : type(fun type(float) -> type(bool))&br()fisneg : type(fun type(float) -> type(bool))&br()fabs : type(fun type(float) -> type(float))&br()fneg : type(fun type(float) -> type(float))&br()fhalf : type(fun type(float) -> type(float))&br()fsqr : type(fun type(float) -> type(float))&br()floor : type(fun type(float) -> type(float))&br()&br()は、簡潔なので、私が入出力命令と一緒にアセンブリ言語で記述するなり、&br()コンパイラ内部での変換なりで対処しておきます。&br()それらに関して、ちょっと仕様の確認をしたいのですが、&br()fisposとfisnegは0レジスタとの比較で良いですよね。&br()fabs/fnegは基本的には最上位ビット0/反転で良いと思うのですが、&br()引数が0のときはどうしましょう?&br()今のFPUでは、いわゆる-0が入力された場合に結果はどうなります?&br()あと、fiszeroはfabs→0レジスタとの比較で、&br()fsqrは同じ値を引数としたfmulで、&br()floorはftoiとitofの合成で良いですよね。&br()fhalfは…、÷2.0にするのは遅すぎる…?&br()仮数部のみデクリメントってもっと厄介ですよね…。&br()&br()あと、浮動小数点数演算以外に関しては、&br()&br()xor : type(fun type(bool) * type(bool) -> type(bool))&br()read_float : type(fun type(unit) -> type(float))&br()read_int : type(fun type(unit) -> type(int))&br()print_int : type(fun type(int) -> type(unit))&br()&br()いずれも対応する命令が存在するので、コンパイラの拡張ですぐ対応できます。あと、&br()&br()print_char : type(fun type(int) -> type(unit))&br()&br()が何者だかいまいち把握していないのですが…。&br()wordアラインメントだからprint_intと一緒にするしかありませんよね…。 -- buyobuyon (2007-03-02 15:49:50) - fnegは0から引けばよかったのでしたね…。&br()コンパイラのアセンブリコード生成部分を作成したときにはそういう変換をしていたのに…。&br()&br()absは、もし最上位ビット反転という方針がだめな場合、&br()例えば、fnegしたものと、もとの値のandをとるという方針なら大丈夫ですよね? -- buyobuyon (2007-03-02 15:56:36) - もうひとつボケをかましていましたね…。&br()fhalfは÷2.0より×0.5ですね…。&br()&br()あともう１つ。現在、コンパイラでは、&br()fequalを通常の整数の比較で置き換えてしまっているのですが、&br()これは大丈夫ですよね? -- buyobuyon (2007-03-02 16:09:26) - >fabs/fnegは基本的には最上位ビット0/反転で良いと思うのですが、&br()>引数が0のときはどうしましょう?&br()>今のFPUでは、いわゆる-0が入力された場合に結果はどうなります?&br()FMULでは+0が出力されます。&br()FADD,FSUBでは+0と-0の区別はつけず、また、出力が0となる場合は必ず&br()+0になります。（多分…）&br()FLESSはご存知の通り-0<+0の判定に使います。&br()FTOIは+0の場合と処理は同じです。&br()FINVSQRTは非正規化数の処理がいらないということなので、挙動は未定義です。&br()FPUの出力の0はすべて+0となっているはずなので、FLESS絡みで問題がなければ&br()fabsは最上位ビット0でいいような気がします。&br()fisneg(-0.0)はtrueでいいんですかね？ -- tsuy (2007-03-02 18:35:21) - >floorはftoiとitofの合成で良いですよね。&br()floorって確か小数点未満切捨てですよね？&br()FTOIの結果は小数点未満四捨五入としているので問題になる気がするのですが、&br()FPUのFTOIを切り捨てにしたほうがいいですかね？&br()(そっちのほうが速くなるので好都合だったりしますが)&br()&br()>print_char : type(fun type(int) -> type(unit))&br()>が何者だかいまいち把握していないのですが…。&br()すみません、僕もよく分かりません…。 -- tsuy (2007-03-02 18:42:40) - >absは、もし最上位ビット反転という方針がだめな場合、&br()>例えば、fnegしたものと、もとの値のandをとるという方針なら大丈夫ですよね?&br()なるほど、それなら大丈夫ですね。&br()&br()>fequalを通常の整数の比較で置き換えてしまっているのですが、&br()>これは大丈夫ですよね?&br()大丈夫だと思います。 -- tsuy (2007-03-02 18:54:22) - fequalの話で思いついたんですが、丸めを切捨てにしてしまったので、&br()(1.0/3.0)*3.0と1.0が等しくならないんですよね…&br()FMULだけでも丸めを切り上げにしたほうがいいだろうか… -- tsuy (2007-03-02 18:58:12) - なるほど…。+0.0と-0.0がきわどいですが、とりあえず、&br()&br()fiszero → rd := (rs AND 0x7fffffff) >. +0.0&br()fispos → rd := rs >. +0.0&br()fisneg → rd := rs <. -0.0&br()fabs → rd := rs AND 0x7fffffff&br()fneg → rd := +0.0 -. rs&br()fhalf → rd := rs *. +0.5&br()fsqr → rd := rs *. rs&br()&br()としてみます。&br()floorをどうするか…。&br()floorって切り捨てというよりも、～を超えない最大の整数を表すfloat値を&br()返す演算でしたよね、正負で非対称な…。&br()コンテストルールがあるので、ftoiの仕様を変えるわけにもいきませんし…。一応、&br()&br()floor → r1 := ftoi(rs); r1 := itof(r1); rd := rs <. r1; rd := itof(rd); rd := r1 +. rd&br()&br()とすると、正しい値が求まりそうですが(そうでもない？)、命令数が…。&br()あとは…、0.5引いて四捨五入、みたいなアバウトなことが許されるのであれば&br()速くなりそうですが…。何かいい方法はないですかね…。&br()&br()あと、FPUで提供する演算、やっぱりFINVSQRTではなくてFSQRTの方にしてもらえます？&br()たぶんその方が高速かつ楽なので(特にFINVSQRTをFSQRTとFDIVの合成として求めているのであればなおさら)。&br()FINVSQRTのライブラリでの実装も任意で良いようです。&br()何か、たくさん実装してもらった後で申し訳ないのですが…。 -- buyobuyon (2007-03-02 20:30:25) - FSQRTですか…&br()以前開平法で実装したものはサイズ、速度ともに実用的ではなかったので、&br()また一から作ることになると思いますが、コンテストまでに間に合うだろうか…&br()それからサイズの方も、今のFINVSQRTを超えると完全にオーバーしてしまう&br()という不安があります。&br()&br()しかしどうやって実装しよう… -- tsuy (2007-03-02 22:08:00) - >FINVSQRTをFSQRTとFDIVの合成として求めているのであればなおさら&br()すみません、これはどういうことでしょうか？ -- tsuy (2007-03-02 22:12:34) - FPUにFSQRTをのせる場合、逆数や割り算はどうなります？&br()ライブラリで作ったINVでは少々遅いので、やはりFPUには&br()FINVSQRTがいいような気がしないでもないのですが… -- tsuy (2007-03-03 15:56:18) - >>FINVSQRTをFSQRTとFDIVの合成として求めているのであればなおさら&br()>すみません、これはどういうことでしょうか？&br()あれ？私、何か勘違いしていました？&br()↓に&br()>・FINVSQRT &br()>　－SQRTとFDIVで計算 &br()と書いてあったので、&br()FINVSQRTは、内部でFSQRTとFDIVを組み合わせているだけなのかなと思ったのですが。&br()だとすれば、FSQRTの方がFINVSQRTよりは速いわけですよね。&br()&br()min-rtでは、SQRTのみ使用されていて、INVとINVSQRTは直接使用されてはいないので、&br()SQRTではなくINVSQRTがFPUで提供された場合には、&br()コンパイラ内部では、&quot;1 ./ SQRT(x)&quot;をINVSQRT(x)に変換し、&br()それ以外の&quot;SQRT(x)&quot;をINV(INVSQRT(x))に変換することで高速化を図るわけですが、&br()よくよくmin-rtを見ると、&br()&quot;1 ./ SQRT(x)&quot;を求める場合でも、直前or直後に別の用途で&br()&quot;SQRT(x)&quot;を使用している場合が多いのですよ。&br()例えば、min-rtには、&br()&br() let l = sqrt (fsqr v.(0) +. fsqr v.(1) +. fsqr v.(2)) in&br() let il = if fiszero l then 1.0 else if inv then -1.0 /. l else 1.0 /. l in …&br()&br()という部分があって、まぁfiszero lは、fiszero (fsqr v.(0) +. fsqr v.(1) +. fsqr v.(2))に変えても&br()一般的に問題はないはずですが、一応意味の違う文面ですし、またコンテストルールに&br()&br()>非最適化実行の場合と同一オペランドの浮動小数点演算が&br()>同一回数行われなければならない。ただし、(2)については定数&br()>割り算最適化(後述)、冗長性除去、定数畳み込みは例外とする&br()&br()とあるので、この変換はちょっときわどいかなと思いまして。&br()&br()とすると、結局INVSQRTしたものだけではなくSQRTしたものも求める必要があります。&br()&br()INVSQRT(x)とSQRT(x)の両方を求める必要があるとしたら&br()SQRTがFPUで求まったいた方が速く(速いですよね？)、&br()またプログラムの文面そのままで変換すれば良いので私の方も楽にはなるのですが…。&br()&br()あ、でも、上の話はFPUでFINVSQRTは内部でFSQRTとFDIVを組み合わせることで実装している、というのを前提にしていたので、&br()そうでないのであれば実装し直すのも大変ですし、このままFINVSQRTでやってみます。 -- buyobuyon (2007-03-03 17:14:42) - なるほど、分かりました。&br()&br()下のほうでFSQRTとFDIVの合成となっているのは、11月にそのようにして実装したものが&br()実用的な性能ではなかったのでニュートン法で実装しなおしたという経緯があるのですが、&br()その際にwikiの記述を直し忘れていたという私のミスです。すみませんでした。&br()&br()FSQRTは開平法では前述の通り性能が悪く、ニュートン法では割り算をする必要があるため&br()どうしても遅くなるので、ニュートン法のFINVSQRTを入れたほうが良いよねというお話を&br()した記憶があります。また、FSQRTを採用するとFPUのサイズ的にINVをライブラリで実現&br()せざるをえないと思うのですが、それだとやはり遅くなる気がします。FINVSQRTを使えば&br()その結果を2つ掛けるだけですし。&br()&br()時間的余裕があればFSQRTもやってみたいのですが2週間では多分無理なので、FINVSQRT&br()を使う方向でお願いします。 -- tsuy (2007-03-03 19:04:26) - あ、了解です。&br()私が勘違いしていただけなので、FSQRTは実装し直さなくて良いですよ。&br()&br()なら、結論として、&br()FPUで実装されるのは、FADD/FSUB/FMUL/FINV/FINVSQRT/FTOI/ITOF/FLESSの8つで、&br()コンパイラの方では、&br()&br()(x ./ y)　→　(x *. (inv y))&br()(sqrt x)　→　(inv (invsqrt x))&br()&br()とし、(実装する時間があれば)最適化のステップで&br()&br()(inv (inv x))　→　x&br()&br()という変換をすれば良いのですよね。&br()&br()コンパイラは直接の関係はないですが、OPCODEってどうなってます？ -- buyobuyon (2007-03-03 19:36:24) - FPUで実装されるのはFADD/FSUB/FMUL/FINVSQRT/FTOI/ITOF/FLESSの7つです。&br()上のほうで誤解させてしまう書き方をしてしまいましたね。すみません。&br()&br()FINVは、すぐ下にあるとおり基盤の18×18の乗算器の数が足りないというのと、&br()他の命令のパイプライン化でサイズが大きくなることが予想されるため、FPUに&br()載せることは不可能です。&br()&br()だからおそらく&br()(x ./ y)　→　(x *. （(invsqrt y) *. (invsqrt y)))&br()(sqrt x)　→　(invsqrt （(invsqrt x) *. (invsqrt x)))&br()のような感じになるかと思われます。&br()&br()OPCODEはFPU外部から下の仕様にあるFUNCの部分に4bit入力してもらうように&br()しています。命令セットのページにあるOPCODEでFPUでサポートしている命令の&br()OPCODEなら結果を規定のクロック後に出力し、それ以外なら&br()&quot;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&quot;&br()が出力されるようになっています。 -- tsuy (2007-03-03 21:01:24) - あ、了解です。&br()割り算にもinvsqrtが入りますか…、結構遅延が大きくなりそうですね。&br()FINVが入らないってことは、4bitずつ引き算っていうFDIVも入れるのは無理なのですよね？&br()&br()あと、FINVSQRTを使ってFDIVやSQRTを実現する場合、&br()FDIVやSQRTの精度の条件は満たされますか？&br()&br()何かいろいろと聞いてしまって申し訳ありません。&br()&br()あと、FPUのOPCODEの件、一応その4bit値がわかるように、&br()命令セットのページにでもまとめておいておいてもらえます？&br()アセンブラとシミュレータも多少変更する必要があるでしょうし。 -- buyobuyon (2007-03-03 21:54:35) - FDIVどころかFINVSQRT自体入る保証がなかったり…&br()パイプライン化しなくていいのなら余裕なんですけどね。&br()ちなみにFDIVはFINVSQRT10個分のサイズなので、使い物になりません。&br()&br()精度は…満たされないような気がしてきました。&br()FDIVとSQRTに使うFMULとFINVSQRTの誤差は最大で仮数部23bit目のずれ&br()なのはFPUのテストで分かっていて、FDIVもSQRTも4回これらが使われて&br()いるんですよね…少し考えて見ます&br()&br()OPCODEの件、命令セットのところに書かれているOPCODEをそのまま4bit&br()値にしているんですがそれをまとめるということですか？ -- tsuy (2007-03-03 23:12:08) - 精度の件について&br()FDIVですが、&br()(x ./ y)　→　(x *. （(invsqrt y) *. (invsqrt y)))&br()を使うとすると、&br()(invsqrt　y)＝(y^(-1/2))*(1+2^(-23))&br()であり、&br()(invsqrt y) *. (invsqrt y)＝(invsqrt y)*(invsqrt y)*(1+2^(-23))&br()なので&br()(invsqrt y) *. (invsqrt y)＝(y^(-1/2))*(y^(-1/2))*（(1+2^(-23))^3)&br()となりますよね？&br()さらにこれにxを掛けるので、真の値との誤差は&br()(1+2^(-23))^4　-　1&br()分になるものと思われます。&br()そしてこの値を計算すると&br()1+2^(-21)+2^(-44)+2^(-45)+2^(-67)+2^(-92)&br()となります。&br()ルールは確か2^(-20)だったと思いますが、これならぎりぎりセーフかと思います。&br()計算が違ったらすみません -- tsuy (2007-03-03 23:56:13) - SQRTについてですが、&br()(sqrt x)　→　(invsqrt （(invsqrt x) *. (invsqrt x)))&br()を使うものとして、&br()(invsqrt x) *. (invsqrt x)&br()部分の真の値をaとおきます。&br()上と同様に考えると、誤差を入れた値は&br()a*（(1+2^(-23))^3)&br()となり、これにFINVSQRTを適用すると、誤差も入れて&br()[｛a*（(1+2^(-23))^3)｝^(-1/2)]*(1+2^(-23))&br()=｛a^(-1/2)｝*｛(1+2^(-23))^(-1/2)｝&br()となります。ルールでは確か2^(-20)だったかと思うので、&br()|1　-　(1+2^(-23))^(-1/2)| < 2^(-20)&br()なら問題ないことになります。&br()実際計算してみると、同値変形で成立した不等式になったので、恐らく&br()問題ないかと思います。&br()&br()とは言っても計算に自信がないのですが、他の高速化した命令が正しいか&br()テストするときに一緒にテストしたほうがいいかな？&br()ついでに、というには時間と手間がかかるけれど。 -- tsuy (2007-03-04 00:19:38) - 大丈夫そうですね、それなら先ほどの式を使わせていただきます。&br()&br()ただ一つ気になったのが、FDIVやSQRTを求める際に(INV x)を求める段階で、&br()let t = (invsqrt x) in (t *. t)&br()とすると最初の演算の誤差が後の演算の2つのオペランドに影響しますが、&br()let t = (x *. x) in (invsqrt t)&br()とすると後の演算のオペランドが1つなので、&br()結果として浮動小数点数演算1つ分誤差が小さくなるような気がするのですが、どうですかね？&br()sqrtの入力が負の場合が未定義で良いのなら、ルール上は問題ないはずですし。&br()(また何か勘違いしているような気もしますが…)&br()&br()テストは余裕があればで良いと思いますよ。&br()結果的にレイトレが動けば良いわけですし(早く一度動かさないとね…)。&br()&br()あと、OPCODEの件、またまた私の勘違いでした。すみません。&br()FINVが無いなら、前に定義したもので足りるのでしたね…。 -- buyobuyon (2007-03-04 00:29:59) - 話が変わるのですが、floorの実装をライブラリの方でやっていただけますか？&br()よくよく考えると、ftoiしてからitofする方針だと、intの範囲を超える整数のfloat表現が&br()入力に入ったときに厄介ですし、&br()まじめにやるとなるとマクロというより関数という感じのサイズになってしまうもので。&br()一応、関数内で何をすればよいかはわかっている(つもりな)ので、&br()もし大変であれば私が実装しておきますが、どうしましょう？ -- buyobuyon (2007-03-04 00:56:14) - 確かに&br()let t = (x *. x) in (invsqrt t)&br()の方が誤差が少なくなりますね。盲点（？）でした。&br()&br()そちらのやることもいっぱいあるようですし、floorの実装をさせていただきます。&br()ただ性能のよくないものを作ってしまってはいけないので、方針を教えていただけますか？&br()それからもう一つ、OCamlの文法で書いていいのかな？ -- tsuy (2007-03-04 01:54:20) - すみません、お願いします。&br()&br()実装はOCaml文法で構いません。できれば、アップしたコンパイラで&br()コンパイルできる形にすぐ直せるよう、多相関数などの使用は控えてください。&br()あと、ftoiはint_of_floatという名前の一変数関数として、&br()itofはfloat_of_intという名前の一変数関数として、それぞれ実装しますので、&br()必要なら使ってください。&br()&br()ええと、実装方法についてあれから改めて考えてみたのですが、&br()floatの仮数部のsizeってsizeof(int)より断然小さいですよね。&br()そのため、floatで表された値がintで表現できる範囲を超えた場合というのは&br()もう既にfloatの仮数部に1を足したら(引いたら)float値は1以上変化する場合なので、&br()そのときにはそのまま引数を返してやればよいわけですよね。&br()&br()とすると、指数部がその境界となる値以上であったら引数をそのまま返し、&br()そうでなければ先ほど述べたように、&br()FTOI → ITOF → FLESS結果が真なら(int値に)-1 → ITOFというので&br()良いかなと思うのですが、どうでしょう？&br()たぶん、下手に指数部に応じてシフト・場合分けを繰り返すよりは&br()このようにFTOI→ITOFでごまかした方が速いような気がするのですが…、&br()あまりクロック数とか意識していなかったので、どうなんだろ？&br()&br()一応、上の方針だと2箇所だけ場合わけがありますが、2つ目に関しては、&br()真=int型の-1なので足し算で代用可能ですよね。&br()とは言っても、ML文法だとint値にbool値を足すようなことはできないので、&br()後で自作コンパイラでコンパイルして出力されたコードを一部書き換えるように&br()すれば良いと思います。&br()他のcosやatanなどもその方針で高速化できるものがあるかもしれませんし。&br()&br()あと、finvは結局let t = (x *. x) in (invsqrt t)の形を採用しました。 -- buyobuyon (2007-03-04 03:15:41) - なるほど分かりました。&br()&br()念のため確認しておくと、&br()入力ｘについて、&br()｜ｘ｜≧2^(23)のとき、この浮動少数はすでに整数なのでそのまま返す&br()　　こうすることでftoiでINT_MAXやINT_MINが返る問題を避ける&br()｜ｘ｜＜2^(23)のとき、y=itof(ftoi(x))とすると、yはxを四捨五入した&br()　　ものになるので、x＜yなら切り上げられているのでy-1を、&br()　　　　　　　　　　x≧yなら切り捨てられているのでyを返す&br()ということでいいですよね？&br()&br()上の方で&br()>0.5引いて四捨五入、みたいなアバウトなことが許されるのであれば&br()>速くなりそうですが&br()とありますが、できないですかねー…&br()出来るとありがたいんですけどね -- tsuy (2007-03-04 16:24:53) - itof・ftoiによる方針、それで良いと思います。&br()&br()0.5引いて四捨五入も実はOKのような気がしてきたのですが…。&br()0.5が非常にきりの良い値なので、引き算したときに滅多に桁落ち(情報落ち？用語がわからない…)しませんから、&br()0.5の引き算で正しい値が求まる下限と上限の2つの境界で場合分けすれば、この方針でもいけますよね？&br()ただ、場合分けが1つ増えると命令は2つ増えるので、&br()結局命令数は上の方針と変わらないような気がします。&br()&br()あと、-0.5を四捨五入したときに0.0でなく-1.0になるように、&br()すなわち正負で対象になるように四捨五入が定義されていると、&br()後者の方針では正しい値は求まりませんね…。 -- buyobuyon (2007-03-04 17:15:28) - ftoiによる四捨五入は正負で対象となっているので、0.5引くのはよくない&br()ようですね。&br()&br()最初の方針で実装しようかと思います。&br()テストも含めて火曜日夜あたりまでにこのページに上げようかと思うのですが、&br()それで間に合いますよね？ -- tsuy (2007-03-04 19:12:55) - あ、大丈夫だと思います。&br()というか、私が火曜日夜までWiki見られなくなりますので…。&br()一応こちらもテスト作業だけは進めておきます(できればある程度の最適化も).&br() -- buyobuyon (2007-03-04 21:01:06) #comment(vsize=5,nsize=20,size=80) 2009-06-07T10:59:44+09:00 1244339984 harry(昔） https://w.atwiki.jp/ttth/pages/29.html ***昔のページをここに移動 ------------ **2月22日 ------------ アセンブラで仮想命令movの変換が出来たので、最新版を添付します。 To [[buyobuyon]] アセンブラは仮想命令変換が簡単にできるように変えたので、また仮想命令変換があったらどんどん言ってくださいね あのう、buyobuyon氏のページにあるfibのコードをアセンブリにかけたら、 エラーが出てしまったのですが…（We cannot read line 1が大量に。) ([[yastak]]) ざっと見たところ、原因の一つはadd r0,r0,r0のようです。 この命令は"000..."(all 0)ですが、all 0の時にエラーをはくことになっているので、 エラーが出たようです。 We cannot read line 1　が大量だったのは、1の部分のところの引数がおかしいのではないかと。 （inではなくout？） そのほかにも原因があるようなので、修正をお願いします。 (yastak) To yastak: 大変申し訳ございません。 間違いの原因の一つはyastakさんの言ったようにall 0の時エラーを吐くようにしているからであるが、 大量のエラーが出たのは スペースのありなしの違いのようです 私は例えば addi r1,r2,30; のようにオペランド間にスペースの無いものを想定したのですが、 ぶよぶよ氏のページにあるのは addi r1, r2, 30; とワンスペースあるものです。 そこを直したらこんな感じの結果になりました [hari@localhost Desktop]$ ./assem2-25 source.txt exit.txt label------MAIN; move value---15 label------fib_00000002; move value---1 label------LABEL_00000010; move value---2 jmpl label OK--label[1], num: 5, content: fib_00000002; move value---1 jmpl label OK--label[1], num: 5, content: fib_00000002; assembly finished there is no error [hari@localhost Desktop]$ cat exit.txt mov 00 : 00000001000001000000000000001111 jmpl 01 : 11000000011010000000000000000001　　　　　／／ここは間違い add 02 : 00000000000000000000000000000000 end; 03 : 11000000001110000000000000000000 add 04 : 00000000000000000000000000000000 mov 05 : 00111110000001000000000000000001 cmplt 06 : 00111101101100111110000000100000 not 07 : 00111101010110111101100000000000 beq 08 : 11111101000000000000000000001000 add 09 : 00000000000000000000000000000000 addi 0A : 00000001000001000001000000000000 ret; 0B : 11000000001100111111100000000000 add 0C : 00000000000000000000000000000000 addi 0D : 00111110100001111110111111111101 storei 0E : 10000001011011111110100000000010 mov F : 00111100100001000000000000000010 sub 10 : 00000001000010000001011110010000 storei 11 : 10111111111011111110100000000000 jmpl 12 : 11000000011010000000000000000101 add 13 : 00000000000000000000000000000000 storei 14 : 10000001011011111110100000000001 mov 15 : 00111110000001000000000000000001 loadi 16 : 10111101110011111110100000000010 sub 17 : 00000001000010111101111111000000 jmpl 18 : 11000000011010000000000000000101 add 19 : 00000000000000000000000000000000 loadi 1A : 10111110010011111110100000000001 add 1B : 00000001000000000001011111000000 loadi 1C : 10111111110011111110100000000000 addi 1D : 00111110100001111110100000000011 ret; 1E : 11000000001100111111100000000000 add 1F : 00000000000000000000000000000000 END; [hari@localhost Desktop]$ とりあえず大雑把に直したものを添付しますが、このアセンブラはまだ要修正なので、修正後また新しいものを載せます。 ☆自分へのメモ： 問題点： ☆assem2-25.cように一行ずつ入力ファイルから読んで結果を出力ファイルに出力するとジャンプなどラベル値のあるものは自分より前のラベルに飛べるけど、後ろに飛べない。 assem.cように入力ファイルを全部読んから出力ファイルを開いて出力すると、movのような命令変換がうまくできない。。。 これを解決しなければ。 ☆movの処理を吟味すべし ☆ジャンプなどラベルに飛ぶのはいいけど、即値のケースをも追加すべし（かな？） ありがとう～♪お世話かけますm(_ _)m ☆最初に全ての行をよんで、配列に格納（よみつつラベルの記録をして、movはhi,addiに変換する） すると、配列中の命令からラベルとmovが消える。 →格納した命令を順番にマシンコードに… とかでできないかな…？ (yastak) ----------- **2月20日 ----------- アセンブラの最新版を添付します 変更点： （1）命令の変更を入れた （2）出力ファイルは必要分だけにした（前は256行に限定してた） （3）負の数にも対応するようにした（即値あたり。1の補数表記で） 問題点： 仮想命令のmovですが、 addiに変更するのはできているけど、 n>1024のとき、つまり二命令に書き換える のはまだできていないです。 書き換えるだけだからすぐに出来ると思ったけど、返り値は一つだから意外と全体の仕様と相性が悪く、試行錯誤中。。。 そこができたらまたアップします。とりあえずそこ以外は修正しました。 to [[tsuy]]: fpu_ftoiなのですが、floatで表せる数の範囲がintで表せる範囲を超えているので、 FPUでは入力がintの範囲を超えるものである場合にINT_MAXやINT_MINを返すようにしている のですが、シミュレータでは不要なんですかね？(tsuy) 追加します。指摘ありがとうございます。 実行結果例： addi r3,r8,-10; muli r1,r100,100; andi r1,r2,20; andi r1,r2,-20; :first; hi r1,64; hi r1,-64; :second; out r2,100; out r1,-100; jmp first; addi r1,r0,6; addi r2,r0,4; mov r1,second; mov r2,first; [hari@localhost Desktop]$ ./assem2-20 source.txt exit.txt jmp label OK--label[0], num: 4, content: first; mov label: 6 mov label: 4 there is no error assembly finished [hari@localhost Desktop]$ cat exit.txt 00 : 00000001100001000100011111110110;-- 18447F6 01 : 00000000100101110010000001100100;-- 972064 02 : 00000000110001000001000000010100;-- C41014 03 : 00000000110001000001011111101100;-- C417EC 04 : 10000000100000000000000001000000;-- 80800040 05 : 10000000100111111111111111000000;-- 809FFFC0 06 : 10000000011101000001000001100100;-- 80741064 07 : 10000000011101000000111110011100;-- 80740F9C 08 : 11000000011000000000000000000100;-- C0600004 09 : 00000000100001000000000000000110;-- 840006 0A : 00000001000001000000000000000100;-- 1040004 0B : 00000000100001000000000000000110;-- 840006 0C : 00000001000001000000000000000100;-- 1040004 END; -------------- **2月19日 -------------- （1）　＞yastak ＞即値のところにマイナス値を入れると出力ファイルに FFFFFFF...というall 1の命令が出力されてしまいました。 バグかなぁ？ えーと、アセンブラを作るときにマイナスの値を考慮しませんでした。すみません。(m_m) addiの返り値は return (ra << 23) | (ADDI << 18) | (rb << 11) | (imm); で、 immの値は1の補数（全32ビット）で表記されるからその前の部分が上書きされて、こんな出力となってしまいましたのだと思います。 ここではimmは11ビットだから、11ビットのみの1の補数表記にして、返り値を return (ra << 23) | (ADDI << 18) | (rb << 11) | ((imm<<21)>>21); に直したら addi r1,r2,10; addi r1,r2,-10; addi r1,r2,20; addi r1,r2,-20; を入れたところこういう感じになりました 00 : 00000000100001000001000000001010;-- 84100A 01 : 00000000100001000001011111110110;-- 8417F6 02 : 00000000100001000001000000010100;-- 841014 03 : 00000000100001000001011111101100;-- 8417EC これでいいのかな？ movをaddiとhiの組み合わせに直して、演算部のオペランドにラベルが来てもいいようにしてからアセンブラを添付します。一応明日中に添付する予定です。遅くなってすみません。。。 （2） シミュレータのfpuがとりあえず完成したので、添付します 実行結果をもいくつか貼りました [hari@localhost Desktop]$ ./2-18 f1:　　//f1, f2はユーザが入力する 3.1 f2: 4.5 fadd: 7.600000 fsub: -1.400000 fmul: 13.950000 fpu_inv of 3.100000: 0.322581 fpu_finvsqrt of 3.100000: 0.567962 fpu_ftoi: 3 fpu_itof of 100: 100.000000 fpu_fless: -1 [hari@localhost Desktop]$ ./2-18 f1: 4.1 f2: 1.3 fadd: 5.400000 fsub: 2.800000 fmul: 5.329999　　//←このように入力データにより誤差がでることもある。ここでは本来5.33になるはず fpu_inv of 4.100000: 0.243902 fpu_finvsqrt of 4.100000: 0.493865 fpu_ftoi: 4 fpu_itof of 100: 100.000000 fpu_fless: 0 [hari@localhost Desktop]$ ./2-18 f1:　　　　　　　　　　　//入力データはうまく限られたビットで収まれば誤差が出ない。 4.0 f2: 1.5 fadd: 5.500000 fsub: 2.500000 fmul: 6.000000 fpu_inv of 4.000000: 0.250000 fpu_finvsqrt of 4.000000: 0.500000 fpu_ftoi: 4 fpu_itof of 100: 100.000000 fpu_fless: 0 fpu_fless（）なんだけど、引数1＞＝引数2の場合は0を、そうでない場合はー1を返すようにしてあるけど、それでいいのかな？？ って、各関数の引数も返り値もunsigned int型ですが、 どれも32ビットの文字列をそのまま整数に直した値にしてある。（符号無し） 例：　ビット列が00000000000000000000000000001111なら15に直すとか（2の補数で） それでいいのかな？符号つきで1の補数の整数にした方がいいのかな？ あとfpu_ftoi()ですが、負の数の場合は、絶対値が近い方の整数を返すようにしてあるが、いいのかな？ （たとえば-26.38なら-26に、-26.78ならー27に丸めた） 「fpu_fless（）なんだけど、引数1＞＝引数2の場合は0を、そうでない場合はー1を返す」 「fpu_ftoi()ですが、負の数の場合は、絶対値が近い方の整数を返すようにしてある」 これらはこれでいいかと思います。 fpu_ftoiなのですが、floatで表せる数の範囲がintで表せる範囲を超えているので、 FPUでは入力がintの範囲を超えるものである場合にINT_MAXやINT_MINを返すようにしている のですが、シミュレータでは不要なんですかね？(tsuy) -------- 進行状況報告（１）１０月３０日 ------- アセンブラ： 大体はできたつもりで、まだ完成していません（＞＿＜）。遅くても１１月中に完成させます。 シミュレーター： この前見つかった資料をまだ解読中です。まだあまり理解していない感じです。 ＰＳ. 家の用事により、１１月の３日から７日まで日本にいないです。大変申し訳ないのですが、何か連絡があれば [[こちらに書かれたアドレス>harry_sub]]にお願いします。（すぐに返事できない場合もありますが） -------- 進行状況報告（２）－－－１２月１日 -------- ずっと更新していなくて本当に申し訳ございません。 進行状況ですが、アセンブラは完成しました。 これからシミュレーターをやる感じです。 本当に作業が遅くて大変申し訳ございません。 -アセンブラの方はすぐ動きますか？シミュレーターは一応作ったものがありますので(機能は少ないです)、月曜の空き時間なり木曜の放課後なりに、一度テストしてみて、そもそも正常に動くかどうか確かめ、また今後どのような機能を追加すべきかを決めたいと思うのですが。(buyobuyon) -返事遅れて申し訳ございません。 一応適当にコードを書いてテストした結果とりあえず動くみたいです。 コードと結果を以下のようになりました。(harry) コード： hi r1,100; hi r2,200; add r1,r2,r3; addi r1,r2,1; fadd r1,r2,r3; sqrt r1,r2; in r1,1203; load r1,r2; 結果： DEPTH = 256; WIDTH = 32; ADDRESS_RADIX = HEX; DATA_RADIX = BIN; CONTENT BEGIN [00..7F] : 000000000000; 00 : 10000000100000000000000001100100;-- 80800064 01 : 10000001000000000000000011001000;-- 810000C8 02 : 00000000100000000001000000110000;-- 801030 03 : 00000000100001000001000000000001;-- 841001 04 : 01000000100000000001000000110000;-- 40801030 05 : 01000000101000000001000000000000;-- 40A01000 06 : 10000000110101000000010010110011;-- 80D404B3 07 : 10000000110000000001000000000000;-- 80C01000 08 : 00000000000000000000000000000000;-- 0 09 : 00000000000000000000000000000000;-- 0 0A : 00000000000000000000000000000000;-- 0 0B : 00000000000000000000000000000000;-- 0 0C : 00000000000000000000000000000000;-- 0 0D : 00000000000000000000000000000000;-- 0 0E : 00000000000000000000000000000000;-- 0 0F : 00000000000000000000000000000000;-- 0 10 : 00000000000000000000000000000000;-- 0 11 : 00000000000000000000000000000000;-- 0 12 : 00000000000000000000000000000000;-- 0 。。。以下省略 -------- 12月9日 ---------- うん、あまり進んでいません（＞＿＜） ぶよぶよんが作ってくれたシミュレータのプログラムを大体読んでみた でも同時進行よりもまずアセンブラを完成させることを優先するように言われたのでその通りにします。 -------- １２月１７日 風邪を引いてほとんど進まず。。。 とりあえずアセンブラのジャンプを実装しました。 まだテストしていません。。。 -------- -------- １月３日 あけましておめでとうございます。 大学生活の最後の年になりましたね。 今年はが皆さんにとっていい年でありますように～☆ 昨日は久しぶりに地下に行きました。思った通りに誰もいなかった。大学キャンパスの中にも何人いるんだろう？っていう感じでした。。。 そしてなぜか無線は繋がるのに、有線は繋がらなくなってしまった。なんでだろう？？？（＞＿＜） 年末はたまりまくった課題に手を付けました。って、未だに終わらず。。。 昨日はアセンブラのジャンプなどのテストをしてみました。大丈夫そうな感じでしたけど、 えーと、ちょっと不明な点がありました。 displacement上位７ビットと下位１９ビットって２４ビットも使うってことなのかな？？ そこまで使うことってあるのかな？ あとラベルとかを使わずにジャンプとか条件分岐はほとんどdisplacementを使うってことですよね？ 一応命令セット通りに実装したつもりでした。 ↑ごめんなさい、書き方が悪かったですね。ジャンプや条件分岐もアセンブリ言語ではラベルを用いて表記するようにし、アセンブラがラベルからdisplacementを計算してくれるようにしていただけるとありがたいです。(buyobuyon) ＞ displacement 24bit(26bit?) SRAMのアドレスが20bitだから最大20bitで良いはずだと思いますー。 どっちにしろdisp19じゃたりないけど…。 大ジャンプ（最上位1）と小ジャンプ（最上位0）に命令を分けるとかすればdisp19でことたりるようになるけど、コンパイラさんの手間が増えてしまうだけかなぁと。(yastak) あれ？コンパイラが出すコードは番地でなくラベルを扱うので、大ジャンプ（最上位1）と小ジャンプ（最上位0）に命令を分けた場合には、アセンブラさんの手間の方が増えません？(buyobuyon) あ、そうですね。勘違いしていました…。ラベル使うならアセンブラの段階で分かれますね…。 コンパイラのはく命令がJMPH imm/JMP immに分かれるのかなぁというイメージでした。 (yastak) --------------- --------------- １月１２日 アセンブラでレジスタ関係でとんでもないミスをしたことが分かった。。。（＞＿＜） 幸いすぐに直せるものでよかったよかった。 命令セットの意味がようやく分かって、今週中にアセンブラを直して完成したいと思います。 シミュレータのFPUの部分はとりあえずfloatで直接計算するようにします。後で単精度などを読んで、 シフトを利用したバージョンも作りたいと思います。 色々と教えてくれた班の皆さんに感謝感謝です。 あとテスト勉強と連続系のたまった課題を消化しなくては。。。 ------------ ------------ 1月17日 アセンブラのジャンプと条件分岐を中心に色々とテストしました。 テストしたものは全部大丈夫でした。 いくつかの結果を張っておきます。 ソースファイル： :first; hi r2,200; :second; add r1,r2,r3; addi r1,r2,1; fadd r1,r2,r3; :third; sqrt r1,r2; jmp second; jmpl first; jmpr r2; jmprl r1; beq r1, first; bne r2, second; bgt r3, third; ret ; end ; 実行結果： [hari@localhost ~]$ ./assem source.txt result.txt jmp label OK--label[1], num: 1, content: second; jmpl label OK--label[0], num: 0, content: first; beq label OK--label[0], num: 0, content: first; bne label OK--label[1], num: 1, content: second; bgt label OK--label[2], num: 4, content: third; ret end there is no error assembly finished 出力されたファイル： 00 : 10000001000000000000000011001000;-- 810000C8 01 : 00000000100000000001000000110000;-- 801030 02 : 00000000100001000001000000000001;-- 841001 03 : 01000000100000000001000000110000;-- 40801030 04 : 01000000101000000001000000000000;-- 40A01000 05 : 11000000011000000000000000000001;-- C0600001 06 : 11000000011010000000000000000000;-- C0680000 07 : 11000000001000000001000000000000;-- C0201000 08 : 11111111101010000000100000000000;-- FFA80800 09 : 11000000100000000000000000000000;-- C0800000 0A : 11000001000010000000000000000001;-- C1080001 0B : 11000001100100000000000000000100;-- C1900004 0C : 11000000001100111111100000000000;-- C033F800 0D : 11000000001110000000000000000000;-- C0380000 0E : 00000000000000000000000000000000;-- 0 0F : 00000000000000000000000000000000;-- 0 。。。 -------- --------- １／２６ テストが近づいていますよね。。。（＞＿＜） シミュレータの FPUのとこ一応ほとんど作ったけど、 なぜか微妙に期待した値とずれたり。。。 たとえば５．０００００００００００になるべきところが４．９９９９９９９９９９９９９９とかになったり。。。 日曜日に発表資料を作りたいので、土曜日の２４時までに[[中間発表３]]のページに書き込んで頂ければ幸いです。 原因は分からないけど型をfloatにしているから誤差が出てきてしまった、とかかな？ 分からないようでしたらテスト前でも後でもいつでもいいので見せてください。(tsuy) たぶんその辺だと思います。ありがとうございます。 さっき津田くんがPerlで書いたファイルを読みました。 ほぼ似たようなのことをやっている感じだが、ずっと簡潔なコードに感心しています。 これを参考にさせて頂ながら自分の書いたコードをきれいにしてみます。 （はりー＠地下) ------------ ------------ 2/14 試験お疲れ様＆お久しぶりです。 シミュレータのFPUの誤差のところのバグが取れました。 非正規数とかのエラー処理をまだ全然していないので、それらを追加してからアップロードします。 集中講義に参加してしまったため、暫くの間平日は結構埋められているけど、平日の夕方や土日中心に頑張りたいです。えーと一応17日土曜日は地下に行く予定で、シミュレータのファイルをできれば今週中にアップロードする予定です FPU部分の非正規化数の処理なのですが、コンテストのルールでは要らないそうなのでFPUではサポートしていない（非正規化数が絡む処理の挙動は未定義）んですよね。だからシミュレータでも非正規化数の処理は入れない方がいいような気がするんですが、どうなんでしょうね？(tsuy) 分かりました。ありがとうございます。 えーとFPUの部分についてちょっと聞きたいことがありますけど、tsuyさんはいつ地下に行く予定ですか？ （はりー） 16日以降の午後なら時間を指定してくれればいつでも地下に行けます。曜日もいつでもいいです。(tsuy) アセンブラについてなのですが、次のように、ラベルが算術演算命令のオペランドとなるような場合には正しく機械語に翻訳できます？ addi r1, r0, func; jmprl r1; end; :func; ret; クロージャ経由の関数呼び出しや、外部変数の読み込みの際に、このような形が現れるのですが…。(buyobuyon) To tsuy 17日の午後～2時半、または5時以降はいかがでしょうか？（２時半～5時に一応バイトが入っていますが、時間調整ができますので、そちらの都合のいい時にあわせます） To ぶよぶよん 今のアセンブラだとできないと思います。 土日に直します。 To yastak 命令の変更は一箇所だけですよね？ こちらも明日に地下に行って直します よろしくお願いします。(buyobuyon) 先ほどの、少し訂正。 mov r1, func; jmprl r1; end; :func; ret; addiを仮想命令movに置き換えました。 (ラベルが32bit値なのに、addiの定数部が32bitでないことを忘れていました…。) 仮想命令movを、命令hiとaddiに置き換えるのは、 アセンブリ側にお任せしてしまってよろしいですか？ これをコンパイラでやろうとすると ラベルの処理までコンパイラでやる必要が出てきてしまうので…。(buyobuyon) 17日午後はできるだけ地下にいるようにします。2時半に間に合うか分かりませんが、少なくとも5時にはいると思います(tsuy) To tsuy 分かりました。ありがとうございます。 早めに戻れるようにバイトの時間を調整します。 ではまた五時ころにお願いしますね＠地下 （はりー） To buyobuyon mov命令ですが、ちょっと質問がありました。詳細はそちらのページにかき込みました。(m_m) (harry) ども。 シミュレーションで、アセンブリを使いたいので、最新版UPしてくださいm(_ _)m 因みに、現在UPされているのをつかってみたのですが、 addi r1,r2,-1 などど、即値のところにマイナス値を入れると出力ファイルに FFFFFFF...というall 1の命令が出力されてしまいました。 バグかなぁ？ (yastak) #comment(vsize=2,nsize=20,size=40) 2009-06-07T10:59:25+09:00 1244339965 中間発表2 https://w.atwiki.jp/ttth/pages/21.html 12月の第2回中間発表のページです。 >コンテストでレイトレを動かすというゴールを成就するために >必要な事のうち、現時点までに完了した事と、これから行わねば >ならない事が何か、できるだけ具体的に伝わるようまとめて下さい。 とのことですので、みなさん現在の進捗と今後の予定の書き込みをこのページにお願いします。 とりあえず、12/8(金)24：00を書き込み締切として、12/9(土)24：00までに作成した資料をupします。 それを見て何かあれば12/10(日)、&strike(){15：00}24:00までにこのページに書いて頂いて、発表までに訂正したいと思います。 ここの書き込みをほぼそのまま資料に使う予定ですので、そのつもりでお願いします。 (当初の予定では12月中にレイトレ完動ということでしたが、みなさん間に合いそうでしょうか。 僕は間に合いそうにないのですが…) **ハードウェア -FPU >10月、11月で10種類の命令を実装　今月中に実際に使用する命令を選び、精度等のテストを行う予定 -その他 >USBはechoが動作。 >SRAM回路は書きました。これからテスト予定。 >CPU本体は前回の中間発表から進んでいないです。 >SRAMが動き次第着手予定。動かなくても煮詰まったら着手予定。 **ソフトウェア -ライブラリ >全く手をつけていない状態　FPUが終わり次第着手したい -アセンブラ ほぼ完成。これから不足の部分を補って、テストする予定 -シミュレータ FPUの部分を追加して、テストする予定 **コンパイラ >だいたいの仕様・方針はMinCamlと同様 >Ｃ言語で一から作成 >現時点で、Ａ正規化まで実装完了 >最適化などは後まわしにし、とりあえず動くコンパイラを12月中には完成させる - 今年中にライブラリまで終わりそうにないのですが、やらせてもらっていいんですかね？ -- tsuy (2006-12-08 20:27:22) - 発表時間が10分ももたないと思うんですが、進捗と予定以外に何かネタありますか？ -- tsuy (2006-12-08 20:30:44) - コンパイラは順調にいけば12月中に終わる「かもしれない」といった感じです。 -- buyobuyon (2006-12-08 21:37:55) - とりあえずはコンパイラを優先させますが、ライブラリもちょっと書いてみたい気がします。 -- buyobuyon (2006-12-08 21:39:11) - 前回の発表からアーキテクチャには変更がないですし、まだ高速化というよりもとりあえず動くものを作っている段階ですから、進捗と予定を話すだけで良いと思うのですが…。 -- buyobuyon (2006-12-08 21:49:40) - ライブラリはtsuy氏の負担にならなければお願いしたい…と思っています。&br()実際には私も年内に終わるか怪しいので手伝えるかが微妙です…。申し訳ないです(>_<) -- yastak (2006-12-08 23:56:47) - アセンブラの機能追加とシミュレータのFPU追加はまだはっきりと&br()分からないのですが、出来るだけ年内に終わらせたいと思います。&br()ライブラリー出来るかどうかかなりあやふやですが、アセンブラと&br()シミュレータが終わり次第、ライブラリーの勉強をしてみて、&br()少しでもお手伝い出来たらと思います。 -- harry (2006-12-09 12:23:46) - 中間発表用の資料をアップロードしました。&br()ご意見ご感想は10日中は受け付けますので、このページにお願いします。 -- tsuy (2006-12-09 23:24:37) - ライブラリの件は、とりあえず僕の担当としておいて、手が空いた方に&br()手を貸して頂くという感じでよさそうですね。 -- tsuy (2006-12-09 23:26:54) - ハードウェアのFPU以外の部分の名称を勝手に「制御部」としましたが、&br()これでいいですかね？ -- tsuy (2006-12-09 23:28:08) - 進捗と予定のほかに、前回発表からの変更点（12月中に終わらない？）を加えてみたのですが、どうでしょうか。&br()暫定的にコンテストまでにレイトレ完動と書きましたが、もっと早い時期がいいだとか、&br()そもそもそんなこと書かなくていいだとか意見がありましたら、こちらにお願いします。 -- tsuy (2006-12-09 23:35:02) - げっ、odp… -- buyobuyon (2006-12-09 23:43:41) - ぎゃ～、バッテリーが切れたからって、いきなり「ぶちっ」はひどいだろ～ -- buyobuyon (2006-12-09 23:44:57) - ACアダプターをさして再起動しています。少々お待ちください。 -- buyobuyon (2006-12-09 23:45:36) - と書き込んでいるのはWindowsマシンで、こちらはパワーポイントが入っているもので、odp形式が読めないのですよ…。 -- buyobuyon (2006-12-09 23:46:13) - 「CPU本体はSRAMが動くか煮詰まったら着手予定」ってところが変に改行されていてちょっとわかりにくいかな。&br()強引に一行に収めるか、もしくは文字列 &quot; -- &quot; か何かを各文の先頭に入れた方がいいかな。 -- buyobuyon (2006-12-09 23:50:19) - うん、やっぱり全体的に箇条書きの先頭に &quot; -- &quot; とか &quot; ・ &quot; みたいな文頭識別子を入れておいた方がわかりやすいかもしれない。 -- buyobuyon (2006-12-09 23:55:04) - アセンブラの「ジャンプを追加」ってところ、進捗状況を知らない人がいきなり見たら意味がわからないかもしれない…。&br()とはいえ、何て書けばいいんだろう…。 -- buyobuyon (2006-12-10 00:03:46) - う～ん、文句をつけておきながら、代替表現が思い浮かばない。&br()たぶん「ジャンプ」といきなり言われるのがわかりにくいと感じたのだと思うので、&br()あまり具体的に書かずに、「不足部分を補って…」みたいな感じで書けば良いのかな…？&br()う～ん、わからん。私の国語力ではこの程度なので、誰かよろしく～。 -- buyobuyon (2006-12-10 00:17:41) - 「アーキテクチャに変更は無し」ってところ、具体的な話が全部レジスタのことなので中途半端な気がする。&br()RISCとか、パイプラインとかも含めて、全て書いてしまうか、もしくは具体的なことは何も書かないようにした方が良いか、&br()と思ったのですがどうでしょうね。 -- buyobuyon (2006-12-10 00:21:42) - 「レイトレ完動」後に最適化をしないといけないから、&br()完動が今月中は無理だとしても、「コンテストまで」はちょっと危険かもしれない。&br()「次の中間発表までには」くらいにしておいた方が良いのではないかと思うのですがどうでしょう？&br()とか言いつつ、コンパイラの完成が最後になってそうな気がする…。 -- buyobuyon (2006-12-10 00:26:45) - あと、今月中にはここまで終わらせようっていう中間目標があった方が良いと思います。&br()とは言っても何を目標にすれば良いのだろう？実機でfib完動とかだとちょっと微妙かな…。 -- buyobuyon (2006-12-10 00:30:43) - 何かすみません、自分がやる部分でないからといって、いろいろと注文をつけてしまって…。&br()でも細かいところは気になるところもありましたが、全体的な発表の流れはこんな感じで良いと思います。&br()tsuyさん、連続系課題締め切り前の大変な時に、ありがとう。 -- buyobuyon (2006-12-10 00:35:56) - いくらか変更したものをアップしました(pre12ver2.odp)&br()中間目標などについてはもう少し意見が出てからにします。 -- 名無しさん (2006-12-10 01:12:25) - >いくらか変更したものをアップしました&br()どうもすみません、私の仕事なのにありがとうございます。 -- tsuy (2006-12-10 03:04:14) - >たぶん「ジャンプ」といきなり言われるのがわかりにくいと感じたのだと思うので、&br()あまり具体的に書かずに、「不足部分を補って…」みたいな感じで書けば良いのかな…？&br()&br()そうですね。ご意見ありがとうございます。(m_m)&br()その通りに直しました。 -- harry (2006-12-10 20:34:11) - すみません、土日ともパソコンつけられていない状況でした…。&br()現在も.odpは開けない状況…。&br()コメントできなくてすみません…。&br()あ、FPU以外は制御部で構わないと思いますー！ -- yastak (2006-12-11 01:03:22) - odpはあまり良くなかったようですね…&br()知りませんでした、すみません&br()&br()レイトレ完動の目標時期については特に意見は無いようなので次の中間発表まで&br()にしたいと思います。次って一月でしたっけ？ -- tsuy (2006-12-11 03:04:45) #comment(vsize=5,nsize=20,size=50) 2009-06-07T10:59:11+09:00 1244339951 FPU関連の質問 https://w.atwiki.jp/ttth/pages/14.html *FPU・ライブラリ関連の質問等 なんかcollisionして書き込みに失敗することが多かったので、 意見を書き込むところを勝手に分離しました。([[buyobuyon]]) - そうですね。&br()確かコンテストルールでは指数部が1～254で表される数と+0が適切に表現されていれば&br()良いのでしたよね(あまりよくルールを読んでいないので間違っているかも…)。&br()あと、-0をどうするかについてちょっと気になっているのですが。&br()-0があると整数と同じ方法で比較が行えないことをすっかり忘れていて、&br()浮動小数の比較命令を用意していなかったのですが…。&br()一般にはどのように扱われているようですか？ -- buyobuyon (2006-10-24 22:21:13) - 丸め方式は…、詳しくないのでよくわからないのですが。&br()なんか感覚としては、銀行で使われるとk林先生が仰っていたあの丸め方式が、&br()一番誤差が少なくなりそうな気はするけど、&br()Firexhlとかで部分的に切り捨て方式が使われているということは、&br()たぶん速度の面で問題があるのでしょうね。&br()どうしましょう…。 -- buyobuyon (2006-10-24 22:33:01) - -0…。&br()１．使わない&br()２．検出したら+0に変える&br()３．特別扱いでcmpを実装&br()とかですかねぇ。&br()1,2は本質的にそんなに変わらないのかな？&br()3はできなくはないと思うのですが回路的にどうなんだろう？（よくわからんです） -- yastak (2006-10-25 14:22:52) - コメント書き込もうとしたら、collision起こして、書いたことすべて消えてしまった(; ;) -- buyobuyon (2006-10-25 15:26:31) - 改めて…。&br()-0の件ですが、やや勘違いしていました。&br()　 -0があると整数と同じ方法で比較が行えない → 負の値があると整数と同じ方法で比較が行えない&br()でした。すみません。&br()そういうわけで、結局、浮動小数点数比較命令flessが必要だと思います。&br()flessを作成するとなると、-0ありにして、-0 < +0という扱いにすると良いかと。&br()簡単だし。ルール違反じゃないよね？&br()それから、浮動小数点数では=による比較は+-0との比較以外は普通使わないでしょうし、&br()+-0との比較は0x80000000Uとのxorをとることで代用できますし、&br()(もしどうしても必要なときは)0以外との比較は not(a > b or a < b)で代用できますので、&br()浮動小数点数比較命令は<だけあれば良いと思います。&br()&br()というのが今の私の見解なのですが、どうでしょう。素人の意見なので、あまり信用しないでね。 -- buyobuyon (2006-10-25 15:33:37) - flessの仕様について。整数比較命令の仕様を決めるときには、とりあえず、&br()　　真 → -1 (0xffffffffU) , 偽 → 0 (0x00000000U)&br()としましたが、特に意味があってのことではないので、&br()整数比較とflessとで形式があっていれば別に-1でも1でも良いかと。&br()とは言いつつも、何となく-1の方が使い勝手がよさそうに見えるかな…。 -- buyobuyon (2006-10-25 21:33:01) - ごめん、比較結果をnotしたときに真偽が入れ替わるようにしたかったから&br()　真 → -1&br()としたのでした。-1でお願いします。 -- buyobuyon (2006-10-25 21:55:00) - FDIVの仕様で、「±0で割る場合、出力の符合はSRC1の符号と一致」としているけど、&br()0以外で割る場合と同様に、被除数の符号と除数の符号のxorをとって商の符号とした方が&br()自然じゃないかな？ -- buyobuyon (2006-11-17 01:22:07) - 自然だとは限らなさそうだな…。&br()う～ん、-0がよくわからない…。-0に関しては、&br()・演算の答えとしては-0を生成しないようにする&br()・同じ値の引き算など、ちょうど0になる場合には+0と決めておき, それ以外なら答えの符号に応じて+0か-0かを決める&br()のどちらかの方針をとることになると思うんだけど、今回はどっちの方針をとっているのかな？ -- buyobuyon (2006-11-17 01:37:59) - とりあえずは「演算の答えとしては-0を生成しないようにする」という方針で行っています。&br()tsuyのページの仕様の各命令の部分を見ていただければ分かるかと。&br()また、「同じ値の引き算など、ちょうど0になる場合には+0」になるようにしています。&br()とにかく、FPUからの出力が-0となることは無いように気をつけています。（実装で漏れがあるかもしれませんが）&br()&br()「それ以外なら答えの符号に応じて+0か-0かを決める」&br()この部分がよく分からないんですけど、「それ以外」って「ちょうど0に」ならない場合？&br()0にならないのなら+0にも-0にもならないような…　読解力なくてすいません -- tsuy (2006-11-17 17:59:19) - 昨日地下で聞いたときには、&br()&br()「±0で割る場合、出力の符合はSRC1の符号と一致」でいいんじゃない？&br()&br()的なことを言ってたではないですか＞＜； -- tsuy (2006-11-17 18:05:00) - あっ、すみません。-0を生成しない方針をとっているのならいいんです。&br()&br()ちなみに、 「それ以外」 = 「ちょうど0でない」 というのは、&br()計算した値の指数部がfloatで表せる範囲を(下に)超えてしまって、その結果、&br()答えが+0か-0になった場合(NaNじゃなくて±0になるんでしたよね)のことを、言っていたつもりでした。&br()FMULの仕様のところに、「オペランドの少なくとも一方が±0のとき、出力は+0」と書いてあったので、&br()どちらのオペランドも±0でないが答えが±0になる場合には、出力が-0になることもあるのかな、と勘違いしていました。 -- buyobuyon (2006-11-17 23:44:43) - > 「±0で割る場合、出力の符合はSRC1の符号と一致」でいいんじゃない？&br()> 的なことを言ってたではないですか＞＜；&br()&br()そうだっけ…、ごめん。&br()FPUが-0を出力しない以上、SRC2に-0が入っているのは、&br()ユーザーがわざわざそのレジスタに+0でなく-0を入れた場合だから、&br()出力の符号をSRC2の符号にも依存させた方がいいと思います。その方が、SRC2が-0の場合でも&br()　出力の符号 = SRC1の符号 xor SRC2の符号&br()が成り立つから、例外的な処理が減って、回路が小さくなるような気もするし。 -- buyobuyon (2006-11-18 00:01:55) - >FPUが-0を出力しない以上、SRC2に-0が入っているのは、ユーザーがわざわざそのレジスタに+0でなく-0を入れた場合&br()&br()なるほど、了解しました。&br()次回地下に降りたときにでも修正しておきます。&br()&br()>計算した値の指数部がfloatで表せる範囲を(下に)超えてしまって&br()&br()ここを読んで一部の命令にオーバーフローやアンダーフローしたときの処理を入れ忘れていることに&br()気づいてしまった…&br()さらに回路サイズが大きくなるんだね…&br() -- tsuy (2006-11-18 17:42:10) - なるほど、アンダーフローが実装されていなかったから話がかみ合わなかったのか…。 -- buyobuyon (2006-11-18 20:50:21) - 正規化数のみサポートすることにしたのですが、&br()　･INVに０、FINVSQRTに負の数を入力したときの処理&br()　･オーバーフロー、アンダーフロー&br()はどうしましょうか？&br()特にオーバーフローアンダーフローをなくせば、命令によってはかなり高速化できそうなのですが… -- tsuy (2006-12-14 23:55:19) - ライブラリなのですが、やはりある程度私が関与した方が良いのですかね。&br()というのは、例えば、ライブラリ内部で使用しているlfabs関数、&br()これは最上位ビットを0にする命令(and)で置き換えられますけど、&br()OCamlやMinCamlだと、型の関係でそういう処理は表せないですよね。&br()とすると、&br() 1.ライブラリで作成する関数やライブラリ内部で用いる関数の一部をはじめからアセンブラで書く&br() 2.MLで書いたライブラリをコンパイルし、生成されたものを一部修正する&br() 3.自作コンパイラで記述できる構文を増やす(float同士のandなどを追加?)。&br() 4.諦めて、MLで記述できる構文のみで書く&br()のどれかですよね…。どうします? -- buyobuyon (2007-01-11 14:36:14) - ライブラリのニュートン法で初期値を与えるところに大量の比較・分岐命令が入っていますが、&br()例えばテーブルを作成するとか、適当な(かつ簡単な)連続関数の値を初期値とするなどの方法で、&br()分岐命令数を減らせませんかね?&br()無理そうなら、if{ }elseif{ }elseif{ }elseif{ }...を&br()if{if{...}else{...}}else{if{...}else{...}}みたいに書き換える、&br()使用頻度の高い分岐先には少ない回数の分岐で飛べるようにifの順番を変える、&br()などの方法で平均実行命令数は減らせば良いとは思いますが。&br()&br()とは言っても、高速化は精度などの問題を突き詰めてからの話でしたね。&br()&br()あと、それに関連して、浮動小数点数の指数部分を取り出して整数型の値にするような&br()命令はあった方が良いのかな?&br()今ある命令の組合せで簡単に書けるけど、やはりOCamlでは表現できなかったり…。 -- buyobuyon (2007-01-11 15:49:35) #comment(vsize=5,nsize=20,size=80) 2009-06-07T10:58:56+09:00 1244339936 tsuy https://w.atwiki.jp/ttth/pages/13.html ●ＦＰＵ・ライブラリ進捗(3/14) 　・今日はライブラリを見直しました 　　－繰り返しの回数を減らし、極力定数の計算を減らしました。 　　　変更の影響のあったsin,cos,atanについてランダムな100万パターンの 　　　テストを行いました。lib-03-14.mlで上げておきます。 #comment(vsize=9,size=60) [[FPU関連の質問]] ●ＦＰＵ今のところの仕様 entity FPU is 　　port(SRC1,SRC2　: in std_logic_vector(31 downto 0); 　　　　　FUNC　　　　　: in std_logic_vector(3 downto 0); 　　　　　CLK　　　　　　:　in　std_logic; 　　　　　START　　　　:　in　std_logic; 　　　　　FIN　　　　　:　out　std_logic; 　　　　　OUTPUT　　　: out std_logic_vector(31 downto 0)); end FPU; 　・FUNCに対応したcomponentからの出力をOUTPUTに出力 　・STARTはFPUを使用する場合最初の2clock間'1'に、それ以外は'0' 　・CLKの立ち上がりにFINが'1'になる時点でOUTPUTから結果が出ている 　・指数部が1～254が正規化数 　・指数部が0の数はすべて0 　・指数部が255の場合は 　　－仮数部が0のとき±∞ 　　－仮数部が0でないときNaN 　・以下では、 　　－+Inf　 = "0　11111111　00000000000000000000000"(+∞) 　　－-Inf　 = "1　11111111　00000000000000000000000"(-∞) 　　－Nans = "0　11111111　10000000000000000000000" 　　とする。 　・上記の非正規化数のサポートは一応行ったが、最終的には外した 　・FADD 　　－動作確認済み。 　　－オペランドの符号が異なる場合は適切な処理後、FSUBに投げる。 　　－仮数部を Gbit切り上げ により丸め 　　－(±0)　+　(±0)　=　+0(複号任意) 　・FSUB 　　－動作確認済み。 　　－オペランドの符号が異なる場合は適切な処理後、FADDに投げる。 　　－仮数部を Gbit切り上げ により丸め 　　－2つのオペランドが同じ値である場合には、+0を出力。（IEEE 754に準拠） 　　－(±0)　-　(±0)　=　+0(複号任意) 　・FMUL 　　－動作確認済み。 　　－仮数部を　Gbitの切り上げ により丸め 　　－オペランドの少なくとも一方が±0のとき、出力は+0 　・FLESS 　　－trueなら"11111111111111111111111111111111" 　　　falseなら"00000000000000000000000000000000"を返す。 　　－&strike(){　-0 < +0　とする。}指数部8bitが0であれば同じ0.0として扱う 　　－動作確認済み。 　・ITOF 　　－Gbit切り上げ 　・FTOI 　　－小数点以下四捨五入 　　－結果がsigned intの最大値(最小値)を超える場合はINT_MAX(INT_MIN)を返す 　　－　+0.0 -> +0 , -0.0 -> +0 　　－&strike(){NaN　を受け取った場合は +0 を出力} 　・FDIV 　　－4bitずつの引き算の繰り返しでCLKを使わず実装 　　－この実装がまずい場合は作り直す 　　－0で割ったときにはNans(="0　11111111　10000000000000000000000")を返す 　　－丸めは今のところは行わない(Gbit、Rbitは作ってあるので必要ならすぐ実装できる) 　　－(±0)　÷　(±0)　=　+0　(複号任意) 　　－(±Normal)　÷　(±Inf)　=　+0　(複号任意) 　　－(±0)　÷　(±Normal)=　+0　(複号任意) 　　－(±0)　÷　(±Inf)　=　+0　(複号任意) 　　－±0で割る場合、出力の符合はSRC1の符号と一致 　　　->(-5)　÷　(-0)　=　-∞ 　　－結局不使用 　・SQRT 　　－2bitずつ筆算の様に計算する方式 　　－入力が負(-0含む)ときにはNans(="0　11111111　10000000000000000000000")を出力 　　－仮数部をround evenで丸め 　　－結局不使用 　・FINVSQRT 　　－&strike(){SQRTとFDIVで計算}ニュートン法により実装 　　－入力が負のときの出力は絶対値を入力としたものとなる 　　－入力が0.0のときは0.0を出力 　　－&strike(){仮数部をround evenで丸め}Gbit切り上げ 　・INV 　　－ニュートン法で実装 　　－仮数部を　Gbit切り上げ　により丸め 　　－結局不使用 下記の表について、非正規化数のサポートは最終的に行わない予定 |RIGHT:SRC1|RIGHT:SRC2|RIGHT:｜|RIGHT:FADD|RIGHT:FSUB|RIGHT:FMUL|RIGHT:FDIV|RIGHT:FLESS| |RIGHT:Normal|RIGHT:Normal|RIGHT:｜|RIGHT:Normal|RIGHT:Normal|RIGHT:Normal|RIGHT:Normal|RIGHT:t or f| |RIGHT:Normal|RIGHT:+Inf|RIGHT:｜|RIGHT:+Inf|RIGHT:-Inf|RIGHT:+Inf|RIGHT:+0|RIGHT:true| |RIGHT:Normal|RIGHT:-Inf|RIGHT:｜|RIGHT:-Inf|RIGHT:+Inf|RIGHT:-Inf|RIGHT:+0|RIGHT:false| |RIGHT:+Inf|RIGHT:Normal|RIGHT:｜|RIGHT:+Inf|RIGHT:+Inf|RIGHT:+Inf|RIGHT:+Inf|RIGHT:false| |RIGHT:-Inf|RIGHT:Normal|RIGHT:｜|RIGHT:-Inf|RIGHT:-Inf|RIGHT:-Inf|RIGHT:-Inf|RIGHT:true| |RIGHT:NaN|RIGHT:Normal|RIGHT:｜|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans| |RIGHT:Normal|RIGHT:NaN|RIGHT:｜|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans| |RIGHT:+Inf|RIGHT:+Inf|RIGHT:｜|RIGHT:+Inf|RIGHT:Nans|RIGHT:+Inf|RIGHT:Nans|RIGHT:Nans| |RIGHT:+Inf|RIGHT:-Inf|RIGHT:｜|RIGHT:Nans|RIGHT:+Inf|RIGHT:-Inf|RIGHT:Nans|RIGHT:false| |RIGHT:-Inf|RIGHT:+Inf|RIGHT:｜|RIGHT:Nans|RIGHT:-Inf|RIGHT:-Inf|RIGHT:Nans|RIGHT:true| |RIGHT:-Inf|RIGHT:-Inf|RIGHT:｜|RIGHT:-Inf|RIGHT:Nans|RIGHT:+Inf|RIGHT:Nans|RIGHT:Nans| |RIGHT:NaN|RIGHT:±Inf|RIGHT:｜|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans| |RIGHT:±Inf|RIGHT:NaN|RIGHT:｜|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans| |RIGHT:NaN|RIGHT:NaN|RIGHT:｜|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans|RIGHT:Nans| |RIGHT:SRC|｜|RIGHT:SQRT|RIGHT:FINVSQRT|RIGHT:FTOI|RIGHT:INV| |RIGHT:+Normal|｜|RIGHT:+Normal|RIGHT:+Normal|RIGHT:+integer|RIGHT:+Normal| |RIGHT:-Normal|｜|RIGHT:Nans|RIGHT:Nans|RIGHT:-integer|RIGHT:-Normal| |RIGHT:+Inf|｜|RIGHT:+Inf|RIGHT:+0.0|RIGHT:INT_MAX|RIGHT:+0.0| |RIGHT:-Inf|｜|RIGHT:Nans|RIGHT:Nans|RIGHT:INT_MIN|RIGHT:+0.0| |RIGHT:NaN|｜|RIGHT:Nans|RIGHT:Nans|RIGHT:0|RIGHT:Nans| |RIGHT:+0.0|｜|RIGHT:+0.0|RIGHT:Nans|RIGHT:0|RIGHT:+Inf| |RIGHT:-0.0|｜|RIGHT:Nans|RIGHT:Nans|RIGHT:0|RIGHT:-Inf| ○過去の進捗 ●3/13 　・[[buyobuyon]]氏にご指摘いただいた部分を訂正しました。 　　－訂正した部分は、fpu-sim-03-13.zipにまとめてあげておきます。 　・FADD,FSUBがまずいようなのでしばらくソースを見てみます 　・とりあえず現時点でのFPUのソースを上げておきます。(fpu-03-13.zip) 　　－サイズ27%、Slices　1277/5120（24%） 　　－最長の遅延時間は 　　　1クロック命令で16.500ns 　　　2クロック命令で29.042ns 　　　5クロック命令で91.188ns - シミュレート関数の方も、変更に対応しておきました。&br()一応、buyobuyonのページにあげておきました(raichu_fpu.c)。&br()FADDとFSUB…、本当に何なのでしょうね？&br()何回か書き換える際にチェックしてきたのですが、&br()特にまずそうな点は見つからないのですよね…。 -- buyobuyon (2007-03-13 19:39:15) - 入力が0.0の場合のあらゆるパターン(+-や入力のどちらが0.0か)と&br()入力が0.0でない場合の符号についてのあらゆるパターン(加算器、減算器どちらを使うかや&br()どちらの入力の絶対値が大きいか)について、手計算とModelSim上の波形のテストをしてみました。&br()でもやっぱり問題は見つからないんですよね…。&br()シミュレート関数のほうも見てみます。 -- tsuy (2007-03-13 19:56:29) - 試しに、符号が同じ値同士の加算の丸めをいわゆる銀行丸め方式に&br()してレイトレを実行してみたのですが、結果は変わらず…。&br()となると精度とかの問題ではなく、何らかの例外を見逃していることに&br()なると思うのですが…、何だろう…。&br()銀行丸めのやり方を間違えた可能性もありますが…。 -- buyobuyon (2007-03-13 20:10:50) - ごめんなさい、とんでもない勘違いをしていたようです。&br()私のシミュレート関数で、C言語の論理シフトの法を考慮していなかったのが悪かったようです。&br()&br()いろいろ試してみたら、何か非常に複雑なことになっていて、&br()(0xffffffffU << 32)のようにシフト量が定数の場合は、(定数 mod 256)だけ左シフトして、&br()(0xffffffffU << p)のようにシフト量が変数の場合は、(変数 mod 32)だけ左シフトするみたいです。&br()しかもひどいことに、p = 43; (0xffffffffU << p)のようなことをすると、&br()定数畳み込みされるらしく、(43 mod 256)だけ左シフトされる、すなわち値は0になるみたいです…。&br()&br()いろいろとお手数おかけいたしました。&br()とりあえずシフト部分を全て修正してみます。 -- buyobuyon (2007-03-13 20:56:18) - なんとも複雑な文法ですね…&br()ともあれ、白い点の問題は解消されたようで何よりです。 -- tsuy (2007-03-13 21:32:57) - なんとも複雑な…。&br()というか、そこに気づいたbuyobuyon氏もすごいですね…。&br()お疲れ様ですm(_ _)m -- yastak (2007-03-13 23:55:28) ●3/12 　・ITOFなど、Gbitの切り上げを行う命令で指数部が1増える場合の処理を忘れて 　　いたので追加しました。 　　－ITOFでは遅延時間が18.7nsにまで増え、どうなることかと思いましたが、 　　　その後制約なしで16.3nsにまで減りました。いいアイデアをくれたbuyobuyon氏に 　　　感謝です。これで1クロックで動くといいのですが。 　　－FMULの遅延時間も増えましたが、同じ要領で16ns以内に収まりました。(テストも終了) 　　　FADD,FSUB,FINVSQRTについては明日高速化を行う予定です - 一応、確認を。&br()あげていただいたfpu-sim-03-12のReadme.txtに&br()「FTOI,FMULは指数部の処理に加え高速化も行い…」&br()と書かれていますが、このFTOIってたぶんITOFの間違いですよね？ -- buyobuyon (2007-03-13 11:05:55) - itofですが、SRC(31)='1'のときにSRC_absを求める場合、&br()先に最上位に'0'を付加してから、+1するのでないと、&br()0x80000000U(INT_MIN)が与えられたときに、途中でオーバーフローするのでうまくいかないのでは？ -- buyobuyon (2007-03-13 11:13:27) - あ、ちなみに↑に関連して。&br()こちらでC言語で書いているときには、in1の絶対値を求めるときに、&br()&br()mask = ((signed int)in1) >> 31;&br()in1_abs = (in1 ^ mask) - mask;&br()&br()ということをやっています。&br()(signed int)とかやっているのは、直後のシフトを算術シフトにするため。&br()maskはin1の符号が正ならビット列0000...0、負なら1111...1となるので、&br()in1が正ならin1_absはin1, in1が負なら(not in1) + 1となります。&br()ハードでこの方針をとると速いのかどうかはわかりませんが、まぁ参考までに。 -- buyobuyon (2007-03-13 11:29:56) - 一応、シミュレート関数の修正が終わったのですが、&br()FINVSQRTに関して気になる点がありまして。&br()入力が、指数部が0で、仮数部が0でないような値の場合でも、&br()もし計算の結果、nextXが&quot;111111111111111111111111&quot;と&br()なってしまうことがあれば、GBit切り上げによって、指数部に1足されて&br()出力が0でなくなってしまうような気がするのですが…。&br()もし支障がなければ、やはり入力の指数部が0なら出力は(others => '0')に&br()してしまった方が良いと思うのですがいかがでしょう。 -- buyobuyon (2007-03-13 13:53:17) - ご指摘ありがとうございます。&br()一つ目の件についてですが、書き間違いです。すみません。&br()ITOFとFINVSQRTについては修正します。 -- tsuy (2007-03-13 15:49:16) - ええと、FINVSQRTについてもう一つ。&br()&br()Zero = '1'のときには、MANTを0にするのでなく、&br()OUTPUTを '0' & EXP & &quot;000...0&quot;にするようにしてください。&br()&br()引数が0のときと同様、EXP部が+1されてしまうことがあるようです。&br()&br()EXP部が+1されるなんてこと、ごく稀にしか起こらないだろうと思ったら、&br()結構な頻度で起こるようで、レイトレ画像の変化がすごかったです。 -- buyobuyon (2007-03-13 16:57:23) - 了解しました -- tsuy (2007-03-13 17:33:14) ●3/11 　・buyobuyon氏から指摘・要望等があった部分を書き換えています。 　　とりあえず最低限必要そうなもの(FLESSの0.0の扱いやFINVSQRTへの0.0入力、ITOFの修正)を優先します。 　・FPU外部からの入力ですが、FINが'1'として出力されるまでは 　　－SRC1,SRC2,FUNCはそのまま 　　－STARTは最初の1クロックのみ'1'、(2クロック以上かかる命令では)以降の 　　　クロックは'0'でお願いします。 　　－FINは1クロック間はずっと同じ値をとります。連続して1クロック命令が 　　　入力された場合は、ずっと'1'のままになります 　・書き換えが終わった部分 　　－ITOFの入力が０のときのバグを修正 　　－ITOFの出力を四捨五入で丸め 　　－FLESSの+0.0,-0.0を同一視 　　－FINVSQRTの入力が0.0のときの出力を0.0に(ただし、仮数部は0でない) 　　－FMULの丸めをGbit切り上げに 　　－FADD,FSUBの丸めをGbit切り上げに 　　－FINVSQRTの丸めをGbit切り上げに(戻す可能性あり) 　　－FTOIの改良 　・書き換えた命令のうち、 　　－ITOF,FLESS,FINVSQRT,FTOIについて、手動で入力が０の場合のテストを行いました。 　　－全命令について、25万パターンの入力に対するテストを行いました。 　・出力のタイミングも恐らく大丈夫だと思うので、使えると思われるFPUがとりあえず出来たことになります。 　　－サイズは27%、Slicesは1243/5120(24%) 　　－各演算部分は組み合わせ回路、遅延時間は 　　　1クロック命令で最長が16.094ns 　　　2クロック命令で26.712ns 　　　5クロック命令で91.170ns 　・現時点でのFPUのソース(fpu-03-11.zip)をこのページに上げておきます。 - FPUを乗せてコンパイルしてみました。&br()乗算器があふれたものの（cf.[[yastak]]->13個使用）&br()ALUのDivを変えたらおさまって、&br()コンパイルは通りました！&br()&br()Device utilization summary:&br()&br() Number of External IOBs 94 out of 432 21%&br() Number of LOCed External IOBs 94 out of 94 100%&br()&br() Number of MULT18X18s 33 out of 40 82%&br() Number of RAMB16s 1 out of 40 2%&br() Number of SLICEs 2241 out of 5120 43%&br()&br() Number of BUFGMUXs 1 out of 16 6%&br()&br()あと、Warningの一つで、&br() FF/Latch <CountClock2_3> is unconnected in block <FINVSQRT_n>.&br()というのを発見したのですが、大丈夫ですか？ -- yastak (2007-03-12 00:52:55) - Warningは多分、ラッチで保持された信号が使われていない？といった意味かと思います。&br()実際その信号は使わないので、おそらく大丈夫かと思います。&br()&br()乗算器が1つ足りないようですね。&br()FINVSQRTに使うのを1つ、精度を落とさないように減らせるかもしれないし減らせないかも&br()しれないという感じなのですが、DIVの方はどうですか？ -- tsuy (2007-03-12 01:37:38) - ええと、FPU変更部分をシミュレート関数の方にも反映させておきました。&br()それで、1つ気になることがありまして。&br()&br()ITOF/FINVSQRT/FMUL/FADD/FSUBと、&br()今回切り上げ処理が追加されましたが、&br()これって、&quot;1111...1&quot;というようなビット列が与えられたときに&br()この切り上げ処理をすると&quot;0000...0&quot;になってしまいませんか？&br()一応、ITOFに関しては、実際に(2^25)-1を引数として与えたときに、&br()最上位ビットの上への繰り上がりが反映されずに間違った値が出力される&br()ことを確認したのですが。 -- buyobuyon (2007-03-12 07:52:22) - 丸め方式を変えた新しいバージョンでレイトレ実行してみましたが、&br()やっぱり白い点ができてしまいますね。&br()&br()おそらくFADD/FSUBに気づかないバグ(私がシミュレート関数を&br()作成した段階でできたバグかもしれません)があるか、もしくは&br()誤差の蓄積が問題なのだと思うのですが…。&br()&br()とりあえず、各プログラムの整理・アップが終わったらもう一度見てみますね。 -- buyobuyon (2007-03-12 09:43:54) - 乗算器はDIVを書き換えた現時点で33個（cf.Device Utilization summary）なので&br()になったので大丈夫かと思います。&br()今後書き換える必要もありそうですが…。 -- yastak (2007-03-12 11:00:44) - FADD,FSUB,FMUL,FINVSQRTあたりは、仮数部が&quot;111…1&quot;になるときに&br()切り上げを考慮して指数部を1増やすという機能があったのですが、&br()切り捨てにしたときにはずしたのを忘れていました。&br()今日ITOFも含めてその機能を戻してみます。&br()サイズはともかく遅延時間の増加が怖いですが…&br()&br()乗算器は足りると考えてよさそうですね。安心しました。 -- tsuy (2007-03-12 11:24:31) ●3/9 　・パイプライン化は必要なかったようなので戻します 　　－FINVSQRTが6clockから5clockになるので有利、サイズも減る 　・FPUのentityにSTART,FINの信号を追加します 　　詳しくは下の仕様をご覧ください 　　2clock以上かかる命令について、FPUが処理を行っている間(2から5clock間)はSRC1,SRC2は変化せず、 　　CLKは通常通りのクロック、STARTは最初の1clockのみ'1'で以降は'0'、 　　&strike(){FUNCは最初の1clockのみOPCODEを示し、次以降のclockは"1111"という入力を想定しています} 　　&strike(){特にFUNCはこのようにして頂けると実装が簡単になるのですが、問題ありませんよね？} 　　すみません、混乱しました。今日中に実際に動かせるものを仕上げる予定でしたが、START,FIN 　　を入れるのが思いのほか難しいので、また後日にします。 　・サイズに余裕が出来れば丸め方式を元に戻すかも 　・基盤について、[[harry]]さんとともに配線を行い、教官の方からOKをいただきました。 　　決めてもらうこともあるので、次に皆集まるときに半田付けを行う予定です。 　・INVの求め方について、考えてみましたがいい案は思いつきませんでした。 　　(inv　y)をライブラリでif文を使って処理するのもだめですよね… - if文で処理する → 2命令 + 遅延スロット増 なので、&br()たぶん現在用いている、ビット操作で符号ビットを付加するやり方の方がまだ速いかと。&br()まぁ正しい値は求まるので、とりあえずINVはこのままでいきましょう。&br()また何か思いついたらお願いします。 -- buyobuyon (2007-03-09 23:12:19) - harryさんのところにあるシミュレータFPU部分の実装が、&br()Cライブラリを用いたものなので、&br()とりあえずうちの班のFPUの演算精度でレイトレ画像を生成したときにどの程度ノイズが入るか&br()(もしくは入らないか)をシミュレータ上でテストできるよう、&br()うちの班のFPUの挙動をビット列操作でそのままシミュレートした関数をこれから作成します。&br()FADD, FSUB, FMUL, FINVSQRT, FLESS, FTOI, ITOFを一通り実装した方が良いかと思うのですが、&br()このページにあるvhdlソースファイルを元にすれば良いですか？&br()あと、精度のテストに使ったPerlのソースファイルがあれば見せていただきたいのですが。 -- buyobuyon (2007-03-10 13:42:08) - 現時点でのソースをまとめ直して上げますので、少々お待ちください。 -- tsuy (2007-03-10 14:09:49) - あ、お願いします。 -- buyobuyon (2007-03-10 14:22:07) - アップロードしました。&br()fpu-sim.zipがそれです。&br()FINVSQRTあたりは、シミュレート関数作成が少々面倒かもしれません。 -- tsuy (2007-03-10 14:44:46) - アップロードしたソースのうち、finvsqrt_table.vhdがあまりに&br()読みにくいので修正したものを上げておきました。 -- tsuy (2007-03-10 14:58:14) - ありがとうございます。&br()関数作成、やっぱり結構時間かかりますかね…。&br()関数作成にかかる時間も気がかりですが、あまり複雑な関数だと&br()シミュレータで実行する際にひどく時間がかかりそうで…。&br()&br()でも、やっぱりシミュレータ上でテストしておいた方が良いですよね…。&br()テストするなら、一番誤差を生じやすいfinvsqrtをテストしないと仕方がないですし…。&br()まぁ、とりあえずやってみます。 -- buyobuyon (2007-03-10 15:02:02) - すみません、手伝えたらいいのですが締め切り間近の連続系の課題が残ってまして…&br()関数作成頑張って下さい。 -- tsuy (2007-03-10 15:46:13) - あ、大丈夫ですよ。&br()私は前に時間をいただいていたので最低限の課題は出し終えていますし。&br()連続系の方を優先してください。&br()&br()ひとつだけ確認しておきたいのですが、&br()FPUの回路はループのない組み合わせ回路と考えてしまって大丈夫ですよね？ -- buyobuyon (2007-03-10 16:13:36) - ありがとうございます。&br()&br()FPUの計算部分はパイプライン化していないので完全にループなし組み合わせ回路です。&br()f_adsb.vhdとfinvsqrt_n.vhdでクロックを読んでますが&br()計算にはかかわらないので無視して大丈夫かと思います。&br()また、FINVSQRTでは、&br()finvsqrt_repeat_1.vhdの前半が初期値の表引き、&br()その後半とfinvsqrt_repeat_2.vhd、finvsqrt_repeat_3.vhdが繰り返し計算1回目、&br()finvsqrt_repeat_4.vhd、finvsqrt_repeat_5.vhd、finvsqrt_repeat_6.vhdの前半が繰り返し計算2回目、&br()finvsqrt_repeat_6.vhdの後半が整形して出力&br()となっているので、同じコードで使いまわせるはずです。 -- tsuy (2007-03-10 16:52:57) - 了解です。&br()演算量を少なくしようとすると結構大変…。 -- buyobuyon (2007-03-10 20:09:36) - 気になったことはここに書き込んでいきますので、後で余裕ができたら見てみてください。&br()ちなみに、こちらはfaddが終わったところです。&br()&br()・FSUB_S_2のNeqは無くても(常に引数が異なるものとしても)良いのでは？(Neqが'0'のときは呼び出し元でEqualが'1'となり、0x00000000Uを返すようになっているから) -- buyobuyon (2007-03-10 20:53:38) - ・FMULの整数乗算の分割の仕方、highのbit数を増やしてlowのbit数を減らし、&br()low×lowを無視するようにすれば、乗算器1個不要かな…、なんて思ったのですが。&br()ただ、出力値は現在のものから1変化する場合があるかもしれませんね&br()(良くなる場合も悪くなる場合もあるはず…、たぶん)。 -- buyobuyon (2007-03-11 00:37:00) - ご指摘ありがとうございます。&br()SUBの方は余裕があったら高速化したいと思っているので、そのときに試してみます。&br()MULの方は、その分割はしたのですが速度だったかサイズだったかが悪くなったので&br()現在の分割に落ち着きました。掛け算の分割はほかの部分でも使うので、いろいろな&br()パターンを試しました。 -- tsuy (2007-03-11 00:55:11) - あ、分割の仕方を変えてしまうとかえって遅くなるのですか。&br()普通に考えたら均等なビット幅で分けるのが一番速そうなものですが…、&br()FPGAって難しいですね。 -- buyobuyon (2007-03-11 01:31:42) - バグ…、かな？&br()ITOFで引数が0のときの例外処理を忘れているので、&br()ITOF(0)が1.0になってしまいます。&br()&br()とりあえず、シミュレート関数の方では、&br()関数のトップで、引数が0だったら0x00000000Uを返すようにしておきますね。 -- buyobuyon (2007-03-11 04:16:46) - ああー　バグですね…　なんと初歩的な…&br()とりあえず明日テストしてバグであることを確認して直そうかと思います。&br()何だかデバッグしてもらっている状態になってしまってすみません -- tsuy (2007-03-11 04:47:17) - あ、いえいえ。&br()こちらとしても、精練されたFPUのソースコードを読むことで、&br()非常に勉強になっていますので。&br()&br()自分の側の部分にも、ちょっとした問題を見つけまして…。&br()fsqrtで引数が0のときにどうするかを考えていなかったのですが、&br()(fsqrt x) → (finv (finvsqrt x))&br()(finv x) → (finvsqrt (x *. x)) xor (x and 0x80000000U)&br()としているので、もし(finvsqrt 0)が0と定義されていればこのままでOK、&br()逆にこのように定義されていないと、sqrtで正しい値を返すためには&br()余計な命令を付加する必要が生じてしまい、sqrtの効率が落ちてしまいます。&br()また、(finvsqrt x) → (finv (finv (finvsqrt x)))とならなくなるので、&br()最適化がしにくくなります。&br()&br()そのため、もし支障がなければ、(finvsqrt 0)が0となるようにFPUの方で&br()してもらいたいのですが、いかがでしょうか？&br()(まだfinvsqrtのソースは読んでいないので、もし既にそうなっていたらすみません。) -- buyobuyon (2007-03-11 05:15:04) - 了解しました。&br()遅延時間とサイズが増えるのが怖いですが、実装自体は簡単なので明日(というか今日)やってみます。 -- tsuy (2007-03-11 05:40:43) - よろしくお願いします。&br()元の回路が大きいからそれほど変化しないと思う(思いたい)のですが…。&br()&br()あと、また気づいたことなのですが&br()(あ、夜遅いので気にせずにお休みになってくださいね。勝手に書き込んでいるだけなので。)、&br()ftoiの引数が0の時の例外処理なのですが、&br()非正規化数を実装していた頃の名残が残っているようで、&br()やや冗長になっているような気がします(返す値は正しいと思いますが)。&br()&br()たぶん、INT_abs_bufを得るための式の0に関する例外処理を外し、&br()OUTPUTを得るための式における、引数が0であるかの判定式をEXP=0に&br()変えても大丈夫だと思います。 -- buyobuyon (2007-03-11 05:46:58) - 確かにそうですね。これも今日書き換えてテストしてみます。&br()何というか、自分ひとりだと気付かないところがやっぱり多いものですね。&br()(ちなみにまだ起きているのは未だに連続形が終わらないからだったりします) -- tsuy (2007-03-11 06:03:29) - ならなおさら、こんな書き込み見ていないで連続系に専念してください！&br()後で忘れないように書き留めているだけですので。&br()&br()一応、続きを書いておきます。連続系が終わってから読むこと。&br()&br()先ほどのFTOIの話ですが、おそらく引数が0.0である場合の例外処理自体が&br()いらないような気がします。&br()引数が0.0なら、Zeroが'1'、故にINT_abs_roundedが0となり、&br()最終的に引数が+0.0の場合も-0.0の場合もOUTPUTは0になるはずです。&br()&br()また、Zeroが'1'のときは必ずOUTPUTが0になるので、途中式でのZeroの使用を省き、&br()OUTPUTを求める際の場合分けでZero='1'なら0を返すようにすると&br()良いのではないでしょうか。&br()&br()って、おそらくもとから速い＆サイズの小さいFTOIを&br()最適化してもあまり意味はないのですよね…。 -- buyobuyon (2007-03-11 06:20:12) - 連続系終わりましたー&br()いえね、プログラムの結果が出るまでの待ち時間が中途半端に長いもので、&br()ついついここを覗いてしまうのですよ。&br()&br()夜が明けたようなのでこれから寝て、目が覚めたらFPUの修正と改良を&br()行おうかと思います。&br()buyobuyonさんもあまり無理はしないでくださいね -- tsuy (2007-03-11 07:32:18) - あ、お疲れ様です。&br()そういえば常微分方程式とかは結構時間がかかりましたね。&br()ゆっくりお休みになってくださいね。&br()私ももう少ししたら休みます。&br()&br()ええと、一つ戻って、ITOFのことなのですが、&br()四捨五入で丸めないとコンテストルールに反するような気がします。&br()まぁ、2^24を超えるような値を入れてITOFすることは稀だとは思いますけど…。 -- buyobuyon (2007-03-11 07:52:37) - 見たところ、 (-0.0) < (+0.0) としたことは&br()特にFLESSの高速化につながっているわけではなさそうですね。&br()FLESSの単純化のために-0.0の導入を提案したのですが…。&br()たぶん、指数部が0なら全て0.0、という仕様になって、&br()0.0を特別視する必要が出てきたからですよね。&br()それならいっそのこと、もう-0.0と+0.0を区別せず、&br()符号にかかわらず、指数部が0なら+0.0としてしまいませんか？&br()まだfinvsqrtは見ていませんが、それ以外は-0.0を+0.0に変えても特に&br()問題は生じないはずですし、&br()ちょうど、2種類の0.0があったことでFISNEGの仕様をどうすればよいか&br()決めかねていたもので(-0.0より真に小さければtrueとするのが妥当に見えるが、&br()それではコンテストルールを満たさないため)、 -0.0 = +0.0 とした方が&br()こちらとしては助かるのですが。 -- buyobuyon (2007-03-11 08:27:00) ●3/8 　・パイプライン化は多分終了、現在テスト中 　・同じ命令がずっと続く場合(1クロック目:FADD、2クロック目:FADD、…など) 　　のテスト終了 　・複数の命令が混じる場合はまた今度 　・シミュレータ上でうまくいっても実機でうまくいかないかもしれないので不安です 　・FINVSQRT：6クロック、FADD,FSUB：2クロック、その他は1クロック 　・複数の命令の結果が重なる場合(例えば1クロック目にFADD,2クロック目にFMULを入力した場合の 　　3クロック目の立ち上がりの出力)の優先順位 　　－finvsqrt>fadd,fsub>(その他の1クロック命令) - 私の方のページにも書いたのですが、&br()この前決めた方針ではy<0のときに(x /. y)が正しく求まらないことに先ほど気づきました。&br()最適化のことを考えて、できれば(x *. (inv y))として(x /. y)を求めるようにしたいのですが、&br()なかなか良い(inv y)の求め方が思い浮かばないもので…。&br()もし良い方法が見つかったら教えてください。&br()とりあえずは、( (invsqrt (y *. y)) xor (y and 0x80000000U))として求めるようにしておきます。&br()(こうすると、引数が負のときに値の保証が要らないsqrtで損をするのがもったいないのですが…)。 -- buyobuyon (2007-03-08 23:17:59) - 確かにそうですね。&br()&br()ライブラリで&br()let　rec　fdiv　x　y　=　if　y　<　0.0　then　…&br()とするのもよくなさそうですね。&br()しばらく考えてみます。 -- tsuy (2007-03-08 23:38:23) - えと、CPUのロジックはパイプライン2段で、&br()n番目の命令を実行している最中(exw)に、n+1番目の命令を読み込む(fdr)、&br()という仕様になっています。&br()n番目の命令の実行・書き込みが終了するまでn+1番目の命令はexwの回路にはやってこないので、&br()mクロック目でFADDがきて、m+1クロックでFADDがくる、といったことは生じ得ないのですが…。&br()すみません、今まで私が「パイプライン」の意味を誤解していたようです…。&br()&br()FPU命令に複数クロックかかるのはまったく構わないのですが…。 -- yastak (2007-03-09 11:53:48) ●3/7 　･FINVSQRTをパイプライン化中 　　－6段にする予定だが、2段目と5段目が20nsで収まるか分からないので8段になる可能性も 　　－分割終了　想定通りに動くか明日テスト 　　－サイズは意外と大丈夫でした。現時点で26% 　･FADD,FSUBの動作チェックもまだ 　･25MHzならこのページに上げたFPUのファイルで動かせるつもりだったが、多分ミスを発見 ●3/6 　・ライブラリfloorができたのでこのページに上げておきます 　・コンパイルも(多分)通ったし、テストも一応問題ないはず 　･FADD,FSUBをパイプライン化中 - floor実装、ありがとうございます。&br()何かテストが大変だったみたいですね。&br()とりあえずこれでmin-rtを実行するための道具は全てそろったはず…。&br()明日、シミュレータのバグ(たぶん私が記述したメモリ操作部あたりに問題があるのだと思うのですが)を&br()チェックして、直ったら実行してみましょうね。コンパイラのバグが露呈しそうで怖い…。 -- buyobuyon (2007-03-07 00:46:11) ●3/5 　・高速化を行った全命令についてテスト終了 　　－テスト方法は年末に行った、ランダムな100万パターンの入力に対しての出力と 　　　　　Perlで行った計算の結果を比較する方法 　　－FADD,FSUB,FMUL,FTOI,ITOF,FINVSQRT問題なし 　　－FLESSのVHDLとテストプログラムにミス(高速化部分とは関係なし)発見 　　　また、高速化も結果にあまり自信がないのでやめておきました 　　　FLESS:64,6.296ns 　・テスト結果待ちの間にライブラリのfloorを作っています 　　－他の数値計算ライブラリに比べて簡単に出来ると思いきや、 　　　困ったことに我々が使うint_of_floatが四捨五入なのに対して、 　　　OCamlのint_of_floatは切捨てらしい→テストが大変そう 　・入力ｘと0.5を足したものに対して切捨て版int_of_floatを適用すると、 　　－入力が非常に小さいとき(ｘ+0.5=0.5となるとき) 　　　・ｘ>0.0とすると、floor(ｘ)=0.0となればよい。 　　　　float_of_int(int_of_float(ｘ+0.5))＝0.0となり、 　　　　ｘ>0.0なので出力は0.0となり、OK 　　　・ｘ<0.0とすると、floor(ｘ)=-1.0となればよい。 　　　　float_of_int(int_of_float(ｘ-0.5))＝0.0となり、 　　　　ｘ<0.0なので出力は-1.0となり、OK 　　－入力が大きいとき、 　　　・｜ｘ｜≧2^(23)ならばint_of_floatは使わないので問題なし 　　　・ｘ＜2^(23)で最大のfloat数となる2^(23)-0.5について、 　　　　floor(ｘ)=2^(23)-1となればよい。 　　　　float_of_int(int_of_float(ｘ+0.5))＝2^(23)となり、 　　　　2^(23)-0.5<2^23なので出力は2^(23)-1となり、OK 　　　・ｘ＞-2^(23)で最小のfloat数となる-2^(23)+0.5について、 　　　　floor(ｘ)=-2^(23)となればよい。 　　　　float_of_int(int_of_float(ｘ-0.5))＝-2^(23)となり、 　　　　-2^(23)+0.5>-2^23なので出力は-2^(23)となり、OK 　・以上から、我々の使う四捨五入のint_of_float(x)は、 　　OCamlの切捨てのint_of_float(x+0.5)(負ならint_of_float(x-0.5)) 　　と同じものと考えてよいはずなので、 　　テストはOCamlの0.5加えたもの(引いたもの)で行い、このページに上げるのは0.5 　　加えてないもの(引いてないもの)にします。 ●3/3 　・FINVSQRT：403,87.558ns->329,87.858ns ●3/2 　・ITOF：204,15.006ns->129,13.797ns 　　－大幅に書き換えたので実行テスト必須 　・FPU全体のスライス数：1265->1226 　・FADD：426,26.243ns->412,26.193ns 　　－肝心のFADDがあまり速くならない… 　・FINVSQRT 　　－4時間かけて成果なし　　 - 何というか、大幅に速くなっていますね…。 -- buyobuyon (2007-03-02 13:17:26) - まだ実行テストをしていないので、ぬか喜びになる可能性もありますけどね。&br()パイプライン化でどの程度サイズが増えるか分からないので、そこも不安です。&br()みなさんも順調に進んでいるようで何よりです。 -- tsuy (2007-03-02 13:36:19) この後のコンパイラ組み込み関数に関する相談は[[こちら>tsuy and buyobuyon]]に移動しました。(buyobuyon) ●3/1 　・FTOI：170,13.778ns->166,12.212ns->139,11.432ns 　・FMUL：58,17.356ns->52,14.743ns 　　－指数部にずれが生じるかも 　・FINVSQRT:404,87.558ns->403,87.558ns ●2/27 　・FADD,FSUBの高速化中 　・FADD,FSUB,FMUL,FLESS,FTOI,ITOF,FINVSQRT個別のサイズの合計よりも 　　すべてまとめたサイズの方が予想外に大きいためサイズオーバーになりそうという事と、 　　5~6時間FADDの高速化をしているのですが0.001nsも速くならないので、とりあえず 　　FADDはパイプライン化して2clockで動かすという方向で進めようかと思います 　　FADDの高速化は余裕があったらということで 　・現在、多少遅くなってもいいのでサイズを小さくする方向でソースを書き換えています 　　FADD：546,26.151ns->536,26.149ns->426,26.243ns 　　　－ulpの下の1bitの切り上げにより丸めを行っていましたが、切り捨てにするとなぜか大幅にサイズを 　　　　減らせるようなので、丸め方式は切り捨てにします 　　FMUL:80,17.396ns ->58,17.356ns 　　　－丸めを切り捨てにしました 　　FINVSQRT:430,90.781ns ->404,87.558ns 　　　－丸めを切り捨てにしました 　　FTOI：171,15.159ns->170,13.778ns 　　　－なぜかNaNのサポートが残っていたので外しました 　　FLESS：64,7.482ns->33,3.627ns 　　　－指数部の8bitが"00000000"の数を０として扱っていました 　　　　（例えば"00000000011111111111111111111111"も"00000000000000000000000000000001"も 　　　　　　　　"00000000000000000000000000000000"と同等として扱っていた） 　　　　が、この特別扱いをやめて単純に指数部と仮数部をあわせたものを比較するようにしました 　　　　FPUの他の命令の出力で指数部が０になるものは仮数部もすべて０となっている　は　ず　 　　　　なので問題はないかと思うのですが、大丈夫ですよね？ 　・これらの書き換えに対しての動作確認をする必要があるので、近いうちに大学に行きます 　・非常にサイズが厳しいです… ●今後の予定や疑問点など(2006) 　・FPUは今後は高速化・省サイズ化 　・50MHz・1clockに収まらないものはパイプライン化を行う 　・18×18の乗算器の数が足りないので、現時点ではINVとFINVSQRT両方をハードで実現できない 　　－ニュートン法以外の方法を探すか諦めてソフトウェア実装するか 　　－乗算器を使わないとなるとサイズが大きくならざるを得ないと思うので、諦める気配が濃厚 　・恐らく1月中間発表向けにレイトレを動かす段階では50MHz・1clockでは動かない 　　－時間的にパイプライン化などをする余裕はなさそう 　　－必要最低限の命令は25MHz・1clockで動くはずなので、1月は25MHzにしていただけるとありがたい 　　－この段階ではINV,FINVSQRTはソフトウェアで動かすつもり 　・ライブラリはどんな命令を実装しましょうか？ 　　－sin,cos,atan,INV,FINVSQRTの他には？ 2009-06-07T10:58:37+09:00 1244339917 harry https://w.atwiki.jp/ttth/pages/10.html * Harry's Page 私も新しいページを作りました。 昔のものは[[harry(昔）]]に移動 * はりーの掲示板 えーと、みなさんからのコメントを見落とさないように、ページの一番最初の領域を掲示板として使います。 新しいコメントはこの領域の一番上に書いていただくとありがたいです。 ここの領域が大きすぎないように、既に読んだ＆解決したコメントはその日のところに移します。 ~~~~~~~~ここから書き込んでくださいね♪~~~~~~~~~ アセンブラの最新版（assem3-15.c),とそれにmin-rt02.sを入力したところ、吐き出した コードファイル(newcode.txt), アセンブリファイル（newout.txt)をアップします。 ** 3月15日(木） アセンブラのコードを綺麗にしました。 最終版をアップします（assem- last.c) **　3月12日(月） アセンブラの最新版をアップします。 ぶよぶよん氏による多大な援助を感謝感謝 6〜7行程度コンパイラの方と行数がずれていて、またバグがあるはずですが、たぶん movあたりのムダな変換かな？？ ＜昔のコメント＞ -To buyobuyon 行数を32000行、ラベル数を2048行確保しました。 [[yastak]]のページにあるmin-rt02.sをやってみたところ、min-rt02.binと一致しました。 -To yastak 申し訳ないです。通電テストはまだしていません。 午後学校に行きますので、その時にしたいと思います。 大丈夫？CPU実験も大事だけど、体も大事だよ！お大事にね！ 拡張基盤についてですが、これって、通電テストしてありますか？ いきなり接続して使ってみようと思うのですが、大丈夫ですか？(yastak) 風邪ですか。お大事に。 アセンブラ、正しく動作するようになって何よりです。 一応、コンパイラでインライン展開などを実装した関係で、 min-rt.sのサイズがかなり大きくなりましたので、 読み込み可能なラベル数・プログラムの行数の限界を少し大きめにしておいてください。([[buyobuyon]]) できたっぽい！ えーと、diffで調べて、min-rtn.sの方も完全に一致したので、たぶん今度は大丈夫だと思います。 今まで本当に多大な援助を頂いたぶよぶよん氏に感謝感謝です。 アセンブラの最新版（assem 3-14.c)と　それが吐き出したコードファイル　(min-code.txt),アセンブリファイル(min-out.txt)をアップします。 （はりー） 風邪で寝込んでしまいました。こんな時期に申し訳ないです。 もうだいぶよくなったので、今から作業を再開します。 buyobuyonさんの言う通りにstrcmp("mov", opcode)に変えたところ、min-rtnは8478と、行数はちゃんと一致しました。 それでruntime.binと一行ずつ比較したところ、完全一致しました。 しかしmin-rtnの方で比較したら、ラベルのところでやはり間違いが出ました。 ラベルの処理でちゃんとラベルの配列すべて見るように直したが、label[]はint の配列で、ラベル値は　unsigned int のせいなのか、addi,hiあたりで、ラベル値が負になったりしてバグがあるようです。 恐らくまたintとunsigned intの型の扱いに問題があると思われます。 この辺はきちんと分かっていないので、まずunsingned intとintについてきちんと勉強してからデバッグしたいと思います。できるだけ今日の夜中に最新版をアップしたいのです（間に合うのかな。。。） （はりー） ええと、アセンブラのことですが、 一応、min-rtで試すと複雑すぎるので、代わりとなるアセンブリソースファイルとして、 runtime.sをこのページにアップロードしておきました。 同じくアップロードしたruntime.binには、アセンブラにruntime.sを与えたときに 本来出力されるべき内容が入っています。 とりあえず、最新版のアセンブラ(assem3-12.c)でruntime.sをコンパイルしてみたところ、 本来35行目に入るはずのmul命令が抜け落ちてしまうことがわかりましたので、 そのあたりからデバッグを始めてみてください。単純にdiffをとるとたくさん差分が 出力されますが、おそらくほとんどは、一部の命令が抜け落ちたことにより、 ラベルの行番号がずれてしまったことが原因だと思うので、あまり気にせず、 とりあえず総命令数をruntime.binと一致させることをまず目指してください。 ちなみに、mulが抜け落ちるのは、180行目あたりのif(opcode[0]!= ':' && opcode[0]!='m')が 原因だと思います。movを除外するための条件のつもりなのだと思いますが、MULやMULIなども ありますので、"mov"を除外できて"mul"を除外しないような条件にしないといけませんので。 もう一つ気になるのは、ラベルの個数です。ラベルが出現したときに、一致するラベルを配列中から 探す際、配列の中身を256個しか調べておらず、またその際に配列中で見つからなくても エラーメッセージが出ないようになっているので、そのあたりを修正しておいてください。 (buyobuyon) ** 3月10日　(土） アセンブラの最新版を添付しました(assem3-10.c) それを用いて、min-rt.sで吐き出したコードファイル(code.txt)とアセンブラファイル(out.txt)をもアップしました。 ./assem3-10 入力ファイル　　アセンブラファイル(出力ファイル）　コードファイル（出力ファイル） で使用してください <むかしのこめんと＞ To buyobuyon 御指摘ありがとうございます。 文字列の扱いに問題があり、一行のものが二行になったりして、行のズレが生じてしまいました。 それを直したファイル(assem3-11.c)をアップしました。 結果のコードファイル(code.txt)とアセンブラファイル(out.txt)をもアップしました。 一応両ファイルはともに8494行となりました。 ええと、アセンブラにバグが…。 例えばmin-rt.sをコンパイルすると、99行目の"mov r13, 0;"が00000000になってしまいます。 あと、心なしか生成されるコードの長さが違うような気がするのですが。 生成されるコードの長さは、 元々の命令の個数＋MOV命令の個数(引数として即値をとり、その値が-1024から1023まで場合を除く) になるはずですよね？(buyobuyon) To buyobuyon 配列を大きくするのを忘れました。(m_m) 一応16384行確保したのですが、足りるのでしょうか？ エラーチェック（レジスタや即値やラベル値のチェック）も入れたので最新版をアップします。昨日までにアップすると言ったのに遅れてすみません。 それでmin-rt.sをアセンブラに変えたところエラー表示はありませんでした。 ちなみにmain()関数は入力ファイル、アセンブラファイル（出力ファイル）、コードファイル（出力ファイル）と引数3つにしました。 実行結果は以下のようになり、assem3-10.c,code.txt,out.txtを添付しました。 [hari@localhost Desktop]$ ./assem3-10 min-rt.s out.txt code.txt assembly finished [hari@localhost Desktop]$　↑エラー表示されなかったので、min-rt.sに値の大きさ関係のエラーはない模様 (harry) min-rt.sにアセンブラを適用してみたら何かエラーが起きて強制終了されました。 たぶん、確保した配列が小さすぎたのだと思います。 今後、インライン展開などを実装したらさらにmin-rt.sは長くなると思うので、 充分なサイズの配列を確保するようにしてください。 一応、現段階のコンパイラ・globals解析器・ライブラリ・リンカもどきが生成した min-rt.sをこのページにアップしておきましたので、テストに使ってください。(buyobuyon) **3月6日（火） 昨日の春の嵐から一転して、今日はずいぶんと穏やかな日ですね。 天気が変わりやすく、風邪を引きやすい時期になりましたが、みなさん体調を崩さないように気をつけましょう えーと、FPUのシミュレータの最新版をアップしました。 <昔のコメント＞ buyobuyon氏に助けをもらって、アセンブラのバグが分かった。感謝感謝！！ えーと、アセンブラの最新版をアップします エラー処理をきちんと追加する予定なので、それを入れたらまたアップします。 (harry) ↓jmp/jmplや分岐命令では、ジャンプ先の絶対的なアドレスではなく、 ジャンプ先の相対的なアドレス(ジャンプ先のアドレス - そのジャンプ命令のあるアドレス)を 指定する必要があります。 そのように修正するとたぶんfib_b.txtのようになるかと。(buyobuyon) - to buyobuyon 詳細なアドバイスありがとうございます。 直して、3076,1025,2047...あたりでやってみて大丈夫だったので、movはたぶん大丈夫だと思います。 添付してくれたfib_b.txtとアセンブラが吐き出したコード(out.txt)を一行ずつ比較したのですが、以下の5行に違いが出ました。（他は全部一致しました） 行数　　　対応するコード　　　　 13　　　　　　　jmpl fib_00000001;　　 (fib) : 11000000011010000000000000000110 (out) : 11000000011010000000000000010010 15 jmpl print_int; 　 　　 (fib):11000000011010000000000000100111 (out): 11000000011010000000000000110101 21　　 beq r13, LABEL_00000015; (fib): 11000110100000000000000000000100 (out): 11000110100000000000000000011001 31　　　　　　　jmpl fib_00000001; (fib): 11111111111011111111111111110100 (out): 11000000011010000000000000010010 37　　　　　　jmpl fib_00000001; (fib): 11111111111011111111111111101110 (out): 11000000011010000000000000010010 えーと、それぞれの飛び先のラベル値を調べたら18、53、25、18、18となっていて、out.txtに出てきた結果が一応私の予想通りのものとなっていますが、もしかしたら何か私の勘違いなのかな？ 最新版のアセンブラとout.txtと実行結果（result.txt)をアップしました - to tsuy 御指摘ありがとうございます。 これは完全に私のミスです(m_m)申し訳ございません。 直してアップしました。(harry) - すみません、直していただいて恐縮なのですが"100000000"同士の比較の部分、 fpu-3-6.cの374行目は 　return　-1; ではなく 　return　0; でお願いします。([[tsuy]]) - 一応、この前fibのテストを行う際に作成した、&br()fib.sを変換してできたアセンブリコードをこのページに載せておきました。&br()fib_b.binがシミュレータで実行可能なバイナリ形式のファイル、&br()fib_b.txtがビット列をテキスト形式で出力したものとなっています。&br()(ファイルの形式が違うだけで、この2つが表すアセンブリコードは同じです)&br()一応、fib_b.binはシミュレータでテスト済み(fibの引数が30以上でも&br()正しく動作するバージョン)なので、間違いは無いはず…。&br()&br()fib_b.txtとharryさんのアセンブラの変換結果を比べると&br()とりあえず、hiとaddiの引数(レジスタの番号)が違っています。&br()hi r1, 1048576; &br()addi r125, r1, 1048576;&br()とすると、もともとr1に入っていた内容を消し去ってしまうので、&br()hi r125, HI(1048576); &br()addi r125, r125, LO(1048576);&br()のようにしてください(HIとLOは1048576の上位21bit対応部と下位11bit対応部)。&br()&br()ええと、あと、mov, addiの引数の話。&br()ごめんなさい。movもaddiも引数は(符号つきの)intです(fprintfの%dで出力していますので)。&br()ちゃんと仕様を説明しておくべきでしたね…。&br()&br()で、addiの符号拡張の件ですが、とりあえず上のレジスタ番号の件を修正した後で、&br()mov r1, 3072;&br()を変換して、&br()10000000100000000000000000000010&br()00000000100001000000110000000000&br()となるかどうか確かめてみてください。 -- buyobuyon (2007-03-07 01:52:13) #comment(vsize=4,nsize=20,size=80) To tusy 直しました。 新しいFPUのシミュレータをアップしました♪ーーーfpu-3-6.c また何か変更あったら言ってくださいね。 (harry) シミュレータのFPU部分についてですが、申し訳ないのですが私の作ったPerlのプログラムにミスが あったので、該当箇所を訂正していただけたらと思います。 Flessの if($in1_n < $in2_n){ 　　　$result = "11111111111111111111111111111111"; }else{ 　　　$result = "00000000000000000000000000000000"; } に該当する部分に、先に+0.0,-0.0に関する条件分岐をつけて if(substr($in1,0,9) eq "000000000" && substr($in2,0,9) eq "000000000"){ 　　　$result = "00000000000000000000000000000000"; }elsif(substr($in1,0,9) eq "100000000" && substr($in2,0,9) eq "000000000"){ 　　　$result = "11111111111111111111111111111111"; }elsif(substr($in1,0,9) eq "000000000" && substr($in2,0,9) eq "100000000"){ 　　　$result = "00000000000000000000000000000000"; }elsif(substr($in1,0,9) eq "100000000" && substr($in2,0,9) eq "100000000"){ 　　　$result = "00000000000000000000000000000000"; }elsif($in1_n < $in2_n){ 　　　$result = "11111111111111111111111111111111"; }else{ 　　　$result = "00000000000000000000000000000000"; } のような処理をするようにしていただけたらと思います。 忙しい時期に申し訳ありませんが、よろしくお願いします。(tsuy) -to buyobuyon ご指摘ありがとうございます。 えーと、たぶん私がよくわかっていないのだと思いますが、今日アップしたアセンブラでfib.sの3ー6、8ー9は以下のようになりました。これは一応私が想定した結果と一致したものになりますが、どういう結果が出るべきでしょうか？ （一応全体の実行結果と変換結果をresult1.txt　result2.txtとして添付しました） （1）03〜06行目： 対応しているコード： hi r1, 1048576; addi r125, r1, 1048576; hi r1, $-_-$; addi r126, r1, $-_-$; アセンブリ： 03 : 10000000100000000000001000000000 04 : 00111110100001000000100000000000 05 : 10000000100000000000000000000000 06 : 00111111000001000000100000111000 （2）08〜09行目： 対応しているコード： hi r1, x_array; addi r14, r1, x_array; アセンブリ： 08 : 10000000100000000000000000000000 09 : 00000111000001000000100000000010 addiの符号拡張の部分は私もかなり気になりました。 えーと、ちょっと確認したいのですが、movの引数はunsinged intで、addiの引数はint でいいのかな？ （はりー） -とりあえず、テスト用として、このページに最新版のfib.sをアップしておきました。 これを見た感じでは、hiは即値部分だけでなく、レジスタ指定部分も値が違うような気がします。 (fib.sをアセンブリコードにしたときの03～06、08～09行目あたりを見てもらえると良いかと)。 mov関連で一つ気になることが。addiは演算時に定数部が符号拡張されるため、 mov→hi+addiの変換の際に、movの引数(定数orラベルの値)の下から11bit目が '1'か'0'かで場合分けする必要があると思うのですが、そのあたりは大丈夫ですか？(buyobuyon) **3月4日（日） -To yastak mov の変換hiの部分は確かに間違いました。 御指摘ありがとうございます。 えーと、endの方ですが、こっちで何回かテストしたけど、全部普通に出力されました。 最新版で使ってみて、やはりall 0になるのだったら知らせてください。(harry) -アセンブラにバグがあるようです。 end;が0000...(all 0) に変換されてしまいました…。 あと、movをhiとaddiに変換したときのhiの即値部分の値がおかしい気がします。 ちょっと自信ないけど。(yastak) えーと、アセンブラの最新版を添付します movの即値の変換は即値の大きさで場合分けできるようになりました。 以下に実行結果を貼ります。 :MAIN; mov r2, 3500; end; mov r4, 30; add r0, r0, r0; mov r3, MAIN; end; :FADD; mov r5, FADD; mov r1, 1023; mov r1, 1025; addi r0, r0, -256; [hari@localhost Desktop]$ ./assem3-4 source1.txt exit.txt; mov_int------ mov, r2, 3500 big m---3500 mov_int------ mov, r4, 30 small m---30 mov_label------- mov, r3, MAIN; mov_label------- mov, r5, FADD; mov_int------ mov, r1, 1023 small m---1023 mov_int------ mov, r1, 1025 big m---1025 hi r1, 3500; addi r2, r1, 3500; end; addi r4, r1, 30; add r0, r0, r0; hi r1, MAIN; addi r3, r1, MAIN; end; hi r1, FADD; addi r5, r1, FADD; addi r1, r1, 1023; hi r1, 1025; addi r1, r1, 1025; addi r0, r0, -256; assembly finished [hari@localhost Desktop]$ cat exit.txt 00 : 10000000100000000000000000000001 01 : 00000001000001000000110110101100 02 : 11000000001110000000000000000000 03 : 00000010000001000000100000011110 04 : 00000000000000000000000000000000 05 : 10000000100000000000000000000000 06 : 00000001100001000000100000000000 07 : 11000000001110000000000000000000 08 : 10000000100000000000000000000000 09 : 00000010100001000000100000001000 0A : 00000000100001000000101111111111 0B : 10000000100000000000000000000000 0C : 00000000100001000000110000000001 0D : 00000000000001000000011100000000 END; 昔のコメント： アセンブラ機能追加のお願い データを表現するための構文、".word"の追加をお願いします。 .word 即値オペランド(符号付き32bit値) .word ラベル の2つの形をとることができ、 どちらも、オペランド(ラベル)の値をその行の値としてそのまま出力するようにしてください。(buyobuyon) ** 3月2日（金） .wordを追加したアセンブラの最新版をアップしました。 テストしてみた結果を貼ります ソースファイル： :MAIN; mov r2, 15; .word FADD; add r0, r0, r0; :FADD; .word MAIN; .word 3; 実行結果： [hari@localhost Desktop]$ ./assem3-2 source1.txt out.txt label[0]---0---MAIN; label[1]---4---FADD; hi r2, 15; addi r2, r1, 15; .word FADD; add r0, r0, r0; .word MAIN; .word 3; .wrod label---FADD;---4 .wrod label---MAIN;---0 int_word: 3 assembly finished [hari@localhost Desktop]$ cat out.txt 00 : 10000001000000000000000000001111 01 : 00000001000001000000100000001111 02 : 00000000000000000000000000000100 //.word FADD 03 : 00000000000000000000000000000000 04 : 00000000000000000000000000000000 //.word MAIN 05 : 00000000000000000000000000000011　　 //.word 3 END; - .word構文の追加、ありがとうございます。&br()&br()こちらの方も、.word構文を使って&br()データ領域を作成するプログラムの実装が終わったので、&br()もう少しでmin-rt実行できますね。 -- buyobuyon (2007-03-02 11:52:35) ** 2月28日（水） アセンブラの最新バージョンをアップします。 yastakさんのアドバイス通りに実装したらうまくいきました☆ありがとう♪ To buyobuyon movだけでラベル値と即値の両形式に対応できるようにしました。 新しい構文の形式が決まったら追加しますので、どんどん言ってくださいね。 自分へのメモ ☆アセンブラーーー高速化をまだやっていない（mov変換部） ☆シミュレーターーー（1）tsuy氏に指摘されたMAX,MINの対応の追加 　　　　　　　　　　（2）テストすること って、一応実行結果を貼ります （buyobuyon氏のとこのもののmovをいくつかラベル値にしたのをソースファイルとした） 一応前問題点だったmovの両形式の命令変換と前へジャンプすることができたみたい。 ソース： :MAIN; mov r2, 15; jmpl fib_00000002; add r0, r0, r0; end; add r0, r0, r0; :fib_00000002; mov r124, LABEL_00000010;　／／ここをらべるにした（後ろに飛ぶ） cmplt r123, r124, r2; not r122, r123; beq r122, LABEL_00000010; add r0, r0, r0; addi r2, r2, 0; ret; add r0, r0, r0; :LABEL_00000010; addi r125, r125, -3; storei r2, r125, 2; mov r121, fib_00000002;　　／／ここをラベルにした（前に飛ぶ） sub r2, r2, r121; storei r127, r125, 0; jmpl fib_00000002; add r0, r0, r0; storei r2, r125, 1; mov r124, 1; loadi r123, r125, 2; sub r2, r123, r124; jmpl fib_00000002; add r0, r0, r0; loadi r124, r125, 1; add r2, r2, r124; loadi r127, r125, 0; addi r125, r125, 3; ret; add r0, r0, r0; [hari@localhost Desktop]$ ./assem2-28 source1.txt exit1.txt label[0]---0---MAIN; label[1]---6---fib_00000002; label[2]---15---LABEL_00000010; hi r2, 15; addi r2, r0, 15; jmpl fib_00000002; add r0, r0, r0; end; add r0, r0, r0; hi r124, LABEL_00000010; addi r124, r0, LABEL_00000010; cmplt r123, r124, r2; not r122, r123; beq r122, LABEL_00000010; add r0, r0, r0; addi r2, r2, 0; ret; add r0, r0, r0; addi r125, r125, -3; storei r2, r125, 2; hi r121, fib_00000002; addi r121, r0, fib_00000002; sub r2, r2, r121; storei r127, r125, 0; jmpl fib_00000002; add r0, r0, r0; storei r2, r125, 1; hi r124, 1; addi r124, r0, 1; loadi r123, r125, 2; sub r2, r123, r124; jmpl fib_00000002; add r0, r0, r0; loadi r124, r125, 1; add r2, r2, r124; loadi r127, r125, 0; addi r125, r125, 3; ret; add r0, r0, r0; count---36 jmpl label OK--label[1], num: 6, content: fib_00000002; hi label OK--label[2], num: 15, content: LABEL_00000010; addi label OK--label[2], num: 15, content: LABEL_00000010; hi label OK--label[1], num: 6, content: fib_00000002; addi label OK--label[1], num: 6, content: fib_00000002; jmpl label OK--label[1], num: 6, content: fib_00000002; jmpl label OK--label[1], num: 6, content: fib_00000002; assembly finished [hari@localhost Desktop]$ cat exit.txt 00 : 10000001000000000000000000001111 01 : 00000001000001000000000000001111 02 : 11000000011010000000000000000110 03 : 00000000000000000000000000000000 04 : 11000000001110000000000000000000 05 : 00000000000000000000000000000000 06 : 10111110000000000000000000001111 07 : 00111110000001000000000000001111 08 : 00111101101100111110000000100000 09 : 00111101010110111101100000000000 0A : 11111101000000000000000000001111 0B : 00000000000000000000000000000000 0C : 00000001000001000001000000000000 0D : 11000000001100111111100000000000 0E : 00000000000000000000000000000000 0F : 00111110100001111110111111111101 10 : 10000001011011111110100000000010 11 : 10111100100000000000000000000110 12 : 00111100100001000000000000000110 13 : 00000001000010000001011110010000 14 : 10111111111011111110100000000000 15 : 11000000011010000000000000000110 16 : 00000000000000000000000000000000 17 : 10000001011011111110100000000001 18 : 10111110000000000000000000000001 19 : 00111110000001000000000000000001 1A : 10111101110011111110100000000010 1B : 00000001000010111101111111000000 1C : 11000000011010000000000000000110 1D : 00000000000000000000000000000000 1E : 10111110010011111110100000000001 1F : 00000001000000000001011111000000 20 : 10111111110011111110100000000000 21 : 00111110100001111110100000000011 22 : 11000000001100111111100000000000 23 : 00000000000000000000000000000000 END; [hari@localhost Desktop]$ - 自分へのメモ：&br()mov 変換で&br()hi r1, imm&br()addi r1, r1, immと二番目のレジスタをr1に直し忘れないように -- harry (2007-03-01 00:03:28) **　　2月26日(月） To yastak: アドバイスありがとうございます。 全くおっしゃる通りですね うん、今まで自分が何を悩んでいたんだろう？？（＞＿＜） えーと、明日（27日）はちょっと用事があって、28日中にさっそくアセンブラの最新版をアップしたいと思います。 - 構造が出来上がっちゃうと、&br()それを生かして変えるのって難しいと思うから…。&br()私はいままで何も考えていなかった（すみません）のが幸いしましたｗ -- yastak (2007-02-27 02:15:28) - 私のページの方で議論中なのですが、&br()おそらくアセンブラに新しい構文の追加をお願いすることになると思います。&br()たぶん追加してもらうことになるのが、&br()　　　　　　.word オペランド１&br()というような構文なのですが、&br()オペランド１(32bitの数値、もしくはラベル)の値をそのままその行の値として出力するようなものです。&br()外部変数の初期値を書き込む＆外部変数の領域を確保するのにあると便利そうなので。 -- buyobuyon (2007-02-28 05:07:28) 2009-06-07T10:58:14+09:00 1244339894 トップページ https://w.atwiki.jp/ttth/pages/1.html **お知らせ - ページを見た人挙手！ #vote(挙手[3]) - ページを見た班員挙手！ #vote(挙手[3]) ↑ 自分と同じ日にこのページをチェックした班員がいたことに感動！(2/22) - [[ファイル提出について]]…ディレクトリ案作りました。コメント求む！ -【最重要】無事単位が認定された模様です。お疲れ様でした。 - 基板は熟成のために、私のロッカーに入っています。ご入用の際は声をかけてください。(yastak) - あとは拡張基板ですね。ぼちぼち頑張りましょう～！ - お知らせページを整理。こちらへ移動→　[[過去のお知らせ]] **各自のページ -各自のページもあるといいかもとか思っています。 -てなわけでこっそり作成　yastak…[[yastak]] -便乗してひっそり作成　buyobuyon…[[buyobuyon]] -私も参加☆　harry [[harry]] -遅れましたが　tsuy [[tsuy]] **その他リンク -[[過去のお知らせ]] -[[作業予定&進捗概略]] -[[中間発表３]] **@wikiへようこそ -ウィキはみんなで気軽にホームページ編集できるツールです。 -このページは自由に編集することができます。 -メールで送られてきたパスワードを用いてログインすることで、各種変更（サイト名、トップページ、メンバー管理、サイドページ、デザイン、ページ管理、等）することができます **新しいページを作りたい！！ -ページの下や上に「新規作成」というリンクがあるので、クリックして作成してください。 **表示しているページを編集したい！ -ページ上の「このページを編集」というリンクや、ページ下の「編集」というリンクを押してください。 **ブログサイトの更新情報を自動的に載せたい！！ -[[お気に入りのブログのRSSを使っていつでも新しい情報を表示できます。詳しくはこちらをどうぞ。>http://atwiki.jp/tools/blogrssmaker.html]] **まとめサイトを作りたい -[[archiveプラグインを使うと好きなときに好きなウェブページを保管することができます>http://www1.atwiki.jp/faq/pages/143.html]] -[[archive_logプラグインを使うと保管もらくらく>http://www1.atwiki.jp/faq/pages/144.html]] **ニュースサイトの更新情報を自動的に載せたい！！ -[[RSSを使うと簡単に情報通になれます、詳しくはこちらをどうぞ。>http://atwiki.jp/tools/rssmaker.html]] **その他にもいろいろな機能満載！！ -[[@wiki 便利ツール >http://atwiki.jp/tools/]] **ヘルプ・マニュアル・FAQで間違いを見つけたら？ お手数ですが、メールにてお知らせください。support@atfreaks.com **バグ・不具合を見つけたら？ お手数ですが、こちらからご連絡宜しくお願いいたします。 ⇒http://bugs.atwiki.jp/ ⇒http://bugs.atwiki.jp/node/4 **分からないことは？ -[[@wiki FAQ>http://faq.atwiki.jp/]] -[[@wiki 初心者講座>http://www1.atwiki.jp/faq/]] -[[@wiki マニュアル>http://doc.atwiki.jp/]] -メールで問い合わせ -[[@wiki 便利ツール >http://atwiki.jp/tools/]] 等をご活用ください 2008-02-22T16:04:06+09:00 1203663846 ファイル提出について https://w.atwiki.jp/ttth/pages/37.html *ファイル提出について 実験Ⅱのファイル群提出が最終レポートの代替として課されました。 というわけで。 ディレクトリ構成案を書いてみます。 各自で作ったファイルを各自の責任であげるということでいかがでしょうか？ /pub/Seika/2006/4han/... Compiler（[[buyobuyon]]） Software Simulator([[harry]]?buyobuyon?) Assembler(harry) Library([[tsuy]]) Others(*) Hardware FPU(tsuy) Others([[yastak]]) CPU(yastak) CPU_com(buyobuyon) sram(yastak) usb(yastak) Results(*) presentation(yastak) bitfile(yastak) Others(*) Resultsは発表資料と画像（sld）を入れる予定です。 別に誰がやっても良いと思うのですがどうします？ 誰もいないようならやりますー。 ディレクトリ内は各自で自由に…。（）内が責任者です。 過不足あったら付け足したり消去したりしてくださいm(_ _)m （buyobuyonディレクトリ、harryディレクトリ、tsuyディレクトリ…という方法もありだと思いますが、ちょっと後々見るにはわかりにくいかなぁと思ったので…） (yastak) ディレクトリ分けは上のもので良いと思います。 ただ、アップするのは、rs232cも動いてからにしませんか？ 最新版の各プログラムでレイトレが正しく動くことの確認にもなりますし。 あと、rs232cのコントローラに関して気になったことを、 yastak氏のページに書き込んでおきましたので、ご覧ください。(buyobuyon) ディレクトリ構成案は賛成です。 rs232cもそうですが、50MHzで動かせるといいなあなどと思っております。 (まだ動かせてませんでしたよね？)(tsuy) 50MHzはまだですね。確か25MHzまではOKだったはず。 あと、忘れていたのですが、sldをバイナリ化するプログラムや、ppmのdiffをとるプログラムなども おそらく提出した方がよいのですよね？ これらを入れるディレクトリとしてSoftware/othersが欲しいです。(buyobuyon) とりあえず現在の分だけファイルをUPしようと思ったのですが、 パーミッションの関係でUPできないです… 変えてもらえると嬉しいですm(_ _)m あと、自分のUP担当のところのディレクトリ構成を編集しました。 （Hardware/Others/ and Results/） みなさまもなにかあれば編集しておいてくださいー！ (yastak) おおっと、失礼しました。 studentグループから書き込みできるよう、修正しておきました。 (buyobuyon) ぎりぎりセーフで、rs232c間にあいましたので、 Hardware/Others/CPU_comディレクトリを作成し、 vhdlファイルを入れておきました。 (buyobuyon) 2007-04-30T22:01:37+09:00 1177938097