0

I'm trying to implement this type but I cant seem to find any documentation on it.

The binary-256 format reserves 236 bits for the mantissa and the remaining 20 for the sign & exponent. IEEE-754 BCD formats, on the other hand, use the two bits after the sign as flags to interpret the high bits of the mantissa. If we use DPD packing, then the lower 230 bits contain 69 BCD digits and my guess is that the other 6 bits would have to contain two, but how?

A DPD decimal-256 is laid out as follows:

    0..229      23 decets of 3 BCD digits each
    230..252    "combination" field containing exponent and hi bits of the
                mantissa

    253..254    2 bits following sign that are used as flags to interpret 
                the following 23 bits and/or as part of the value thereof.

    255         sign

My question is: how should I interpret the "combination" field mentioned above?

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • 2
    Your question ("but how?") is not very clear. Please expand on the problem you are experiencing with all applicable detail. – Lightness Races in Orbit Nov 17 '19 at 15:44
  • thx. the ? has been edited to add more info. –  Nov 17 '19 at 16:20
  • Please put as much effort into your question as possible. It is surely not necessary to abbreviate "question" to "?". You are asking for our free time! – Lightness Races in Orbit Nov 17 '19 at 16:32
  • 1
    Do you already know how the decimal64 type works? If so, decimal256 is completely analogous. If not, I'd suggest looking into decimal64 first. BTW, all of bits 230 through 254 form the "combination field". – Mark Dickinson Nov 17 '19 at 16:38
  • It's not clear what you mean by "the other 6 bits". Where are you getting that "6" from? Did you mean "the other 26 bits"? – Mark Dickinson Nov 17 '19 at 17:17
  • "the other 6 bits" are 230..235. binary256 simply incorporates these into the mantissa while in decimal 256 they are combined w/ the other 19 higher bits to derive the exponent and the hi bits of the mantissa. and although all the different widths are analogous, they have different remainders (the remainder being the start of the exponent in the binary of the same width modulo 10 (since BCD digits are packed 3 in 10 bits), 4xmpl in decimal128 the remainder is 2 (bits 110..111) and in decimal256 its 6 (230..235), hence "the other 6 bits"). –  Nov 17 '19 at 18:43
  • and when different widths have different amounts of spare bits to squeeze more digits out of, then i would guess that would have to be done differently for any given amount of spare bits. in this case since theres 6 they will prolly try to force two extra digits into them. –  Nov 17 '19 at 18:53
  • If your aim is to understand the decimal256 type, information about the binary256 type isn't helpful: that's a different format with a different bit layout and a different mechanism for interpreting the bits. For decimal64, there's no reason to separate out the 6 bits 230 through 235 from the other bits 236 through 254 of the combination field: there's just one combination field of width 25 bits. The wikipedia page on the decimal64 type explains how this field is interpreted in the 64-bit case, and it should be straightforward to extend that explanation to the 256-bit case. – Mark Dickinson Nov 17 '19 at 19:19
  • Having said all that, if you're implementing the type it would probably make sense to get hold of the standard itself, if you can. – Mark Dickinson Nov 17 '19 at 19:22
  • i think i get it, but i have one final question, that being why theres only 17 expo bits available when only the top 6 of the 26 hi bits are reserved? –  Nov 17 '19 at 20:48
  • 1
    For decimal encoding of a finite value, bit 255 is the sign bit, bits 250 through 254 encode two exponent bits (but only allowing values 0, 1, or 2 for those bits) along with the most significant decimal digit of the significand. Bits 230 through 249 are the remaining 20 exponent bits, and bits 0 through 229 are the trailing significand bits (230 bits = `3*23` = 69 decimal digits using DPD). That gives a total of 70 decimal digits for the significand and a range of `3*2**20` different values for the exponent (emax = `3*2**19`, emin = `1 - 3*2**19`). I don't know where you got the "17" from. – Mark Dickinson Nov 17 '19 at 21:30

0 Answers0