コグノスケ

ヘッドフォンの謎のノイズ

オーディオは専門ではないし、神の耳も持っていないので、細かい音質うんぬんは全くわからないし、高級○○ケーブルなどはオカルトの一種とすら思っていますが……。

音質で唯一体験したことを思い出したので、メモしておきます。

以前はテレビのファーム開発をしていたため、職場ではテストのために少し良い（1万円〜2万円レベルの）ヘッドホン（SHURE SRH440-A）を使っていました。

何も鳴らしていないのに、ヘッドホンからたまにブーン……という微かなノイズと、バリ、バリ！という大きめのノイズが聞こえていました。

スマホとヘッドフォン

最初、評価ボードか機材の故障を疑っていたのですが、なんと原因は自分のスマホでした。

前者のブーン……ノイズは、ヘッドホンのケーブルをくるくると丸めて束ねた上に、スマホを置いていたため、スマホの電波を拾ってノイズになっていたようです。

たまにしか鳴らないのは、パケット通信のときしか強く電波を発しないからですかね？スマホを机の上に置かないようにしたらノイズは聞こえなくなりました。

家の安いヘッドホンで同じことをしても、ノイズは聞こえなかったので、感度の良いヘッドホンじゃないと拾わない（？）のかもしれません。

後者のバリバリ！ノイズは、ヘッドホンアンプの上にスマホを置きっぱにしたときに鳴っていました。ノイズを増幅するのか、かなり目立つバリバリ音が聞こえていました。

これもスマホとアンプを遠ざけて置くことで、ノイズが消えました。

謎が解ければ何てこと無い原因でしたけど、最初はわからなくて、このヘッドフォン壊れているんだろうか？不良品かしら……？とか思っていました。冤罪でした、ごめんねヘッドホンさん。

タチの悪い内蔵音源

音質でもう一つ思い出したのが、先代ノートPC（ThinkPad Edge E420）のアナログオーディオ出力は、常にシューシューというノイズが聞こえていたことです。

2010年は遥かに過ぎて、こんなにノイズが鳴るオーディオがあるはずない、聞き間違いだろうと思いきや、安物のオシロで見てもすぐわかるくらいノイズが載っていてショックでした。Conexantさん勘弁してよ……と思いました。

測定結果は、以前の日記に書いています（2014年10月18日の日記参照）。あれからもう五年も経ったのか。早いものだ。

メモ: 技術系？の話はFacebookから転記しておくことにした。リンクなどを追記。

RISC-V原典

RISC-V原典という本も買って読んでいます。どちらかというと頭から読む本ではなく、辞書的な本です。命令一覧の章はとても便利ですね。

RISC-V原典では「過去のアーキテクチャが患ったインクリメンタリズム」と他のアーキテクチャの複雑さを評していましたが、RISC-Vは出来たばかりなので「今」シンプルなのは当然だよね……などと思ったりしました。

RISC-Vと昔のARM

RISC-Vは命令セットの独自拡張を許しているため、同じRISC-V CPUを名乗っていても「A社CPUとB社CPUでは、同じバイナリが実行できない」ことがありえます。

ARMやx86も互換性のないCPUは存在しますが、共通の命令セットが大きいためあまり問題にはなりません。一方RISC-Vは共通命令セットが小さい（RV32I、MMUなしのマイコンレベル）ので、非互換性で問題が起きそうですね。ARMでいうとCortex-A系とCortex-M系を混ぜて売るようなもので、混乱を招きそうです……。

このタイプの命令拡張方式で私が思い出したのはARMです。ARMも昔はARMv5TEJのように、対応する拡張命令をアルファベットで追記する、似たような方式を採用していましたが、ARMv6で拡張命令に全て対応したため、拡張命令方式は消滅しました。

未来予想

私の予想としては、スマートフォン、デジタル家電、PCのような、比較的高性能な分野にはRV64GC（G = IMAFD、multiple, atomic, float, double）が共通命令セットになり、マイコン系にはRV32IかIMくらいが共通命令セットになる、辺りが落としどころかなと思います。

RISC-Vも「インクリメンタリズム」に陥る未来は避けられず、拡張に次ぐ拡張でゴチャゴチャになる未来を迎えると思いますが、20年後、

• RISC-Vがそもそも使われているか
• RISC-Vは今と同じことを言えるくらいシンプルを維持できるか
• RISC-Vが別のアーキから同じ欠点を指摘されていないか（歴史は繰り返す…）

期待が大きいだけに、将来的にどうなるか、楽しみです。

強いオセロ

どうやっても圧勝してしまう「最弱オセロ」（リンク）が話題ですが、実はその横に「強いオセロ」（リンク）もあります。URLから推測するにこちらの方が先に作られたように見えます。

名前に偽りはなく、ものすごく強いです。私のような素人の実力ですと50石（ほぼ真っ白）〜64石（全て白）で完敗します。終盤に一気にひっくり返され、全く勝てません。

まともにやっても全く勝てなかったので、どんな手でも良いから、1度でも勝てないだろうか？と試行錯誤するうちに、ちょっとしたクセが見えてきました。このAIは「終盤の大逆転」を重視していて、序盤〜中盤は石数が不利でも無視する傾向があります。

このクセを逆手に取り、中盤戦でとにかくゴリ押しして、白を全滅させる作戦を取ると、ごくたまに勝てることがあります。下記はその例です。

中盤でゴリ押しして勝てたケース

中盤で押し切れなければ負けです。20〜30局やりましたが、これ以外の勝ち方はできませんでした……。

RISC-Vの命令

目次: RISC-V

最近、何かと関わっているRISC-Vの理解のため、エミュレータを書いてみています。先日購入したHiFive Unleashed（2019年5月26日の日記参照）の1st ROMと2nd ROMを拝借して、Linuxがブートする辺りまで作るのが当面の目標です。

スクラッチから作ると辛いので、ARMv5のエミュレータememu（GitHubへのリンク）をベースにして改造して作っています。まがりなりにもARMv5が動いているんだから、RISC-Vも楽勝だろうと思いきや、世の中そんなに甘くありませんでした。

最初にコケたのはUnalignedな命令ロードです。RISC-VのC拡張をサポートする場合32bit境界ではないアドレスから、32bit命令をロードする場合があります。ARMv5ではUnalignedアクセス例外が発生します。

RISC-Vの命令エンコード

まだ完成していないので、現時点での感想ですが、RISC-Vの命令エンコードは比較的わかりやすい気がします。ただ、ブランチ命令のオフセットは、下記のような並びになっていて、不思議な配置です。

RISC-Vのブランチ命令

今まで見た中で一番見づらいものは、C拡張命令のバイナリです、これは異様に見づらいです。しかしC拡張の目的（命令長を削るため16bit長に無理して詰めている）からすると、仕方ないでしょうね。

C言語とCPUアーキテクチャと除算命令

目次: C言語とlibc

今まであまりCPUアーキテクチャの違いを感じたことはありませんが、除算命令を触っていたところ、アーキテクチャによってかなり動きが違っていて面白かったので、メモしておきます。

プログラムは下記のとおりです。

#include <stdio.h>
#include <limits.h>

void f(int a, int b)
{
        printf("mul:%08x * %08x = %08x\n", a, b, a * b);
        printf("div:%08x / %08 = %08x\n", a, b, a / b);
}

int main(int argc, char *argv[])
{
        f(INT_MAX, -1);
        f(INT_MIN + 1, -1);
        f(INT_MIN, -1);     //乗算、除算の動作は未定義
        f(INT_MAX, 0);      //除算の動作は未定義
}

初めに断っておくと、コメントを打った箇所については、C言語上の仕様上、動作が未定義です。つまり、どんなことでも起こり得ます。不定な結果が返ることもあるし、プログラムが停止することだってあります。

未定義動作も色々

このプログラムをx86 (x86_64, Ryzen 7 2700), ARM (AArch64, Cortex A53), RISC-V (RV64GC, SiFive FU540) のLinux上でそれぞれ実行してみます。

#### x86_64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
Floating point exception


#### AArch64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = 00000000


#### RV64GC ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = ffffffff

当然ながら、動作が定義されている演算は、どのアーキテクチャでも同じ結果です。当たり前ですね。

• INT_MAX * (-1) = INT_MIN + 1
• INT_MAX / (-1) = INT_MIN + 1
• (INT_MIN + 1) * (-1) = INT_MAX
• (INT_MIN + 1) / (-1) = INT_MAX
• INT_MAX * 0 = 0

一方で動作が未定義の演算は、かなり挙動が変わります。

• INT_MIN * (-1) = INT_MIN
• INT_MIN / (-1) = クラッシュ (x86_64), INT_MIN (AArch64, RV64GC)
• INT_MAX / 0 = クラッシュ (x86_64), 0 (AArch64), -1 (RV64GC)

個性が出ますね。

x86の除算命令の奇妙な仕様

先ほどの例でx86上でINT_MIN / (-1) の除算がクラッシュする原因はidiv命令の仕様です。

Intelの命令仕様書（Intel Architectures Software Developer Manual: Vol 2）のIDIV - Signed Divideのページを見ると、保護モード例外 #DEが発生する条件として、

• ソース・オペランド（除数）が0である場合
• デスティネーションに対して符号付きの結果（商）が大きすぎる場合

この2条件が挙げられています。INT_MIN / (-1) は結果が32bitで表現できないため、後者に引っ掛かるわけです。

異常な演算に対して例外を発生させる設計思想なら分かりますが、乗算命令は異常な結果でも素通しなのに、除算命令は異常な結果だと例外発生します。片手落ちの不思議な仕様です。変なの……。