Problem with number printing function

[makuc9]

so I have written a function to write a number higher than 9 to the screen. But as soon as I push a value to the stack, I can't print anything using BIOS interrupt until the stack is empty again. Is there a way to go around this?

Here is the code:

Code: Select all

print_int:          ; Breaks number in ax register to print it
    mov cx, 10
    mov bx, 0
    break_num_to_pics:
        cmp ax, 0
        je print_all_pics
        div cx
        push dx
        inc bx
        jmp break_num_to_pics
    print_all_pics:
        cmp bx, 0       ; tests if bx is already null
        je f_end
        pop ax
        add ax, 30h
        call print_char
        dec bx
        jmp print_all_pics

print_char:             ; Function to print single character to      screen
        mov ah, 0eh     ; Prepare registers to print the character
        int 10h         ; Call BIOS interrupt
        ret

f_end:              ; Return back upon function completion
    ret

If I disable the loop (remove "push" and "pop" functions, everything concerned with bx stack size tracking and the final print_all_pics loop, I can successfully print the first number (example. I try printing 9573, I can successfully print 9) or everything in reverse order (well, this would also do the trick, but I'd still like to know what I am doing wrong, for learning purposes).

Any help appreciated.
Sincerely.

[TightCoderEx]

Before each division, clear contents of DX.

Code: Select all

    break_num_to_pics:
        cmp ax, 0
        je print_all_pics

        XOR DX, DX

        idiv cx
        push dx
        inc bx
        jmp break_num_to_pics

[egos]

I see that 0 isn't number for you.

And, makuc9, it's asm so you should optimize your code by hand. For example:

Code: Select all

  mov bx,10
  xor cx,cx
@@:
  xor dx,dx
  div bx
  inc cx
  push dx
  and ax,ax
  jnz short @b
@@:
  pop ax
  add al,"0"
  call putchar
  loop @b
  ret

[makuc9]

I see that 0 isn't number for you.

And, makuc9, it's asm so you should optimize your code by hand. For example:

Code: Select all

  mov bx,10
  xor cx,cx
@@:
  xor dx,dx
  div bx
  inc cx
  push dx
  and ax,ax
  jnz short @b
@@:
  pop ax
  add al,"0"
  call putchar
  loop @b
  ret

One question, where is the @b? (i think you've made a typo...) Thanks for all your help. Will test it all out soon.

[Combuster]

It's a label shorthand, meaning the preceding label (jmp @b/@f = jump to the first @ found backward/forward in the code), but it's not present in all assemblers - actually I can guess the exact assembler he wrote it for.

[makuc9]

Thanks for explaination, Combuster.
This function is needed for temporary preview (in case i will need it) of calculated values, and I am not sure yet I will keep it in completed bootloader, so I did not really paid much attention to optimazing it ... But thanks anyway. I will be testing it out and studying its structure.

[makuc9]

Hello, for my late reply, but I've been working on some other parts of my bootloader and I have run out of 512b limit (I did managed to get rid of some useless data to get within the limit again) but than I remembered the updated integer printing function from egos. I copied it and compiled it. NASM however, complains about '@@' symbol being repeated. For which compiler did you made this function for? (I did solved the problem by renaiming them to '@a' and '@b', but I'd still want to know if there is something similar for NASM, since it would be useful).

[Combuster]

NASM ... compiler

assemblers aren't compilers

NASM and their kin have the local label shorthand: start a label or reference to one with a . and the assembler will prepend the last label without a leading period to create the complete name. Just having @f and @b yields the problem that you still need to explicitly name labels globally unique whenever you nest a loop in another, whereas NASM's naming convention makes that process relatively painless.

[makuc9]

Ah, just a typo. I've read that a lot of times already, so I know. I just wasn't thinking enough about it at the time of posting reply...
Sorry, but thanks for correcting me.

And thanks for explanation. Will have to play a bit with this, than.