Hello Michael, >> >> > The optimization is the one that tries to align EDI to an >> >> > eight-byte boundary before the main REP MOVSD. >> >>Allow me to have a different 'opinion'. As far as I understand+remember >>Intel optimization guides (whatever CPU that was for), alignment of ESI >>is more important.
> Table 19.5, Data Misalignment Penalty for REP MOVSD, in "Pentium Processor > Optimization Tools" by Michael Schmit (to pull out an obscure reference) > agrees with you for 386sx, 386, 486. Aligning to [E]SI provides a smaller > penalty when [E]SI is aligned and [E]DI is not than the reverse. Pentium > is the reverse: you should align to EDI since it provides no > penalty. CPUs above that, the book is too old. Nothing else handy seems > to say much on the subject. this partially reflects my personal computing history: I took a lot of care about performance, when CPU's started with a 2,3, and maybe '4'; after that, 'P' CPU's were simply 'fast enough' for what I was doing. so my memory referenced most probably 486 optimization; thanks michael for correction ;) As a side effect of this discussion, I check Drive Snapshot for all unaligned accesses, and I found indeed a place to optimize: when reading (large) records from random positions in a file, you should try to align the read position nicely (in particular if you are using UDMA) if aligned properly (4 byte boundary), UDMA will transfer sectors directly into user memory. If not, it will read them to XMS memory, the XMScpy() them to user memory. that doesn't make the XMScpy faster - it simply avoids it ;) tom ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
