デバイス作る人>>デバイス使う人>>デバイスおたく
続けざまにぐだぐだです。前回、なんとかコンパイラがクワッドワード（１２８ビット）幅のレジスタを使ったNeon命令を吐き出すようになりましたが、何か思っていたより複雑なコードになっていました。もしやと思ってよく考えてみたら、それは私の書いたコードがイケないことに気付きました。それでもコンパイラ様は必死に注文にこたえるべく、コード生成をおこなってくれた結果、なにやら複雑なコードが生成されてしまったのでした。自分の書いたコードをコンパイラ様が素直に解釈できるようにちょいと直せば良かったのでした。それでようやく、クワッドワードかつシンプルなコードが出力されるようになりました。
ぐだぐだです。前回は、NEONを使ってみると書いておりましたが、今日見直してみれば、本当の意味のNEONじゃありませんでした。すみません。最近では、ArmのVFP(Vector Floating Point. 一応「ベクトル」計算機だったのね）は、NEONお供というか補完用の命令セットでなっているみたいです。NEONが１レジスタに複数の要素を入れて同時に処理できるのに比べるとVFPはパイプライン方式のベクトル化（昔はこれが本道だったような気もしますが）。１レジスタには１要素であります。こちらの命令が生成されていた。ま、今じゃNEONの一部と言えないこともないですが、狙いは１レジスタに複数要素のSIMDなので違う。狙い通りのコードを生成するにはどうするの？
今回から、少し実用的？に、ArmのNEONを学んでみたいと思います。所謂SIMD(Sigle Instruction/Multiple Data)の命令セットです。Intelでいうと、AVXとか、SSEとかに相当します。Arm NEONの場合、128ビット幅のレジスタなので一度に単精度の浮動小数であれば４個、16ビットの整数なら8個を計算できます。GPUの並列度には遠く及びませんが、使えるものは使いましょう。それに、我がRaspberry Pi 3 model B+でも立派に使用できるのであります。
＜訂正＞この回はNeon命令使用に行きついていませぬ。その一歩手前で終わっております。
店頭にならんで直ぐに購入させていただいたのですが、しばらく「寝かせて」しまいましたスミマセン、トラ技2019年11月号であります。特集「世界のＡＩマイコン」、しかし、その上の青文字を見逃してはいけません、64bit/400MHz RISC-Vです。世界のと言いつつ、その実態はK210（RISC-Vコア）の特集といって良いでしょう（そのくせRISC-Vそのものは前面に出てこない）。愛用のJetson NanoもRaspberry Piなども登場はしますがぶっちゃけ比較相手。しかし、このチップ、物欲をそそります。読めばボードが欲しくなる、そしてお手頃価格！そういえば前回も特集読んでJetson Nanoポチりました。どうしたものでしょ。
“Literature Watch Returns(9) 「世界のAIマイコン」特集、トラ技2019-11月号” の続きを読む
私なんぞは「その筋」の専門家でもなんでもないので、XMLと向き合わなければならないことなどさほど多くはありません。時折あるそんな機会も、とりあえずPythonでlxml使っておけばOK、てな感覚でおりました。XPath便利ですし、lxmlは速いのではないですかね。でもね、たまに困ることがあります。名前空間の指定されているXML、それもプリフィックス無し、デフォルト名前空間というやつが含まれるとき。そういうときはどうしたらよいんでしょうか？
前回までで大域変数について、単純な変数、初期値のあるもの無いもの、配列、構造体とコンパイラの吐き出したメモリアクセスのコードを一通り調べてみました。今回は、関数の中のローカル変数、引数について調べてみます。前回、前々回と同じく、環境はRaspberry Pi 3 model B+上のRaspbian OS、コンパイラはgcc 8.3.0 です。なお、生成されたアセンブリ言語コードの読みやすさを優先に、最適化オフ、デバッグ情報ありです。 “ぐだぐだ低レベルプログラミング(15) 変数アクセスのコードを眺めてみれば3” の続きを読む
今も必死で復旧作業に取り組んでいらっしゃる皆さま方、非常にお疲れのことと思います。くれぐれも事故の無いようお気をつけください。そして、あの大雨の夜の闇の中で各地で悲劇が起きていたことがようやく判明してきたようです。未だ全貌は分かりませんが、亡くなられた方が増え続けています。痛ましいことであります。
あまりに多数の河川の多数の箇所で決壊が起きたようです。決壊にいたらないまでも越水したところはさらに多いようです。今も水が引いていないし、まずは堤防の復旧と排水を急がないとならない状況だと思います。しかし、ニュースを見ると、橋梁の流出、落橋、損傷もまた多数。橋の復旧は堤防の後でしょうが、取り急ぎ場所だけでも書きとめておく必要を覚えました。ニュースになったような鉄道橋、道路橋あたりを中心として、後日の控えとして列挙しておきます。あまり増えてほしくはないリストですが、何か判明すればまた戻ってきて書き込みたいと思います。（追記10/20)
前回は、Ｃコンパイラの吐き出した単純な大域変数へのメモリアクセスのコードを眺めてみました。今回は、大域変数でも構造体と配列へのアクセスを見てみます。今回も環境は、Raspberry Pi 3 model B+上のRaspbian OS、コンパイラはgcc 8.3.0 です。なお、生成されたアセンブリ言語コードの読みやすさを優先に、最適化オフ、デバッグ情報ありです。
前回は、オブジェクトファイルと言いながら、絶対番地のHEXファイルなど、ついついFlashライタでもなければ使わないようなものにフォーカスしてしまいました。今回は、心を入れ替えて（どう？）、本道のリンク可能なオブジェクトファイルを調べてみたいと思います。コンパイル、アセンブルした後のオブジェクトファイルとリンクした後の実行可能なオブジェクトファイル、例によってRaspbian上のArmの32ビットコードで見てみます。
昨日に続いてPythonネタです。数か月前にPython3へ移行始めた件、何かの投稿の中に書きました。今年いっぱいでPython2.7のサポート終了、来年からはPython3に天下統一、ということで急に不安になったがためですね。ま、もともとそんなに特殊なものは書いていなかった（筈）なので、順調に移行（というか手動移植による両用化）できていると思っていたのです。が、やっぱりね、ハマりました。それもとてもプリミティブなところに。
普段、あまりモノを考えずにPythonのコードを感覚的に書いているからだと思うのですが、時々、ハマります。今回は、便利な *演算子、掛け算だけでなく、文字列やリストにも使えるアレ、を考え無しに空リストに使ってハマった件を書かせていただきます。ま、後で見てみれば馬鹿馬鹿しい、けれども、ハマったときには見えていない。。。
前回、コンパイラの出力を元とするオブジェクトファイルのアセンブリリストをながめておりました。そこで現れてくるメモリアクセスを読み解くときには、セクションなる存在を無視することはできません。ただ、セクションなるもの、多面的な顔を持っていますな。全てを一度に知ろうとしても膨大すぎるかも。多分、列挙する前に速攻で忘れそうです。裏では活躍されているのでしょうが、実際、とりあえず知らんでも済むセクションの方々も多数。しかし、だいたいセクションとは何に含まれておるのかや？その在りかを知らずしてセクションの理解には至らぬであろう（本当か）。今回はその手前のオブジェクトファイルについてぐだぐだ書いてみました。 “ぐだぐだ低レベルプログラミング(11) オブジェクトファイルその１” の続きを読む