>> Actually, it was a bit surprising to me that I still need a software
>> cache ... Well, perhaps the NVIDIA SATA isn't the best fit for DOS.
> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
> It would be even slower without UDMA or a software cache.   As to
> why you need it, it's because (quoting Martin Reiser) "Software
> gets slower faster than hardware gets faster".   Also known as
> "What Intel giveth, Microsoft taketh away."

Intel "giveth" NOTHING, and followeth only "All we want is MONEY!",
same as Gates & Co.!   In my opinion, absolutely NO excuse for AHCI
that a better-written Windows driver could NOT have solved, but for
Intel as-always wanting to sell-Sell-SELL new chips!   Back in 2008
I asked Lucho how my (then) relatively-new UIDE driver "fared" v.s.
Windows, as he ran both DOS and Win/XP, and Lucho replied "You beat
THEM 2 months AGO"!!   At-least Intel does not "sucketh" like Gates
Co. does!!

Re: SATA, it does not offer an "IDE compatibility" mode, as it uses
all the same commands as IDE.   Only its drive cables are different
and NOT its "software interface"!   AHCI is the one using a totally
DIFFERENT command protocol, so it does need and have an "IDE compa-
tibility" mode on most mainboards and in most BIOS routines.

As I have noted, (A) AHCI is USELESS for DOS, as DOS does "One at a
time" I-O and cannot make use of AHCI's much-touted "Native command
queuing", and (B) AHCI is RIDICULOUSLY complex, the obvious results
of it being designed by a [MISERABLE!] "ANSI committee" which tried
to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual!   I
have REFUSED to implement actual AHCI in UIDE/UIDE2, and I shall do
so for as long as "IDE compatibility" mode exists -- I have NO wish
to double my drivers' I-O logic and so reduce their cache capacity,
"Por NADA!" [for NOTHING], since DOS can never use AHCI queuing!

> But actually even DOS software gets slower and bloatier over time. I
> hate to bring up DJGPP, one of my favorite things, but take a look at
> CC1.EXE (C compiler proper) over the years, quite a difference!!! And
> don't forget the differences in x86 families (and software
> optimizations) and L1/L2/L3 cache sizes (among a billion other
> things). It all heavily varies (and GCC has both pros and cons).

Hardware improvements like those you mention will never "hurt" any
existing software, only make it faster.   As for poor-old "C" com-
pilers, which ALSO try to satisfy everybody and end-up satisfying
NOBODY, maybe you can understand why I prefer assembly-language!
No "constraints" on what code you generate, except your own!!

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Freedos-user mailing list

Reply via email to