x86에서 멀티 바이트 오브젝트가 메모리 리틀 엔디안 스타일로 저장된다는 것을 알고 있습니다.Linux x86 CPU 명령어 레이아웃 혼동
일반적으로 말하자면 CPU 명령어의 경우 OPCODE가 명령어의 용도를 결정하고 데이터/메모리 주소가 인코딩 된 형식의 opcode를 따를 수 있습니다. 필자의 이해는 명령어의 Opcode 부분이 최상위 바이트 여야하므로 주어진 명령어 인코딩 표현의 최상위 주소에 나타납니다.
누군가이 x86 linux gdb 예제에서 메모리 레이아웃을 설명 할 수 있습니까? opcode 0xb8이 가장 중요한 바이트이기 때문에 더 높은 주소에 나타날 것이라고 생각합니다.
(gdb) disassemble _start
Dump of assembler code for function _start:
0x08048080 <+0>: mov eax,0x11223344
(gdb) x/1xb _start+0
0x8048080 <_start>: 0xb8
(gdb) x/1xb _start+1
0x8048081 <_start+1>: 0x44
(gdb) x/1xb _start+2
0x8048082 <_start+2>: 0x33
(gdb) x/1xb _start+3
0x8048083 <_start+3>: 0x22
(gdb) x/1xb _start+4
0x8048084 <_start+4>: 0x11
mov movx, 0x11223344 명령어는 0x11 0x22 0x33 0x44xxxx로 인코딩됩니다.
질문
1.) 첫 번째 바이트가 opcode가 아닌 경우 명령어가 차지할 바이트 수를 CPU가 어떻게 알 수 있습니까?
2.) 아마도 x86 CPU 명령어가 엔디안 - 네스 (endian-ness)조차 갖고 있지 않으며 일부 유형의 문자열을 고려하고 있는지 궁금합니다. (아마 여기서 떨어져)
# 2가 정확합니다.지침에는 엔디안이 없지만 임베디드 상수는 포함되어 있습니다. gdb 덤프에서 볼 수 있듯이 opcode **는 첫 번째 바이트입니다 (단, 앞에 접두어 바이트가 올 수 있습니다). 참고 항목 _Intel® 64 및 IA-32 아키텍처 소프트웨어 개발자 설명서 제 2 권 : 명령어 세트 참조 서, AZ 제 2 장 명령어 형식 – Jester
다중 바이트 정수를 메모리와 관련하여 2 바이트 이상을 포함하는 CPU 명령어와 혼동시킬 수 있습니다 표현 – htederson
Jester는 opcode가 인코딩 된 명령어의 첫 번째 바이트임을 지적합니다. – htederson