FPU handling got broken over half a year ago when I removed separate interrupt DLL and added support for DPMI32. Interrupt DLL made sure that builtin protected mode interrupt handlers saw regular IRET return record on stack. Current protected mode interrupt code does not provide an IRET record and real mode interrupt code never did provide it.
I'm currently working on a two part fix for FPU code:
1. Make sure that DOSRELAY called via RELAY_BuildCallFrame sees original stack and code pointers and can modify them.
2. Make FPU emulation use CS/IP instead of IRET record.
Both of these patches are about 10 lines of code so I guess I shall have it fixed within a week, assuming testing patches don't take up too much time.
Jukka Heinonen,
FPU handling got broken over half a year ago when I removed separate interrupt DLL and added support for DPMI32. Interrupt DLL made sure that builtin protected mode interrupt handlers saw regular IRET return record on stack. Current protected mode interrupt code does not provide an IRET record and real mode interrupt code never did provide it.
The EIP on the stack, from what I saw in the trace, was pointing to the interrupt. If we have that CS:IP available, then the offset math that I am unsure of could be avoided and we could just use those values. It would be optimal if we could tell the return code not to increment the instruction pointer, although I doubt that we could do that. My pointer math problem lies in the possibility that I could cross a real mode segment boundary while working on the interrupt in protected mode. Is there any way of forcing a return to the point at which the exception happened rather than having program flow return at the next instruction? Since you are working on code that handles both the real and protected mode pointers, I figure that you would be the best source of information. I'd like tog et time to work on making some more of the dos graphics code work. God Bless, --Robert 'Admiral' Coeyman
-
admiral coeyman -
Jukka Heinonen