On 8/11/23 03:02, Song Gao wrote:
The la32 manual from [1], and it is not the final version.
[1]:
https://www.loongson.cn/uploads/images/2023041918122813624.%E9%BE%99%E8%8A%AF%E6%9E%B6%E6%9E%8432%E4%BD%8D%E7%B2%BE%E7%AE%80%E7%89%88%E5%8F%82%E8%80%83%E6%89%8B%E5%86%8C_r1p03.pdf
I really hope this manual will be changed before final.
-TRANS(pcaddi, ALL, gen_pc, gen_pcaddi)
-TRANS(pcalau12i, ALL, gen_pc, gen_pcalau12i)
+TRANS(pcaddi, 64, gen_pc, gen_pcaddi)
+TRANS(pcalau12i, 64, gen_pc, gen_pcalau12i)
TRANS(pcaddu12i, ALL, gen_pc, gen_pcaddu12i)
-TRANS(pcaddu18i, ALL, gen_pc, gen_pcaddu18i)
+TRANS(pcaddu18i, 64, gen_pc, gen_pcaddu18i)
For the compiler, PCALAU12I is much more useful than PCADDU12I.
Because PCALAU12I produces zeros in the lower 12 bits, the high-part pc-relative
relocation does not need to be paired with a corresponding low-part pc-relative relocation.
Whereas PCADDU12I produces a full 32-bit result, and the low-part pc-relative relocation
needs to know where the high-part was produced in order to compensate. This fundamental
error was made by the RISC-V ISA, and their toolchain is still paying the price.
@@ -69,6 +77,10 @@ static bool trans_cpucfg(DisasContext *ctx, arg_cpucfg *a)
TCGv dest = gpr_dst(ctx, a->rd, EXT_NONE);
TCGv src1 = gpr_src(ctx, a->rj, EXT_NONE);
+ if (!avail_64(ctx)) {
+ return false;
+ }
For the operating system running on LA32, lack of CPUCFG means that you now have to
provide the cpu configuration in another way:
(1) Via compilation options, such that one operating system build will only run on a
single cpu.
(2) Via external data, like device tree.
Either option complicates the usage of LA32.
I would hope that a few words of rom for CPUCFG to read is not too expensive to
incorporate in even the smallest cpu implementation.
r~
