Question

I keep reading that in order for one to perform integer/floating point division on a register, the register(s) being performed on need to actually be initialized. I’m curious to what the proper assembler directive is to do this. Do I simply provide an address by something like:

mov ecx, 0x65F ;0x65F represents an address for ecx to point to.

And then promptly (later in code) do something like:

mov byte [ecx], 0xA ;move the value of 0xA into the contents of ecx, using only a byte's worth of data

Is this the proper way to perform such an operation? If not, what is?

Update

Ok, so what I’m trying to do is basically multiply two values and print them to the screen.
The code is as follows, and for some reason every time I try to divide edx I get either a segmentation fault or a floating point arithmatic exception. Could someone explain to me what it is that I’m doing wrong?

Code

section .data
    counter: db 0xA                         ;store value 10 in 'counter', while allocating only one byte. This will be used for decrementing purposes
section .bss
    valueToPrint: resb 4                    ;alloc 4 bytes of data in 'valueToPrint'

section .text

global _start

_print_char:                    
    add eax, '0'                ;convert to ascii
    mov [valueToPrint], eax     ;store contents of 'eax' in valueToPrint
    mov eax, 4                  ;syswrite
    mov ebx, 1                  ;stdout
    mov ecx, valueToPrint       ;machine will take whatever value exists in 'ecx' and print
    mov edx, 1                  ;print only a single byte's worth of data
    int 0x80                    ;invoke kernel to perfrom instruction
    ret                         

_convert_values:
    mov edx, 0xA                ;dividing eax by 10, which will lower its tens place
    div edx                     ;(**Program crash here**)do division: remainder SHOULD be stored in edx
    mov byte [edx], 0x0         ;zero out edx       
    call _print_char            ;do printing for latest character
    dec byte [counter]          ;decrement counter
    mov dword [eax], counter    ;store counter in eax
    jnz _convert_values         ;while eax > 0 continue process

_endl:
    mov eax, '\n'               ;store newline character in eax to be printed
    call _print_char            ;print value
    ret                 

_mul:
    mov eax, 0x2A ;store 42 in eax
    mov edx, 0x2B ;store 43 in edx
    mul edx       ;multiply [eax] * [edx]
    ret

_safe_exit:
    mov eax, 1  ;initiate 'exit' syscall
    mov ebx, 0  ;exit with error code 0
    int 0x80    ;invoke kernel to do its bidding 

_start:
    nop                             ;used to keep gdb from complaining

    call _mul                       ;multiply the values
    call _convert_values            ;do hex to ascii conversion

    jmp _safe_exit                  ;use jmp as opposed to call since it technically doesn't 'ret'

Answer 1

We spoke separately in chat….

Here’s a working version to play with.

It has a subtle problem. Can you find it?
Can you explain WHY it does what it does?

; Multiply two numbers, display in ascii/decimal
;
; (because I have a 64bit system, this forces 32bit code)
        bits    32
;
        section .text
;
; _start is the ONLY label you MUST prepend _
; others might be library functions (ex: _printf,_exit)
; pure assembly only needs _start, if linked with glibc
; typically need _main INSTEAD of _start
;
        global _start
;
;
_start:
        nop                             ;placeholder for gdb's debug interrupt
;
        call    mul                     ;multiply the values
        call    convert_values          ;do hex to ascii conversion
;
        jmp     safe_exit               ;use jmp as opposed to call since it technically doesn't 'ret'
;
;
; subroutines / functions follow
;
mul:
        mov     eax, 0x2A               ;store 42 in eax
        mov     edx, 0x2B               ;store 43 in edx (42*43=1806)
        mul     edx                     ;multiply eax*edx, result in edx:eax
        ret
;
; this routine doesn't handle BIG values from 'mul' which extend into edx
; we're learning, don't make things multiply out to more than 4.2 billion-ish
convert_values:
        mov     edx,0                   ;value actually edx:eax, zero edx
        mov     ecx,0x0A                ;divide edx:eax by 10
        idiv    ecx                     ;result in eax, remainder in edx
        push    eax                     ;save value on stack
        mov     eax,edx                 ;put remainder (0-9) in eax
        add     eax,'0'                 ;convert value to ascii character
        call    print_char              ;print the latest character
        pop     eax                     ;restore value
        or      eax,eax                 ;set flags based on eax value
        jnz     convert_values          ;while eax != 0 continue process
;
; nasm doesn't convert \n into LF... just use 10, equivalent
endl:
        mov     eax, 10                 ;store newline character in eax to be printed
        call    print_char              ;print value
        ret
;
print_char:
        mov     [valueToPrint], eax     ;store contents of 'eax' in [valueToPrint]
        mov     eax, 4                  ;syswrite
        mov     ebx, 1                  ;stdout
        mov     ecx, valueToPrint       ;machine will take whatever value exists in [ecx] and print
        mov     edx, 1                  ;print only a single byte's worth of data
        int     0x80                    ;invoke kernel to perfrom instruction
        ret
;
safe_exit:
        mov     eax,1                   ;initiate 'exit' syscall
        mov     ebx,0                   ;exit with error code 0
        int     0x80                    ;invoke kernel to do its bidding
;
; =====================================
        section .bss
; this section is not allocated, just reserved.
; Automatically set to zero when program starts
;
; alloc 4 bytes of data in 'valueToPrint'
valueToPrint:
        resd    1               ; 1 resd=4 resb (Dword/Byte)
;
;

Spoiler Alert…

It prints the result BACKWARDS!
To fix this, we’ll have to redesign how the digits are obtained
and stored before printing.

I’m emailing this directly to you, along with some additional notes.