Why are the DAC and ARG not 8 bytes?

Página 3/3
1 | 2 |

Por WORP3

Paladin (855)

Imagen del WORP3

28-01-2022, 12:49

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

Repository

Por WORP3

Paladin (855)

Imagen del WORP3

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 Wink

Por Grauw

Ascended (10580)

Imagen del Grauw

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?

Por WORP3

Paladin (855)

Imagen del WORP3

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

Por ducasp

Hero (550)

Imagen del ducasp

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

Por zeilemaker54

Champion (341)

Imagen del zeilemaker54

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.

Por WORP3

Paladin (855)

Imagen del WORP3

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.

Por WORP3

Paladin (855)

Imagen del WORP3

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?

Por Grauw

Ascended (10580)

Imagen del Grauw

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.)

Por zeilemaker54

Champion (341)

Imagen del zeilemaker54

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.

Página 3/3
1 | 2 |