Polyphony の 2018
2018 は Polyphony にとってもう少し普及を図るはずでしたが十分な成果をあげることなく終わりに近づいています。
去年の記事を見てみましょう
[Polyphony のこれから：「鳥が卵から出ようとする」]
(https://qiita.com/ryos36/items/468a47e4c991d5a29d5b)
予定通りに v0.3.3 は出せました。次の機能は達成しました。
- import
- パイプライン化
- for 文の unroll
II=2 以上のパイプライン実装
これはほぼできました。次の v0.3.4 ではこの機能が盛り込まれるでしょう。
Tuple による同時性記述 検討(実装)
残念ながら実装には至らず。これはいろいろインタフェース上の諸問題があったためです。Tuple による単純な同時性の記述は今後も検討しますが、重要ではなくなっています。
その代り別の手段を考えています。
bit ライブラリ(検討)
これも実装には至っていません。う～ん。ここは早めに達成したいですね。
Python のインライン関数の列挙(検討)
これも実装には至っていません。
関数オブジェクト対応
これも実装には至っていません。あまり優先順位は高くないかな。
柔軟なリソース対応
これは内部的にだいぶ対応しました。クロックをあげるための仕組みをいれるにあたって内部リソースは柔軟に対応できるようになりました。ただ、それを表現する API が十分ではありません。
ここは慎重になっています。というのも #pragma と同じ運命になってはいけないとおもっているので。
柔軟な配列(setitem/getitem)
ここは再考が必要なところです。できればよいのですが、list や配列をどう実際のメモリ、BRAMやレジスタにマッピングするのか？は難しい課題です。ケースバイケースで違うものなのでユーザが指定できるようにするのが望ましい気がします。そしてここにも #pramga (Python ならデコレータになるでしょうが） 問題が顔を出します。
何が書けるのか？にフォーカスしていく
「コンパイラ自身の機能アップというより、何が書けるのか？にフォーカスしていく」と書いていますが、あまり達成してませんね。2019 へ課題持ち越しです。今回、いろいろ書いてみて”使える””使えない”は比較的はっきりしてきました。整理が必要です。
Polyphony の 2019
「コンパイラ自身の機能アップというより、何が書けるのか？にフォーカスしていく」を継続して検討し、おおくの例を示せるようにしたいと思っています。分野はそこそこ絞りたいとは思っています。
- 同時性記述 検討(実装)
これが次の一番のターゲットになります。あと API まわりは整理しないといけません。使いやすい例をいかにあげられるか？これが 2019 年の前半のポイントです。なので、早い段階で、なんらかのアクションを起こしたいと思っています。2019 のアドベントカレンダーを待つという事はしません。