그래서 저는 에뮬레이터를 작성하려고했거나 적어도 물건이 어떻게 작동하는지 이해했습니다. 나는 z80과 x86과 같은 어셈블리에 대한 적절한 이해를 가지고 있지만 오브젝트 파일 (또는 제 경우에는 .gb ROM 파일)이 어떻게 명령의 시작과 끝을 나타내는 지 결코 이해하지 못했습니다.오브젝트 파일에서 명령어의 시작과 끝을 어떻게 결정합니까?
각 명령어의 opcode를 구문 분석하려고하지만 모든 명령어 다음에 줄 바꿈이없는 것처럼 보입니다. 그러면 어떻게 될까요? 필자는 opcode와 피연산자의 차이를 알 수있는 방법이없는 바이트 묶음처럼 보입니다.
대부분의 CPU에서 Z80이이 범주에 속한다고 생각합니다. 명령어의 길이는 내재적입니다.
즉, 명령의 길이를 알아 내기 위해 명령을 디코딩해야합니다.
에뮬레이터를 작성하는 경우 실제로 전체 디스 어셈블리를 얻을 필요가 없습니다. 이제 프로그램 카운터가 무엇인지 알면 새로운 opcode, 주소, CB 페이지 opcode 등을 기대하는지 여부를 알 수 있으며 방금 처리 할 수 있습니다. 실제로 사람들이 작성하게되는 것은 보통 opcode 당 재귀 파생 파서입니다.
대부분의 사람들은 완전한 디스어셈블러를 사용하기 위해 약간의 시뮬레이션을 반복적으로 추적합니다. 지시 사항을 찾으면 데이터는 공제로 남습니다.
스토리지가 풍부하고 불법 복제가 물리적 인 장벽이있는 GB는 그리 많지 않지만 다른 플랫폼에서는 공간을 절약하거나 코드를 작성하여 코드를 작성하는 것이 합리적으로 일반적이었습니다. opcode의 중간은 멀티플렉싱 된 두 번째 작업 스트림을 만들거나 유효한 데이터를 갑자기 재사용하여 동일한 코드를 얻는 것입니다. Orlando의 6502 개 노력 중 하나는 로더 텍스트 (일반 ASCII)를 암호 해독 코드로 다시 사용하기까지했습니다. 그런 종류의 물건은 분해하기가 쉽지 않습니다. 왜냐하면 거기에 간단한 조립이 없기 때문에 디스 어셈 블러는 일반적으로 어떻게해야 할지를 알아낼 수 없기 때문입니다. 반대로 적절하게 정확한 에뮬레이터에서 이러한 코드는 정확히 원래대로 작동해야합니다.
좋아요, 실제로 그것은 엄청난 의미를 갖습니다. 하지만 어떤 것이 교육인지 데이터인지 어떻게 알 수 있습니까? 그것은 단지 파일의 주소 공간을 기반으로합니까? –
아아, 아니. 코드를 분석하고 제어 흐름이 코드인지 여부를 결정하기 위해 특정 주소에 도달 할 수 있는지 확인해야합니다. –
정말 고마워요. 그 일에 대해 약간의 독서를 가르쳐 주시겠습니까? :) –