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
as information sources :-)
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.
Freedos-kernel mailing list