인텔 및 AMD 프로세서가 원래 단어 길이 (요즘 주로 64 비트)로 명령어를 가져 오는 것을 알고, 필자는 그것에 대해 제 동생에게 물었고 더 효율적으로 프로세서를 실행하기 위해 일부 조립 프로그래머 패드 nop의 32 비트 감독의 지시 이상 4 또는 8 바이트의 바이트 길이를 넣어 다음 명령 경우 :패딩 명령어에 실제적인 이점이 있습니까?
xor ax, ax ; 2 bytes
nop ; 1
nop ; 1
그래서이 일을 어떤 혜택이?
예, AMD Bulldozer 및 Intel Atom에서 성능을 크게 향상시킬 수 있으며, Intel Core 2에서는 Nehalem을 사용하면 성능이 크게 향상 될 수 있습니다. & 불도저 및 코어 2의 경우 16 바이트 경계에, 아톰의 경우 8 바이트 경계에 정렬됩니다. 그러나 NOP 대신 추가 접두어 또는 긴 명령 형식을 사용하는 것이 바람직합니다. 피크 IPC의 절반 이상이 필요한 경우에만 지침을 정렬하는 것이 좋습니다.
제어 흐름 변경 대상이 아닌 다른 정렬 문제가 있습니까? OP의 예는 직선 코드입니다. – srking
예, 예 : 여기에 인텔 최적화 설명서 (Atom 최적화 정보)에서 발췌 한 내용이 있습니다. "명령어 길이 및 정렬은 디코드 처리량에 영향을 줄 수 있습니다. 프런트 엔드 내부의 프리 페치 버퍼는 7 사이클 창에서 디코딩되는 바이트 수가 48을 초과 할 경우 처리량 제한을 부과합니다 바이트를 사용하면 프런트 엔드에서 버퍼를 기다리는 데 지연이 발생하며, 명령 쌍이 16 바이트 경계를 넘을 때마다 프런트 엔드 버퍼를 적어도 한 번 더 유지해야하므로 16 바이트 경계는 매우 문제가있다. " –
니스 찾기! 이 텍스트는 Atom을위한 것이지만 이해가됩니다. 인텔의 다른 코어에 적용되는 "프런트 엔드 최적화"절에 그러한 강력한 내용이 나와 있지는 않습니다. – srking
예제에서 nop 명령의 이유는 없습니다. 일반적으로, 명령 정렬을위한 유일한 사용은 제어 흐름 브랜치의 타겟에서 페치 된 명령의 수를 최대화하는 것이다. 함수 호출. 최신 x86 인출 및 디코드 장치는 x86 인코딩의 가변 길이 특성에 맞게 최적화되어 있습니다. 이 같은 여백은 상황을 저하시킵니다.
인텔 볼륨 4 최적화 설명서 (만료 된 지 몇 년되지 않은)를 스캔하면 지침 채우기의 이유가 제공되지 않습니다.
386 프로세서에서? 아마도. 오늘? 불안한. – Wug
최근 페치 크기는 16 또는 32 바이트입니다. 어떤 경우에는 패딩에 약간의 이점이 있습니다. 가장 중요한 경우는 Core2에서 16 바이트 블록에 7 개의 명령어가있을 때입니다 (프리 디코더는 다음 사이클을 위해 7 번째 명령어를 남기고 하나의 명령어 만 그 다음 사이클에서 미리 디코딩 됨). 이 경우에는'nop'으로 채우는 것이 도움이되지 않을 것입니다. 접두어로 덧붙여 야합니다. – harold
나는 386에서 한 일을 기억하지 않습니다. 프리 페치 대기열이 얼마나 큰지를 기억할 수는 없지만 패딩이 도움이되는 상황이 있다는 것을 기억할 수는 없습니다. –