home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / intel / 1593 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  2.4 KB
  1. Xref: sparky comp.sys.intel:1593 alt.lang.asm:363 comp.os.msdos.programmer:8843
  2. Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!amodra
  3. From: amodra@ucs.adelaide.edu.au (Alan Modra)
  4. Newsgroups: comp.sys.intel,alt.lang.asm,comp.os.msdos.programmer
  5. Subject: 386SX code optimisation
  6. Message-ID: <8348@sirius.ucs.adelaide.edu.au>
  7. Date: 27 Aug 92 15:24:15 GMT
  8. Followup-To: comp.sys.intel
  9. Organization: Information Technology Division, The University of Adelaide, AUSTRALIA
  10. Lines: 36
  11.  
  12. I'm often involved in producing fast, tight assembly code for things
  13. like BIOS and drivers.  One little thing that helps here is to put
  14. entry points into code on machine word boundaries ie. on a 386SX align
  15. to word boundaries, and on a 386DX align to dword boundaries.  OK you
  16. say, that's all fairly obvious - feed as much code as you can into the
  17. CPU pipeline on its first fetch.  The curious thing about a 386SX is
  18. that it often pays to align to addresses that are an odd multiple of
  19. two.  Anyone know why this is so ?
  20.  
  21. I suspect it may be that the internal pipelines of the 386SX are 32 bits
  22. wide, and the prefetch unit gets as much of the first dword as it can
  23. before passing instructions on to the next stage.  This means that if
  24. your first code fetch is on a dword boundary, you get two word reads
  25. before anything happens.  If your first code fetch is on an odd multiple
  26. of 2 address, then you read only one word.
  27.  
  28. Here's some relative timing I measured on one of my 386SX systems, for
  29. 64K of repeated JMPs and other code snippets:
  30.  
  31.                                      Start address mod 4
  32.                                   0       1       2       3
  33. Code              bytes                    Timing
  34. JMP short         EB,02,xx,xx   1.208   1.208   1.000   1.318
  35. JMP near          E9,01,00,xx   1.000   1.000   1.091   1.091
  36. JNC short         73,02,xx,xx   1.203   1.203   1.000   1.312
  37. JNC long          0F,83,00,00   1.000   1.158   1.000   1.075
  38. NOP; JMP short    90,EB,01,xx   1.065   1.065   1.000   1.076
  39. MOV AX,AX; JMP    89,C0,EB,00   1.000   1.089   1.009   1.089
  40. XCHG BX,BX; JMP   87,DB,EB,00   1.058   1.076   1.000   1.136
  41. MUL BP; JMP       F7,E5,EB,00   1.062   1.062   1.000   1.087
  42.  
  43. Timing is normalized to the fastest time in each row.
  44.  
  45. Anyone from Intel like to comment on why the 386SX (mis)behaves this
  46. way?  I'd expect this sort of behaviour on a 386DX with 16 bit memory
  47. but not on a 386SX which can (and does) fetch words rather than dwords.
  48.