Re: itoa assembly version

leon800219@xxxxxxxxx wrote:
Frank Kotler wrote:

The only thing I see (without testing it) is that you zero dx at the
*end* of your loop. What's dx on the *first* iteration? Possibly
different in "protected mode" - I assume you mean v86 mode - and real
mode? That's what first comes to mind... try moving it and see if it helps.

By *end* of your loop do you mean:
mov byte ptr ds:[si], dl
mov dx, 0

Yep. Try it like:

s0: mov dx, 0 ; or "xor dx, dx"
div bx
mov cx, ax
cmp ax, 0 ; or "test ax, ax"
jz ok
add dl, 30h
mov byte ptr ds:[si], dl
inc si
jmp short s0
...

Actually, you probably want to check for "done" after you process the last digit instead of before:

s0: mov dx, 0 ; or "xor dx, dx"
div bx
mov cx, ax
add dl, 30h
mov byte ptr ds:[si], dl
cmp ax, 0 ; or "test ax, ax"
jz ok
inc si
jmp short s0
...

Even better, if you do it "dead last"...

...
mov byte ptr ds:[si], dl
inc si
cmp ax, 0 ; or "test ax, ax"
jnz s0
ok: add di, 2
loop s

(since we no longer trash cx, we can eliminate the push/pop - both please! - of cx)

That way, you won't have to duplicate the "add dl, 30h", etc. at the "ok:" label to catch the last digit...

At the *first* iteration the dl holds the remainders.

Yeah, *after* the "div". What's dx *before* the div?

If that was
removed the divide operation will be dx:ax/bx again, I believe that's
the cause of "Divide Overflow"
If that's what you mean. But I really curious what make the program
"Divide Overflow" again?

The "div" operation is always dx:ax - the number we *want* to divide is
in ax - we need to make sure dx is zero, or we'll get false results even
if it doesn't overflow.

By rmode I mean the real DOS, and by pmode I mean WinXP

Okay. Even real dos is in v86 mode if you've got "emm386.sys" or
something similar running. That really isn't the issue. I forget what
the "usual" state of dx is on program startup. (hell, this'll only take
a minute - be right back)

Mmmm, didn't really find anything definite - according to DEBUG, dx is zero at startup in an .exe, but not in a .com... I haven't got XP to check it. That's the only thing I can think of that would cause a divide overflow exception - except actually dividing by zero, which you're not doing...

What's the advantage of moving ax to cx and then testing cx for zero,
compared to just testing ax for zero?

" jcxz ok" was also a guard against the last bit of a digit, I wish I
could compare ax against zero but I haven't learn it yet.

Ah. Very complicated:

cmp ax, 0
jz ok ; "je" is the same instruction

That's not how I'd actually do it - "cmp ax, 0" takes two bytes to store the zero - "test ax, ax" performs a "notional and" - sets flags as if "and" had been executed, but doesn't store the result anywhere. ("cmp" is a "notional subtract" - sets flags, but doesn't store the result). Either of them will set the zero-flag if ax is zero (indicating we're done).

Well, you're closing in on it. As Betov says - one time I do agree with
him - "Courage!"

Well, Thanks a lot, encouragement is really what I needed.

Yeah, there are some really frustrating issues - even worse is when you can't get the damn thing to assemble at all! But after a while, it gets better... or you get used to it...

Best,
Frank
.

Relevant Pages

  • Re: itoa assembly version
    ... mov byte ptr ds:, dl ... cmp ax, 0; or "test ax, ax" ... the cause of "Divide Overflow" ... zero at startup in an .exe, ...
    (alt.lang.asm)
  • Improving multi-compares in an inner loop
    ... MOV EAX,DWORD PTR minmax ... CMP EAX,DWORD PTR minmax ... FCOMP QWORD PTR minmax ...
    (comp.lang.asm.x86)
  • AM186 instructions
    ... I want to know the fifference between: ... - MOV Byte Ptr DS:Offset, ... - Call near ptr Sub_routine ... - Cmp byte DS:Offset, 00 ...
    (comp.lang.asm.x86)
  • Re: Fastcode UpperCase B&V 3.5.0
    ... mov byte ptr, 'a' ... cmp byte ptr, 'a' ... Jouni ...
    (borland.public.delphi.language.basm)
  • Re: newbe
    ... 1D5F:0117 803E010220 CMP BYTE PTR,20 ... 1D5F:011E 8A160102 MOV DL, ...
    (alt.lang.asm)