home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / intel / 1346 < prev    next >
Encoding:
Internet Message Format  |  1992-07-24  |  1.9 KB
  1. Path: sparky!uunet!mcsun!uknet!axion!vulture!dlumby
  2. From: dlumby@axion.bt.co.uk (Dave Lumby)
  3. Newsgroups: comp.sys.intel
  4. Subject: Clocks, bus cycles and wait states on the 8088
  5. Message-ID: <1992Jul24.160813@axion.bt.co.uk>
  6. Date: 24 Jul 92 15:08:13 GMT
  7. Sender: news@axion.bt.co.uk
  8. Reply-To: dlumby@axion.bt.co.uk (Dave Lumby)
  9. Organization: British Telecom Research Labs
  10. Lines: 33
  11.  
  12.  
  13. I'm currently modifying a peice of time critical assembler code for a rather
  14. old 8088 based system and I'd like to be able to work out *exactly* how long
  15. my new code will take to execute.
  16.  
  17. From reading Intel's iAPX86,88 User Manual I can get figures for the no. of
  18. _clocks_ for each instruction but how do _clocks_ relate to bus cycles. From
  19. what I've read it would appear that each bus cycle is broken into at least
  20. four clock cycles (T1 - T4) + wait states + idle cycles.
  21.  
  22. The heart of the code I'm planning to introduce will include a REP MOVSW to
  23. copy a 64 byte string as 32 words. The code is held in EPROM (running with 2
  24. wait states) the source and destination strings are both in RAM (with one
  25. wait state). The timings for REP MOVSW are quoted as 9 + 17/rep (8086) and 9
  26. + 21/rep for an 8088.
  27.  
  28. Given that the 8088 is running at 5MHz then with no wait states the transfer
  29. of 32 words would take 9 + 21*32 = 681 clocks = 136.2uS
  30.  
  31. REP MOVSB is coded as two bytes and therefore I'd guess that the 2 wait
  32. states on the EPROM would add 4 clocks to the overall time. But do the wait
  33. states on the RAM also add a further 2 clocks (1 read/1 write) per byte
  34. transfered?
  35.  
  36. I'd be very grateful if someone could let me know how the wait states will
  37. affect the timing.
  38.  
  39.     Dave
  40. Dave Lumby, Software Maintene[e]ance Group, Software Technology Division, BT
  41. Research Labs, Martlesham Heath, Ipswich, IP5 7RE, UK
  42. Phone:  +44 473 642613
  43. E-mail: dlumby@axion.bt.co.uk
  44. "I don't mind valid criticism, as long as it doesn't come from other people"
  45.