direct address

Well, the x86 doesnt have indirect addressing per se, so I don't quite understand your question.  And if we can only use ax, then we can't use the multiply instruction, which is kind of a strange restriction.

Could you restate the problem a bit more clearly?

Thanks,


grg99

@ grg99:
Erm, the x86 _does_ have indirect addressing. Or what would you call this:

mov bx, some_address
mov ax, [bx]

Moreover, imul can be used with immediate operands (286+):

mov ax, 10
imul ax, 20

works for me. So I guess there is no cure against uninformed opinions....

I'm not sure how to solve the (homework?) assignment for one reason: While being able to calculate 12*x and 5*y and pushing them onto the stack, I'm rather puzzled how to add them, without indirectly accessing the data on the stack and only using ax -- unless you split up the ax register into al and ah parts, thus limiting intermediate expressions to a range of -128..127. Are there any restrictions on the values of x and y?

On to the question why pop [7000] won't work (besides the fact that this _is_ indirect addressing): x86 doesn't support memory-to-memory copies, which is what this instruction would do. To illustrate this, here is a substitution of what pop [7000] does (btw. it's lacking a size argument, so how is the assembler to decide whether you want to pop a BYTE/WORD/DWORD/QWORD/...):

mov [7000], [sp]    ; this doesn't work on x86's
dec sp

.f

Hey fl0yd,

> On to the question why pop [7000] won't work (besides
> the fact that this _is_ indirect addressing):

That _is_ direct addressing.  It 'directly' refers to an absolute memory address.  Futhermore, it's actually a valid x86 instruction (minus the size argument as you said).

POP WORD [7000] <--> 8F 06 00 70

Yip, sorry mixed that up with the expanded mov-instruction, which does not support m2m transfer. Since pop accesses data at [sp] I would still refer to it as indirect addressing.

.f

@ grg99:
Erm, the x86 _does_ have indirect addressing. Or what would you call this:

mov bx, some_address
mov ax, [bx]


That is called DIRECT ADDRESSING!

Indirect addressing is when the address you supply is the address of an address.  This is not a debatable point, it goes back to the dawn of computers and is a firmly established concept.

Actually, the x86 *Does* have a bit of indirect addressing, but only for jumps and calls.  That's what the "call (d)word ptr [address]" format means.


>Moreover, imul can be used with immediate operands >(286+):
>mov ax, 10
>imul ax, 20

w>orks for me. So I guess there is no cure against >uninformed opinions....

You're right about the uninformed bit.  Lookup what the mul instruction really does.   Hint:  There's always an extra 16 bits of answer that goes into some register.

@ grg99:

Technically, you are right about the description of terminology for 'indirect addressing'. And yes, it then only exists for jmp/call-operations on x86's. The term is, however, casually also used for register-indirect addressing which is what I was referring to. So technically speaking, yes, you are right.

You are wrong about the mul/imul instructions though. If we did this:

mov al, 10
imul al, 10

I'm somewhat sure that the result will go into ax exclusively, and Intel's documentation seems to back my claims here. So your 'There's always an extra 16 bits' just isn't true.

.f

> You are wrong about the mul/imul instructions though.
> If we did this:
>
> mov  al, 10
> imul al, 10

Actually:

  imul al, 10

is not a valid x86 instruction.

However, for the most part, fl0yd is correct.

If you did this:

  mov ax, 10
  imul ax, 20

then the result would go into AX and any overflow would be signaled through the Carry and Overflow flags.

There is no extra 16-bits.

*That* is according to Intel documentation.