Scali
Veteran Member
I've been toying with OpenWatcom as a cross-compiler for my old IBM 5160... and I ran into a problem.
It seemed that as soon as I pulled in any code that used floats, it would lock up, even before it ever got to the main() of my program.
I could not reproduce this problem in PCem, DOSBox or any of real PCs.
I have been doing some debugging on the real metal, and eventually I found out that the problem is in the initialization of the FPU emulation routines, a function called __Fini_FPE_handler, which can be found in the file fpe87.asm.
The problem here is that it is assembled with some fwait-instructions. Since there is no actual FPU present to signal that the bus is free, fwait locks the bus indefinitely, locking up the machine.
I have also found some information on this here: http://www.openwatcom.org/index.php/Math_Coprocessor_Interface_Evolution
Now, apparently these fwaits should have been removed by the linker (I have tried to build it with various settings for FPU emulation), but they were not.
So, I went in there with the ole hex-editor and patched the fwaits to nops in my clibs.lib.
This fixed the lockup, and apparently float-code seemed to execute correctly afterwards, so it seems the rest of the code is working as it should.
However, I was wondering if other people have encountered this problem as well, and perhaps have a better workaround than this (I may have missed some linker switch somehow?).
It seemed that as soon as I pulled in any code that used floats, it would lock up, even before it ever got to the main() of my program.
I could not reproduce this problem in PCem, DOSBox or any of real PCs.
I have been doing some debugging on the real metal, and eventually I found out that the problem is in the initialization of the FPU emulation routines, a function called __Fini_FPE_handler, which can be found in the file fpe87.asm.
The problem here is that it is assembled with some fwait-instructions. Since there is no actual FPU present to signal that the bus is free, fwait locks the bus indefinitely, locking up the machine.
I have also found some information on this here: http://www.openwatcom.org/index.php/Math_Coprocessor_Interface_Evolution
The WAIT/FWAIT instruction thus implements the software-visible portion of the synchronization mechanism. Note that FWAIT is the same instruction as WAIT, and it is a CPU instruction despite the 'F' prefix. The difference between WAIT and FWAIT is that the latter can be eliminated by the linker if an emulation library is used.
Now, apparently these fwaits should have been removed by the linker (I have tried to build it with various settings for FPU emulation), but they were not.
So, I went in there with the ole hex-editor and patched the fwaits to nops in my clibs.lib.
This fixed the lockup, and apparently float-code seemed to execute correctly afterwards, so it seems the rest of the code is working as it should.
However, I was wondering if other people have encountered this problem as well, and perhaps have a better workaround than this (I may have missed some linker switch somehow?).