Numeric to hex string

[hyder]

Tony Tribelli and I have been working on some optimized algorithms that convert a numeric value to a string of hexadecimal digits. The original work for for a new book I'm working on, "The Art of ARM Assembly." However, Tony has graciously converted the ARM code to x86 code. You can find the results of his work here:
https://randallhyde.com/Forum/viewtopic.php?t=694
and
https://github.com/atribelli/hexstr

Spoiler alert: as was the case for the 64-bit ARM CPU, the 256-entry (512-byte) lookup table was the fastest version, even beating (IIRC) the SIMD version.

Cheers,
Randy Hyde

[jack]

thanks hyder 
I would love an algorithm for fast conversion of a multi-precision binary floating-point number to decimal string and vice-versa
my current method involves multiplying and dividing by a power of 10 which gets very slow at high precision, especially the string to float conversion

[jj2007]

multi-precision binary floating-point number

Something official, like REAL16? If not, how many bits of mantissa, how many for the exponent?

[jack]

jj, the mantissa is limited to 4294967295 bits and the exponent to 2147483647 bits but with my kindergarten arithmetic algorithms the operations become impossibly slow above 100000 decimal digits, 50000 digits not so bad

[NoCforMe]

I hate to throw shade on your programming efforts, but how is this something we should care about? If you're converting binary to hex, I would assume that the purpose is to display those numbers, either on a screen or perhaps in a text file. What difference could it possibly make how fast the conversion routine is, unless you're somehow logging a bazillion different numbers? Wouldn't your efforts be better spent optimizing something that could really use it?

[jj2007]

the mantissa is limited to 4294967295 bits and the exponent to 2147483647 bits

With simple QuadMath,   you can arrive at pretty high precision - 33 digits:

Code Select Expand

digits  1.23456789012345678901234567890123
Big     1.23456789012345678901234567890123      Real16 precision
PI      3.14159265358979323846264338327950      (as text)
MyPI    3.14159265358979323846264338327950      Real16 precision
FpuPI   3.141592653589793238
That is more than enough precision to shoot Voyager 3 to Andromeda's black hole, where it would arrive in a trillion years. So what is the practical (or theoretical?) relevance of 4294967295 bits of mantissa, when 112 bits are more than sufficient?

Btw there are some threads about REAL16 precision:
8/2017: GCC QuadMath library - REAL16 math
6/2018: REAL16 for statistics and Gamma function

Both have been vandalised by our dear former member nidud, but you can still get useful information from other members' posts.

[jack]

 

[NoCforMe]

I'd really like to see how one can express pi in hexadecimal ...

[jj2007]

Code Select Expand

include \masm32\include\masm32rt.inc

.data?
PI    REAL8 ?

.code
start:
  cls
  fldpi
  fstp PI
  print hex$(dword ptr PI[4])
  inkey hex$(dword ptr PI), "h"
  exit

end start
Output: 400921FB54442D18h (more)

[NoCforMe]

Brilliant. That works but it's totally meaningless.

[ttribelli]

but how is this something we should care about?

It's for a book, for people learning assembly and SIMD. Converting binary to hex string is something that just screams for parallelism and is a quite graspable example of converting an algorithm to SSE or NEON. It's literally the same algorithm as one of the regular assembly implementation.

Assembly language programming should be fun. That's why I do it.

You don't find converting an 8-byte hex values into a 17-byte zero terminated strings in about 16 assembly instructions to be fun? :-)

[NoCforMe]

Assembly language programming should be fun. That's why I do it.

You don't find converting an 8-byte hex values into a 17-byte zero terminated strings in about 16 assembly instructions to be fun? :-)

OK, well, you got me there. Never tried any of that fancy-schmancy SIMD, etc., stuff, but 16 instructions is definitely impressive.

[daydreamer]

jj, the mantissa is limited to 4294967295 bits and the exponent to 2147483647 bits but with my kindergarten arithmetic algorithms the operations become impossibly slow above 100000 decimal digits, 50000 digits not so bad

try optimization inspired by SSE RCPPS/MULPS replacing division?
FMUL 0.1 instead of fdiv 10

[daydreamer]

It's for a book, for people learning assembly and SIMD. Converting binary to hex string is something that just screams for parallelism and is a quite graspable example of converting an algorithm to SSE or NEON. It's literally the same algorithm as one of the regular assembly implementation.

I found SSE parallelise taylor series more useful as alternative to most fpu functions
fsinx4,fcosx4,even fsincosx4
 

[alCoPaUL]

there's this old computer virus that converts itself (asm code) to hexadecimal debugscript to infect batch files and i remember that converting from whatever data/numtype it begins to hexadecimal string is not that complicated..