ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1992/08/21/10:06:08

Date: Fri, 21 Aug 92 09:17:06 EDT
From: DJ Delorie <dj AT ctron DOT com>
To: ljo AT r2d2 DOT eeap DOT cwru DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: device memory access speed

>Now that physical memory access works for memory locations above 1MB (thanks DJ)

Whew. :-)

>Now the time is between 1.9 and 2 s. which is about 1.3MB/s. It is pretty clear
>that the speedup of a factor two is due to the fact that memcpy is doing 8bit
>access to memory while the second routine uses 16 bit access. I also tried
>a third variant using int pointers but the speed was the same as for the
>second algorithm.

A best alternative is to use a 32-bit memcpy implementation, or write
a memcpy32.s that uses a strict rep movsl loop.

>o I have heard that the peak speed of the at-bus is supposed to be 2MB/s is that 
>  correct?

1 MB/s on 8-bit transfers - 4 w/s plus 2 regular cycles on 6 MHz bus.
16-bit transfers are faster - 1 w/s, so two transfers at 16 bits at 6 MHz
is 4 MB/s.  8Mhz bus is 5.33 Mb/s, etc.  Extra wait states might be added
by the I/O card.

>o What is the preferred way of implementing memcpy for 16 bit at-bus memory use?
>  (The supplied memcpy in djdev108.zip is in assembler and clearly very fast for
>  non at-bus operation.)

32-bit operations are ideal.  They will get broken into two 16-bit
transfers for 16-bit devices, and four 8-bit transfers for 8-bit
devices.  Note that it is only faster if the 32-bit transfer occurs on
a 32-bit boundary on at least one of the operands.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019