> 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.
> 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.
this is not about 'lazy'
it's easier for the user to select between 2 choices then between
4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
there's not much use for a 186 kernel as NOBODY has 186/286 machines
> 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)
nothing of this is used by the compiler
was always supported
> and near conditional
> jumps and loops that are supported starting at 386.
*far* conditional jumps started with 386.
however what *IS* used by wcc is
the additional FS and GS register
push DWORD constant
what would be useful, but is not used by WCC
filesystem code uses long variables everywhere
> 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!
strange enough, compiling here with -3 and -6 makes exactly no
difference. using watcom 1.9
could you post the compiled files, or even
for %i in (*.obj) do wdis -l -a -s %i
for -3 and -6 and show us the differences ?
> Maybe your compiles assume that 486 does and 386
> does not have FPU? That would not be very accurate.
pointless as the kernel doesn't use any FPU code
> 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.
it doesn't use cmov
> 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.
as the kernel doesn't much memcpy/memmove, you can't accelerate it
by any significant amount.otherwise we *would* have
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