Hi Louis, if I understand your patch correctly, you only changed the build configuration to check how it affects the size of the compiled kernel before UPX compression, which also is an indicator of RAM size of the kernel? You changed the config.b, build.bat, buildall.bat files and generic.mak and watcom.mak and the resulting kernel sizes give the impression that in fact you only have FOUR distinct CPU optimizations, rather than seven cases...
Kernels without FAT32: 086: 64158 bytes 186: 63028 bytes (286 same) 386: 62164 bytes 486: 62068 bytes (586 and 686 same) Kernels with FAT32: 086: 68358 bytes 186: 67180 bytes (286 same) 386: 66044 bytes 486: 65948 bytes (586 and 686 same) It is interesting that even 186 instructions do make a quite big difference and that there is a difference at all between 386 and 486. With 186, you get pusha and popa, shift/rotate by fixed numbers of bits. some mul extensions, enter/leave and I/O strings and some more exotic things. I think even I/O strings are not used at all for the kernel. Everything added in 286 is for protected mode, so 186 and 286 are exactly the same kernels because DOS runs in real mode ;-) In the past, we compiled kernels for 8086, 186 and 386 separately afair. I guess we got lazy and have dropped 186 because very few users have 186/286 as their CPU? They either have modern or REALLY old. Also, we keep offering 8086 compiles for the sake of good old times and for people with emulators. The 386 optimization is useful and we already used it: Having 32 bit computations helps even for DOS. There are also some new bit string opcodes, SETCC (conditional set a byte) JCXZ and near conditional jumps and loops that are supported starting at 386. Your 486 to 686 kernels are the same size and 486s only XADD and BSWAP (and CMPXCHG). It is impressive that those actually make any (100 byte) difference! Maybe your compiles assume that 486 does and 386 does not have FPU? That would not be very accurate. As with 286, the news in 586 is mostly protected mode related (simply speaking). Neither CMPXCHG8B nor the time stamp counter nor CPUID bothers DOS. The main news in 686 would be CMOV, a conditional MOV, but looking only at kernel sizes, it is likely that the compiler just does not use CMOV for 686. It is odd to get exactly the same size otherwise. For even newer CPU, you could use FPU and vector (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+, SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions but it is highly unlikely that those make any DOS difference. At most they could speed up memmove. There are also some string comparison / bit count things in SSE4, but the overhead to use them is probably higher than the benefit in DOS context. DOS is not math-heavy, so even a classic like a fused multiply add is unlikely to optimize DOS. This mail uses www.sandpile.org and http://en.wikipedia.org/wiki/X86_instruction_listings#Added_in_specific_processors as information sources :-) Regards, Eric ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
