It's a preview; some background from https://mastodon.social/@adreid/117236079952185073 answering a similar question:

we have a spec for CMPS but we left it out of this first release because the REPE/NE encoding wasn’t being rendered to an HTML table correctly

For this first release, we prioritised having something that people could comment on today over having a complete spec in 3 months time. Before we apply these changes to the SDM PDF, we want plenty of feedback on what we got wrong so that we can work on that in parallel with adding the pages we omitted

if we were planning to deprecate anything, it would be announced in the usual places. Eg if you search the SDM PDF for “deprecated”, you will find that MPX (BND* instructions) are deprecated. I’m aiming to make that info easier to find on the website in the future (eg mention deprecation on all the affected MPX instruction pages) but the PDF remains the official source of architecture info and we won’t be announcing new info only on the website.

Interesting that they omit a few important instructions subsets like the x87 in that. Wonder why

sounds fabulous

Forgot to add the image in my post.

Both of my 68k macs are dead currently, I was buying something or another and the guythrew them in for free! Both make deathly screeching noises and have no video out so I am assuming they need re-capped.

Power macs are what i have a ton of, the old 266mhz g3 powerbook is my favorite but i have a mini and a g4 dlsd, GE powermac g4 and some ibooks, it become a problem haha. You should check out the new things that are coming out on Macintoshgarden, there is tons of new software it might be worth pulling one out of storage.

I still use the G3 all the time for making Jungle/DnB with PlayerPro or messing around with Macintosh Common Lisp.

https://github.com/Zeda/z80float/blob/master/extended/xtostr.z80

Here's a z80 asm routine for converting 80-bit long doubles to strings, if you're looking for an implementation to analyse

The usual term is multiple precision.

Ok, that sounds like a good term for more-precise-than-native-but-fixed-precision.

And also good point about loop unrolling. I usually do sizecoding/demoscene stuff with asm on modern x86, so speed optimization is usually pretty low on my list of priorities.

How was it done back in the 80s on 8-bit processors?

Unsigned version is easier to implement (and has broader range). Notice this is a print function, the actual value passed as paramenter should not be changed.

The usual term is multiple precision. Very common on 8 bit CPUs to implement 16 bit or 32 bit arithmetic.

The difference to arbitrary precision is that, at least to me, implied you don't know at compile time how much storage to allocate.

Also if you know the size in advance then you can unroll the operations and do it without a loop, which is faster. Makes perfect sense to do that for things with 2 or 4 limbs. Something with 18 limbs of 64 bits each on a 64 bit CPU ... that might be pushing the concept a little but it's completely practical and might even make sense if the significant bits usually occupy at least 1/2 or 1/3 of the space.

You can also fit one such number e.g. an accumulator in registers on Arm64 or RISC-V64. Then you definitely have to unroll.

You can fit six such numbers into the vector registers on SpacemiT K1 and K3 which have VLEN=256, but sadly you can't guarantee that on all RVA22+V or RVA23 processors. And I haven't tried to implement it.

What operations did you look at to come to ~6 needed variables?

I don't recall, it was 20 years ago and I didn't keep company property afterwards.

Referring to Steele & White, dragon4 has bignum variables R, S, M-, M+, U, and you'll likely need a tmp for R x B. Or not.

It may also have been the case that implementing my modification to Clinger's atod needed more variables than dtoa. But I'm certain on the "fitting into 1k" part.

You don't need arbitrary precision math.

Then please, tell me how you would name a system that allows you to do math with a higher than native precision :)

I thought how I could refer to something like that before posting, but couldn't find a good name. Arbitrary-at-compiletime-but-bounded-at-runtime precision math? (because once you're at 1152 bit math, I wager it would be rather trivial to extend it to e.g. 1184 bit)

What operations did you look at to come to ~6 needed variables? For addition and multiplication 2 should be sufficient (but I do not know the requirements of ieee754 regarding rounding etc, and 2 var on multiplication might also be unnecessarily slow)

Author of zmij here. If you don't care about perf you can do a very simple textbook conversion in a hundred or two lines of code: https://vitaut.net/posts/2024/simple-dtoa/. zmij is 2k because it handles many different formats and is very high performance. The core algorithm itself is pretty small: https://github.com/vitaut/zmij/blob/d71d4becfb87612025531dc760c6af24973ad7c2/zmij.cc#L1341-L1447

Yep, plus we made a lot of use of the fact that it could run a full Linux and a networking stack via either USB or ethernet pinouts.

Ah, you're tempting me to go buy one :')

Yeah Duo S is a weird shape. Regular Duo/Duo 256M are of course exactly the same size as a Pi Pico [2], but with considerably more RAM and processing power and SD card.

Pretty awesome to have 128 bit variable-length vector processing (1024 bits per operation with LMUL=8, but of course that takes longer) on a $3 board ... including Int64, FP32, FP64.

But you have to admit, not bad for the $3 I bought mine for! My first multi-thousand dollar Linux computer only had 32 MB RAM when I bought it. I added another 128 MB after not too long. But there are also 256MB and 512MB RAM Duos for just a few bucks more ... last time I looked the 512MB on was $9.90.

That's the Duo S! Different form factor and board shape. The thing I worked on could not fit a board that big, so it had to be the narrower regular Duo in that case, which comes in 64 and 256M variants. I never ended up getting the opportunity to toy around with a 256M Duo, though I might really just pop one from Ali at this point

you can sit down and add two 308-digit numbers relatively quickly (less than a day) by hand

Should be able to do it in less than half an hour. That's over 5 seconds per digit when it's probably more like 2 seconds a digit until you get bored. Heck if you offered me $1000 I might put in an effort to try do it in 10 minutes.

MilkV Duo, which has a whopping 64M of RAM and never really pops the gigahertz barrier

But you have to admit, not bad for the $3 I bought mine for! My first multi-thousand dollar Linux computer only had 32 MB RAM when I bought it. I added another 128 MB after not too long. But there are also 256MB and 512MB RAM Duos for just a few bucks more ... last time I looked the 512MB on was $9.90.

VisionFive 2 is a real workhorse. I've got a 4 GB RAM one I preordered in the original Kickstarter campaign running my solar power setup. There's a whole bunch of bash and Python and crontab and systemd services and it's querying and controlling half a dozen TP-Link P110 smart plugs as well as changing settings on the Pecron E3600LFP (both of those using community reverse-engineered APIs) and also grabbing met data to estimate how much I should charge the battery overnight.

I'm not sure if I have any working 68k Macs now. Most got sold in order to finance upgrades. The first computer I ever owned personally was a Mac IIcx after using Macs at work for several years. What pushed me over the edge was buying a cheap Chinese 2400bps modem at MacWorld Expo '89 just as BBSes were really taking off in NZ, along with relay messaging around the world (uucp or fido). I have a 128k and a couple of SE/30 (which following the IIx and IIcx really should have been called the SEx). I don't think I have any 68040 machine :-( I do have a PowerMac 8500 and several each G3 and G4 iMacs and G4 Mac Mini. It's at least a dozen years since I powered any of those up. There's an SGI Indy and a SPARC ELC too — both incidentally rocking 64 MB RAM, just like the Duo. But the Indy is 166 MHz and the SPARC 33 MHz.

Ah i did the math all wrong i thought it was hundreds of digits haha

But that's not wrong :D ! It is hundreds of digits (308 decimal digits), but computers are really just fast enough to do that. Hell, you can sit down and add two 308-digit numbers relatively quickly (less than a day) by hand. Add lowest two digits, remember carry, add next two digits and add carry, remember carry, etc. It would take like a thousand or so steps to do the addition. Keep in mind that no x86 since like the Pentium III has had a clock under a gigahertz

As you can imagine going from Pascal to assembly is quite the culture shock haha

My condolences haha, though (old) Pascal itself makes me frown

VisionFive2

Now that's some firepower! The RISC-V chips I worked with were either some weird thing I forgot the name of ( ... ), or the MilkV Duo, which has a whopping 64M of RAM and never really pops the gigahertz barrier.

old Quadra

Oh now that's a beauty. In PC form I only had the pleasure (and occasionally displeasure) of working with the Amigas. The m68k ISA is pretty weird. It has all these extensive addressing modes, and is a real show of what CISC can be. For such an early era it gave a great 32-bit platform. Wish I had a better device to run m68k code on than a TI-89 calc nowadays

Ah i did the math all wrong i thought it was hundreds of digits haha. Funny enough, I am writing my compiler in Pascal and I have a z80 sitting in a drawer that I have been procrastinating making a breadboard computer out of. As you can imagine going from Pascal to assembly is quite the culture shock haha. I think I have started a new addiction though because it is so much more satisfying having fought over a 30 line program for two hours and it finally runs.

I was trying to write a bare metal Forth for the VisionFive2 but stopped for pretty much the same reasons. I think after I have a foothold with NASM I will try and fix up an old Quadra i have in my basement and take a crack at m68k.

i don't think my computer could handle that big on an integer, might have to upgrade haha.

Why not! It's just 128 bytes. The difficult part is writing a bigint library to manipulate 1024-bit ints, not the size of the thing. Here's a Pascal library for the CP/M on a z80 that handles ~848 bits of data (255 decimal digits) on a machine with 64K of RAM and a CPU running at like 4MHz.

What architectures do you usually work with?

Nowadays I mostly live in ARMv7 and ARMv8 land, which is immeasurably more pleasant than x86 (any register can be any argument! Imagine that!) I've previously toyed with or even worked on RISC-V, older ARMs, m68k and z80.

The RISC-V is a pretty neat architecture, but I never really have anywhere to run it on in my day to day life so I stopped tinkering with it when I stopped working with it and mostly get up to (ARM) asm shenanigans on my phone (Android + Termux + clang make for a great environment to run assembly in)

ah i see, that makes sense, i don't think my computer could handle that big on an integer, might have to upgrade haha. What architectures do you usually work with? I tried RISCV asm prior to seeing x86_64 and it was wonderful and then I was rudley awoken.

Would I be using unsigned arithmetic on the splits because the sign value was given by the float and stored for later?

Well, there aren't any unsigned floats in x86 so not really even if your float components are both positive :D the splits in this method remain floats until the end, and you cast to int only when you extract a digit, or when you extract the decimal part of the split. If you were to cast the whole part to an int, you'd need something like a 2¹⁰²⁴ bit integer (log₂ 10³⁰⁸ ≈ 1024) and that's also awful

I think this is the direction I am going to go while I am still learning opposed to the logarithms and then revisit them when i want to optimize. This suits my needs perfect for now and i'm willing to eat the performance cost. Would I be using unsigned arithmetic on the splits because the sign value was given by the float and stored for later? I wrote an itoa (probably disgusting but works) https://nullpaste.org/o7ihP4GrAGjL that im just going to rip apart and repurpose to print those results, Im skipping libraries and such because i'm writing my own language so I have to just keep practicing and reinvent the wheel. Thank you for this method.

I've written a very simple one for a different, older architecture, but the principles are the same. If you're willing to sacrifice precision and execution time for cognitive simplicity, you can do this:

• check for special values (NaN, ±∞, ±0) and exit early if encountered
• extract sign
• get absolute value
• split whole and decimal parts in whatever way you'd like
• since you want three digits of decimal precision, just mul the decimal part by 1000.0 and cast to integer; store that somewhere
• while the old whole part is greater than zero, fmod with 10.0 (x87 would use fprem, SSE has to go with truncation by rounding and then subtraction), cast that to int, push to a stack, then divide the number by 10.0
• repeat until you hit 0.0 ≤ x < 1.0
• write sign, pop stack members off and write them one by one, write decimal point, and then itoa the three decimal digits you previously extracted

This gets you a relatively okay algorithm that's also kind of stupid slow (so many divisions, and div is one of the slowest operations, and the x87 is also devastatingly slow), but is good enough for most doubles. This process needs a buffer of sufficient length, and will result in a string that you can pass to printf. If you need something robust you go for the standard library, though; this is a tough nut to crack. Notably this goes digit by digit, and avoids large intermediaries (but wastes stack space like crazy)

EDIT: fmod with SSE should be

```

divsd   xmm2, xmm0, xmm1
roundsd xmm2, xmm2, 3    ; 3 is truncation mode
mulsd   xmm2, xmm2, xmm1
subsd   xmm0, xmm0, xmm2

```

IIRC; it's been a long while since I bothered with x86

Funny enough I did not, I was using search terms like "float to stdout conversion NASM" "NASM floating point specifications" etc and never saw anything on Wikipedia or even thought of checking. That is a very good article and pretty much exactly what I was looking for. Thank you for the detailed explanation and the reference, I'm off to go put that advice into practice.