문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 x86 (문단 편집) === 중구난방으로 확장된 명령어 세트 === 8080의 구조를 최대한 옮겨오면서도 16비트 명령어를 추가하려다 보니 8086 때부터도 복잡한 명령어가 많았다. 특히 아이태니엄이 실패하기 전까지 인텔은 꾸준히 x86을 포기하려고 시도하였기 때문에 AVX 이전까지 명령어 추가가 추후 확장을 고려하지 않고 무분별하게 이뤄져 명령어의 인코딩이 매우 복잡해졌다. 이런 명령어들은 고속화에 악영향을 준다. AX(AL)을 16비트 상수값 포인터가 가리키는 메모리 주소로 쓰거나 읽는 명령어가 있었다. 또 비슷한 기능을 하는 ADD, SUB 등 9개의 명령어가 있다. 이는 다른 명령어를 사용하는 것보다 고작 1바이트만 줄였을 뿐이다. AH 레지스터는 이용하지 못한다. 심지어 반복문을 처리하는 명령어(LOOP, LOOPZ, LOOPNZ)도 있을 정도였다. 가장 쓸데없던 명령어는 PUSH, POP, INC, DEC (레지스터 피연산자) 명령어로 다른 명령어와 고작 1바이트 차이였을 뿐 하는 기능은 완전히 같았다. 얼마나 쓸모없었는지 INC는 64비트 모드에서는 버려졌다. 왜 문제되냐 하면 확장성에 문제가 된다. 단독으로 32개의 1바이트 opcode를 잡아먹는다. 이제는 남은 공간이 얼마 없어 추가적인 명령어 확장은 POP CS 명령을 이용해서 확장한다. x86 디버거를 사용해서 바이너리를 읽어보면 대부분의 명령어가 0x0F로 시작하는 경우가 많은데 이는 사용하지 않는 명령어의 값을 접두사로 사용하는 것이다. AVX의 경우 거의 쓰이지 않아 64비트 모드 사양에서 비활성화된 특수한 레거시 명령어[* VEX 인코딩]를 사용하여 인코딩한다. 그래서 디버거가 오래되었을 경우 AVX 명령이 다른 명령어로 해석되지만 실행은 정상적으로 이루어지는 기괴한 상황이 발생한다. 다른 RISC 계열 프로세서는 고정된 크기의 명령어를 읽고 해석만 하면 되지만 x86은 이러한 복잡한 디코딩 과정을 전부 거쳐야만 한다. 1978년 당시에는 전반적인 CPU 성능과 메모리 크기가 열악했기 때문에 명령어 크기의 1바이트 차이가 큰 영향을 주었을지도 모른다. 특히 메모리 크기가 영향을 매우 심하게 줬다. 지금은 이해가 안 될지도 모르지만, 당시에는 64KB도 굉장히 큰 거였다. [[MS-DOS]]의 베이스 메모리 640KB가 이것 때문에 나왔으며, 1MB급 메모리만 해도 2020년 후반부터 시작된 이른바 [[그래픽 카드 채굴 대란|그래픽카드 대란]]이 장난으로 보일 정도로 비쌌다. 애초에 2000년대를 앞두고 터진 이른바 [[밀레니엄 버그]] 역시 이것이 원인 중 하나다.[* 이것은 MS-DOS 6.0 이전 기준으로 yyyy-mm-dd 라는 형식으로 연도 날짜를 정하는 기준이면 당시 시스템으로는 메모리에서 그 날짜 데이터를 다 받아들이지 못했다. 그래서 메모리를 아끼기 위해 yy-mm-dd라는 형태로 한 것.] 하지만 64비트 시스템이 보편화된 오늘날에는 더 이상 1바이트의 차이가 성능을 결정짓지 않는다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기