[windows] Windows64가 x86-64의 다른 모든 OS와 다른 호출 규칙을 사용하는 이유는 무엇입니까?

Windows가 그들이 한 일을 한 이유 IDK. 추측에 대해서는이 답변의 끝을 참조하십시오. SysV 호출 규칙이 어떻게 결정되었는지 궁금 해서 메일 링리스트 아카이브를 파헤쳐 서 깔끔한 것을 찾았습니다.

AMD 아키텍트가 활발하게 활동하고 있었기 때문에 AMD64 메일 링리스트에서 오래된 쓰레드 중 일부를 읽는 것은 흥미 롭습니다. 예를 들어 레지스터 이름을 선택하는 것은 어려운 부분 중 하나였습니다. AMD 는 원래 8 레지스터 r0-r7의 이름을 바꾸거나UAX .

또한, 커널의 피드백은 원래의 설계했다 확인 된 것들 DEVS syscall및 swapgs사용할 수를 . 이것이 AMD가 실제 칩을 출시하기 전에 이것을 분류하기 위해 지침 을 업데이트 한 방법 입니다. 2000 년 후반 인텔이 AMD64를 채택하지 않을 것이라는 가정도 흥미 롭습니다.

SysV (Linux) 호출 규칙과 호출자 보존 대 호출자 저장에 대한 레지스터 수에 대한 결정은 2000 년 11 월 Jan Hubicka (gcc 개발자)에 의해 처음에 이루어졌습니다 . 그는 SPEC2000을 컴파일 하고 코드 크기와 명령어 수를 조사했습니다. 그 토론 스레드는이 SO 질문에 대한 답변 및 의견과 동일한 아이디어 중 일부를 중심으로 튀어 나옵니다. 두 번째 스레드에서 그는 현재 시퀀스를 최적이며 최종적으로 제안하여 일부 대안보다 작은 코드를 생성 합니다.

그는 “글로벌”이라는 용어를 사용하여 푸시 / 팝해야하는 호출 보존 레지스터를 의미합니다.

의 선택 rdi, rsi, rdx처음 세 인수에 의해 동기가되었을 때 :

• memset인수에 대한 다른 C 문자열 함수를 호출하는 함수에서 코드 크기를 약간 절약 합니다 (여기서 gcc는 rep 문자열 작업을 인라인합니까?).
• rbxREX 접두사 (rbx 및 rbp)없이 액세스 할 수있는 두 개의 호출 보존 된 reg를 갖는 것이 승리이기 때문에 호출 보존됩니다. 어떤 명령에서도 암시 적으로 사용되지 않는 유일한 다른 reg이기 때문에 아마도 선택되었을 것입니다. (rep string, shift count, mul / div outputs / inputs touch all other all).
• 특별한 목적을 가진 레지스터는 호출 보존되지 않으므로 (이전 포인트 참조) rep 문자열 명령어 나 가변 카운트 시프트를 사용하려는 함수는 함수 인수를 다른 곳으로 이동해야 할 수 있지만 저장할 필요는 없습니다. 발신자의 가치를 회복하십시오.

• RCX는 EAX와 같은 특수한 목적으로 일반적으로 사용되는 레지스터이므로 시퀀스에서 누락되는 동일한 목적을 가지고 있으므로 시퀀스 초기에 RCX를 피하려고합니다. 또한 syscall에 사용할 수 없으며 가능한 한 함수 호출 시퀀스와 일치하도록 syscall 시퀀스를 만들고 싶습니다.

  (배경 : syscall/ sysret불가피하게 rcx(with rip) 및 r11(with RFLAGS) 파괴 하므로 커널이 실행 rcx되었을 때 원래 있던 내용을 볼 수 없습니다 syscall.)

커널 시스템 호출 ABI는 r10대신을 제외하고 함수 호출 ABI와 일치하도록 선택 rcx되었으므로 libc 래퍼 mmap(2)는 mov %rcx, %r10/ mov $0x9, %eax/ 와 같은 기능을 수행 할 수 있습니다 syscall.

i386 Linux에서 사용하는 SysV 호출 규칙은 Window의 32 비트 __vectorcall에 비해 짜증이납니다. 스택의 모든 것을 전달 edx:eax하고 작은 구조체가 아닌 int64에 대해서만 반환 합니다 . 그것과의 호환성을 유지하기 위해 약간의 노력을 기울인 것은 놀라운 일이 아닙니다. 그렇게하지 않을 이유가 없을 때, 그들은 rbx원래 8 (REX 접두사가 필요하지 않음)에 다른 것을 갖는 것이 좋다고 결정했기 때문에 통화 보존을 유지하는 것과 같은 일 을했습니다.

ABI를 최적으로 만드는 것은 다른 고려 사항보다 장기적으로 훨씬 더 중요합니다. 나는 그들이 꽤 잘했다고 생각합니다. 다른 regs의 다른 필드 대신 레지스터에 압축 된 구조체를 반환하는 것에 대해 완전히 확신하지 못합니다. 필드에서 실제로 작동하지 않고 값별로 전달하는 코드가이 방법으로이기는 것 같지만, 압축을 푸는 추가 작업은 어리석은 것 같습니다. 그것들은 단지보다 더 많은 정수 리턴 레지스터를 가질 수 있었으므로, rdx:rax4 개의 멤버가있는 구조체를 리턴하면 rdi, rsi, rdx, rax 등으로 리턴 될 수 있습니다.

SSE2는 정수에서 작동 할 수 있기 때문에 벡터 regs에서 정수 전달을 고려했습니다. 다행히 그들은 그렇게하지 않았습니다. 정수는 포인터 오프셋으로 자주 사용되며 스택 메모리로의 왕복 비용은 매우 저렴 합니다. 또한 SSE2 명령어는 정수 명령어보다 더 많은 코드 바이트를 사용합니다.

나는 Windows ABI 디자이너가 asm을 한 곳에서 다른 곳으로 포팅해야하는 사람들의 이익을 위해 32 비트와 64 비트 사이의 차이를 최소화하는 것을 목표로했을 수도 #ifdef있고, 같은 소스를 더 쉽게 구축 할 수 있도록 일부 ASM에서 몇 s를 사용할 수 있다고 생각합니다. 32 비트 또는 64 비트 버전의 함수.

툴체인의 변경을 최소화하는 것은 불가능 해 보입니다. x86-64 컴파일러에는 레지스터가 무엇에 사용되며 호출 규칙이 무엇인지에 대한 별도의 테이블이 필요합니다. 32 비트와 약간 겹치는 부분은 도구 체인 코드 크기 / 복잡성을 크게 절감 할 수 없습니다.

답변