home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / msdos / programm / 7985 < prev    next >
Encoding:
Text File  |  1992-07-21  |  1.2 KB  |  31 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!caen!sol.ctr.columbia.edu!csa!kibirev
  3. From: kibirev@csa.bu.edu (oleg kibirev)
  4. Subject: Re: fast memcpy
  5. Organization: Computer Science Department, Boston University, Boston, MA, USA
  6. References: <2a66baaf@ralf> <1992Jul19.234636.25680@ccu1.aukuni.ac.nz>
  7. Message-ID: <1992Jul21.162618.25425@ctr.columbia.edu>
  8. Sender: news@ctr.columbia.edu (The Daily Lose)
  9. Date: Tue, 21 Jul 1992 16:26:18 GMT
  10. X-Posted-From: csa.bu.edu
  11. X-Posted-Through: sol.ctr.columbia.edu
  12. Lines: 17
  13.  
  14. In article <1992Jul19.234636.25680@ccu1.aukuni.ac.nz> stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:
  15. >
  16. >in microsoft ( 5.0 and 6.0, atleast... ) a memcpy is done with an inline
  17. >string move instruction, ie:no call overhead, short of using DMA, there
  18. >is no way of going faster ( I think it uses word move, but could be wrong.. )
  19. >
  20. So, each time you use memcpy, optimization is turned off for the entire module?
  21. Or it's only Borland's reacrion to ASM? I think there is a way to do it faster
  22. (sometimes): checking if the start of both source and dest are misaligned and
  23. fixing it with single movsb before doing word move. 
  24.  
  25. DMA won't be faster on anything better than 4.77MHz PC: it operates at 4MHz on
  26. all later machines.
  27.  
  28. Oleg Kibirev
  29.  
  30.  
  31.