8086은 16 비트 명령어를 사용하지만 RAM 주소는 8 비트 만 보유합니다. 그러면 CPU가 RAM에서 프로그램을로드하는 방법은 무엇입니까? 하나의 주소를로드 한 다음 명령어가 1/2/3 바이트를 필요로하는지 (예 : 레지스터를 8/16 비트로 즉시 이동) 확인한 다음 작업을 실행하는지 아니면 하나의 RAM '공간'이 16인지 잘못 판단하고 있습니까? 큰 비트?RAM에서 8086의 프로그램로드 중
많은 명령어는 멀티 바이트이며 예는 두 개 이상의 주소에 걸쳐 있음을 의미합니다.
IIRC, 8086의 메모리 버스는 16 비트이므로 단일 작업으로 16 비트 (인접한 두 개의 주소)를로드 할 수 있습니다. 버스 주소와 바이트 주소 지정 가능 메모리를 혼동하고 있습니다.
는 하나 개의 주소를로드 않고 다음 지시 1/2/3 바이트 필요한지
그것은 계속 지시가에 바이트를 가져온다 (예를 들어, 레지스터 8/16 비트에 즉시 이동) 점검 6 바이트 버퍼 (16 비트 버스를 가진 16 비트 CPU이기 때문에 한 번에 2 바이트). 버퍼는 허용 된 최대 8086 명령어 (IDK와 별도로 디코딩 될 수있는 접두어 제외)를 수용 할 수있을만큼 충분히 큽니다. 이전 명령 실행이 끝나면 버퍼를 찾습니다. 더 자세한 설명은 아래의 링크를 참조하십시오. 그러나 아마도 전체 명령으로 버퍼를 디코딩하려고합니다. 명령의 끝을 찾기 전에 페치 버퍼의 끝에 도달하면 다음 페치 사이클이 완료 될 때까지 기다린 후 다시 시도합니다.
참고 : 8086 CPU architecture은 "8086 코드 가져 오기"의 첫 번째 히트였습니다. 가져 오기와 실행이 겹치기 때문에 가장 기본적인 방법 인에 파이프 라인되어 있습니다.
TL : DR : 디코딩 할 전체 명령이있을 때까지 버퍼로 가져옵니다. 다음 여분의 바이트를 다음 명령의 일부이기 때문에 버퍼 앞쪽으로 이동합니다.
일반적으로 명령어 가져 오기가 8086의 병목 현상이라는 것을 읽었으므로 코드 크기 최적화가 그 밖의 모든 것을 능가합니다.
파이프 라인 된 CPU는 디코딩 시작을 위해 이전 명령의 실행을 기다릴 필요가 없습니다. 최신 CPU의 경우 이 많으므로 높은 대역폭 코드 불러 오기가 가능하므로 디코드 된 명령 대기열이 준비되어 있습니다 (분기가 엉망인 경우 제외). 및 x86 태그 위키의 다른 링크를 참조하십시오.
또한 아주 일반적인 명령어는 push r16과 같은 단일 바이트입니다.
우리 옛날 가장 좋아하는 [** The Art of Assembly Sect 3.3.7 **]에서 디코딩의 잡초에 들어갈 수 있다고 생각합니다. (https://courses.engr.illinois.edu/ece390/books/artofasm/CH03 /CH03-3.html#HEADING3-102). 그것은 디코딩의 개요입니다. –
신속하고 정확한 답변을 해주셔서 고맙습니다. –
8086의 프리 페치 대기열은 6 바이트 였지만 명령어 길이에는 제한이 없었습니다. 여분의 접두사를 원하는만큼 사용할 수 있지만 '386'에는 15 바이트 제한이 추가되었습니다. 중복 접두사가 없으면 명령어가 6 바이트를 초과 할 수 있습니다. 예를 들어'mov [es : 0], 1234'는 7 바이트 길이입니다. 그러나 접두어가 없어도 8086 명령어가 6 바이트를 초과 할 수 있다고 생각하지 않습니다.내 생각 엔 접두사 바이트가 개별적으로 디코드되고 개별 지시문처럼 개별적으로 디코딩된다는 것입니다. –
RAM은 실제로 24 비트입니다. 이것이 세그먼트 레지스터와 오프셋으로 정렬 된 단락의 이유입니다. 8 비트 주소를 지정하면 세그먼트 레지스터가 기본이라고 가정합니다. –