VOGONS


First post, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Continued from the glide topic...

There is a bug somewhere in the dynamic fpu code, resulting in a RedGuard crash. The bug occurs with dyn_fpu_esc1 opcodes. There's about 200 calls to dyn_fpu_esc1 before the crash, is there an easy way to determine which opcode returned the wrong result? Commenting out opcodes like in decoder.h does not work I guess 😀

http://www.si-gamer.net/gulikoza

Reply 1 of 7, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Try something like that (decoder.h) :

		case 0xd9:
dyn_get_modrm();
if (decode.modrm.val >= 0xc0) goto illegalopcode;
dyn_fpu_esc1();
break;

to see which of the two causes it, and then a similar check
for decode.modrm.reg.

Last edited by wd on 2007-08-30, 10:07. Edited 1 time in total.

Reply 2 of 7, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Maybe check this function (line ~290) :

case 0x00: /* FLD float*/ gen_call_function_raw((void*)&FPU_PREP_PUSH); gen_mov_word_to_reg(FC_OP2,(void*)(&TOP),true); […]
Show full quote

case 0x00: /* FLD float*/
gen_call_function_raw((void*)&FPU_PREP_PUSH);
gen_mov_word_to_reg(FC_OP2,(void*)(&TOP),true);
dyn_fill_ea(FC_OP1);
gen_call_function_RR((void*)&FPU_FLD_F32,FC_OP1,FC_OP2);
break;

Maybe check this function:
and swap the gen_mov and the dyn_fill functions. On x86-64 the
FC_OP2 is the same as the temp reg of the ea filling...

Reply 3 of 7, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Hm there seem to be a few more (dunno if it helps for redguard) :

		case 0x07:   /*FNSTSW */
gen_mov_word_to_reg(FC_OP1,(void*)(&TOP),true);
gen_call_function_R((void*)&FPU_SET_TOP,FC_OP1);
gen_mov_word_to_reg(FC_OP2,(void*)(&fpu.sw),true);
dyn_fill_ea(FC_OP1);
gen_call_function_RR((void*)&mem_writew,FC_OP1,FC_OP2);
break;

and two similar cases in dyn_fpu_esc7().

Reply 4 of 7, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

You're right again 😀
Already changing the first one solves the crash and graphic errors inside the game (that occured if I started with normal core and later switched to dynamic). But I guess all should be fixed...

btw: is this a proper fix? I mean, changing the order of generated instructions - x86_64 has far more regs than x86, temp reg could be set to >r10...

http://www.si-gamer.net/gulikoza

Reply 5 of 7, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It's just a workaround, but one that causes no harm and works perfectly.
As you say that temp reg should be unique, feel free to choose one and
figure out if it still works 😉
Suppose a special case is needed where the temp reg is used then.

Reply 6 of 7, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, >r8 might not work because of longer opcodes and lack of dword access. But EDX seems to work 😀. It is also used as a 3rd function parameter, but as I can see, there are no function calls when TEMP_REG_DRC is used.

http://www.si-gamer.net/gulikoza