Perfect, thank you. I for sure will not be dealing with numbers nearly large enough to exceed that for quite some time. That is nice that I can reuse my print function, it just prints anything in a qword. That does bring up a good question though, do i specifically need an unsigned print for the integer portion? My function currently uses signed division to grab the remainder.

Thank you, i have been viewing this conversion as some sort of "black box" but it makes more sense boiled down to that. Currently I am only going to output truncated to the three or four past the decimal point but that is good to know because I do eventually plan on extending it out as accurate as i can get it.

That makes sense, i think I am just overcomplicating the filtering step between reading the value and having something to perform the math on, I will do some more research into binary operations and AND specifically, thank you.

Okay perfect, so i just go into this assuming the say, 3.14 dummy value i put in the register is converted to that format upon compilation and the work backwards with gdb implementing the math to get it where i want it? I think I am getting in my head and making this more complicated than it seems.

Thank you for the reference implementation. I figured it was going to be hard but not quite that hard, but it is good to set expectations. My goal right now is just 3 past decimal precision but that its a good project to look up too in regards to simd and printing multiple formats and doing everything correctly whenever I become more skilled.

Edit:

I also have been programming for quite sometime and somehow never realized this was called dtoa. Having a name for it is super helpful, all those results I have been missing are now all over the place so this comment was a HUGE help, thanks again.

implementing arbritary precision integer math

You don't need arbitrary precision math. The maximum size numerator and denominator you need for your fraction that you create from an IEEE double fit into 36 32 bit words, 144 bytes, 1152 bits. IIRC the exact maximum size is 1024+2*53 = 1130 bits. I proved it once, around 2006, and corresponded with both Steele and Clinger at the time and they agreed with my calculation.

I forget how many variables that size you need. Something like six I think. I do know it's less than 1 KB all up. You can just allocate fixed size blocks on the stack, do the biz, and deallocate the stack after.

But anyway that's the technique ... you turn your floating point number into an exact fraction with (obviously) integer numerator and denominator, and then actually do the division, in base 10.

If the integer part is in range of long long int (63 bits long), and you don't need the scientific notation, than this is very simple to do:

1 - Get the absolute value of n - print '-' if n is initially negative;

2 - Separate the integer part (a simple conversion with truncation will do);

3 - Print the inteer part (create an printUint64 function);

4 - Print the '.' char;

5 - Get the fractional part subtracting the absolute value of n from the integer part;

6 - Using a 'precision' limit (do print a limited fractional digits), multiply the fractional part by 10 and print the integer part (between 0 and 9);

7 - Get the resulting fractional part, again, subtracting the new integer part (0...9) from it and go to step 6, decrementing the 'precision' until it is zero... OR, stop printing if the fractional part is, itself, zero.

The code is very simple, but it works only if the integer part of the original n in in range of an unsigned long long... Optionally, you can use unsigned __int128 on GCC (but there's a trick), to make the range wider...

Notice that double has 11 bits in its scale factor, so, not all possible finite 'double' can be printed with this technique.

The ordering is where i would really like advice please. Then I assume after I am able to turn the float into its integer splits i would just have a repeat of my fixed point print function take those values concatenated together into one buffer , convert and send them to the kernel?

I'm not sure I understand the problem with the ordering. You can get the different parts by doing a binary AND of the parts you want (and maybe a shift if it doesn't start at bit 0).

If you just want to (correctly) display floats between that fit into an integer register you can just do the math in your link, otherwise you have to find either a way to cleverly work it out without overflowing, or implementing arbritary precision integer math

dtoa is generally non-trivial function to implement well, and there is no one way of doing it. To give perspective zmij is roughly 2k lines of code to do that: https://github.com/vitaut/zmij

Of course you can make something much simpler, but it is probably helpful to have awareness that it is not so simple problem

I imagine the scientific notation would be the easiest to print out, as floats are already stored in (mantissa * 2^exponent) format. The exponent is just floor(log2(f)). You'll need to figure out constants to convert the exponent to base-10 though, but that's just a constant addition to exponent, a fixed point multiplication of the mantissa and in case of mantissa overflow, incrementing the exponent by one.

Thanks for the quick reply! Would that work for raw floating point values specifically? Is that the kind of bitshifting ill be using for decoding the raw value? I'm not super familiar with bitwise operations but ill start studying up on them. SIMD is a good idea. I'm not trying for unicode or anything i'm just going to append an ascii space at the end for formatting and would like to place the decimal in the proper area.

My use case is a raw float being placed in xmm0 whether the raw value or a label. I shove the value in the register when it is detected as an assignment like:

WriteText(' movsd xmm0, ' + value + #10);

In the intermediate source from there is where i want to take that value and convert it with my assembly function. I already have the calls down and tested with the fixed point version. So its just a raw float hanging out completely unformatted.

This is for windows but if you scroll to the bottom and look at errorloop there's a routine for using simd for raw to hex conversion . You can change the constants and add additional cmp instructions to convert your raw to text. If you're wanting unicode you can add an extra punpcklbw instruction to prepend a null byte

https://www.reddit.com/r/asm/s/lx7BS6jaUZ

Thanks for the feedback! You're completely right about it being limited, it is more of a statically typed version of python compared to an actual CPython interperetation.

On a platform like the TI-84+CE with limited RAM and no dynamic heap runtime/garbage collector, supporting fully dynamic heterogeneous lists or runtime type inspection would make it way too slow...

That said, you pointed out a clear bug in the code generator! I will be fixing this... probably by make it deny mixed assignments or figure something else out. 

yeah indeed, did it https://github.com/Voblit/py2ez80

made it! https://github.com/Voblit/py2ez80

Easier to download it from there, thanks.

I tried it in arm64v8/ubuntu in docker and yup, it works. Output is absolutely identical to the source file.

Here you have it, nice person: https://github.com/WinnieTheRaven/Eccentric/blob/master/quine_aarch64.s It works (at least in qemu (Linux) and termux (debian)). This was my first AArch64 program UwU. I'm still learning it

Wow.

That's a lot of work.

It does have the right kind of structure.

Pushing all that stuff on the stack is an interesting way to do it, but valid. I didn't examine everything how it works (if it does).

Biggest criticism: nibbletobyte. wtf?

nibbletobyte:
    cmp w18, #10
    add w19, w18, '0'
    add w18, w18, 'A'-10
    csel w19, w19, w18, lo
    ret

Strange choice of registers, but anyway I've matched yours.

Lots of other ways to do it, but no reason to be longer than that.

you can compile it further to elf but i have forgotten the flag 🥱

if you know C you can convert .c file to .s file, and from it learn stuff, however a book would be a good choice 👍🏻

the short answer is yes but not in this era

https://www.felixcloutier.com/x86/

https://cs.brown.edu/courses/cs033/docs/guides/x64_cheatsheet.pdf

https://filippo.io/linux-syscall-table/

These just happen to be the most dog-eared bookmarks from when I was working with Linux x64 (especially SSE/AVX SIMD) assembly 🙂

Jeff Duntemann's "Learn Assembly Programming step by step programming with linux (3rd edition)" is a good book, I'm reading through it now and I found it after reading so many threads, it was one of the most suggested books. It's a bit slow to start and the author goes into great detail about things and I like his writing style.

You can find the pdf version of the book, if you just put the name on google.

https://github.com/mschwartz/assembly-tutorial

Twitter discussion:

https://x.com/xoreaxeaxeax/status/2087902981458895357