gBcd -> gBcdVal
?

You have a lot of global vars. Does we need all of them? And can we declare all of necessary vars in one place?

Wondering if the baseline amount of static memory can be reduced here by computing the parts of it that aren't strictly necessary to have as LUTs?

Looks like post-process stage. Can we optimize this and do in-place on main processing stage?

ftoa & dtoa already have hint about type so simplify names to:

ftoa_buffered and dtoa_buffered

Plz move all constans and lut tables on top

What 70 meaning here? Can you make local const with meaningful name or comment?

Also as I mentioned we can remove gBcdLen and return it as laocal var from here function and leave only gBcd for glob var.

mulhi64 -> umul64hi

umul64hiCarry(a: u64, b: u64, carry: u64): u64

This also reduce one global var. Also do the same for the rest similar functions which store low u64 part in glob instead return it

These two functions are too small and trivial. Inline into call sites and remove them

It's ASCII -> UTF16. It can be more efficient. It's typical interleave with zero idiom:

Also putBlock8 is not perfect name. I guess better use writeUnpacked8 or writeDeinterleved64toUtf16 or something like this

We have CharCode enum for such char literals

import { CharCode } from "./string";

What if we inline this function on all 3 call sites? Does this allow us to eliminate or reduce the number of such glob vars? It really bothers me that there are so many of glob vars even though most of them could be stored locally and passed as arguments. Also at least one could be returned from the function. And use extra glob vars as fallback apprach when we need to return a multi-value

How about invert sign for powExp at first place then is will be much more optimal:

Also I recommend ((dotOne >> 54) * 5) and ((dotOne >> (53 - h)) * 5) move out from expr as locals

Also I found a bug. It should be:

  gBcdLen = <i32>((70 - clz<u64>((singles << 1) | 1)) / 8);