x86 程序集 - 为什么 [e]bx 保留在调用约定中? [英] x86 Assembly - Why is [e]bx preserved in calling conventions?

查看:15
本文介绍了x86 程序集 - 为什么 [e]bx 保留在调用约定中?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我注意到很多调用约定都坚持为被调用者保留 [e]bx.

现在,我可以理解为什么他们会保留像 [e]sp 或 [e]bp 这样的东西,因为这会弄乱被调用者的堆栈.我也能理解为什么你可能想要保留 [e]si 或 [e]di,因为如果他们不特别小心,这可能会破坏被调用者的字符串指令.

但是[e]bx?[e]bx 到底有什么重要的地方?是什么让 [e]bx 如此特别,以至于多个调用约定坚持在整个函数调用过程中都保留它?

是否会因使用 [e]bx 而产生某种微妙的错误/陷阱?

例如,修改 [e]bx 是否比修改 [e]dx 或 [e]cx 对被调用方有更大的影响?

我只是不明白为什么这么多调用约定将 [e]bx 单独用于保存.

解决方案

并非所有寄存器都适合保留:

no (e)ax -- 在某些指令中隐式使用;返回值no (e)dx -- edx:eax 在 cdq、div、mul 和返回值中隐式使用(e)bx -- 通用寄存器,可用于 16 位寻址模式(基址)(e)cx -- 移位计数,用于循环,rep(e)si -- movs 操作,可用于 16 位寻址模式(索引)(e)di -- movs 操作,可用于 16 位寻址模式(索引)Must (e)bp -- 帧指针,可用于 16 位寻址模式(基址)Must (e)sp -- 堆栈指针,在 8086 中不可寻址(push/pop 除外)

看表,两个寄存器有充分的理由被保留,两个有理由不被保留.累加器 = (e)ax 例如由于编码较短,是最常用的寄存器.SI,DI 制作一个逻辑寄存器对——在 REP MOVS 和其他字符串操作,都被丢弃了.

在半个被调用者/调用者保存范式中,讨论基本上只有在 bx/cx 优于 si/di 时才会进行.在其他调用约定中,只有 EDX、EAX 和 ECX 可以被丢弃.

EBX 确实有一些在现代代码中仍然相关的晦涩隐式用法(例如 CMPXGH8B/CMPXGH16B),但它是 32/64 位代码中最不特殊的寄存器.

EBX 是调用保留寄存器的不错选择,因为函数很少需要保存/恢复 EBX,因为它们特别需要 EBX,而不仅仅是任何非易失性寄存器.正如 Brett Hale 的回答所指出的那样,它使 EBX 成为需要全局偏移表 (GOT) 指针的 ABI 的绝佳选择.

在 16 位模式下,寻址模式仅限于(任何子集)[BP|BX + DI|SI + disp8/disp16]),所以 BX 在那里绝对是特殊的.

I've noticed that a lot of calling conventions insist that [e]bx be preserved for the callee.

Now, I can understand why they'd preserve something like [e]sp or [e]bp, since that can mess up the callee's stack. I can also understand why you might want to preserve [e]si or [e]di since that can break the callee's string instructions if they aren't particularly careful.

But [e]bx? What on earth is so important about [e]bx? What makes [e]bx so special that multiple calling conventions insist that it be preserved throughout function calls?

Is there some sort of subtle bug/gotcha that can arise from messing with [e]bx?

Does modifying [e]bx somehow have a greater impact on the callee than modifying [e]dx or [e]cx for instance?

I just don't understand why so many calling conventions single out [e]bx for preservation.

解决方案

Not all registers make good candidates for preserving:

no (e)ax -- Implicitly used in some instructions; Return value
no (e)dx -- edx:eax is implicity used in cdq, div, mul and in return values

   (e)bx -- generic register, usable in 16-bit addressing modes (base)
   (e)cx -- shift-counts, used in loop, rep

   (e)si -- movs operations, usable in 16-bit addressing modes (index)
   (e)di -- movs operations, usable in 16-bit addressing modes (index)

Must (e)bp -- frame pointer, usable in 16-bit addressing modes (base)
Must (e)sp -- stack pointer, not addressable in 8086 (other than push/pop)

Looking at the table, two registers have good reason to be preserved and two have a reason not to be preserved. accumulator = (e)ax e.g. is the most often used register due to short encoding. SI,DI make a logical register pair -- on REP MOVS and other string operations, both are trashed.

In a half and half callee/caller saving paradigm the discussion would basically go only if bx/cx is preferred over si/di. In other calling conventions, it's just EDX,EAX and ECX that can be trashed.

EBX does have a few obscure implicit uses that are still relevant in modern code (e.g. CMPXGH8B / CMPXGH16B), but it's the least special register in 32/64-bit code.

EBX makes a good choice for a call-preserved register because it's rare that a function will need to save/restore EBX because they need EBX specifically, and not just any non-volatile register. As Brett Hale's answer points out, it makes EBX a great choice for the global offset table (GOT) pointer in ABIs that need one.

In 16-bit mode, addressing modes were limited to (any subset of) [BP|BX + DI|SI + disp8/disp16]), so BX is definitely special there.

这篇关于x86 程序集 - 为什么 [e]bx 保留在调用约定中?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆