目次: RISC-V
ついにAkaria NS31AのEntry Kitの回路データが書き込まれたFPGAボード(DIGILENT ARTY A7ボード)が到着しました。やったー。
中身はボードとドキュメント類が書き込まれたDVDが入っているだけのシンプルなものです。受領書を返してくれと言われているのですが、返し方が良くわからないのでメールで質問中です。
DVDの中身はまた後日確認したいと思います。
送られてきた荷物を見てビックリしたんですけど、ちょっと包装に問題がありました。自社商品でもあるし、せっかく拓いてもらった個人向け販売チャネルを潰したくないので、忖度全開で詳しいことは書きませんけども……。
私は細かいことは気にしないですが「さすがにこれはダメでしょ?〇〇社に怒られますよ?」と思ったレベルのミス、とだけ添えておきます。
目次: RISC-V
NS31A Entry Kitを受け取ったら受領書を送り返してほしい、と言われているのですが、受領書は不思議な書類で、
受領書に関係していそうな前者2つについて質問したところ「あなたの住所を書いてくれ」という意味が分からん回答が返ってきました。質問の仕方が悪いのか、的の外し方から察するに「私に何を送ったか把握していない」可能性もありそうです。
と推理すると包装の問題とか、個人向け販売なのに受領書がB2B向け販売の仕様(検査票+受領票とセット)が少しは理解できます。
さておき質問を文章で説明するのは厳しそうなので、送られてきた書類をスキャンし赤い字で「ここですけど、どうしたら?」と書いて送ってみました。これならご理解いただけるはず。
付属していたDVDに書かれたデータも欠けていた(サンプルプログラムが入っていない)ので、問い合わせたら「内容が間違ってた、ごめん」的な返事とともに、後日DVDがもう1枚家に送られてきました。
個人向け販売チャネル第一号ってのはなかなか大変ですね。デバッグをしているような気分です。
目次: 独自OS
最近、趣味&趣味からの発展で仕事でも独自OSを作成しています。OSと呼ぶほどの機能はありませんが、位置的にはCライブラリよりハード寄りのいわゆるOSレイヤーです(ソースコードへのリンク)。
想定する動作環境は、複数プロセッサで構成されたシステムにおいて、片方がホスト、もう片方がアクセラレータとして動作する環境です。想定する制御方法は、ホスト側で実行したくない、時間がかかる処理をアクセラレータ側に任せて終わるのを待つ、シンプルなユースケースで下記のようになります。
このようなシステムにおいてPC系のプログラマが気軽にアクセラレータ側のソフトウェアを書ける環境が欲しい、という発想から、アクセラレータのプログラマの補助となるようなOSの作成が目的です。
独自OSの設計目標は下記の通りです。
最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く&便利を両立させることが狙いです。
アクセラレータを動作させるという観点で見れば、わざわざ独自OSを作成せずとも既存のアクセラレータ用言語を使ったり、既存OSの転用でも動作させることができます。
既存のアクセラレータ用言語、CUDAやOpenCLですね。速度は最高だと思います。プログラマ視点から見ると、これら言語の習得には若干手間が掛かります。
LinuxなどPC系OSを転用する場合、使い勝手はPCそのものなので最高でしょう。しかしアクセラレータ向けとしては大規模で大げさでもあり、ハードウェアのリソース特にメモリがかなり必要です。
RTOSを転用するの場合、省メモリかつ大抵の実装は速度も速いです。しかし目的が違う(リアルタイム処理を記述するためのOS)ため、色々なOS独自ルールが存在します。PC系のプログラマには馴染みが薄いです。
手法 | 速度 | メモリ | 手軽さ |
---|---|---|---|
アクセラレータ用言語 | 〇 | 〇 | × |
PC系OS(Linuxなど) | △ | × | 〇 |
RTOS | 〇 | 〇 | △ |
独自OSでは使い慣れたC/C++ 言語が使えて、速さを殺さず、Linuxの使い勝手を可能な限り両立させることを目指します。
目次: 独自OS
最近、趣味&趣味からの発展で仕事でも独自OSを作成しています。独自OSの設計目標は下記の通りです。
最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く&便利を両立させることが狙いです。
「便利、手軽」の実現のため、ソースコードレベルの互換性の確保を目指します。具体的にはLinux用に書かれたソースコードをそのままアクセラレータ用にコンパイル&実行できれば、プログラマから見てLinuxの使い勝手を実現できている、と言えるはずです。
一方で「軽く、速く」を実現するため、Linuxとのソース互換を目指しつつも、アクセラレータ向けに割り切った制限をいくつか設けます。
これらの制限が妥当かどうか?について今は結論は出ないので、実装して使って問題があれば今後修正したいと思います。アクセラレータやOSに詳しい方々の意見も聞いてみたいです。
アクセラレータに処理を依頼する際のインタフェースはいくつかありますが、いずれも定番ではなさそうです。今回はOpenCL風のAPIを採用しました。OpenCL規格に準拠はしませんが、ある程度(例えばclinfoに応答できる程度)のOpenCL APIを実装します(ホスト側のソースコードのリンク)。
ホストとアクセラレータ間のデータ移動や実行制御の方法も考える必要があります。ホスト側からアクセラレータ側に何か計算を依頼するケースと、もう一つアクセラレータ側のスタンドアローン実行(ホスト側から制御なしでアクセラレータ側のみ単独実行するモード)はデバッグの利便性を考えると、必須に近い機能です。
またホスト側に過度に依存しないように、ホスト側のAPIが気に入らなくなったら別のAPIを実装することができるように、アクセラレータ側の独自OSとは別のリポジトリに分離して実装します。
独自にOSを実装する道を選びました。既存のOSSを改造するより実装期間が短く済むと思ったくらいで、独自実装しなければならない強力な理由はないです。個人的な理由も入れて良ければ、独自OS実装に対する興味があったことが大きいです。
RTOSにLinux互換レイヤを積む方法、Linuxをダウンサイズする方法、などでも実現できるのではないでしょうか。Linuxをダウンサイズする方法だとスレッド周りの制約実現が難しいですかね……?やったことがないので何とも言えません。
そんなの簡単にできるよ、という方はぜひOS作成フレンズになりましょう。
< | 2022 | > | ||||
<< | < | 12 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | 1 | 2 | 3 |
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
合計:
本日: