Why are the DAC and ARG not 8 bytes? | MSX Resource Center (Pagina 3/3)

Van WORP3

Paladin (864)

28-01-2022, 12:49

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

Repository

Van WORP3

Paladin (864)

28-01-2022, 13:19

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

Van Grauw

Ascended (10821)

28-01-2022, 14:43

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?

Van WORP3

Paladin (864)

07-02-2022, 13:55

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

print 1000000+0.0000001
 1000000.0000001
print 1000000+0.00000001
 1000000
OK

Van ducasp

Paladin (712)

07-02-2022, 16:09

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

Van zeilemaker54

Champion (355)

07-02-2022, 17:27

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.

Van WORP3

Paladin (864)

09-02-2022, 11:10

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.

Van WORP3

Paladin (864)

09-02-2022, 11:11

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?

Van Grauw

Ascended (10821)

09-02-2022, 12:23

https://openmsx.org/manual/commands.html#debug

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

Van zeilemaker54

Champion (355)

17-02-2022, 19:03

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.