2017-02-10 7 views
0

TYPEDEFを使用して、さまざまなデータタイプのPTRを定義することに違いがないように見えました。例えば、これらの3つのタイプが格納するために使用する場合とまったく同じ動作をするようだと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 

は、より自己文書だ以外のサイズを指定するための実用的な理由はありますか?

+0

あなたはこの質問をしませんでしたか?アセンブラにどの命令を生成するかを指示します。この質問をもう一度聞く前に、インテルのドキュメントをお読みください。 –

+0

誰かが今週これを尋ねました... –

+0

これらの3つのディレクティブが同じように動作するように見える_exact MASM命令を含めてください! – zx485

答えて

1

ポインタ型の宣言と使用は、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 FLATENDディレクティブを追加した後に)あなたの例のコードをアセンブルしているときにリストファイルを生成する場合は、ptr1ptr2ptr3のタイプはすべてDWORDあることがわかります実際に有効なメモリモデルに応じて自動的にサイズが変更されるということは、ポインタタイプが有用である可能性があることを私は知ることができます。したがって、.MODEL FLATの代わりに.MODEL SMALLでサンプルをアセンブルすると、DWORDの代わりにptr1,ptr2およびptr3のタイプになります。同様に、モデルディレクティブを削除し、MASMのx64バージョンでアセンブルした場合、それらのシンボルのタイプはQWORDになります。しかし、これらのいずれかを実行すると、それほど有益ではないことが明らかになります。オペランドサイズの不一致のために、サンプルコードのMOV EAX, ...命令がエラーを生成するためです。実際には、多くの他のコードをポインタサイズの変更に合わせて書き直す必要があります。

もう1つの可能性は、何らかの形で役に立つポインタ型がマクロで使用される可能性がありますが、実際にはそれがどうなるかわかりません。たとえドキュメントであっても、ポインタタイプを使用することは疑いがあります。他の読者は、その定義のコードを検索することなく、PBYTEまたはPTYPEの意味を理解しません。私はそれらを使用することをお勧めしません。

+0

私は自己文書化が唯一本当の有用な目的だと思いますか? – cafekaze

関連する問題