riscV 32Bit/64Bit

まて、32Bit/64Bitって、どんな違いが有るの？

A: RISC-V（リスクファイブ）の勉強、いいですね！ 「riscv32」と「riscv64」の違いは、主に**アーキテクチャのビット幅**とそれに関連する**命令セットやレジスタ、アドレッシング能力**にあります。以下にポイントを整理します。

—

### ✅ 1. ビット幅（ISAの基本幅）

特徴	riscv32	riscv64
----------	----------	----------------------
レジスタ幅	32ビット	64ビット
アドレス空間	最大4GB（2³²）	非常に大きい（理論上 16EB = 2⁶⁴）
整数演算	32ビット	64ビット（+ 32ビットも可能）

—

### ✅ 2. 命令セットの違い（拡張含む）

RISC-Vにはベースの命令セットと、必要に応じて加える拡張命令セットがあります。

• rv32: RV32I, RV32IM, RV32IMF, など（I = Integer, M = Multiply, F = Float）
• rv64: RV64I, RV64IM, RV64IMAFD など

#### 例：

• `add`（整数加算）はどちらにもあります。
• `ld`（64ビットロード）は rv64 のみ。
• `lw`（32ビットロード）はどちらにもあるが、rv64では符号拡張して64ビットレジスタに格納される。

—

### ✅ 3. ABI（Application Binary Interface）の違い

項目	riscv32	riscv64
---------------	---------------------------	---------------------------------
ABI名	`ilp32`, `ilp32f`, `ilp32d`	`lp64`, `lp64f`, `lp64d`
データ型サイズ	int/long/pointer = 32bit	long/pointer = 64bit, int = 32bit
関数呼び出し規約、構造体の配置	異なる	異なる

—

### ✅ 4. 実用面での違い

項目	riscv32	riscv64
-------------	-----------	------------------------
用途	組み込み機器、マイコン	サーバ、デスクトップ、汎用OS
Linuxカーネルサポート	あり（制限あり）	フルサポート（Debian, Fedoraなど）
性能・メモリ対応	小規模向け	大規模対応可能

—

### ✅ 5. 実機・エミュレータでの違い（QEMUなど）

• QEMUでは `riscv32` と `riscv64` それぞれの仮想マシンを起動可能です。
  • `qemu-system-riscv32`
  • `qemu-system-riscv64`

それぞれ別のLinuxディストリビューション用イメージやクロスコンパイラを使う必要があります。

—

### ✅ まとめ

比較項目	riscv32	riscv64
------------	---------	---------------
アドレス可能なメモリ空間	小さい（～4GB）	大きい（64bit空間）
レジスタのビット幅	32bit	64bit
対象アプリケーション	組み込み、IoT	汎用計算、Linux上のアプリ
ABI・命令セット	rv32系	rv64系

—

32/64で命令に違いがあるとな。そして、同じビットのマシンでも、乗算とか 浮動小数点機構はオプション扱いになってるとな。

100 lines OSでは、ファームに opensbi-riscv32-generic-fw_dynamic.bin なんてのを利用するんでDLしとけって 指示されてる。これって、昔言葉で言う、BIOSの事なのかな。DL元はqemuのサイトだ。 オイラーはqemuならgitから一式DLしてるぞ。

qemu/pc-bios/README

- OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
  reference implementation of the RISC-V Supervisor Binary Interface (SBI)
  specifications for platform-specific firmwares executing in M-mode. For all
  supported platforms, OpenSBI provides several runtime firmware examples.
  These example firmwares can be used to replace the legacy riscv-pk bootloader
  and enable the use of well-known bootloaders such as U-Boot.
  OpenSBI is distributed under the terms of the BSD 2-clause license
  ("Simplified BSD License" or "FreeBSD License", SPDX: BSD-2-Clause). OpenSBI
  source code also contains code reused from other projects described here:
  https://github.com/riscv/opensbi/blob/master/ThirdPartyNotices.md.

ファームは唯のデータだと言うので、人様がそれらしく読めるのを抽出する。

sakae@lu:pc-bios$ strings opensbi-riscv32-generic-fw_dynamic.bin
 :
v1.5.1
OpenSBI %s
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|
  :
Platform Name             : %s
Platform Features         : %s
Platform HART Count       : %u
Platform IPI Device       : %s
Platform Timer Device     : %s @ %luHz

1000 lines OS の最初の一歩の結果。

OpenSBI v1.2
  :
Platform Name             : riscv-virtio,qemu
Platform Features         : medeleg
Platform HART Count       : 1
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 10000000Hz

手持ちのファームの方が新らしいな。

見様見真似でコードを作成したけど、下記の様に致命的なエラーになった。 dummyを宣言してるのは、bssエリアが存在する様にするため。

sakae@lu:my$ sh run.sh
+ QEMU=qemu-system-riscv64
+ CC=riscv64-unknown-elf-gcc
+ CFLAGS=-Wall -Wextra -fno-stack-protector -ffreestanding -nostdlib
+ riscv64-unknown-elf-gcc -Wall -Wextra -fno-stack-protector -ffreestanding -nostdlib -Wl,-Tkernel.ld -Wl,-Map=kernel.map -o kernel.elf kernel.c
kernel.c:8:12: warning: 'dummy' defined but not used [-Wunused-variable]
    8 | static int dummy[100];     // dummy for bss
      |            ^~~~~
/usr/lib/gcc/riscv64-unknown-elf/13.2.0/../../../riscv64-unknown-elf/bin/ld: warning: kernel.elf has a LOAD segment with RWX permissions
/tmp/ccMaxAWy.o: in function `kernel_main':
kernel.c:(.text+0x58): relocation truncated to fit: R_RISCV_HI20 against symbol `__bss_end' defined in .bss section in kernel.elf
collect2: error: ld returned 1 exit status

とうとう、あの人に相談。

A: RISC-V はアドレスを24ビット即値（HI20 + LO12）で組み立てます。問題は、GCCがアドレス演算をするたびにそれを命令列でエミュレートするため、範囲外だとリンクエラーになるということです。 __bss_end のような アドレス定数を直接使用した演算を C 側で行うと、GCC はそのアドレスに対し HI20/LO12 などのリロケーションを生成します。 ところが、リンク時点で .bss が .text から遠い場合（たとえば約 0x200 バイト以上離れている場合）、HI20 に収まる範囲を超えるとエラーになります。これはRISC-V 固有の制限です（即値オフセット範囲: ±1MiB）。 それを解消するには、C言語内での演算を止めてアセンブラにするしかないです。

sakae@lu:my$ cat bss.S
.section .text
.global zero_bss
zero_bss:
    la t0, __bss
    la t1, __bss_end
1:
    beq t0, t1, 2f
    sb zero, 0(t0)
    addi t0, t0, 1
    j 1b
2:
    ret

.section .rodata
zero:
        .byte 0

sakae@lu:my$ cat kernel.c
#include <stdint.h>
#include <stddef.h>

void zero_bss(void);

extern uint8_t __bss[];
extern uint8_t __bss_end[];
extern uint8_t __stack_top[];

//static int dummy[100];     // dummy for bss

/* void *memset(void *s, int c, size_t n) { */
/*     uint8_t *p = s; */
/*     while (n--) { */
/*         *p++ = (uint8_t)c; */
/*     } */
/*     return s; */
/* } */

void kernel_main(void) {
  //    memset(__bss, 0, (uintptr_t)__bss_end - (uintptr_t)__bss);
  zero_bss();
    while (1) { }
}

__attribute__((section(".text.boot")))
void _start(void) {
    asm volatile ("la sp, __stack_top");
    kernel_main();
    while (1) { asm volatile ("wfi"); }
}

sakae@lu:my$ cat kernel.ld
ENTRY(_start)

SECTIONS
{
  /* OpenSBIがfw_dynamicとして使用される場合、payloadは0x80200000から開始 */
  . = 0x80200000;
  .text.boot : {    *(.text.boot)   }
  .text : {    *(.text*)  }
  .rodata : {    *(.rodata*)  }
  .data : {    *(.data*)  }
  .bss : {
    __bss = .;
    *(.bss*)
    *(COMMON)
    __bss_end = .;
  }
  . = ALIGN(16);
  __stack_top = .;
}

sakae@lu:my$ cat run.sh
#!/bin/bash
set -xue

QEMU=qemu-system-riscv64
CC=riscv64-unknown-elf-gcc

riscv64-unknown-elf-as bss.S -o bss.o

CFLAGS="-Wall -Wextra -fno-stack-protector -ffreestanding -nostdlib"

$CC $CFLAGS -Wl,-Tkernel.ld -Wl,-Map=kernel.map -o kernel.elf \
    kernel.c bss.o

$QEMU -machine virt -bios default -nographic -serial mon:stdio --no-reboot \
      -kernel kernel.elf

sakae@lu:my$ sh run.sh

OpenSBI v1.5.1

Platform Name             : riscv-virtio,qemu
Platform Features         : medeleg
Platform HART Count       : 1
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 10000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform PMU Device       : ---
Platform Reboot Device    : sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base             : 0x80000000
Firmware Size             : 212 KB
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 0
Domain0 HARTs             : 0*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
Domain0 Region01          : 0x0000000080000000-0x000000008003ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000080200000
Domain0 Next Arg1         : 0x0000000087e00000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 0
Boot HART Domain          : root
Boot HART Priv Version    : v1.12
Boot HART Base ISA        : rv64imafdch
Boot HART ISA Extensions  : time,sstc
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count      : 16
Boot HART MIDELEG         : 0x0000000000001666
Boot HART MEDELEG         : 0x0000000000f0b509

32Bitの時は、Boot HART PMP Address Bits: 32 になってた。

あたり前だけど、オリジナルのmemsetで動いた。

(gdb) bt
#0  memset (s=0x80200094 <dummy>, c=0, n=400) at kernel.c:13
#1  0x80200090 in kernel_main () at kernel.c:21
#2  0x80200012 in _start () at kernel.c:29
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disassemble
Dump of assembler code for function memset:
   0x80200018 <+0>:     addi    sp,sp,-48
   0x8020001a <+2>:     sw      s0,44(sp)
   0x8020001c <+4>:     addi    s0,sp,48
   0x8020001e <+6>:     sw      a0,-36(s0)
   0x80200022 <+10>:    sw      a1,-40(s0)
   0x80200026 <+14>:    sw      a2,-44(s0)
=> 0x8020002a <+18>:    lw      a5,-36(s0)
   0x8020002e <+22>:    sw      a5,-20(s0)
   0x80200032 <+26>:    j       0x8020004c <memset+52>
   0x80200034 <+28>:    lw      a5,-20(s0)
   0x80200038 <+32>:    addi    a4,a5,1
   0x8020003c <+36>:    sw      a4,-20(s0)
   0x80200040 <+40>:    lw      a4,-40(s0)
   0x80200044 <+44>:    andi    a4,a4,255
   0x80200048 <+48>:    sb      a4,0(a5)
   0x8020004c <+52>:    lw      a5,-44(s0)
   0x80200050 <+56>:    addi    a4,a5,-1
   0x80200054 <+60>:    sw      a4,-44(s0)
   0x80200058 <+64>:    bnez    a5,0x80200034 <memset+28>
   0x8020005a <+66>:    lw      a5,-36(s0)
   0x8020005e <+70>:    mv      a0,a5
   0x80200060 <+72>:    lw      s0,44(sp)
   0x80200062 <+74>:    addi    sp,sp,48
   0x80200064 <+76>:    ret

C語だと、効率悪いな。

ob$ riscv32-esp-elf-nm kernel.elf
80200094 B __bss
80200224 B __bss_end
80200230 B __stack_top
80200000 T _start
80200094 b dummy
80200066 T kernel_main
80200018 T memset

リンカーが出力するmapより、こちらの方が慣れているせいか見易いな。

OpenBSD amd64なマシンにもriscv32の環境を作ってみた。試運転です。

0x80200024 in zero_bss ()
(gdb) disassemble
Dump of assembler code for function zero_bss:
=> 0x80200024 <+0>:     auipc   t0,0x0
   0x80200028 <+4>:     addi    t0,t0,31 # 0x80200043
   0x8020002c <+8>:     auipc   t1,0x0
   0x80200030 <+12>:    addi    t1,t1,23 # 0x80200043
   0x80200034 <+16>:    beq     t0,t1,0x80200040 <zero_bss+28>
   0x80200038 <+20>:    sb      zero,0(t0)
   0x8020003c <+24>:    addi    t0,t0,1
   0x8020003e <+26>:    j       0x80200034 <zero_bss+16>
   0x80200040 <+28>:    ret
(gdb) si
0x80200028 in zero_bss ()
(gdb) si
0x8020002c in zero_bss ()
(gdb) display/i $pc
1: x/i $pc
=> 0x8020002c <zero_bss+8>:     auipc   t1,0x0
(gdb) si
0x80200030 in zero_bss ()
1: x/i $pc
=> 0x80200030 <zero_bss+12>:    addi    t1,t1,23

ステップ実行はPC(program counter)を指定してどうぞ。何かPDP-11 みたいで 懐かしい。インテルさんは、IPと言うんだっけな。馴染めない名前だ。