registers as pointer q

[dc]

for this to work:

Code Select Expand

bt [eax][esi],0do i need to:

Code Select Expand

ASSUME eax,ptr BYTEand can I use ecx,edx as pointers the same way?
thanx

[jj2007]

Your instruction won't work. It's one reg that points to memory, the other containing the bit's position:

  xor eax, eax
  bt [esi], eax

[dc]

how about bt [esi+eax],0?
im trying to do indexed indirect addressing
actually i want to reference with an indexed pointer

[jj2007]

How about testing instead of asking?
Or reading the documentation?
Or finding a workaround for illegal instructions?

Error A2049: Invalid instruction operands

[dc]

+im guessing now that i have to add the index to the pointer and then subtract the index from the pointer to preserve the pointer???

[NoCforMe]

how about bt [esi+eax],0?

im trying to do indexed indirect addressing
actually i want to reference with an indexed pointer

I'll be a little more generous than JJ here. Yes, your addressing method ([esi+eax]) will work fine, just so long as you know what you're doing (meaning that you know where the result of this expression points to).
Aaaargh; your addressing mode is OK, but this does indeed give an "invalid instruction operands" error, and I'm not sure why. According to the instruction documentation, you should be able to use the "BT r/m32, imm8" form of the instruction, where the data to be tested is an 8-bit immediate like you have. Maybe JJ can explain why this doesn't work. (I've never ever used this instruction myself, though it does look mighty handy.)

[jj2007]

Yes, your addressing method ([esi+eax]) will work fine

Can you post an example with the bt instruction?

[NoCforMe]

See reply above you. I edited mine after you posted yours.

Try this instead, as suggested:

Code Select Expand

BT [ESI+EAX], ECX

(bit to test in a register instead of coded as an immediate)
It at least assembles correctly ...

[jj2007]

The problem here is a misleading error message (in Masm, UAsm and AsmC):

Code Select Expand

  int 3
  ; bt [esi+eax], 3 ; Error A2049: Invalid instruction operands
  bt dword ptr [esi+eax], 2
  bt word ptr [esi+eax], 2
  ; bt byte ptr [esi+eax], 2 ; Error A2049: invalid instruction operands
  bt [esi+eax], ecx

Code Select Expand

0FBA2430 02   bt dword ptr [esi+eax], 2
66:0FBA2430 0 bt word ptr [esi+eax], 2
0FA30C30      bt [esi+eax], ecx
The instruction operands are absolutely valid, but for some reason the assembler needs the size, too. Besides, DWORD and WORD are legal but BYTE isn't.

[Greenhorn]

Without specifying the size (word, dword or qword ptr) for a memory address the assembler assumes that the memory address points to a byte, and yes that's not possible for BT.
bt [esi+eax], ecx lets the assembler assume that the memory address points to a dword because of ecx as the second operand.

So, the error messages are correct.

EDIT:
bt [eax][esi],0 is the same as bt [eax+esi],0, so this syntax is valid.

[jj2007]

Code Select Expand

include \masm32\include\masm32rt.inc

.data
MyArray dd 25, 18, 23, 17, 9, 2, 6

.code
start:
  mov esi, offset MyArray
  xor eax, eax
  mov [esi+eax], 123
  mov [esi+eax], 1234
  mov [esi+eax], 123456
  exit

end start

Code Select Expand

ml 6.14 ... 14.0 (dumb):
tmp_file.asm(10) : error A2070: invalid instruction operands
tmp_file.asm(11) : error A2070: invalid instruction operands
tmp_file.asm(12) : error A2070: invalid instruction operands

UAsm, AsmC (less dumb):
tmp_file.asm(10) : warning A8019: size not specified, assuming: BYTE
tmp_file.asm(11) : warning A8019: size not specified, assuming: WORD
tmp_file.asm(12) : warning A8019: size not specified, assuming: DWORD
The instruction operands are ok, but the assembler wants to know the size.

Btw bt dword ptr [esi+eax], 40 assembles fine with all three assemblers. Testing bit 40 of a DWORD works ;-)

Seriously:

Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset field in combination with the displacement field of the memory operand. In this case, the low-order 3 or 5 bits (3 for 16-bit operands, 5 for 32-bit operands) of the immediate bit offset are stored in the immediate bit offset field, and the high-order bits are shifted and combined with the byte displacement in the addressing mode by the assembler. The processor will ignore the high order bits if they are not zero.

[NoCforMe]

Code Select Expand

ml 6.14 ... 14.0 (dumb):
tmp_file.asm(10) : error A2070: invalid instruction operands
tmp_file.asm(11) : error A2070: invalid instruction operands
tmp_file.asm(12) : error A2070: invalid instruction operands

UAsm, AsmC (less dumb):
tmp_file.asm(10) : warning A8019: size not specified, assuming: BYTE
tmp_file.asm(11) : warning A8019: size not specified, assuming: WORD
tmp_file.asm(12) : warning A8019: size not specified, assuming: DWORD

Maybe kind of a fine point, but I now don't see that (ML's behavior) as "dumb". Why not? Because otherwise the assembler has to make assumptions about what the coder really meant, assumptions that could well be wrong. So probably the right thing to alert them to the ambiguity of their coding. (Lord knows I've been "helped" this way many times to fix my own mistakes.)

[jj2007]

Because otherwise the assembler has to make assumptions about what the coder really meant, assumptions that could well be wrong

Fully agreed, but there are two options:
1. a warning, see UAsm and AsmC
2. an error saying "you need to specify the size"

"invalid instruction operands" is just plain wrong. Or, in other words, dumb

[NoCforMe]

Yes, fully agree. My vote is for (2), an error saying "you need to specify the size".

[zedd151]

So, what is the consensus, or simply the answer for the OP, dc?
Hard to tell, from the series of posts. 

From what I understood from the posts, to avoid ambiguity and cryptic error messages, to always specify the size? (dword, word, or byte)  Is that correct?