CPU」タグアーカイブ

技術系のブログを書いてて思うこと

書き始めると連日投稿してしまうのは,関心がブログに向くとき向かないときに波があるからだ.本来コンスタントに続けるということが非常に重要なのはわかっているつもりだが,実際のところ気分屋の私には非常に難しい話である.

ブログという媒体に関して

自分を売り込むというくだらない理由でやり始めたこのやる気のないブログだが,地味に続いていて,やはり金をかけてサーバを借りているということの重みがわかる.まあそれはいいとして,私としては細心の注意を払って各記事を書いているつもりだが,記載している情報については多くの間違いを含んでいる可能性が多分にある.
そもそもブログという媒体の性質上,それほど堅苦しく厳密さを求めるようなものではないので,間違った内容を含んでいることは,むしろあって当然という気がする.別に内容を誰かが査読しているわけでもないし,私個人の趣味で書いているようなものなので,これをお読みの皆様には疑ってかかってほしいくらいの気持ちである.

そもそもブログというものは,自由にかつスピーディーに投稿できるということが最大の利点であって,中身の正確さや厳密さは二の次にしている.ただし,私がまだブログを殆ど書いたことがなかった頃は,ネット上で調べたときに引っかかった,なんの信憑性もないブログ記事を深く信用して読んでいたように思う.まあそれはネット上には優れた人たちがたくさんいて,間違いの少ないよくできた記事を大量に提供してくれていたおかげなのだろう.世の中の記事がみんな悪質なものだったら今ほど信用して技術系ブログを読んでいなかったのではないかと思う.

ただし,こうして自分でブログに技術系の内容をまとめてみると,案外多くの人が見てくれていることに気がつく.私のブログでアクセス数が多いのはCPUをFPGAで作ったやつと,モンゴメリ乗算の2つだ.1日あたりのアクセス数はそれほど多いというわけではないが(マイナーだろうし),ちりも積もればなんとやらで毎日一定数の人に見てもらっているということは,総和としては多くの人の目に触れているのだろうと思われる.

私は昔から人に何かを説明するのが好きだったし,今でもそうだがその場合には質問という形で,私に対して何かしらの反応があるものだが,ブログという形態はコメントという形を取らなければならないので,躊躇してしまう人が多いのだろうと思う.個人的には,内容の不備や質問は随時受け付けたいと思っているわけだが,なかなかそうは行かないものだ.そこで各記事の最後には内容についての評価をボタンという形で簡単に投票できるようにしている.まあこんなのはただの気休めにすぎないわけだが,ないよりは全然いいのだろう.身内の人が多いのかも知れないが,それでもそこそこボタンが押されている形跡がある辺り,役目を果たしているのだと思っている.

でもしかし,実際にはコメントをくださる方もいらして,過去に記事の訂正を行ったこともある.そういったコメントをこんなわけの分からないブログにくださる方には非常に感謝している.私としては,疑問や質問,もっと説明してほしい,お前の言ってることはおかしい等々,好きにコメントを書いてほしい.読者の方々のフィードバックが私の原動力になっていると言っても過言ではない.

さて,ここまでごちゃごちゃといろいろ言ってきたが,結局渡しが言いたいことは,私のブログを疑ってかかりながら読んでほしいということだ.間違っている可能性は十分あるわけで,何も考えずうのみにすることは私にとっても,これを読んでいる方にとってもマイナスにしかならない.それに勉強というのはアウトプットしたときが最も負荷がかかって,良いトレーニングとなる.受動的な姿勢で読むのではなく,能動的な姿勢で批判的に受け取ることがwin-winの関係をもたらすのではないかと思う(と言っても私もそれは全くできていないわけだが).

内容についてどう思いますか?
  • いいね (2)
  • だめ (0)

やりたいこと

やりたいと思っていることがいくつかある.箇条書きにすると

  • FPGAのCPU実装をもっと頑張る(具体的にはUnix系OSを動かす)
  • Rustをやる(できれば研究とかバイトのコードも徐々に移行したい)
  • 日本語力を上げる
  • もっといろんなことを勉強する(暗号,音声,機械学習,etc)

のような感じ.別に最後のやつは普段のタスクの中に自然と組み込まれている感じなのであまり意識する必要はないだろうけど,上から2つは個人的に時間を作ってやらないとできるとは思えない.3つ目は文章が下手くそなのでうまくなりたいなということ(願望).

FPGAのやつはできればCPUの実装のコード(verilog)をきれいにしたというのもある.研修Aという研究室の自由課題でやったものだから,締切に合わせて結構その場しのぎでやってしまった感があって,それをどうにかしないと次に進む上で障害になりそう.かと言ってあれってそんな簡単に直せるとは思えない… 抜本的に書き直す羽目になりそう.そもそもverilogってアセンブリに近いものがあって全然きれいに書けてる自信がわかないんだけどどうすりゃいいんだろう.高位合成とかと違って結構低レイヤだから記述量が多くなりがちなのが影響して,とてもじゃないけど見やすくならない.あれも結局経験値で決まってくるやつなんだろうな.

Rustについて言えば,とにかく実践で使っていくしかないだろうなって思ってる.入門書とか初心者向けの記事とかをただ追って読んでるだけだと全然頭に入ってこないたちなので,実際に使って鍛えていくしかない.自分もそんなに詳しいわけじゃないんであれだけど,c言語とかc++みたいなシステム周りとか結構低いレイヤのプログラミング言語って,D言語とか他にもあるんだろうけど結局のところc言語 or C++がデファクトスタンダードって感じがあるように思う(マイコンとかの開発環境でC++/C以外の言語を使う場面ってなくはないけど少ない気がする).LLだとか関数型言語とかだと選択肢がありすぎるくらいにはあるのに,低レイヤ向けの,アセンブリより抽象度が一つ上なメジャーな高級言語ってのが,もう何十年も前に発明されたCとかC++のまま変わってないってのは,あまりに時代遅れな感じがする.と言いながらもう10年近くCだとかC++を書いてきた人間がこんなことを言うのは説得力にかけるのかもしれないけど,流石に限界というかこのあたりにもイノベーションがあってもいいよねってのは薄々思っていたところ.確かにC++は最近になってC++14とかC++17とか新しくなってきてるけど,もともと難解だったC++に更に付け足しつけたしで色々くっつけたもんだから複雑怪奇になって来てて,「C++を理解してます」ってのがジョークになるという笑うにも笑えない状態になってる.

だから流石にそろそろ新しくそういうシステム周りもかける言語を習得したいなと思ってたわけだけど,ちょうどMozillaがRustを開発してるという話を知って,これは良さそうと感じた.最近はライブラリも結構充実してきてて特に問題もなさそう.他に最近話題のコンパイルするような静的型付け言語としてはGoとかもあるけど,あれはポインタを叩くような処理をするというよりは,コンパイルできるLLみたいなイメージが有る.Google的には速度が出るLLが作りたかったってことなんかなという印象(素人目線).個人的にはやっぱりLLとシステム記述向けの言語って住み分けができてると思ってて,前者が簡単にかける代わりに詳細な記述をしたり速度を出したりすることが難しいもので,後者がその反対という感じ.よくGoとRustを対比させる記事を見るけど,それはこの2つがちょうどLLとシステム記述向け言語の間くらいに位置する言語だからということなんだろうな.ただGoはどちらかと言えばLL寄りで,Rustがシステム記述向けよりなんだろうと思うし,だからこの2つは用途が衝突するところもあるけど,全くかぶらないところもあるんだと思ってる.

確かにLLって半端じゃないくらいに遅いから早くしたいと思う人が多いのは当然だよね.pythonくらいしか経験がないけど,それでもC++なら一瞬で終わる処理が半端じゃないくらいに時間かかったりするのを見て,何とも言えない感じなることはある.プログラミング界隈で有名な話?に80:20則ってのがあって,プログラム全体の20%が実行時間の80%を占めてるって経験則なんだけれど,LLの哲学的には,重い20%のコードをCとかにまかせて,速度がでなくても大丈夫な80%ところをLLでどうにかするって話だったんだと思う.確かにそれは合理的に見えるし,全部を無駄に書くのが大変な言語で修行のごとく記述していくのは意味がないってのは大いに賛同するところなんだけど,現実はやっぱりなかなか厳しいものがあって,そう簡単じゃない.実際に使ってみると,LLがおそくてその80%が馬鹿みたいに大きくなったりして,僕の書き方が悪いってのはあるんだろうけど,なんだかなーって結果になることも往々にしてある.そんなこんなあって,みんな早いLLを求めてたんだろうから,Goみたいな言語が出て来たんだろうなという予想.本当のところどういうことなのかはGoを勉強しないとわからないけど,今のところGoが重要そうなWeb界隈の方には全く関わりがないので,実用的な観点でやることはなさそう.

とまあ前置きが長くなったけどRustを勉強したいなと思ってる.関数型言語の流れを受けて色々と拡張があるみたいだし,加えてC++とかと比べて安全だと言われればやらない理由も特にない.速度も結構早いみたいだしね.

ということで今年度も頑張っていきたいと思います.

内容についてどう思いますか?
  • いいね (2)
  • だめ (1)

FPGAでCPUを実装して、テトリスを動かした

先に断っておくが、以前のブログは残してあるというか放置してある。単純に新しいサーバを借りたので、以前のブログから移ったので放置状態になっているだけだ。おそらく更新することはないので、向こうは気にしなくて構わない。

また、今回の記事では自作CPUを作成したことについて話すつもりだが、私は決してハードウェア設計について詳しいわけでも何でもない。むしろ今回作成したものが初めてといっていいだろう。したがってハードウェア設計に通じた人であれば、眉唾物な内容である可能性がある。よって、ここで書いている内容を絶対のものと信じず、むしろ疑ってかかってほしい。ここの内容に騙されたといわれても、私は責任をとれない。

さて、私の大学では研修Aと呼ばれる、各研究室で課題を設定される必修単位がある。私の研究室では、この研修の半分の時間を使ってCPUを作成し、もう半分は好きなものをFPGAで作るということになっている。後半の自由課題は前半で作ったCPUと関連させる必要はない。したがって比較的自由に好きなものを作れるのだが、私は前半の課題で設計したCPUを強化させることとした。

そもそも、前半で作成するCPUはとてもCPUと呼べるような代物ではない。具体的にはパタヘネに掲載されているシングルサイクルプロセッサからパイプラインまでの内容をFPGAで実装するという内容なので、ほとんどの命令はサポートしないし、ピン入出力さえ行うことができないお粗末なものである。例外もないので割り込み処理もできず、仮想メモリもサポートしないのでOSすら乗らない。しかし、最小限の骨組みだけでも作成することで、CPUの動作の基本原理を学ぼうというところにその趣旨があるのだろう。実際、パタヘネを参考にすれば、必要なデータパスはすべて掲載されているので、私がわざわざここで説明しなくても誰でも作ることができる。おそらく最大の問題はむしろFPGAのボードを手に入れるほうではないだろうか。

しかし、私はとてもじゃないがそんなのでは満足できなかった。せっかくCPUを作るなら最低限OSの動作保証をするべきだろうということで、そこからOSが動作するのに必要な機能をどんどん実装していくことにした。最終的な目標はOS動作だが、研修Aの時間で作ることができなかったため、続きは今後個人的にやっていくこととした。したがって現段階ではCPUの動作のみしか確認していない。とりあえずデモとしてテトリスを作成し、これをgccでクロスコンパイルしたものを動作させた結果の動画を掲載する。

画面のすぐ前にあるキーボードの隣にあるのがFPGA(DE0-CV)であり、これに液晶と手前のキーボードが接続されている。今回参考したアーキテクチャはパタヘネに合わせてMIPSだが、その中でも簡単なものとしてR3000プロセッサという、プレイステーションにも搭載されたものをまねて作成した。せっかく作ったのでソースコードを上げようかと思ったが、とりあえず中身があまりきれいではないので、一度全体を作り直そうかと思っているところである。でき次第アップロードしようかと思っている。

参考にした文献を一応挙げておくと、

これが和書としては詳しい。ただし古い本であるので、もしかしたら手に入れるのが難しいかもしれない。と思ったらAmazonには中古が大量にあるようだ。ちなみに私は大学の図書館で手に入れたので購入していない。

また

MIPS32™ Architecture For Programmers Volume I: Introduction to the MIPS32™Architecture

でグーグルで検索してみると、いろいろpdfが出てくるだろう。これらを参考にすればMIPSについてはずいぶんな情報を得られるはずである。もちろんパタヘネも役立つはずである。特にパタヘネの命令表は非常に見やすく便利である。

まだまだFPGAが高価なためか、ネット上にはFPGAにまつわる情報がほかの組み込み系(例えばマイコンで自作するといったような)の話題と比べると少ないように感じる。今後技術的な内容については、ソースコードを直していく際に触れていく予定なので、それがそれらに対する一助になれば幸いである(といっても私のやる気がなくなればそれで終わってしまうわけだがw)。

続き書きました.

FPGAでCPUを実装する(1)

内容についてどう思いますか?
  • いいね (7)
  • だめ (2)