I thought about it and a more correct but slower solution is to check the boundaries before conversion to integer - like this:

1static void FPU_FST_I16(PhysPt addr) {
2	double value = FROUND(fpu.regs[TOP].d);
3	mem_writew(addr,(value < 32768.0 && value >= -32768.0)?static_cast<Bit16s>(value):-32768);
4}
5
6static void FPU_FST_I32(PhysPt addr) {
7	double value = FROUND(fpu.regs[TOP].d);
8	mem_writed(addr,(value < 2147483648.0 && value >= -2147483648.0)?static_cast<Bit32s>(value):-2147483648);
9}
10
11static void FPU_FST_I64(PhysPt addr) {
12	double value = FROUND(fpu.regs[TOP].d);
13	FPU_Reg blah;
14	if (value < 9223372036854775808.0 && value >= -9223372036854775808.0) {
15		blah.ll = static_cast<Bit64s>(value);
16	} else {
17		blah.l.lower = 0;
18		blah.l.upper = -2147483648;
19	}
20	mem_writed(addr,blah.l.lower);
21	mem_writed(addr+4,blah.l.upper);
22}

Thank you, it works perfectly

Your value for the I64 comparison looks off by one (it's 2^63-1 instead of 2^63), but it probably wouldn't matter anyway since 63 is too many bits of precision to be accurately represented in a double.
Using frexp() and checking the range of the exponent might be better?

jmarsh wrote on 2020-12-13, 21:37:

Your value for the I64 comparison looks off by one (it's 2^63-1 instead of 2^63), but it probably wouldn't matter anyway since 63 is too many bits of precision to be accurately represented in a double.

Yes, you're right. I fixed it.

jmarsh wrote on 2020-12-13, 21:37:

Using frexp() and checking the range of the exponent might be better?

Better how ?

1blah.ll = static_cast<Bit64s>(value)

Would that work as well for the i64 or is there a real need to round the data twice ?

Qbix wrote on 2020-12-14, 08:01:

Would that work as well for the i64 or is there a real need to round the data twice ? […]
Show full quote

Copy code to clipboard

1blah.ll = static_cast<Bit64s>(value)

Would that work as well for the i64 or is there a real need to round the data twice ?

I missed replacing it. It's now fixed. (The compiler probably optimized it anyway.)

Is entering the values into lower and upper endian wise safe ? as I orginally added those to write out 64 bit numbers correctly

would
blah.ll= -9223372036854775808
work ?

(it might be fine, but doesn't hurt to think it over, as endian things can sometimes be tricky)

M-HT wrote on 2020-12-14, 05:49:

Better how ?

Just feels a little bit neater/clearer with only one integer comparison against the exponent, since the mantissa value and sign are irrelevant in this case and can be ignored.

1static void FPU_FST_I16(PhysPt addr) {
2	int exp;
3	double value = FROUND(fpu.regs[TOP].d);
4	frexp(value,&exp);
5	mem_writew(addr,(exp < 16) ? static_cast<Bit16s>(value):0x8000);
6}
7
8static void FPU_FST_I32(PhysPt addr) {
9	int exp;
10	double value = FROUND(fpu.regs[TOP].d);
11	frexp(value,&exp);
12	mem_writed(addr,(exp < 32) ? static_cast<Bit32s>(value):0x80000000);
13}
14
15static void FPU_FST_I64(PhysPt addr) {
16	FPU_Reg blah;
17	int exp;
18	double value = FROUND(fpu.regs[TOP].d);
19	frexp(value,&exp);
20	blah.ll = (exp < 64) ? static_cast<Bit64s>(value):LONGTYPE(0x8000000000000000);
21	mem_writed(addr,blah.l.lower);
22	mem_writed(addr+4,blah.l.upper);
23}

Qbix wrote on 2020-12-14, 13:42:

Is entering the values into lower and upper endian wise safe ? as I orginally added those to write out 64 bit numbers correctly […]
Show full quote

Is entering the values into lower and upper endian wise safe ? as I orginally added those to write out 64 bit numbers correctly

would
blah.ll= -9223372036854775808
work ?

(it might be fine, but doesn't hurt to think it over, as endian things can sometimes be tricky)

Since the values are read from lower and upper, I think that writing into them is safer (endian wise) than writing to blah.ll.

jmarsh wrote on 2020-12-14, 23:19:

M-HT wrote on 2020-12-14, 05:49:

Better how ?

Just feels a little bit neater/clearer with only one integer comparison against the exponent, since the mantissa value and sign are irrelevant in this case and can be ignored.

Maybe this part is neater/cleaner (I guess it depends on your preferences), but you're also exchanging two float comparisons for a library call.

frexp is according to gcc mapped to some internal call. I'd guess that it would be just an AND and bitshift in most cases ?

*moving to patches*

Went with a variation but doing explicit checks because frexp has some undefined values on NaN and Inf .
Commited in 4436 and 4437