div 8086 nasm

1

mov dx,0

2

mov ax,64000 ; ax is set to 0xFA00

3

mov cx,10

4

mul cx ; dx:ax is set to 0x9C400 or 640000 decimal, dx is 0x0009, ax is 0xC400

5

div cx ; dx:ax is set to 0x0FA00 or 64000 decimal, dx is 0, ax is 0xFA00

its absolutely not clear "what" doesn't work, the div and mul operationa 
are working as documented

https://c9x.me/x86/html/file_module_x86_id_72.html
https://carlosrafaelgn.com.br/asm86/

It is dx:ax not ax:dx, your number is not correctly splitted in 
hight,low part, the dx value (high) comes first

this couldn't be in the result, in any way

1

0x21436587 / 0x10 = quot=ax=0x2 rem=dx=1

cppbert3 schrieb:
> this couldn't be in the result, in any way
> 0x21436587 / 0x10 = quot=ax=0x2 rem=dx=1

Typo, thanks.

1

0x21436587 / 0x10 = quot=ah=0x2 rem=dx=1

cppbert3 schrieb:
> its absolutely not clear "what" doesn't work, the div and mul operationa
> are working as documented

It just stops working (no output at all).

And what's the use of that stuff when I have to multiply first with the 
number I divide with right after? Confusion -> Inf

Btw: dosbox got an builtin debugger (not in the default release) so you 
dont need to print your results, just watch the registers change, step 
by step

https://www.vogons.org/viewtopic.php?f=32&t=7323

Booter schrieb:
> Typo, thanks.0x21436587 / 0x10 = quot=ah=0x2 rem=dx=1

What do you think is the correct result? Tip: its much much larger than 
0x2 :)

Booter schrieb:
> It just stops working (no output at all).

Because your registers are absolutely not in the value range you expect

Booter schrieb:
> And what's the use of that stuff when I have to multiply first with the
> number I divide with right after? Confusion -> Inf

Its just an small example how mul,div works - nothing more

Your dx:ax understanding is not correct, you whole "algorithm" seems to 
be crippled, partly in code and your comments, also your al,ah usage 
before int 0x10

Beside assembler code, what are you try to archive with this code block?

What is it if not

1

0x1000*dx+ax

2

------------ = ax rem dx

3

     cx

cppbert3 schrieb:
> Beside assembler code, what are you try to archive with this code block?

Actually it's a bug in my version of U/ ( ud u1 --- rem quot ) from the 
fig-FORTH Model

s is data stack, pop adds two to s and jumps to next

1

  db    0x82, "u/", 0x80  ; NF

2

  dw    $abs              ; LF

3

u_slash:

4

  dw    u_slash+2         ; CF

5

  mov   bx, [s]           ; PF

6

  mov   ax, [bx+4]

7

  mov   dx, [bx+2]

8

  div   word [bx]

9

  mov   [bx+4], dx

10

  mov   [bx+2], ax

11

  jmp   pop

and your result quotient needs to fit in ax - that seems not the case, 
so get a "Division quotient overflow"

https://stackoverflow.com/questions/53915057/overflow-in-division-in-assembly8086/53916372

cppbert3 schrieb:
> "Division quotient overflow"

Thank you allot for connecting the dots (and setting the next). :)

So it's:

1

0x10000*dx+ax

2

------------- = ax rem dx,  cx≠0 ∧ cx≥dx

3

     cx

1

mov dx, [high_dividend]

2

mov ax, [low_dividend]

3

mov cx, [divisor]

4

clc

5

cmp dx, cx

6

jnb div_error

7

div cx

8

mov [quotient], ax

9

mov [remainder], dx

10

jmp next

11

div_error:

12

...

Booter schrieb:
> cppbert3 schrieb:
>> "Division quotient overflow"
>
> Thank you allot for connecting the dots (and setting the next). :)
>
> So it's:0x10000*dx+ax
> ------------- = ax rem dx,  cx≠0 ∧ cx≥dx
>      cx
> mov dx, [high_dividend]
> mov ax, [low_dividend]
> ...

better now :)

Booter schrieb:
> What got I wrong about unsigned division in 8086 assembler?
> Why it work only for dividend high part equal zero?

Nothing. This is just the way to do it. For some "deeper" look of view 
you  have to ask Intel-Developers why you have to set dx explicitly to 
0.

Ben B. schrieb:
> You don't have to set DX to zero, you have to set it low enough, that
> the result of the division (by 16) fits in AX.

Are you Intel-Developer? But you are right. It could be sufficient, to 
set dh to 0 - but some more testing and gaming with numbers will give 
some more safety about this case ;)

rbx schrieb:
> Ben B. schrieb:
> You don't have to set DX to zero, you have to set it low enough, that
> the result of the division (by 16) fits in AX.
>
> Are you Intel-Developer? But you are right. It could be sufficient, to
> set dh to 0 - but some more testing and gaming with numbers will give
> some more safety about this case ;)

Its fully and overly well documented for at least 40 years now, 
absolutely no need to talk to intel developers or gaming with numbers