Solved

Posted on 2003-03-22
Medium Priority
445 Views
I'm newbie in Assembler.How to make f(X) = 12X+5Y-3XY, X = 5 , Y = 2, using only register AX,push,pop and without using indirect addressing.In debug i can use direct addressing to solve my problem (ex : POP [7000]) but in MASM611 i can't. Can someone help me to solve this problem? Thank you very much :)
0
Question by:zilnus
[X]
###### Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

• Help others & share knowledge
• Earn cash & points
• 3
• 2
• 2
• +1

LVL 22

Expert Comment

ID: 8186247
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

0

LVL 8

Expert Comment

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

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
0

LVL 3

Expert Comment

ID: 8188414
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
0

LVL 8

Expert Comment

ID: 8189399
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
0

LVL 22

Expert Comment

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

mov ax, [bx]

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.
0

LVL 8

Expert Comment

ID: 8193544
@ 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
0

LVL 3

Expert Comment

ID: 8193684
> 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.
0

Accepted Solution

modulo earned 0 total points
ID: 10315185
PAQed - no points refunded (of 50)

modulo
Community Support Moderator
0

## Featured Post

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Check out the latest tech news, community articles, and expert highlights in August's newsletter.
Hey fellow admins! This time, I have a little fairy tale for you. As many tales do, it starts boring and then gets pretty gory. I hope you like it. TL;DR: It is about an important security matter, you should read it if you run or administer Windows …
Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
###### Suggested Courses
Course of the Month11 days, left to enroll