SCENE RESEARCH STATION  
with my everyday
thinking-and-doctrine

*2003.10.16

::おとなりページ

リンクを張った事もないし,巡回もしていないHjk/変人窟様が3位に来るのは何故でしょうか.

::photogenic blue

いろいろネタがあります.右下の方にあるリンク解析のあたりが面白かったです.難しいので細かいところは読んでないですけど.
確率の勉強をしようと思って調べてたら行き着きました.確率というかゲーム理論とか均衡理論を勉強したいと思う今日この頃.

::クルマの100gのお値段

松坂牛は1000円超/100gらしいので,車はそれと比べると随分と安い事が分かります.
松坂牛>>越えられない壁>>自動車
これは来週の期末テストに出るので覚えましょう.

pcwatch::高効率CPUを目指すEfficeonのアーキテクチャ

Transmetaは面白いというか冒険ちっくなアーキテクチャを出してくれるので好きです.
結局インテルには勝てないわけですが,これからも頑張ってください.

ああ,そうか,ITRONは明示的にdispatch()を呼ばないとタスク切り替えが起きないのか.そうだよなあ,リアルタイムだもんなあ(←よく分かってません).どこでタイムシェアリングするのか必死に探してたよ.逝ってよし.
なんだかもの凄い初歩を理解していない自分に失禁しそうです(意味分からん).

特別講義でT橋技科大のN島先生が来た.
CPUのアーキテクチャの設計には事前の検証が不可欠!てことでCPUのシミュレーションに目覚めて,今は並列マシンのシミュレータを研究しているらしい.上位の命令レベルのシミュ(binary translateとか.数倍のオーダ)の話から,詳細なクロックレベルのシミュレート(これだと5000倍くらいかかる),RTLレベルのシミュレート(ここまでくると6桁.5分の処理をシミュするのに10年掛かる)の話とか,CPUのアーキを検証するのも一苦労ですね.
なんでそんなに正確なシミュが必要かというと,10%程度の速度向上を見込むアーキの検証では正確な数値が出ないと誤差が目立ちすぎて,有効なデータが取れないからだそうな.
ソフトでクロックレベルの検証は流石に無謀だ,FPGAを使って検証しようと言いたい所だけど,そもそも硬直性の高いHDLを書くのがイヤだから色々試せるソフトウェアによるシミュレーションをしてるわけで本末転倒.なら,SpecCとかSystemCを使おう,eXCiteだ.って事に(僕の頭の中では)なるけど,まだ実用の域に達していない高位合成など使ったら(といったら怒られそうだが)誤差どころの話ではなくなる気がするし.

うーん,やっぱ一番重要なのは高位合成の最適化のような気がしてきた.今の回路屋ってのはソフトに例えるなら,ダンプリスト打ち込みからは脱却したけど未だにアセンブラでゴリゴリやってるような世界だからねえ(偏見か).職人芸がまかり通る世界.あ,職人しかどうせ居ないから問題なしですか?とはいえ半導体技術の進歩は留まる事を知らず回路規模も年々増大しているので,C言語並に分かりやすく回路が記述できるようにならないと将来マズいのは自明.かといってSpecCやSystemCが,C言語がasmを置き換えたような勢いで普及するともあんまり思えない.よって,何らかの回路向けの高級な言語が必要な気がします.

てことでそれを考えてみる.僕が思うに,FORTRANとかCという高級言語が成功した大きな要因はレジスタの隠蔽にあったと思う.つまり数に限りのあるレジスタの扱い(スタックに退避したりとか)から解放されたのが大きいのではないか.それから,式の評価という概念を導入して長々とオペコードを垂れる必要が無くなったというのも重要(それと比べれば構造化に関するifとかforの構文はマクロ程度の有り難味しかない気がするので省略).じゃあ,HDLも同様(??)にレジスタを隠蔽しよう.バスも隠蔽するぞ.んで,演算器も隠蔽してしまえ.と思ったけど,そんなん無理!!想像つかない.ていうかそれやると従来の高位合成と変わらんよーな気がしてきて敗北感が漂ってきたので寝ます.

oldlog 99-00 00-01 01 01-02 02
newlog 2002 2003 2004 2005 2006 2007
category scene | 2ch | 麻雀

Copyright (C) 2003-2004 mitsuman(mnishibe at ertl.jp) All Rights Reserved.

750k+