I have found a couple of bugs in the ASSUME statement. In my opinion.
Bug 1:
Here is a code fragment:
.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:
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:
.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.
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.
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.
:undecided:
I am glad I did not hold my breath waiting for a response. Without better information it is unlikely we can help you.