我与一位专家合作,据称他的编码技能比我自己高得多,而我比我对行内汇编的理解要好得多。
其中一项主张是,只要操作数作为输入约束出现,就不需要将其列出为破坏者,也不必指定该寄存器已被内联汇编程序潜在地修改了。 谈话是在其他人试图通过这种有效编码的memset实现获得帮助时发生的:
void *memset(void *dest, int value, size_t count)
{
asm volatile ("cld; rep stosb" :: "D"(dest), "c"(count), "a"(value));
return dest;
}
当我在不告知编译器的情况下评论破坏寄存器的问题时,专家的主张是告诉我们:
“ c”(计数)已经告诉编译器c崩溃了
我在专家自己的操作系统中找到了一个示例,在该示例中,他们以相同的设计模式编写了相似的代码。 他们将Intel语法用于其内联汇编。 该业余操作系统代码在内核(ring0)上下文中运行。 一个示例是此缓冲区交换函数1 :
void swap_vbufs(void) {
asm volatile (
"1: "
"lodsd;"
"cmp eax, dword ptr ds:[rbx];"
"jne 2f;"
"add rdi, 4;"
"jmp 3f;"
"2: "
"stosd;"
"3: "
"add rbx, 4;"
"dec rcx;"
"jnz 1b;"
:
: "S" (antibuffer0),
"D" (framebuffer),
"b" (antibuffer1),
"c" ((vbe_pitch / sizeof(uint32_t)) * vbe_height)
: "rax"
);
return;
}
antibuffer0 , antibuffer1和framebuffer都是内存中的缓冲区,被视为uint32_t数组。 framebuffer是实际的视频内存(MMIO), antibuffer0和antibuffer1是在内存中分配的缓冲区。
在调用此函数之前,已正确设置了全局变量。 它们声明为:
volatile uint32_t *framebuffer;
volatile uint32_t *antibuffer0;
volatile uint32_t *antibuffer1;
int vbe_width = 1024;
int vbe_height = 768;
int vbe_pitch;
我对此类代码的问题和疑虑
作为对内联汇编的一个明显的新手,对这个主题有一个明显的天真理解,我想知道我的明显未受过教育的信念,该代码可能是非常多虫的,是否正确。 我想知道这些担忧是否有好处:
RDI , RSI , RBX和RCX均被此代码修改。 RDI和RSI隐式增加LODSD和STOSD 。 其余的都用显式修改"add rbx, 4;" "dec rcx;"
这些寄存器均未列为输入/输出,也未列为输出操作数。 我认为需要修改这些约束条件,以告知编译器这些寄存器可能已被修改/填充。 我认为正确的唯一被列为“破坏性”的寄存器是RAX 。 我的理解正确吗? 我的感觉是RDI , RSI , RBX和RCX应该是输入/输出约束(使用+修饰符)。 即使有人试图争辩说64位System V ABI调用约定将保存它们(假定IMHO编写这种代码的方式很差), RBX是一种非易失性寄存器,它将在此代码中更改。
由于地址是通过寄存器传递的(而不是通过内存限制的),因此我相信这是一个潜在的错误,即编译器没有被告知和/或修改了这些指针所指向的内存。 我的理解正确吗?
RBX和RCX是硬编码的寄存器。 允许编译器通过约束条件自动选择这些寄存器是否有意义?
如果有人假设必须在这里使用内联汇编(假设),此功能的无错误GCC内联汇编代码会是什么样? 此功能是否还不错,而且我不像专家那样不了解GCC扩展内联汇编的基础知识?
脚注
1 swap_vbufs函数和关联的变量声明未经版权持有者的许可而逐字复制,出于对更大的作品进行评论的目的,在合理使用下。