MASM 6.11 has inexplicable error for valid code

[none]

I'm getting the following error, but I can't determine why:

error A2081: missing operand after unary operator

It's referring to the line with the label sbyte: If I comment that label
out, the error stops. I don't get this. This should assemble, as it
appears to be entirely valid code (a basic mov command)

The offending code follows.

.
.
.
jmp bbyte ; do we need another biggie?
jl451:

sbyte:
mov ax,-1 ; get mask
.
.
.

[h...@40th.com]

sbyte is probably a reserved word. Use xsbyte:
ml 6.11 - I haven't used that in more than a
decade.

>sbyte:

--
40th Floor - Software @ http://40th.com/
PhantasmX - The finest sound in the world
phantasm.40th.com

[JD]

h...@40th.com wrote:
> sbyte is probably a reserved word. Use xsbyte:
> ml 6.11 - I haven't used that in more than a
> decade.
>
> >sbyte:
>

You were right! sbyte was reserved. No wonder it was looking for an
operand. This code was from 1990-1991, so I wouldn't be shocked if it
came from before masm 6.11 (I'm thinking 5.1)

Thanks for the assist.

[JD]

Any thoughts on why this is causing this error:
error A2070: invalid instruction operands

It looks like the offset keyword causing the problem.

There are a few lines of code, all of which involve specifically
[bx+offset kbdtbl]

seen in

mov al,[bx+offset kbdtbl]

[Tim Roberts]

JD <udgr...@yahoo.com> wrote:

>JD wrote:
>> h...@40th.com wrote:
>>> sbyte is probably a reserved word. Use xsbyte:
>>> ml 6.11 - I haven't used that in more than a
>>> decade.
>>>
>>> >sbyte:
>>>
>> You were right! sbyte was reserved. No wonder it was looking for an
>> operand. This code was from 1990-1991, so I wouldn't be shocked if it
>> came from before masm 6.11 (I'm thinking 5.1)

MASM 6.x includes rudimentary variable typing. SBYTE, SWORD, and SDWORD
are the signed versions of BYTE, WORD, and DWORD.

>Any thoughts on why this is causing this error:
>error A2070: invalid instruction operands
>
>It looks like the offset keyword causing the problem.
>
>There are a few lines of code, all of which involve specifically
>[bx+offset kbdtbl]
>
>seen in
>
>mov al,[bx+offset kbdtbl]

How is "kbdtbl" defined, and in what segment?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[JD]

h...@40th.com wrote:
> Real mode, lots of weirdness. It could
> be something like kbdtbl being in a segment
> that the assembler can't get to with what
> it knows (maybe you could use a segment
> prefix -- if that's what it was called --
> like es:kdbtbl, though that's really pulling
> ??it out of the air. Or GROUP? Maybe you
> have kbdtbl on the stack? -- that won't work
> (lea could be used for that). Can bx even
> be used with an offset? Maybe bx with
> an offset needs an es segment override? as
> in es:[bx+...]. Who knows these things?
> I realize I don't...anymore. I used use
> almost nothing else but that, especially
> 16-bit/real mode assembly, I haven't done
> since the early...well, I leave that out.

>
> >error A2070: invalid instruction operands

> >mov al,[bx+offset kbdtbl]
>
I'll take a look at the code today. However I found that removing
"offset" allowed masm to build. Don't know if there's a problem with the
code now, but since bx+label should be an address, maybe the original
author was being explicit that he meant the address of kbdtbl, and it
isn't required.

[Vladimir Grigoriev]

"JD" <udgr...@yahoo.com> wrote in message
news:%23YJs3oF...@TK2MSFTNGP04.phx.gbl...

>> >error A2070: invalid instruction operands
>> >mov al,[bx+offset kbdtbl]
>>
> I'll take a look at the code today. However I found that removing "offset"
> allowed masm to build. Don't know if there's a problem with the code now,
> but since bx+label should be an address, maybe the original author was
> being explicit that he meant the address of kbdtbl, and it isn't required.

The value of the kbdtbl is its segment address. Look at the instruction

mov al,[kbdtbl]

it stores the first byte at address kbdtbl, i.e. DS:offset of kbdtbl, to
the register al.

The original instructions uses the bx register. The format of the second
operand of the command is
DS: offset of kbdtbl + BX..
When you use [bx+offset kbdtbl] you get a scalar value of offset only while
the address should include a base register.

Vladimir Grigoriev

[JD]

Well, there's an ASSUME ds directive earlier in the procedure, so
removing the "offset" operator probably isn't hurting, as DS is assumed.
However, I explicitly used ds:kbdtbl, and it seemed to work. It's
probably a case of three things that all technically mean the same thing
here.