2 forms of PTR instructions

[Rockphorr]

PtrDWORD typedef DWORD
...
mov PtrDWORD PTR [ebx],0 ;no error in MASM. Code is created for WORD
                         ;not DWORD, why?

There is difinition before - PtrDWORD typedef DWORD

so mov PtrDWORD PTR [ebx],0 translates as mov DWORD PTR [ebx],0

Yes, exactly. Why the need for using TYPEDEF's, StillLearningMasm?... seems to add confusion to what you want to accomplish.

It is not need. It is user-defined name of type.

formula: mov <type> ptr <address>,<source>

Any types can be used - user defined or present by default.

[StillLearningMasm]

I did install the latest Masm32 SDK but found no informtion on these 2 forms there. Am I looking
in the wrong place for it?

The only reference I have for masm is the original Masm reference that came with masm version 6.
In that was no mention of the instruction form [size PTR register] or [size PTR number].
Where did you get this information, BugCatcher, for these forms? I found out that these forms
existed from seeing them in a program fragment but they were not explained there so I ASSUMED
that they were the same as the other forms. Bad assumption on my part.

I am writing my own version of masm. My version has no cryptic error messages when errors occur.
But to do this I need to know what are the allowed forms of all the instructions. This is very
hard because there is NO good source of reference information that is easily accessable that I
know of.

Here is a shortened program that explains my TYPEDEF problem:

Code Select Expand

.286
.model small
.data

PtrDWORD typedef DWORD

.code
.386
mov dword PTR [ebx],0   ;no error in MASM, because masm can not
                        ;detect it as a pointer unless PTR is in [].
                        ;Since no error occurs a DWORD size constant
                        ;is created, as expected.
mov [DWORD PTR ebx],0   ;masm has error because it is a pointer

;The code below is affected by the the typedef above.
;If no PTR is in the typedef then the correct code is created
;by the assembler. That is, a dword size constant is created, as
;it is suppose to be. If PTR is in the typedef then a word size
;constant, the wrong size, is created. WHY?
;To me this seems to be a bug in the TYPEDEF instruction and it
;seems to be with PTR. I was told that the PTR instruction used
;in TYPEDEF it not the same as the PTR used within or outside of
;the []. If they are not the same then the problem MUST be with
;using PTR in TYPEDEF.

;I already know that I can use dword to fix the problem . I want
;to know why this way does not work.

mov PtrDWORD PTR [ebx],0

end

Thank you for your help.

Sincerely,

StillLearningMasm

[HSE]

I think MASM born for 16 bits, later was updated for 32 bits, and finally to 64 bits(for now).

Probably what you say about 2 forms of PTR is because you are using the tool incorrectly, and is posible because some old code still is in place.

Anyway have no sense to reproduce a bug, or so.

[NoCforMe]

I am writing my own version of masm.

OK. Finally we know what you're trying to do. Quite an ambitious project; I'm sure we all wish you the best of luck with that.

The question is, do you really want to reproduce all the flaws of MASM? For the sake of "compatibility"? Or wouldn't you rather just implement things the way they're supposed to work, according to the consensus of understanding? Like the meaning of PTR. Since it's your language translator, you're in charge here.

Who's your expected user base for this project? Just yourself, or others? If it's just you then you're free to do whatever you think is best.

[StillLearningMasm]

NoCforMe,
;I always have to use .286 before any code to use code to
;detect the presence of a 386 or above cpu. Then I can use .386.
;But once I do this most of my code has the 66h and /or 67h
;prefixes before them. How do I detect the 386 or above cpu without
;using the .286 before it?

This is why all my code is initially 16 bit.
If I can do it another way then my TYPEDEF issue goes away.

Thank you for your response.

StillLearningMasm

[NoCforMe]

Now we're getting somewhere. I think ...

OK, regarding processor type declarations: I use the standard (for us here) MASM32 include file, masm32rt.inc, which right at the top declares

Code Select Expand

.486

Why don't you try this? Let me ask you this: do you think there's even a slim chance that your code will ever actually be run on an 80386? Those processors are pretty much ancient history now. (Please take what I'm writing here with a few grains of salt, as I am not an expert on this stuff.)

Can you answer what I asked before: What is your intended audience here? Does it include anyone who might possibly be running on a '386 (or earlier) processor? If not, then just fuggedaboudit and use the .486 directive, which works in 99% of cases. Then you can jump straight into good old 32-bit code. And as you noted, then you won't have to worry about any TYPEDEF bullshit either.

If that works out, maybe we can move this whole thread out of this 16-bit forum, since it's apparent that this isn't really 16-bit code we're discussing here.

[HSE]

This is why all my code is initially 16 bit.
If I can do it another way then my TYPEDEF issue goes away.

Why do you think MASM's assembly can work in that way?