Question about ASSUME in masm

[StillLearningMasm]

I have found a couple of bugs in the ASSUME statement. In my opinion.
Bug 1:

Here is a code fragment:

Code Select Expand


.386
assume bx : ptr word


This code causes a error A2158 type is wrong size for register. On the line that has the ASSUME.
The error only occurs if PTR exists. Also the error only occurs for 16-bit registers.

Bug 2:

Here is the code fragment:

Code Select Expand


ASSUME BX : TYPEDEFname


If a TYPEDEF is assigned to a ASSUME instruction and the TYPEDEF is not defined then no error occurs, as it should.


Now is a program fragment that when assembled create error messages for the ASSUME instructions but do not create any error messages if ASSUME is not used to do the same thing:

Code Select Expand


.286
.model medium, c

ffword typedef far ptr word
nword typedef near ptr word
pproc typedef ptr proc

.data

dummy db ?

.code

assume bx:ptr pproc
call [bx]

call far ptr [bx]
assume bx:far ptr  ;error A2158: type is wrong size for register
call [bx]

call near ptr [bx]
assume bx:near ptr
call [bx]                ;error A2023: instruction operand must have size
assume bx:nothing

mynear proc near
call word ptr [bx]
call nword ptr [bx]
mynear endp

myproc proc far
call word ptr [bx]
call ffword ptr [bx]
myproc endp

end


I have 2 questions:
Why does the first error for the ASSUME occur when the same instruction can be created without the ASSUME? AM I overlooking something?

Is there another way to rewite the ASSUMEs for the 2 instructions that it flagged as errors?

I know those instructions can be written in other ways. I am interested in how to rewrite them where ASSUME is used to do so.

Thank you for you help in advance.

[jj2007]

I can only guess that assume ebx : ptr word would work.

If you had posted a complete example, I would have assembled it and tried to solve it. But today I am too lazy to construct a complete example around your fragments, sorry.

[hutch--]

The code you have posted so far is 16 bit MS-DOS technology, you will get something like a useful answer if you tell us a few things, what is your OS target and what reference material are you using. Also, what binaries are you using, ML.EXE has been around since about 1990 and back then it could handle 16 bit real mode code and early Windows 3.0 code. As of about 1997 it could also write 32 bit code.

If you tell us what you are doing and what you are using, you may get a useful answer.

[hutch--]

 

I am glad I did not hold my breath waiting for a response. Without better information it is unlikely we can help you.