TYPEDEF PTR - 크기가 중요하지 않습니까?

TYPEDEF를 사용하여 다양한 데이터 유형의 PTR을 정의하는 것이 어떤 차이도없는 것으로 나타났습니다. 예를 들어, 이러한 세 가지 유형이 저장하는 데 사용하는 경우 정확히 같은 행동을 보인다 및 mov 32 비트 주소 :TYPEDEF PTR - 크기가 중요하지 않습니까?

PTYPE TYPEDEF PTR 
PBYTE TYPEDEF PTR BYTE 
PWORD TYPEDEF PTR WORD 

.data 

arrayByte BYTE 10h,20h,30h 

ptr_1 PTYPE arrayByte 
ptr_2 PBYTE arrayByte 
ptr_3 PWORD arrayByte 

.code 
main PROC 

mov eax, ptr_1 
mov eax, ptr_2 
mov eax, ptr_3 

exit  
main ENDP

는 더 자기 문서화의 이외의 크기를 지정하기 위해 어떤 실제적인 이유가 있나요?

출처

2017-02-10 cafekaze

당신은이 질문을하지 않았습니까? 어셈블러에게 생성 할 명령어를 알려줍니다. 이 질문을 다시하기 전에 인텔 문서를 읽어보십시오. –

누군가 이번 주에이 질문을했습니다 ... –

이 세 가지 지시어가 같은 방식으로 작동하는 것처럼 보이는 _exact MASM 지침을 포함하십시오! – zx485

포인터 형식 선언 및 사용은 MASM에서 거의 사용되지 않습니다. MASM의 형식은 기본적으로 크기 뿐이며 개체와 피연산자의 크기와 호환성을 크기에 따라 결정합니다.

Types: 

       N a m e     Size  Attr 

PBYTE . . . . . . . . . . . . .   00000004  Near32 PTR Byte 
PTYPE . . . . . . . . . . . . .   00000004  Near32 PTR 
PWORD . . . . . . . . . . . . .   00000004  Near32 PTR Word 

... 

Symbols: 

       N a m e     Type  Value Attr 

... 
ptr_1 . . . . . . . . . . . . .  DWord 00000003 _DATA 
ptr_2 . . . . . . . . . . . . .  DWord 00000007 _DATA 
ptr_3 . . . . . . . . . . . . .  DWord 0000000B _DATA

유일한 것은 (그것이 조립 있도록 .MODEL FLAT 및 END 지시어를 추가 한 후) 귀하의 예제 코드를 조립하는 동안이 목록 파일을 생성하면 ptr1, ptr2 및 ptr3의 유형이 모두 DWORD있는 것을 볼 수 있습니다 그 (것)들을 유용하게 만들 수있는 포인터 유형에 관해서는 실제로 적용되는 메모리 모델에 따라 크기가 자동으로 변경된다는 사실을 알 수 있습니다. 따라서 .MODEL FLAT 대신 .MODEL SMALL으로 예제를 어셈블하면 ptr1, ptr2 및 ptr3의 형식이 DWORD 대신 WORD가됩니다. 마찬가지로 모델 지시문을 삭제하고 x64 버전의 MASM으로 어셈블하면 이러한 심볼 유형이 QWORD가됩니다. 그러나이 중 하나를 수행하면 예제 코드의 MOV EAX, ... 명령어가 피연산자 크기가 일치하지 않기 때문에 오류가 발생하기 때문에 소리가 나지 않는 것이 유용하다는 것을 알 수 있습니다. 실제로 포인터 크기의 변경에 따라 다른 많은 코드를 다시 작성해야합니다.

또 다른 가능성은 포인터 유형이 매크로에서 어떻게 든 유용하게 사용된다는 것입니다. 그러나 실제로 무엇이 될지 알 수 없습니다. 문서화 된 것처럼 포인터 유형을 사용하는 것은 의심 스럽습니다. 다른 독자는 코드 정의를 검색하지 않고 PBYTE 또는 PTYPE의 의미를 알 수 없습니다. 나는 그들을 사용하지 않는 것이 좋습니다.

출처

2017-02-10 19:34:57

자체 문서화 만이 유일한 유용한 유용한 목적이라고 생각하십니까? – cafekaze

TYPEDEF PTR - 크기가 중요하지 않습니까?

답변

관련 문제