current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 5 down vote favorite
3

This is my best effort at converting a 32 bit integer in EAX, to an 8 character ascii string (result in RDI). It will work accurately up to 99,999,999. Higher values could be done using an xmm register. The byte order in RDI is correct (e.g. if copied directly to video ram, the most significant byte is displayed first) No expensive DIV instructions or memory accesses required. Can this be improved further?

    mov ebx, 0xCCCCCCCD             
    xor rdi, rdi
.loop:
    mov ecx, eax                    ; save original number

    mul ebx                         ; divide by 10 using agner fog's 'magic number'
    shr edx, 3                      ;

    mov eax, edx                    ; store it back into eax

    lea edx, [edx*4 + edx]          ; multiply by 10
    lea edx, [edx*2 - '0']          ; and ascii it
    sub ecx, edx                    ; subtract from original number to get remainder

    shl rdi, 8                      ; shift in to least significant byte
    or rdi, rcx                     ;

    test eax, eax
    jnz .loop
share|improve this question
    
What constitutes an "improvement?" Smaller code? Faster code? Error checking? I can make it smaller by using div, faster (on my hw) by moving things around, and checking for overflow would be trivial. There are some comments that could be improved too. – David Wohlferd Sep 30 '16 at 10:32
1  
Faster is the criteria. – poby Sep 30 '16 at 12:20
up vote 3 down vote accepted

There are all sorts of things that LOOK like they should perform better, but I can only get a tiny bit of improvement. And that may disappear (or worsen) on other hardware:

    mov ebx, 0xCCCCCCCD             
    xor rdi, rdi

.loop:
    mov ecx, eax                    ; save original number

    mul ebx                         ; divide by 10 using agner fog's 'magic number'
    shr edx, 3                      ;

    mov eax, edx                    ; store quotient for next loop

    lea edx, [edx*4 + edx]          ; multiply by 10
    shl rdi, 8                      ; make room for byte
    lea edx, [edx*2 - '0']          ; finish *10 and convert to ascii
    sub ecx, edx                    ; subtract from original number to get remainder

    lea rdi, [rdi + rcx]            ; store next byte

    test eax, eax
    jnz .loop

The 2 changes are:

  • Move shl rdi to a 'better' place
  • Use lea instead of or to set rdi
share|improve this answer
    
I understand moving the shl rdi but how is lea faster than or? – poby Sep 30 '16 at 23:35
2  
Strictly speaking, the answer is "I don't know why it's faster, I just tried it and it works." or (presumably) uses a different pipeline, or has different dependencies than lea. Given the "out-of-order" execution of today's processors, it's hard for mere mortals to understand how anything works anymore. That's (one reason) why most people use higher level languages. The people who write the compiler's optimizers understand this crap so the rest of us don't have to. The days when you could just dash off a few lines of asm that performed better then the C output are long gone. – David Wohlferd Oct 1 '16 at 1:08
1  
Why use lea here at all? Why not just add rdi, rcx? Also, xor rdi, rdi should be xor edi, edi since that will implicitly clear the upper 32 bits but is shorter because it doesn't require the REX prefix. – Cody Gray Jan 2 at 15:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.