-
Notifications
You must be signed in to change notification settings - Fork 56
Add the LoongArch instruction format conventions doc. #56
base: main
Are you sure you want to change the base?
Conversation
7ac9664
to
b07e09d
Compare
这个看起来比较实用。 |
b858a6d
to
c2ed92d
Compare
Done |
Ping |
|
||
3. 涉及对 csrrd/csrwr 指令编码与 csrxchg 重叠这一事实的不同认知。 | ||
+ | ||
本约定将 csrrd/csrwr 视作 csrxchg 行为上的特例,从而 csrrd/csrwr 在汇编上应被视作 csrxchg 的语法糖,因而实际只存在 csrxchg 一条指令,程序不需要在机器语言层面考虑编码重叠的情况(而是在语义分析的层面考虑);而手册认为它们是三条不同的指令。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
csrwr
为啥是 csrxchg
的语法糖呢?
按照手册说法:
csrxchg rd, rj, csr
,将rd
中对应rj
掩码的位写入csr
,并将旧值读出到rd
;csrwr rd, csr
,将rd
值写入csr
,并将旧值读出到rd
。
再根据指令编码表,csrxchg
与csrwr
的区别在于rj
是否为1,但$r1
是ra寄存器吧,并不是全1的?所以这两个并不等价?
或者用另一句话说,如果实现csrwr
,使用csrxchg
的话需要弄一个全1的寄存器;另外识别现有的csrwr
,会有错误的认知(认为使用$ra
作为mask
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我的意思是,如果不考虑/允许操作码存在重叠,那么应该只存在 csrxchg
一条指令,它会根据 rj
取值不同出现三种行为,其中有两个特例:
rj == 0
-- 只读rj == 1
-- 只写- else -- 原子交换
由于向 rj
槽填入 0 或者 1 的取值,不会取得 csrxchg
的效果,因此下游(汇编器等)可以对此报错,也是目前的现状。相比之下,允许操作码重叠会给所有需要反汇编 LA 机器语言的地方带来额外复杂度,只是下游看到 csrxchg
指令时候可以少处理这两种特例而已,总复杂度其实没变。
总之此处的特殊处理是客观存在、无法避免的复杂度,问题在于将复杂度放在哪。我做的权衡是倾向于维持“所有指令的操作码不存在重叠”这个个人认为较客观的价值,龙芯则选择了“所有指令助记符只做一件事”这个较主观的价值,为了仅有的这三条指令而牺牲了很方便利用的一个编码空间性质。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
至于同样编码的“寄存器”表示不同语义,其实也已经有先例了,例如 AArch64 的 xzr 寄存器有时表示 zero,有时表示 sp,视具体指令而定,这样他们就省出了一个寄存器不用像 MIPS/Alpha/RV/LA 这些架构一样总是保留一个真正的 zero。判断、记忆的标准是“哪些指令在正常用法里访问 zero 没道理,他们的 xzr 就是 sp;反之,哪些指令正常就不会访问 sp,那他们的 xzr 就是 zero”。
我觉得这个逻辑在此处也可以讲通:zero 和 ra 意义特殊,而 csrxchg 作为读写 CSR 这种特殊资源的寄存器,寻址 zero 和 ra 没什么道理,正常人不会这么写。因此人为规定 rj = zero/ra 的情况不做 xchg 以节省编码空间。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
zero
其实是非常合理的,主要问题可能还是集中于ra
上。对于出现的ra
的情况,是不是在文档里面需要注明一下,以免引起不必要的误会?:)
是不是没有加入 另外是不是添加
这两个会更好一些?毕竟感觉有不少人问 |
伪指令下一篇《汇编语法约定》讲,本篇只讲具体指令 |
那 |
nop 是语法糖,真正具体指令还是 andi,所以当然本文不会有 nop 龙芯不是一家成熟有积淀的技术公司,它的手册不能被认为是绝对正确,叙述天衣无缝的 |
个人想法:虽然 nop 是语法糖,但相比其他的伪指令来说更加重要(无论是x86还是riscv都单独列出),对于处理器内部也有可能会有针对性优化。个人感觉单独列出更好?当然不列入也很合理。 可以询问一下大家的想法?:) |
嘶,这么组织语言容易搞得没员工敢 ACK,人要吃饭的嘛 :) 我来换个说法:“根据一家非常成熟且有几十年积淀的友商的先进经验,更新手册是个很正常的事情”
nop 好像 ISA 手册里面有罢。move 这个东西我强烈要求加,因为我之前看到过 4 种不同的 move 写法 :(。 |
Add clarification that manual assembly syntax is not affected by this doc. Explain why FCSR operands is treated as immediates in this doc. Many wording tweaks. Explain the justification behind unification of csrrd/csrwr/csrxchg. Explain some popular pseudo-instructions.
No description provided.