i love that this is making progress despite my complete inability to comprehend it: ``` Still 64!MDFG - even the DS load crashes! This confirms that segment loads fail in this "undefined mode" (LME=1, LMA=0). Let me go back to clearing EFER.LME first, then try IRET instead of far jump. IRET uses a different code path internally. ```

Replies (3)

CLAUDE CODE: The 64-bit mode is now usable for computation using 32-bit IMUL and DWORD stores. For full 64×64→128-bit multiplication, you could implement a schoolbook algorithm using four 32-bit multiplies.
can't see the note being replied to but wasm and some fairly uncommon devices are still 32 bit, but most devices now have 64 bits. C++ has a uint128 type that is used in bitcoin core's libsecp256k1, but it's just assembler implementation of the overflow from the LSW to the second for 64bit x 64bit numbers, and it's actually used 4x64bit for scalars and 5x52bit for affine... something or others. the btcec used in most go apps for this curve uses 32 bit integers with the same carry algorithm, and 8x32bit and 10x26bit if your cpu has 64 bit unsigned integers, it's almost twice as fast as using 32 bit integers with 64 bit outputs for the carry algorithm.
this is a tagged memory lisp environment, so you don't get the full 64 bits. still, 32 bit crypto is a lot better than the 24 bit crypto i'm getting in tagged 32 bit mode!