David Hess (davidwhess.delete@this.gmail.com) on October 5, 2021 5:19 pm wrote:
> Yuhong Bao (yuhongbao_386.delete@this.hotmail.com) on October 3, 2021 1:30 am wrote:
> >
> > Even on the IBM PC the 8237 memory-to-memory copy mode never were used.
>
> Embedded systems running on bare metal might have used it, and I think I remember seeing examples
> in application notes, but didn't Dr. Dobb's Journal include an example on the PC in one issue?
>


The 8237 DMA was very seldom used for anything in IBM PC's (except in its legacy application in the floppy disk driver) not because it was a DMA controller, but because it was a very bad DMA controller.


8237 was not really designed as a companion of CPU's with large address spaces. It had just minimal improvements over the 8257, which was designed as a companion for Intel 8080.


Using 8237 for large or unaligned transfers was tedious and it was very slow.

Starting with the IBM PC/AT, i.e. with 80286 or better CPUs, the CPU had the instructions INS & OUTS, which could transfer data much faster and much simpler than 8237.


So the fact that one of the worst DMA controllers known in history, 8237, was not used in IBM PCs, does not prove anything about whether it is better or worse to use DMA or the CPU for memcpy/memset.

With many embedded CPUs, using a DMA controller for the larger transfers is certainly better.

Whether this might also be worthwhile on a high-performance CPU with multi-level caches, it is hard to estimate without some realistic simulations, as it depends on how frequent the larger transfers are and on which effects would dominate, those that would increase or those that would decrease the performance.