Re: binary128 implementation

On 5/24/2024 6:29 PM, MitchAlsup1 wrote:

BGB-Alt wrote:
 Don't you EVER snip useless crap off the top of your posts ??
 

In my case, BGBCC supports __int128 operations whether or not the ALUX instructions are enabled (along with _BitInt, *1).

 I am guessing that your CPU does not do 128, 256, 384 bit calculations
natively, but the compiler supports those by emitting sequences of instructions.
 

The (optional) ALUX extension does native 128-bit operations, albeit internally via pairing registers and function units across lanes.
For 256 and wider, it is necessary to fall back to 64-bit operations (unless I added a ADCX instruction or something...).
So, ALUX has:
   ADDX          Xm, Xo, Xn  //128-bit ADD
   SUBX          Xm, Xo, Xn  //128-bit SUB
   ANDX/ORX/XORX             //128-bit AND/OR/XOR
   SHADX/SHLDX   Xm, Ro, Xn  //128-bit shift
   SHADX/SHLDX  Xm, Imm, Xn  //128-bit shift
   MOVX          Xm, Xn      //128-bit MOV
   CMPEQX/CMPGTX Xm, Xn      //128-bit compare
   ...
Encodings had been reserved for 128-bit multiply, but this is not implemented as of yet. These are also a different extension, and only exist as 2R ops, but this isn't a huge loss as it is not exactly like these would be pipelined...
If the ALUX extension is not enabled in BGBCC (disabled is the default, except in the G and H profiles, *), it will fall back to using 64-bit operations to perform __int128 arithmetic, or runtime calls for other operations.
Many operations in this case will become a multi-instruction sequence.
*1: The G and H profiles are also the ones that have 128-bit pointers and assume a 96-bit address space, differing mostly in "sizeof(void *)":
   G assumes "sizeof(void *)==16", whereas H assumes 8.
In any case though, 128-bit multiply or divide will still require a runtime call (which in some cases may produce or require working with 256 bit values, which will always require runtime calls).

*1:
   _BitInt(56)  x0;  //maps to 64-bit
   _BitInt(64)  x1;  //maps to 64-bit
   _BitInt(80)  x2;  //maps to 128-bit
   _BitInt(128) x3;  //maps to 128-bit
   _BitInt(160) x4;  //maps to 256-bit
   _BitInt(256) x5;  //maps to 256-bit
   _BitInt(272) x6;  //maps to 384-bit
   ...
All sizes beyond 256 bit mapping to the next integer multiple of 128 bits. The 256-bit type is special, in that it has its own dedicated logic, but exists via the _BitInt type. For 384 and beyond, generic logic is used that deals with any size value, but is slower.

 

Can note that in my implementation, BitInt does not enforce modulo behavior in the case of overflow (it is modulo only to the size of the container; enforcing odd-bit modulo behavior would add a fair bit of cost to using them).

 The multi-precision arithmetic in My 66000 supports rather arbitrary width calculations, although only those 256-bits and smaller can be considered fast and/or efficient. In addition, both signed and unsigned multi-precision arithmetic is available.
 

In my case, these ones are done in software. Supporting fine-grain variable width would come at a performance penalty.

 

Terje
>