I did not know that masm supported 2 different forms of the PTR operator.
Notice PTR and size is inside [] in one form but outside the other form.
form1: mov [size PTR register],number
form2: mov size PTR [register],number
The same can be done when all numbers are used.
I also thought that the results were the same. This does not seem to be always true.
Here are some examples:
.286
.model small
.data
PtrWORD typedef ptr WORD
PtrDWORD typedef ptr DWORD
.code
;Why does form1 sometimes cause errors and form2 does not?
mov ds:[word ptr 20],0 ;no error in MASM
mov word ptr ds:[20],0 ;no error in MASM
mov ds:[PtrWORD PTR 20],0 ;no error in MASM
mov PtrWORD PTR ds:[20],0 ;no error in MASM
mov [word PTR bx],0 ;causes error in MASM, why?
mov WORD PTR [bx],0 ;no error in MASM, why?
mov [PtrWORD PTR bx],0 ;no error in MASM, why?
mov PtrWORD PTR [bx],0 ;no error in MASM, why?
.386
;check WORD
;Why does form1 sometimes cause errors and form2 does not?
mov ds:[word ptr 20],0 ;no error in MASM
mov word ptr ds:[20],0 ;no error in MASM
mov ds:[PtrWORD PTR 20],0 ;no error in MASM
mov PtrWORD PTR ds:[20],0 ;no error in MASM
mov [word PTR ebx],0 ;causes error in MASM,,should not, why?
mov word PTR [ebx],0 ;no error in MASM, why?
mov [PtrWORD PTR ebx],0 ;causes error in MASM,should not, why?
mov PtrWORD PTR [ebx],0 ;no error in MASM, why?
;now check DWORD
mov ds:[dword ptr 20],0 ;no error in MASM
mov dword ptr ds:[20],0 ;no error in MASM
;Why are these 2 assembled instructions different then the 2 above?
;NOTE: if the type definition for PtrDWORD is changed to this:
; PtrDWORD typedef DWORD
; then the same code is created above. Notice PTR is missing.
mov ds:[PtrDWORD PTR 20],0 ;Both of these and the 2 above should all be
mov PtrDWORD PTR ds:[20],0 ;the same assembled instructions. But are not.
;these 2 instructions have code created for WORD
;not DWORD, Why?
mov [dword PTR ebx],0 ;causes error in MASM,should not, why?
mov dword PTR [ebx],0 ;no error in MASM
;Why are these 2 assembled instructions different then the 2 above?
mov [PtrDWORD PTR ebx],0 ;causes error in MASM, should not
mov PtrDWORD PTR [ebx],0 ;no error in MASM. Code is created for WORD
;not DWORD, why?
end
Why does the existance of PTR in the typedef definitions have a
affect on the instructions created when the instuctions created
have a PTR in them?
Can anybody explain any of this?
Thank you for any help,
StillLearningMasm
Just what the hell are you actually trying to do? Seems like all you're presenting us are weird outlier MASM errors for stuff that nobody actually uses ...
Look, if your main complaint here is that things like this don't work:
mov [dword PTR ebx],0 ;causes error in MASM,should not, why?
then my advice is the punch line of the old joke:
"Doc, it hurts when I do this!"
"Then don't do that!"
Just use the regular old
mov dword PTR [ebx],0
and don't worry about why MASM gets all confused sometimes.
@ StillLearningMasm...
Seems that you are either using very old reference material, non Masm reference material, or are just plain experimenting.
I am curious to see any source code from you of a working program.
Since you are using ".model small", also leads me to believe that you are using very old stuff here.
What version of Masm (ml.exe) are you using? And what version of the Masm32 SDK do you have on your system?
If my assumptions are correct, I will move this thread to the 16 bit board.
mov [word PTR ebx],0 ;causes error in MASM,,should not, why?
[word ptr ebx] The brackets turns the whole thing into a pointer statement. But whats the type (or length of bytes) to write to?
mov word PTR [ebx],0 ;no error in MASM, why?
ebx is the pointer to memory. The assembler now knows to write length of a word to that memory location.
Quote from: zedd151 on October 09, 2023, 09:31:02 PMI am curious to see any source code from you of a working program.
Me too. As I think are most of us here.
Don't worry, we don't bite.
The Campus
A protected forum where programmers learning assembler can ask questions in a sensible and safe atmosphere without being harassed or insulted.
You know, I think that is a wonderful idea for a sub-forum! When can we get one up and running?
@satpro, who exactly has been harassed or insulted here? Btw, you just reminded me that I was going to move this thread out of the Campus, and to the 16 bit board.
.model small indicates to me that the OP is working with 16 bit MS-DOS code
zedd.
In reference to my post here: https://masm32.com/board/index.php?msg=124380
It does seem that StillLearningMasm is using outdated reference material, and has been doing so for quite some time:
https://masm32.com/board/index.php?msg=86514
Quote from: zedd151 on October 09, 2023, 09:31:02 PMI am curious to see any source code from you of a working program.
satpro has a point here: this is/was indeed The Campus. OTOH I can understand that you are a bit fed up, Z. Me too.
StillLearningMasm please install the latest Masm32 SDK, and don't waste time on asking too exotic questions. Yes, MASM has quirks and bugs and strange "features", but if you really want to explore all of them,
you are free to do so. Read the manual, test what you don't understand (trial & error are the programmer's best friends), and from time to time report to us what you found :cool:
always use this formula: mov <type> ptr <address>,<source>
mov word ptr DS:[2],0
mov word ptr DS:[bx],0
mov byte ptr DS:[bx],0
mov word ptr DS:[bx],AX ;; corrected after NoCforMe notes.
mov byte ptr DS:[bx],AL
etc.....
PtrDWORD typedef DWORD
...
mov PtrDWORD PTR [ebx],0 ;no error in MASM. Code is created for WORD
;not DWORD, why?
There is definition before - PtrDWORD typedef DWORD
so mov PtrDWORD PTR [ebx],0 translates as mov DWORD PTR [ebx],0
Exactly. Like I said. If it ain't broke don't fix it.
Quote from: Rockphorr on October 11, 2023, 06:52:50 AMalways use this formula: mov <type> ptr <address>,<source>
mov word ptr DS:[2],0
mov word ptr DS:[bx],0
mov byte ptr DS:[bx],0
Yes, except that in your last 2 examples
Quotemov byte ptr DS:[bx],AX
mov byte ptr DS:[bx],AL
The first one is invalid, as the "byte ptr" conflicts with the size of the source register which is a WORD
**;
The "byte ptr" in the last one is completely unnecessary, as the source register gives the size, so "byte ptr" is implicit.
** I just confirmed this; MASM said "Illegal instruction operands".
Quote from: NoCforMe on October 11, 2023, 07:02:54 AMQuote from: Rockphorr on October 11, 2023, 06:52:50 AMalways use this formula: mov <type> ptr <address>,<source>
mov word ptr DS:[2],0
mov word ptr DS:[bx],0
mov byte ptr DS:[bx],0
Yes, except that in your last 2 examples
Quotemov byte ptr DS:[bx],AX
mov byte ptr DS:[bx],AL
The first one is invalid, as the "byte ptr" conflicts with the size of the source register which is a WORD **;
The "byte ptr" in the last one is completely unnecessary, as the source register gives the size, so "byte ptr" is implicit.
** I just confirmed this; MASM said "Illegal instruction operands".
yes, i fogot to correct when copy+paste
>The "byte ptr" in the last one is completely unnecessary, as the source register gives the size, so "byte ptr" is implicit.
I do so. Sometimes byte ptr DS:[bx] is modifed to like byte ptr DS:(struc_name ptr [bx]).coords and I use word for coords field, but writes to column only :)
Quote from: Rockphorr on October 11, 2023, 06:57:14 AMPtrDWORD 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.
Quote from: zedd151 on October 11, 2023, 08:32:13 AMQuote from: Rockphorr on October 11, 2023, 06:57:14 AMPtrDWORD 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.
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:
.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
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.
Quote from: StillLearningMasm on October 18, 2023, 05:27:13 AMI 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.
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
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
.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.
Quote from: StillLearningMasm on October 18, 2023, 08:07:07 AMThis 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?