home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19312 < prev    next >
Encoding:
Text File  |  1993-01-06  |  1.2 KB  |  30 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!taumet!steve
  3. From: steve@taumet.com (Steve Clamage)
  4. Subject: Re: Problem with string processing.
  5. Message-ID: <1993Jan6.162841.5570@taumet.com>
  6. Organization: TauMetric Corporation
  7. References: <1993Jan4.022737.19792@kpc.com> <2mqVwB6w165w@cybrspc.UUCP> <MCGLK.93Jan5005833@yang.cpac.washington.edu> <811@ulogic.UUCP>
  8. Distribution: usa
  9. Date: Wed, 6 Jan 1993 16:28:41 GMT
  10. Lines: 18
  11.  
  12. hartman@ulogic.UUCP (Richard M. Hartman) writes:
  13.  
  14. >Actually, on systems w/ block memory move supported at the
  15. >CPU level, memcpy() can be implemented much more efficently.
  16. >If there were a decent way of getting the string length w/o
  17. >counting all the bytes then direct support for strcpy() could
  18. >be done easily.  Are there any CPUs that have a single-instruction
  19. >way of saying "find the next 0 byte & tell me how far it was from here"?
  20.  
  21. Of course there are, but this does not mean that such CPU's get a win
  22. over CPU's which don't have the instruction.  One way or another, the
  23. bytes in the string have to be examined.  (Metaphysics aside, that is.)
  24.  
  25. The question is whether you have one big complicated slow instruction,
  26. or several small fast simple instructions, or something in between.
  27. -- 
  28.  
  29. Steve Clamage, TauMetric Corp, steve@taumet.com
  30.