コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2023年7月20日 >>> 2023年7月20日
link もっと後

2023年7月20日

RISC-Vも完璧じゃない

目次: RISC-V

RISC-Vは最後発の命令セットだけあって、従来の命令セットで評判の悪かった部分は改善されている場合が多いです。しかし人の作るものですからミスや見落としはあります。

例としてわかりやすいのがRV64I命令セットの32bit unsignedと64bit unsigned加算処理です。下記のようなコードを書いたとします。

32bit unsignedと64bit unsigned加算処理のサンプルコード

unsigned int __attribute__((noinline)) something(int n)
{
	return n * n;
}

int test(unsigned int num)
{
	unsigned long long sum = 0;

	for (int i = 0; i < num; i++) {
		sum += something(i);    //32bit unsigned + 64bit unsigned
	}

	return sum;
}

下記のようにコンパイルします。RV64GCはRV64IMAFDCの略(M: Multiplication and Division, A: Atomic, F: Single-Precision Floating-Point, D: Double-Precision Floating-Point, C: Compressed)です。RV64I以外のMAFDCの各命令も出てきますが、話題と関係ないので気にしないでください。RV64GCが基本的な命令セットくらいの認識でOKです。

RV64GCでコンパイル
$ riscv64-unknown-elf-gcc -g -O2 -march=rv64gc -mabi=lp64d -c -o rv64gc.o a.c

逆アセンブルを見ると変なシフト命令(アドレス24, 26)が2つ出力されます。

RV64GCを使用したときの逆アセンブル

000000000000001a <.L5>:
                sum += something(i);
  1a:   8522                    mv      a0,s0         # s0: i, s1: sum
  1c:   00000097                auipc   ra,0x0
  20:   000080e7                jalr    ra            # call something()
  24:   1502                    slli    a0,a0,0x20    # a0: something() の返り値
  26:   9101                    srli    a0,a0,0x20    # shift x 2で上位32ビットを0埋め
        for (int i = 0; i < num; i++) {
  28:   2405                    addiw   s0,s0,1
                sum += something(i);
  2a:   94aa                    add     s1,s1,a0      # shift x 2 + add
        for (int i = 0; i < num; i++) {
  2c:   ff2417e3                bne     s0,s2,1a <.L5>

RV64Iには32bit unsigned向けの加算命令がなく、32bit unsignedを64bit unsignedにゼロ拡張してから加算する必要があるためです。さらに悲しいことにゼロ拡張する命令もなく、32bit左シフト命令+32bit右論理シフト命令でゼロ拡張するヘボい処理になります。

SiFiveあなたもか

シフト命令2つくらい何だというのか?ケチケチするなよ?という感覚が普通かもしれませんが、余計な命令が出ると特にローエンドのCPUでは性能への影響が無視できません。どうやらCoreMarkのような典型的なベンチマークにも影響が出ていたようで、

SiFiveが公開しているCoreMarkの型定義(一部抜粋)

// GitHub: sifive/benchmark-coremark
// freedom-metal/core_portme.h

typedef signed short ee_s16;
typedef unsigned short ee_u16;
typedef signed int ee_s32;
typedef double ee_f32;
typedef unsigned char ee_u8;
typedef signed int ee_u32;     //★★★u32なのに "signed" intになっている★★★
typedef signed long ee_u64;    //★★★u64なのに "signed" longになっている★★★
#if __riscv_xlen == 32
typedef ee_u32 ee_ptr_int;
#else
typedef ee_u64 ee_ptr_int;
#endif
typedef signed int ee_size_t;

RISC-Vの盟主たるSiFiveすらも「unsigned型をsigned型にすりかえて性能を上げるぞい!」というCoreMarkハックを行っていた(該当箇所へのリンク)ほどです……。

RISC-Vパッチワーク

当然RV64Iのまずい点はRISC-Vの方々も気づいており、B拡張(Bit-manipulation extensions)を追加したときに上記の問題は修正されました(RISC-V Bitmanipulation extension規格書へのリンク)。

B拡張はZba, Zbb, Zbc, Zbsの4つがあります。

  • Zba: Address generation instructions
  • Zbb: Basic bit-manipulation
  • Zbc: Carry-less multiplication
  • Zbs: Single-bit instructions

この中のZba拡張にて32bit unsigned加算命令であるadd.uw命令が追加されました。他にも1, 2, 3bitシフト&加算命令なんかも追加されています。unsigned加算や1, 2, 3bitシフト&加算は配列の要素のアドレスを計算する際に頻出で、Address generation instructionsというグループ名にしたのでしょう。

Zba拡張を使うとどのように改善されるか確認します。

RV64GCとZba拡張でコンパイル
$ riscv64-unknown-elf-gcc -g -O2 -march=rv64gc_zba -mabi=lp64d -c -o rv64gcb.o a.c

逆アセンブルを見ると変なシフト命令は消滅し、新たにadd.uw命令が出力されていることが分かると思います。

RV64GCとZba拡張を使用したときの逆アセンブル結果

000000000000001a <.L5>:
                sum += something(i);
  1a:   8522                    mv      a0,s0       # s0: i, s1: sum
  1c:   00000097                auipc   ra,0x0
  20:   000080e7                jalr    ra          # call something()
        for (int i = 0; i < num; i++) {
  24:   2405                    addiw   s0,s0,1
                sum += something(i);
  26:   089504bb                add.uw  s1,a0,s1    # shift x 2は消滅、add.uwのみ
        for (int i = 0; i < num; i++) {
  2a:   ff2418e3                bne     s0,s2,1a <.L5>

めでたしめでたし。なんですけど、人によっては色々言いたいこともあると思います。Bit-manipulationとAddress generation全然関係ないぞ?とかね。

しかし冒頭にも書いたとおり、何事も最初から完璧なものはないです。命令セットが汚くなっていくのはRISC-Vが実用段階に入った証であり、むしろ良いことだと個人的には思います。

編集者:すずき(2023/07/23 17:11)

コメント一覧

  • hdkさん(2023/07/21 22:45)
    x86脳なので、mov %eax,%eax (32ビット→ゼロ拡張64ビット) とか、movzwl %ax,%eax (16ビット→ゼロ拡張32ビット) とか、そういうのに相当する何かがありそうに思ってしまいますが、わざわざシフト命令2個生成されるところをみると、ないんですね... intとintptr_tのサイズが同じならよかったんでしょうけど、違うと確かに厳しそう...
  • すずきさん(2023/07/23 17:10)
    x86はもちろん、先代であるMIPSにさえこの手のミスはないらしい(詳しくは知らない)んですが、RISC-Vは命令削減にこだわり過ぎたのか、見落としたのかなんだか知らんのですが、ミスってるんですよねー……。
open/close この記事にコメントする



link もっと前
2023年7月20日 >>> 2023年7月20日
link もっと後

管理用メニュー

link 記事を新規作成

<2023>
<<<07>>>
------1
2345678
9101112131415
16171819202122
23242526272829
3031-----

最近のコメント5件

  • link 24年5月17日
    すずきさん (05/20 13:16)
    「そうですねえ、普通はStandardなの...」
  • link 24年5月17日
    hdkさん (05/19 07:45)
    「なるほど、そういうことなんですね。Exc...」
  • link 24年5月17日
    すずきさん (05/19 03:41)
    「Standardだと下記の設定になってい...」
  • link 24年5月17日
    hdkさん (05/18 22:16)
    「ドメインを変えたせいで別サイト扱いになっ...」
  • link 24年4月22日
    hdkさん (04/24 08:36)
    「うちのHHFZ4310は15年突破しまし...」

最近の記事3件

  • link 24年5月17日
    すずき (05/18 20:34)
    「[TwitterがXに置換された] 今日?あたりからtwitter.comにアクセスするとx.comにリダイレクトされるように...」
  • link 24年5月10日
    すずき (05/18 03:18)
    「[SDIの一覧] 聞かれてぱっと思い出せなかったのでSDI(Serial Digital Interface)の規格一覧をメモ...」
  • link 23年6月1日
    すずき (05/18 03:03)
    「[自宅サーバー - まとめリンク] 目次: 自宅サーバーこの日記システム、Wikiの話。カウンターをPerlからPHPに移植日...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 05/20 13:16