Hi Alain, > 1) Eric pinpointed one problem to a register modification
Yes. EMM386 modifies registers that do not even exist on 8086, and it does so only during EMM386 initialization. As the MS DOS kernel is 100% 8086 compatible, it does not hurt there. > 2) He found out that new compile options could solve it, temporaryly > only meant it as a test. It is *not* clear at all if he did the > compiling himself (probably lots of off-list talk) I still have no OpenWatcom at home, but Jeremy kindly did a test compile with the compile options "create a 386-optimized kernel but do not use 386-specific registers" - which of course reduces the effect of the optimizations - and that turned out to solve the problem. > But I got one idea from it all: fd-emm386 appears to be trashing some > registers somewhere! Michael do you acknowledge that? If so, this could > be a problem for other OpenWatcom optimized programs as well or not? Only the kernel is affected, as only the kernel triggers initialization of EMM386. However, DEVLOAD would be affected if it would be able to load EMM386 (but it is not: Neither UMBs nor HMA are initialized by DEVLOAD, while the kernel automatically initializes them as soon as it detects that EMM386 / HIMEM is active, if DOS=HIGH,UMB). > Then, shouln'd this be fixed in a later version? I think it should, because the "init device" call uses a common interface which is called very often (e.g. for every single character that you send to the screen, unless you use int29 fast interface). So it would be bad to have to "fortify" the common "call any device driver function" code of the whole kernel just because ONE driver in ONE function happens to modify a register. But again, the problem only shows up if you use 386 optimizations in the kernel. You can also reduce the fortification cost by telling OpenWatcom "this function is known to trash those registers" instead of adding extra code to save all registers all the time (even at places where the kernel does not use those registers around a call to the generic device driver function call interface). Still, the very best solution would be to make EMM386 initialization code backup all registers (and not only, as in current version, and as it has been ever since c't EMM386 came out, the 8086 registers) to the local initialization stack and to make EMM386 restore those values from backup when it is done with initialization. Eric ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
