問題含みの前々回、第23回で『後で実行クロックを一応実測しておきます』と書いてしまった（？）ので、今回は測ってみました。低レベルプログラミングでは、CPU内蔵のサイクルカウンタ類は勿論、ICEなどの開発ツールが提供する時間計測機能などが活躍するシーンも多いですが、「真実の友」はオシロスコープじゃないかと思います。「見ればわかる」ことは多い。
ぐだぐだ低レベルプログラミング(25) 低レベルプログラミングの友、オシロ
ぐだぐだ低レベルプログラミング(24) 訂正！GD32VF103、遅かったのは私のバグ
早速の訂正であります。昨日、RISC-V搭載マイコンGD32VF103のメモリアクセス思ったより遅いじゃん、などとディスってしまいましたが、大間違いでした。申し訳ありません。私のバグです。９サイクルと書いていたところ、実際は２サイクルです。 “ぐだぐだ低レベルプログラミング(24) 訂正！GD32VF103、遅かったのは私のバグ” の続きを読む
ぐだぐだ低レベルプログラミング(23) GD32VF103、メモリアクセスを測る
前回は、RISC-Vのサイクルカウンタを使って、GD32VF103の基本的な実行性能を測ってみました。そこで印象的だったのは、コードはFlashに置かれているのに、分岐しても特に大きな性能低下もなく、毎回きっちり同じ実行時間で処理されていることでした。シングルコア（シングルハードスレッド）のマイコンとしては、良い性質じゃないかと思います。今回は、データに対するメモリアクセスを調べてみます。 “ぐだぐだ低レベルプログラミング(23) GD32VF103、メモリアクセスを測る” の続きを読む
ぐだぐだ低レベルプログラミング(22) GD32VF103、サイクルカウンタ実測例
前回、GD32VF103のRISC-Vコアのサイクルカウンタを動かせるようになったので、今回は短いコードについて測定してみて感触を確かめたいと思います。「たかが」サイクルカウンタと言っても「高等な」マシンだと、いろいろあったりするので。シンプルなシステムなので素直に使えるとよいなあ。 “ぐだぐだ低レベルプログラミング(22) GD32VF103、サイクルカウンタ実測例” の続きを読む
ぐだぐだ低レベルプログラミング(21) GD32VF103のサイクルカウンタ辺の実装
「RISC-V原典」を読んだので（といって全部きちんとじゃないですが）、再び、RISC-Vのアセンブラと戯れてみたいと思います。最初の疑問は、「図3.3 ゼロ・レジスタであるx0を利用したRISC-Vの32個の疑似命令」という表に掲げられている rdinstret, rdcycle, rdtimeという３つの「疑似命令」についてです。x86の場合の rdtsc と似たもの共、と言えば「アセンブラ関係者」の方はお分かりと思います。 “ぐだぐだ低レベルプログラミング(21) GD32VF103のサイクルカウンタ辺の実装” の続きを読む
ぐだぐだ低レベルプログラミング(20) RISC-V、nop、mv、li？？
別シリーズに (93) (94) (95) とRISC-Vのアセンブラねたを仕込んでしまいました。一応、アセンブラは「こちら」というこで引っ越しをすることにいたしました。今後はRISC-Vのアセンブラねたはこちらということでお願いいたします。ま、どちらでも大した違いはないんでありますが。しかし、何か月ぶりのシリーズ再開だ？ “ぐだぐだ低レベルプログラミング(20) RISC-V、nop、mv、li？？” の続きを読む
ぐだぐだ低レベルプログラミング(19) Arm NEONをつかってみる4
ようやくコンパイラにNEONのクワッドワードのレジスタを使うコードを吐き出してもらえるようになったので、わずかにハードルを上げてみたいと思います。当初から予定通りで、内積計算ですね。ベクトルの要素毎に単純な掛け算をしているのと比べると、それらの和をとっていかなければならないので、計算はちょっとだけ複雑。それに何と言っても結果はスカラー。コンパイラはどのように料理してくれるのでしょうか。
ぐだぐだ低レベルプログラミング(18) Arm NEONをつかってみる3
続けざまにぐだぐだです。前回、なんとかコンパイラがクワッドワード（１２８ビット）幅のレジスタを使ったNeon命令を吐き出すようになりましたが、何か思っていたより複雑なコードになっていました。もしやと思ってよく考えてみたら、それは私の書いたコードがイケないことに気付きました。それでもコンパイラ様は必死に注文にこたえるべく、コード生成をおこなってくれた結果、なにやら複雑なコードが生成されてしまったのでした。自分の書いたコードをコンパイラ様が素直に解釈できるようにちょいと直せば良かったのでした。それでようやく、クワッドワードかつシンプルなコードが出力されるようになりました。
ぐだぐだ低レベルプログラミング(17) Arm NEONを使ってみる2
ぐだぐだです。前回は、NEONを使ってみると書いておりましたが、今日見直してみれば、本当の意味のNEONじゃありませんでした。すみません。最近では、ArmのVFP(Vector Floating Point. 一応「ベクトル」計算機だったのね）は、NEONお供というか補完用の命令セットでなっているみたいです。NEONが１レジスタに複数の要素を入れて同時に処理できるのに比べるとVFPはパイプライン方式のベクトル化（昔はこれが本道だったような気もしますが）。１レジスタには１要素であります。こちらの命令が生成されていた。ま、今じゃNEONの一部と言えないこともないですが、狙いは１レジスタに複数要素のSIMDなので違う。狙い通りのコードを生成するにはどうするの？
ぐだぐだ低レベルプログラミング(16) Arm NEONを使ってみる1
今回から、少し実用的？に、ArmのNEONを学んでみたいと思います。所謂SIMD(Sigle Instruction/Multiple Data)の命令セットです。Intelでいうと、AVXとか、SSEとかに相当します。Arm NEONの場合、128ビット幅のレジスタなので一度に単精度の浮動小数であれば４個、16ビットの整数なら8個を計算できます。GPUの並列度には遠く及びませんが、使えるものは使いましょう。それに、我がRaspberry Pi 3 model B+でも立派に使用できるのであります。
＜訂正＞この回はNeon命令使用に行きついていませぬ。その一歩手前で終わっております。
ぐだぐだ低レベルプログラミング(15) 変数アクセスのコードを眺めてみれば3
前回までで大域変数について、単純な変数、初期値のあるもの無いもの、配列、構造体とコンパイラの吐き出したメモリアクセスのコードを一通り調べてみました。今回は、関数の中のローカル変数、引数について調べてみます。前回、前々回と同じく、環境はRaspberry Pi 3 model B+上のRaspbian OS、コンパイラはgcc 8.3.0 です。なお、生成されたアセンブリ言語コードの読みやすさを優先に、最適化オフ、デバッグ情報ありです。 “ぐだぐだ低レベルプログラミング(15) 変数アクセスのコードを眺めてみれば3” の続きを読む
ぐだぐだ低レベルプログラミング(14) 変数アクセスのコードを眺めてみれば２
前回は、Ｃコンパイラの吐き出した単純な大域変数へのメモリアクセスのコードを眺めてみました。今回は、大域変数でも構造体と配列へのアクセスを見てみます。今回も環境は、Raspberry Pi 3 model B+上のRaspbian OS、コンパイラはgcc 8.3.0 です。なお、生成されたアセンブリ言語コードの読みやすさを優先に、最適化オフ、デバッグ情報ありです。
ぐだぐだ低レベルプログラミング(13) 変数アクセスのコードを眺めてみれば
ぐだぐだ低レベルプログラミング(12) オブジェクトファイルその２
前回は、オブジェクトファイルと言いながら、絶対番地のHEXファイルなど、ついついFlashライタでもなければ使わないようなものにフォーカスしてしまいました。今回は、心を入れ替えて（どう？）、本道のリンク可能なオブジェクトファイルを調べてみたいと思います。コンパイル、アセンブルした後のオブジェクトファイルとリンクした後の実行可能なオブジェクトファイル、例によってRaspbian上のArmの32ビットコードで見てみます。