> 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
these days,

> 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
some (few)
 push DWORD constant

what would be useful, but is not used by WCC
 dword arithmetic
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
  rep movsD


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

Reply via email to