Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

3-byte floating point code?

865 views
Skip to first unread message

Adam Davis

unread,
Nov 12, 1998, 3:00:00 AM11/12/98
to
I've been given code which was written for the z80 processor.
Actually, I need to decipher the three byte floating point encoding.

It is supposed to be in the form
byte 1 exponent xyzzzzzz
byte 2 mantissa zzzzzzzz
byte 3 mantissa zzzzzzzz

Where
x is mantissa sign(0 is positive)
y is exponent sign(1 is positive)

And I've been given the following values:
Decimal Hex1 Hex2 Hex3
1800 00 e1 4b
900 a0 8c 4e
1 00 80 41
2 00 80 42
4 00 80 43
10 00 a0 44
20 00 a0 45

I see a pattern, but I still can't get it. It does not seem to directly
convert to decimal, or BCD.
If anyone has any insights as to which newsgroup this question would be
best answered, please tell me. If you have any clues, I'd appreciate
them!

Thanks!

-M. Adam Davis
ada...@baladyne.com

Don Yuniskis

unread,
Nov 12, 1998, 3:00:00 AM11/12/98
to
Adam Davis <ada...@baladyne.com> wrote:
> I've been given code which was written for the z80 processor.
> Actually, I need to decipher the three byte floating point encoding.

> It is supposed to be in the form
> byte 1 exponent xyzzzzzz
> byte 2 mantissa zzzzzzzz
> byte 3 mantissa zzzzzzzz

> Where
> x is mantissa sign(0 is positive)
> y is exponent sign(1 is positive)

> And I've been given the following values:
> Decimal Hex1 Hex2 Hex3
> 1800 00 e1 4b
> 900 a0 8c 4e
> 1 00 80 41
> 2 00 80 42
> 4 00 80 43
> 10 00 a0 44
> 20 00 a0 45

THe exponent appears to be the third of these numbers. It is stored
in an "offset 0x40" format -- i.e. 0x41 = "1".

I'm guessing (haven't looked at the values in detail) that the
second and first bytes form a 16 bit "mantissa" with byte 2 being the
more significant. This appears to be encoded as .XXXXXXXX XXXXXXXX
So, 0x8000 is really "1/2". Or, 0x80000 with 0x41 (i.e. the third
example above) is really "1/2 * 2^1" = 1 (OhMiGosh!)

Likewise, "0xA000 0x44" (the sixth example) is "5/8 * 2^4" = 10

I suspect the MSB of the third byte is the sign of the *value*
(e.g., changing the 0x44 to a 0xC4 in this most recent example
would change the *value* to "-10").

Note that the "sign" of the exponent is determined by noting
the value of the third byte wrt the "offset" of 0x40 -- values
greater than 0x40 have a positive exponent while those less than
40 have a negative exponent (e.g., the value 0x3F corresponds to
an exponent of -1)

You'll have to look to see how zero is represented in this encoding (!)

HTH,
--don

Mike Albaugh

unread,
Nov 12, 1998, 3:00:00 AM11/12/98
to
Adam Davis (ada...@baladyne.com) wrote:
: I've been given code which was written for the z80 processor.
: Actually, I need to decipher the three byte floating point encoding.

: It is supposed to be in the form
: byte 1 exponent xyzzzzzz
: byte 2 mantissa zzzzzzzz
: byte 3 mantissa zzzzzzzz

: Where
: x is mantissa sign(0 is positive)
: y is exponent sign(1 is positive)

: And I've been given the following values:
: Decimal Hex1 Hex2 Hex3
: 1800 00 e1 4b
: 900 a0 8c 4e
: 1 00 80 41
: 2 00 80 42
: 4 00 80 43
: 10 00 a0 44
: 20 00 a0 45

: I see a pattern, but I still can't get it. It does not seem to directly


: convert to decimal, or BCD.
: If anyone has any insights as to which newsgroup this question would be
: best answered, please tell me. If you have any clues, I'd appreciate
: them!

comp.arch.arithmetic, or some CP/M group might help. In any
case, I think you have the order of the bytes wrong. I suspect that
what you are calling "Hex3" is what you are also calling "Byte 1".
Note that all your numbers are positive, and have positive exponents.
Often, in F.P. exponents are "biased" rather than signed, and IMHO
that is what you have here, with a bias of 0x40 (64), and the mantissa
is in the range 0..1 (that is, the binary point is immediately to
the left of the MSB) So we have:

: Decimal Hex1 Hex2 Hex3
: 1800 00 e1 4b 0.E100 * (2^11) = (57600 >> 5) = 1800
: 900 a0 8c 4e 0.8ca0 * (2^14) = (36000 >> 2) = 9000
(Are you sure that wasn't a typo?)
: 1 00 80 41 0.8000 * (2^1) = (32768 >> 15) = 1
: 2 00 80 42 0.8000 * (2^2) = (32768 >> 14) = 2
: 4 00 80 43 0.8000 * (2^3) = (32768 >> 13) = 4
: 10 00 a0 44 0.A000 * (2^4) = (40960 >> 12) = 10
: 20 00 a0 45 0.A000 * (2^5) = (40960 >> 11) = 20

Does this look familiar to anybody?

Mike
| alb...@agames.com, speaking only for myself

Spehro Pefhany

unread,
Nov 12, 1998, 3:00:00 AM11/12/98
to
the renowned Adam Davis <ada...@baladyne.com> wrote:
> I've been given code which was written for the z80 processor.
> Actually, I need to decipher the three byte floating point encoding.

> It is supposed to be in the form
> byte 1 exponent xyzzzzzz
> byte 2 mantissa zzzzzzzz
> byte 3 mantissa zzzzzzzz

> Where
> x is mantissa sign(0 is positive)
> y is exponent sign(1 is positive)

> And I've been given the following values:
> Decimal Hex1 Hex2 Hex3
> 1800 00 e1 4b
> 900 a0 8c 4e
> 1 00 80 41
> 2 00 80 42
> 4 00 80 43
> 10 00 a0 44
> 20 00 a0 45

i) Hex 3 is byte 1 (bit 7 appears to be 0 for +ve mantissa, but there
are no examples of negative numbers), there is not enough
information to confirm how numbers less than 1 are handled 8-(
As someone else mentioned, the exponent could well be a biased
number, so 00 80 40 is 0.5, 00 80 3F is 0.25, and so on.

ii) Hex 1 is the ms byte of the mantissa. Note that bit7 appears to be
wasted (always 1). Any number with non-zero bit 7 would presumably
not be normalized. And, as someone else mentioned, zero might be
represented as 00 00 41 or something else. Since this system allows
-0 (possibly 00 00 C1) care is required.

iii) Hex 2 is the ls byte of the mantissa.

iv) The 900 is incorrect, it is actually 9000 decimal.

It should be pretty easy to convert this to more normal floating point
formats, or fixed point, depending on what you want to do with it.

Actually, this description seems pretty flawed, if you can fiddle with the
routines on an emulator or simulator it ought to be easy to figure out.

Hope this helps.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany "The Journey is the reward"
sp...@interlog.com
Fax:(905) 271-9838 (small micro system devt hw/sw + mfg)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


cbfal...@my-dejanews.com

unread,
Nov 13, 1998, 3:00:00 AM11/13/98
to
In article <364B48DB...@baladyne.com>,

Adam Davis <ada...@baladyne.com> wrote:
> I've been given code which was written for the z80 processor.
> Actually, I need to decipher the three byte floating point encoding.
>
> It is supposed to be in the form
> byte 1 exponent xyzzzzzz
> byte 2 mantissa zzzzzzzz
> byte 3 mantissa zzzzzzzz
>
> Where
> x is mantissa sign(0 is positive)
> y is exponent sign(1 is positive)
>
> And I've been given the following values:
> Decimal Hex1 Hex2 Hex3
> 1800 00 e1 4b
> 900 a0 8c 4e
> 1 00 80 41 = 8000h binarypoint at 41h-40=1 from left

> 2 00 80 42
> 4 00 80 43
> 10 00 a0 44
> 20 00 a0 45

lsb sig-^
msb sig----------^ THUS ^^^^^^^^^^^^^^^^^
exponent, offset by 40h--^

probably has the sign bit in the high order exponent byte.

>
> I see a pattern, but I still can't get it. It does not seem to directly
> convert to decimal, or BCD.
> If anyone has any insights as to which newsgroup this question would be
> best answered, please tell me. If you have any clues, I'd appreciate
> them!
>

> Thanks!
>
> -M. Adam Davis
> ada...@baladyne.com
>

I wrote and published a 3 byte floating system some years ago - an early
version was published in DDJ, and that MAY be what you have. It is not my
later version, which was always justified and used an implied leading 1 bit,
replaced by a sign bit. I think the earlier used sign/magnitude in the
significand.

I have no idea whether I can lay my hands on the later version - it includes
a full set of transcendental functions, sufficient to handle standard Pascal.
It rounds everything properly, while the earlier did not. It has only 8080
code, so fully portable.

--
Chuck Falconer (Charles_...@NOSPAMapsnet.com)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Voya Protic

unread,
Nov 18, 1998, 3:00:00 AM11/18/98
to
There is a small error in problem statement - first item on the second
line should be 9000, not 900. The coding scheme that fits well into all
examples is:

hex3[7] - sign (0 - positive, 1 negative)
hex3[6..0] - exponent with base 64 i.e. exponent plus 64
hex2[7..0], hex1[7..0] - 16-bit mantissa, where hex2[7..7] has weight
1/2,
hex2[6] has weight 1/4 ... hex1[0]
has weight 1/65536

Example:

Number: 1800 = 1024 + 512 + 256 + 8 = 2048 * (1/2 + 1/4 + 1/8 + 1/256) =
= 2 ** 11 * (1/2 + 1/4 + 1/8 + 1/256)

So:

sign bit = 0
exponent = 64 + 11 = 75 = 4b(hex)
mantissa = 1110 0001 0000 0000 = e1(hex) 00 (hex)

Sequence is 00 e1 4b.

========================================================
Adam Davis wrote in message <364B48DB...@baladyne.com>...


>I've been given code which was written for the z80 processor.
>Actually, I need to decipher the three byte floating point encoding.
>
>It is supposed to be in the form
>byte 1 exponent xyzzzzzz
>byte 2 mantissa zzzzzzzz
>byte 3 mantissa zzzzzzzz
>
>Where
>x is mantissa sign(0 is positive)
>y is exponent sign(1 is positive)
>
>And I've been given the following values:
>Decimal Hex1 Hex2 Hex3
>1800 00 e1 4b
>900 a0 8c 4e
>1 00 80 41

>2 00 80 42
>4 00 80 43
>10 00 a0 44
>20 00 a0 45
>

0 new messages