Hi, I found that http://fdos.org/kernel/ 386-optimized kernels, at least the CVS stable FAT32 one, crash iff you load EMM386, after the EMM386 "frame at" display and before the next "load Y/N" display of the kernel in F8 mode. Maybe you can have a look at kernel.HEAD sources from the same homepage and find out why...
Things that I found: - there is an I86 define which is triggered for most (all?) known compilers and which activates some Turbo C / ... style syntax in some places. See portab.h and grep for I86 in kernel/*. and tell me WHY we have I86 at all. - there are I186 and I386 defines which are only used in inthndlr.c and main.c, but I have the feeling that you get better consistency by REMOVING those and using the global XCPU define instead. - the main magic is in Protect386Registers and Restore386Registers, BUT: > ; we have never seen MSVC to use anything but eax, ecx, edx, > ; nor have we seen Borland C to use anything but eax, ebx, edx, > ; so we only protect eax, ebx or ecx, edx to conserve stack space > ; WATCOM only uses FS: and GS: (using -zff and -zgf) and never > ; any high part of the 386 registers If any of those assumptions is wrong, you are toast. For example if compilers do start to use more registers. Even worse, there are a few places where the Protect/Restore macros are NOT used: - entry.asm adjusts BP depending on XCPU at int21_exit_nodec, so there should be a WARNING in the code that this has to stay in sync with the Protect/Restore macros. - int2f.asm saves/restores FS and GS to SI and DI if the compiler is Watcom. This saves 4 bytes of stack but is a BAD IDEA because it hardcodes the idea that Protect/Restore macros save ONLY FS and GS if the compiler is Watcom. - the inthndlr.c int2f12regs structure HARDCODES the stack structure created by Protect/Restore macros and the "FS/GS in SI/DI" trick, but the 386 structure elements are never accessed. I think this means that only the size of the structure is relevant. There could be a #define for that in portab.h, read in inthndlr.c, to make sure that people ONLY have to edit portab.h, avoiding inconsistency risks. You should also grep for use of the Protect/Restore macros: It might be that some user-callable functions which do call C functions (which may use 386 registers because of 386 optimizations being enabled) are not properly enclosed in Protect/Restore pairs yet. Note that none of our code, except boot sector code, EXPLICITLY uses 386 registers. Only the Protect/Restore macros "use" the registers, based on the assumption that the optimized C code will modify them, but that is entirely left to the choice of the compiler. Eric PS: Only boot32lb (FAT32/LBA) uses 386 code. So you can boot from CHS-FAT32 (kind of rare) and CHS/LBA FAT12 and FAT16 on 8086 :-). ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel