home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text0602.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  3.3 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id PAA00669 for <executor@nacm.com>; Wed, 26 Apr 1995 15:55:03 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id QAA15753; Wed, 26 Apr 1995 16:58:07 -0600
  3. Received: from gwar.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0s4FyN-000YbDC; Wed, 26 Apr 95 16:54 MDT
  5. Received: by gwar.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0s4FyJ-000GOeC; Wed, 26 Apr 95 16:54 MDT
  7. Message-Id: <m0s4FyJ-000GOeC@gwar.ardi.com>
  8. Date: Wed, 26 Apr 95 16:54 MDT
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: jered@MIT.EDU
  11. Cc: executor@nacm.com
  12. Subject: Re: 486 optmization
  13. In-Reply-To: <9504262205.AA12887@bill-the-cat.MIT.EDU>
  14. References: <9504262205.AA12887@bill-the-cat.MIT.EDU>
  15. Sender: owner-executor@nacm.com
  16. Precedence: bulk
  17.  
  18.  
  19. [Note: this is a fairly technical reply to Jered's question, but there
  20.  are a bunch of assembler-heads on this list, so I thought I'd post it.
  21.  Most people will just want to skip this message.]
  22.  
  23. >>>>> "jered" == jered  <jered@MIT.EDU> writes:
  24.  
  25.     jered> I just saw on the linux kernel discuss meeting that 486es
  26.     jered> and higher have a special instruction for converting
  27.     jered> big-endian to/from little-endian.  Does anyone know if gcc
  28.     jered> (djgpp) uses this and optimizes for it, what sort of
  29.     jered> performance increase it might give, and if it would be
  30.     jered> worth anyone's while to have a 486-higher executable of
  31.     jered> Executor?
  32.  
  33. Jered is talking about the "bswap" instruction, which byte swaps a
  34. four-byte value in a register in one cycle.  It was added when the
  35. 80486 came out, so it isn't present on 80386's.  It's non-pairable on
  36. the Pentium.
  37.  
  38. gcc doesn't generate the "bswap" instruction, because it won't work on
  39. an 80386.  I don't know if gcc has any way of doing anything special
  40. for byte swaps anyway.  The -m486 flag isn't allowed to generate code
  41. that won't run on an 80386, so gcc couldn't generate a bswap.  From
  42. gcc.info:
  43.  
  44.  `-m486'
  45.  `-mno-486'
  46.       Control whether or not code is optimized for a 486 instead of an
  47.       386.  Code generated for an 486 will run on a 386 and vice versa.
  48.  
  49. Executor's C code uses inline assembly to byte swap with three rotate
  50. instructions, which works on both the 80386 and 80486+.  Our CPU
  51. emulator (syn68k) decides at runtime if you have an 80486 or better
  52. and generates bswap instructions "on the fly" if you do.  Otherwise,
  53. it generates three rotate instructions.
  54.  
  55. A version of Executor that didn't work on 80386's would be a little
  56. smaller and a little faster than the current one, but there's no
  57. reason to think the performance difference would be huge.  We
  58. benchmarked such a version long, long ago and found that an
  59. 80486-specific version was something like 5-10% faster.
  60.  
  61. Note that since NEXTSTEP/Intel only works on 80486's or better,
  62. Executor/NEXTSTEP/Intel assumes the presence of an 80486 and takes
  63. advantage of it.
  64.  
  65. The new, faster blitter I'm writing may take advantage of the bswap
  66. instruction, if present.  Once that's done, the CPU emulator and the
  67. graphics engine will both use bswap, so there won't be much
  68. performance to gain by creating an 80486-specific version of Executor.
  69.  
  70. Thanks for the suggestion, though.
  71.  
  72. -Mat
  73.  
  74.