Re: [Freedos-kernel] Trying to figure out 386 kernel EMM386 crashes
! 24--2005 16:02 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-kernel@lists.sourceforge.net: (Other questions already answered by Bart). EA - there are I186 and I386 defines which are only used in inthndlr.c EA and main.c, but I have the feeling that you get better consistency EA by REMOVING those and using the global XCPU define instead. XCPU is only our suggestion how compiler should generate code. I386 defined by (some) compilers and (more precise) reflects real state. EA - entry.asm adjusts BP depending on XCPU at int21_exit_nodec, so EA there should be a WARNING in the code that this has to stay in EA sync with the Protect/Restore macros. Yes, such additional comments always welcomed (from me). EA - int2f.asm saves/restores FS and GS to SI and DI if the compiler is EA Watcom. This saves 4 bytes of stack but is a BAD IDEA because it EA hardcodes the idea that Protect/Restore macros save ONLY FS and GS EA if the compiler is Watcom. ? --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Trying to figure out 386 kernel EMM386 crashes
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=6595alloc_id=14396op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Trying to figure out 386 kernel EMM386 crashes
On Sun, 24 Apr 2005, Eric Auer wrote: 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. it's an old define to distinguish between the Intel chip and the Motorola mc68k chip. I don't think anyone has managed to build an mc68k FreeDOS kernel during the last 10 years but at some point it was possible. At least for Pat. ; 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: www.agner.org/assem has a piece (PDF) about calling conventions. This document may provide some more info. http://www.agner.org/assem/calling_conventions.pdf (Arkady-friendly URL) MSVC and Borland 16bit generating compilers have been dead for 10 years+. Noone expects their register allocators to change. Still it's a somewhat bold statement of Lucho to make about MSVC and Borland but I trust he did his research thoroughly. - 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. I checked the OpenWatcom source code for 386 optimizations in the i86 code generator a couple years ago. There's no use of e* registers at all. I'll promise to let you know if an enterprising developer changes this, but frankly, I think that the chance of a meteorite hitting your house tomorrow at 3:00am is higher. Bart --- 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=6595alloc_id=14396op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
