# Why are the DAC and ARG not 8 bytes?

Página 3/3
1 | 2 |

searching for some z80 math code, I stumbled on this repository from Zeda, quite amazing stuff

To return to the original question of why there are 16 bytes, could it have something to do with normalizing a number to a specific exponent without loosing to much of the mantissa? How is this done anyway if you want to add two numbers in a situation where the exponents of both numbers are far apart? Sorry i'm not a mathematical guru

Or maybe the second half is used for temporary storage? What if you put breakpoints on it and perform a variety of floating point operations?

Everything above 14 digits is cut, see simple basic test below:

```print 1000000+0.0000001
1000000.0000001
print 1000000+0.00000001
1000000
OK
```
WORP3 wrote:

Everything above 14 digits is cut, see simple basic test below:

```print 1000000+0.0000001
1000000.0000001
print 1000000+0.00000001
1000000
OK
```

I don't think Grauw was suggesting that higher precision would work, he was suggesting to put a breakpoint on OpenMSX in that memory area, when it changes, and check if during all kinds of floating point operations the other bytes are used, perhaps they are a temp storage to make things faster or for other kinds of usage during FP math

For sure DAC+8 and ARG+8 are actually used (for rounding purposes). So at least 9 bytes are being used.
I discovered that the math library F4.MAC is not only used in MSX and SVI, but also in the Triumph Alphatronic PC (Z80 based computer from 1983 with MBASIC 5.26) with almost identical code in F4.MAC. So it seems that the F4 code for Z80 is indeed Microsoft code and not MSX or SpectraVideo specific.

ducasp wrote:
WORP3 wrote:

Everything above 14 digits is cut, see simple basic test below:

```print 1000000+0.0000001
1000000.0000001
print 1000000+0.00000001
1000000
OK
```

I don't think Grauw was suggesting that higher precision would work, he was suggesting to put a breakpoint on OpenMSX in that memory area, when it changes, and check if during all kinds of floating point operations the other bytes are used, perhaps they are a temp storage to make things faster or for other kinds of usage during FP math

It was just a test to see what kind of precision was used and if higher resolution bits were just discarded.

Grauw wrote:

Or maybe the second half is used for temporary storage? What if you put breakpoints on it and perform a variety of floating point operations?

I hardly use any emulators, which emulator can handle breakpoint to test this?

(For breaking on access to memory, you’ll want a watchpoint rather than a breakpoint.)

After inspecting the F4 module more closely (and add some usefull comments in the process), it seems that the DECMUL routine (double real multiply) is using the fact that DAC is 16 bytes (at 2871H). It is being used for BCD digit shifting. So the conclusion is that DAC is 16 bytes for a good reason. ARG is just the second accumulator, that is probably why ARG is the same size as DAC.

Página 3/3
1 | 2 |