自治体の接種会場に行きました。ワクチンはファイザー製でした。
入り口には警備員さんがいましたが、予約システムの予約票は確認されないため「予約してまーす」って言ったら誰でも入れそうでした。が、多少嘘つきが混ざる程度は特に問題ないでしょう。
会場に入れないほど混んだり、1人も来ないなどの事態さえ発生しなければ、別に誰に打ったって良いわけですから。
ワクチン接種会場には毎日嫌になるほど人が来ていると思いますが、看護師を始めとした医療従事者の皆様は非常に親切かつ効率的に働いていました。日本の医療は最高だよ、ありがてぇ。
午後だったせいなのか、問診の先生はかなりお疲れモードで、半分目が死んでました。お疲れ様です、無理はしないでください……。
ワクチンを打った後は、肩こりみたいな痛さ、とか、肩にパンチを食らったような痛さ、と言われてますが、体験したら意味がわかりました。これは痛い……。
目次: ゲーム
最近のPCゲームは画面がとてもキレイですね。シミュレーションゲームなど画質とゲーム性があまり関係ないものであっても、こだわりを感じます。海外レーベルのゲームにリアルな画作りが多い印象です。
画面が美しいのはありがたいですけど、我が家のノートPCに積まれてるディスクリートGPU(Radeon RX 550 Mobile)はあまり性能が高い方ではなく、画質をかなり下げないと「コマ送りかな……??」といわんばかりの描画速度になります。
そもそもシミュレーションゲーム好きで、画質や動き重視のゲームは持ってないですが、それでもノートPCには荷が重いゲームたちがいます。
No.1はThe Hunter: Call of the Wildです。画質を上げると景色の描写が非常に美しいです。描画の処理もべらぼうに重いです。我が家のPCでは画質をほぼ最低ランクにしても、草むらなどのオブジェクトの多い場所に突っ込むと、画面がガクガクしてライフルの狙いがつけられません。無駄に難易度が上がる……。
不思議なことに七面鳥だけ、動物の大きさの割に描画が異常に遅くて、描画範囲に入った瞬間に画面がガクガクし始めます。直接見なくても居ることだけはわかるエスパーになれます。
No.2はDyson Sphere Programです。ダイソン球の浮かぶ宇宙、開発中の惑星の景色が素晴らしくキレイです。ゲームの序盤はノートPCでも何ともないんですけど、ゲームの中盤(別の星系に進出する時期)あたりの惑星状に大量の建築物がある状態だと遅くなります。
ジェットで空高く飛び上がったり、惑星間航行で惑星に着陸するときなど、地表の建物が大量に視界に入ってくると、途端に画面がガクガクしてあらぬ方向に飛んでいきます。どこいくんだー。
No.3はAssetto Corsaです。車やコースの描写が非常に美しいです。レースゲームはPlayStation 3あたりで実写と見紛うばかりの画質になりましたが、さらに進化していると思います。ただこのゲーム、最適化を相当頑張っているのか、見た目の綺麗さから想像するより描画の負荷が軽くて驚きます。ロードは遅いけど……。
適当に走るくらいならノートPCでも遊べますが、レースゲームは他のゲームに比較してコマ落ちが致命的ですからね。ノートPCのGPUで遊ぶのは精神衛生上良くないですね。
目次: RISC-V
最近はHiFive Unmatched(HiFive Unleashedも使い勝手はほぼ同じ)を使っていることが多いのですが、このボードは開発環境としてはなかなか魅力的です。素敵なところをいくつか挙げると、
他社のボードもいくつか使いましたけど、USB-JTAGチップ搭載のボードはあまり見かけません。通常はJTAGを使いたいと思ったら、JTAGの箱(私はSEGGER J-LINK EDUを使っています)が必要です。が、HiFive系のボードはJTAGの箱が不要です。これは地味に嬉しいです。
JTAGはベアメタルやブートローダのようなローレベル開発で重宝しますが、製品のボードにはまず搭載されることはないです。理由は単純。JTAGはデバッグ用の機能で、正常動作しているときには全く使わないからです。ボードのコストアップにしかならず、製品用の設計では真っ先に切られる機能です。以前、メーカーに居た時もデバッグ機能はソフトハード関わらず真っ先に切られていました。
利用者目線から見ると、デバッグ機能を切って安くあげるのは大正義です。利用者はまずデバッグ機能なんて使いませんし、デバッグ機能を悪用して機器に侵入するなどの被害を防ぐ効果もあります。
とはいえ開発者目線から見るとデバッグ機能のないボードやSoCは、トラブったとき解析しづらくて困ります……。なので、SoCレベルではデバッグ機能ON、ボードレベルではOFFにしておいて、不具合解析の際は特殊な治具を繋いでボードレベルのデバッグ機能をONにする設計を良く見かけます。
目次: Zephyr
ZephyrのHiFive UnmatchedとHiFive Unleashedへのポーティングが本家のmainにマージ(※)されました。2.7.0のマージウインドウが終わるまで、メンテナーチームは忙しそうだったので、もうしばらく放置かな?と思っていましたが、昨日突然マージされました。
これは以前トライしていたZephyrのHiFive Unleashedへの移植(2021年6月6日の日記参照)に加え、HiFive Unmatchedへの移植(2021年8月20日の日記参照)も追加したものです。RISC-Vはメンテナーが少ないこともあって割と放置気味になりがちなんですよね……。
ポーティングといっても、最低限の設定+とりあえず起動するだけで、ほぼ何にも使えない(UARTとSPIくらいしか動きません)から、まだまだこれからだな。うん。
(※)最近はmasterという単語はダメだねってことで、既存のリポジトリもmaster → mainに置き換えられたプロジェクトが増えてます。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ゲーム
普段PCで何か作業する場合WindowsのノートPCを使っていて、マイコンボードでの実験や開発はLinuxのデスクトップPCにリモートアクセスして行っています。通常の作業には申し分ない性能と使い勝手が実現できています。
が、ゲームとなると話がやや違ってきます。ゲームは大抵Windowsを要求してくるので、我が家の唯一のWindows PCであるノートPCで遊ぶしかないんですけども、最近の3Dを多用したゲームは重すぎて、そのうちGPUが燃える(物理的に)んじゃないかと心配になってきます。
しばらく前に在宅勤務環境を整えた(2021年2月12日の日記参照)こともあり、机近辺に新たなPCを置けそうな場所ができました。Windowsをインストールしたゲーム用PCを新たに作りたいところですが、最近はあまりにもGPUが高すぎて購入に踏み切れません……。
いわゆるミドルエンドと呼ばれるTDP 200W以下(※)クラスは、今だとRadeon RX 6600 XTもしくはGeForce RTX 3060辺りだと思うんですが、Radeonはそもそも売り切れていて手に入りませんし、RTX 3060はお値段が6万円オーバーとあまりにも高すぎます。
GPUの値段はまだまだ下がらないようですし、諦めて買うしかないんですかねえ?
(※)補助電源8pin x 1くらいのカードをイメージしてます。GPUに供給可能な電力はPCIeカードエッジ(75W)+ 補助電源8pin x 1(150W)= Max 225Wです。
目次: C言語とlibc
C言語のmath.hヘッダには、円周率πを表すマクロM_PIが定義されています。しかしこのマクロ、コンパイラに -std=c99やc11を指定すると使えなくなるんですね。C言語通には常識かもしれませんが、個人的にハマったのでメモしておきます。
#include <math.h>
int main(void)
{
return M_PI;
}
$ gcc -Wall -std=c99 a.c a.c: In function ‘main’: a.c:5:9: error: ‘M_PI’ undeclared (first use in this function) 5 | return M_PI; | ^~~~ a.c:5:9: note: each undeclared identifier is reported only once for each function it appears in
もしc99やc11でもM_PIを使いたい場合は、math.hをインクルードする前に_DEFAULT_SOURCE(_GNU_SOURCEでも良いです)をdefineすると使えるようになります。
#define _DEFAULT_SOURCE
#include <math.h>
int main(void)
{
return M_PI;
}
使えるようになりました。
目次: Zephyr
RISC-V向けZephyrの新しいコンテキストスイッチ(CONFIG_USE_SWITCH=y)を実装しているのですが、浮動小数点演算つまりFPUを使うスレッドを生成するとハングします。調べてみると、私が実装している場所の外にある、新しいコンテキストスイッチ(zephyr/kernel/include/kswap.hのdo_swap() 関数)の実装が今まで(CONFIG_USE_SWITCH=n)と違うように見えます。まだ確証はないですけど。
従来の処理arch_swap() では、現在のスレッド(_kernel.current)がコンテキストスイッチ(arch_swap() 内のシステムコール)の内部で旧 → 新に置き換えます。つまりcurrentは切替「前」のスレッドを指している状態でコンテキストスイッチが始まります。
ところがdo_swap() の場合、現在のスレッド(_kernel.current)がコンテキストスイッチ(arch_switch() 関数)を呼ぶ「前」に旧 → 新スレッドに置き換えます。つまりcurrentは切替「後」のスレッドを指している状態でコンテキストスイッチが始まります。
RISC-V Zephyr(他のアーキテクチャも同じかな?)ではFPU使えるスレッドと使えないスレッドを使い分けることができます。コンテキストスイッチ処理では、currentスレッドがFPUを使うか使わないかにより処理を変えています。
私が実装したコンテキストスイッチも当然同じように実装したのですが……。先ほど説明したようにdo_swap() はcurrentを切替「後」のスレッドに設定するため、こんな悲劇が起きます。
原因の一端は掴めたものの、どうして他のアーキテクチャは困っていないのか?do_swap() の実装は意図的なのか?良くわかりません……。
前回(2021年8月26日の日記参照)同様に自治体の接種会場に行きました。ワクチンは当然同じでファイザー製です。
前回同様に看護師を始めとした医療従事者の皆様は非常に親切かつ効率的に働いていました。ありがてぇ。
問診の先生はやっぱりお疲れモードな雰囲気でした。無理はしないでください……。
前回はワクチンを打ってしばらく経ってから肩が痛くなりましたが、今回は打った直後から肩が痛いです。明日はどうなるんだろうか、これ……。
目次: RISC-V
RISC-Vにはcode modelという概念があり、ざっくり言うとメモリアクセスやジャンプの際に参照するアドレスの作り方を指定します。medlowとmedanyの2つがありmedlowがデフォルトです。
詳しくはGCCのマニュアル RISC-V Options (Using the GNU Compiler Collection (GCC)) やSiFiveのエンジニアによる解説 All Aboard, Part 4: The RISC-V Code Models - SiFive を読んでいただくのが良いかと思いますが、ここではどんなときにエラーになるかに重点を置いて、いくつか例を挙げたいと思います。
モデルmedlowは32bit絶対値でアドレスを指定します。具体的にはlui命令とロード命令などの12ビットオフセットを使います。lui命令とは20ビットのimmediateを12ビット左シフトして、符号拡張する命令のことです。
lui a1, 0x12345 # 12ビットシフトされた値0x12345000がa1に格納される ld a0, 0x678(a1) # アドレスa1 + 0x678 = 0x12345000 + 0x678からa0に値をロードする
このようなコードが生成されます。絶対値は -2GB〜 +2GBまでしか生成できませんので、全てのシンボルが範囲に収まっている必要があります。32bitアドレスを使っている場合は全てのアドレス範囲をカバーできますが、64bitアドレスを使っている場合は0x00000000_00000000〜0x00000000_7fffffffまたは0xffffffff_80000000〜0xffffffff_ffffffffのアドレス範囲にシンボルを配置しなければなりません。範囲外にシンボルを配置しようとすると、
// a.c
extern volatile int *hoge;
void _start(void)
{
*hoge = 1;
}
/* a.ld */
OUTPUT_ARCH("riscv")
ENTRY(_start)
SECTIONS
{
PROVIDE(hoge = 0x100000000); /* 0x1_00000000はmedlowの範囲外 */
}
$ riscv64-zephyr-elf-gcc -march=rv64gc -Wall -g -mabi=lp64d -mcmodel=medlow -nostdlib -T a.ld a.c --save-temp a.o: in function `_start': test-medany/a.c:5:(.text+0x6): relocation truncated to fit: R_RISCV_HI20 against symbol `hoge' defined in *ABS* section in a.out collect2: error: ld returned 1 exit status
リンカーがエラーを出します。hogeのアドレスを変更し -2GB〜 +2GBの範囲(0xffffffff_80000000や0x00000000_70000000など)にするとリンクが通ります。
もう1つのmedanyは、PC相対でアドレス指定します。具体的にはアドレスの場合はauipc命令とaddi命令、ジャンプの場合はauipc命令とjalr命令の12ビットオフセットを使います。auipc命令とは、20ビットのimmediateを12ビット左シフトして、符号拡張したあとPCに加算する命令のことです。
PCが0x1_40000000付近でhogeが0x1_a89abcd0だとすると、
アドレスの場合 140000006: auipc a5,0x689ac # 12ビットシフトされた値0x689ac000 + PC 0x1_40000006 = 0x1_a89ac006がa5に格納される 14000000a: addi a5,a5,-822 # 0x1_a89ac006 - 822 = 0x1_a89abcd0 = hogeのアドレスがa5に格納される ジャンプの場合 140000008: auipc ra,0x689ac # 12ビットシフトされた値0x689ac000 + PC 0x1_40000008 = 0x1_a89ac008がraに格納される 14000000c: jalr -824(ra) # ra 0x1_a89ac006 - 824 = 0x1_a89abcd0 = hogeのアドレスにジャンプする
このようなコードが生成されます。相対アドレスはPCの現在地 -2GB〜 +2GBまでしか生成できません。medlowモデルより対応できる範囲は広がったものの、いかなるアドレスでも対応できるわけではないです。例えばコード領域とデータ領域をあまりにも遠くすると、
// a.c
extern volatile int *hoge;
void _start(void)
{
*hoge = 1;
}
/* a.ld */
OUTPUT_ARCH("riscv")
ENTRY(_start)
MEMORY
{
TEXT(rx) : ORIGIN = 0x0000000140000000, LENGTH = 0x10000
}
SECTIONS
{
/* hogeをコード領域から2GB以上離して配置する */
PROVIDE(hoge = 0x1c89abcd0);
/* コード領域を0x1_40000000にする */
.text : {
*(.text*);
} > TEXT
}
$ riscv64-zephyr-elf-gcc -march=rv64gc -Wall -g -mabi=lp64d -mcmodel=medany -nostdlib -T a.ld a.c --save-temp a.o: in function `_start': test-medany/a.c:5:(.text+0x6): relocation truncated to fit: R_RISCV_PCREL_HI20 against symbol `hoge' defined in *ABS* section in a.out collect2: error: ld returned 1 exit status
シンボルhogeが位置するアドレスは絶対値 -2GB〜 +2GBの範囲外であり、コード領域からも離れているためPC相対 -2GB〜 +2GBの範囲外でもあります。よってmedlowモデルでもmedanyモデルでもリンクエラーとなります。
何kHzの音まで聞こえるかテストするサイト、聞こえチェック | Panasonic が、以前Twitterでちょっと話題になりました。
私の場合15kHzまでは聞こえますが、それ以上(17kHz, 19kHz)は全く聞こえません。鳴ってんのか?これ??
まずブラウザの影響を排除するため、上記のサイトから音源をダウンロードします。WavではなくMP3ファイルでした。
直接オーディオプレイヤーで聞いても15kHz以外は聞こえません。ブラウザのせいじゃなかった。私の耳は全くあてにならないので、オシロスコープにご登場願います。
19kHz再生時の波形(グラフはキャプチャし忘れて17kHzのまま。右下の周波数表示が19kHzを示している)
いやあ、バッチリ綺麗にSin波が鳴ってます。私は全く聞こえませんね、これが老いかぁ……。
< | 2021 | > | ||||
<< | < | 08 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
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 | - | - | - | - |
合計:
本日: