home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / CHOSNECK / CHOS2.ZIP / CHOSNECK.2ND / STUFF / DATAS.ZIP / ART50.SCR < prev    next >
Encoding:
Text File  |  2003-12-08  |  8.0 KB  |  196 lines
  1. <head>
  2. <title="...forever...">
  3. <font=monaco10.fnt>
  4. <font=newy36.fnt>
  5. <font=time24.fnt>
  6. <image=back.raw w=256 h=256 t=-1>
  7. <buf=2864>
  8. <bgcolor=-1>
  9. <background=0> 
  10. <link_color=253>
  11. <module=console.mod>
  12. <pal=back.pal>
  13. colors:
  14. 251 - black
  15. </head>
  16. <body>
  17. <frame x=0 y=0 w=640 h=2864 b=-1 c=-1>
  18.  
  19.  
  20. - - --- -- --------------------------------------------------------------------  
  21.  <f1><c000>      Optimizing for FastRAM <f0>
  22.  <f1><c000>              & 68060 CPU <f0>
  23. ------------------------------------------------------------------ - - -- -----
  24.  
  25. Well, so it happend, ct60 arrived to our hands =) Short time after receiving my
  26. CT60 I've  got  some  nice  c2p  source  from  Evil/DHS  by  Michael  Kalms aka
  27. Scout/Appendix where I learned some things about 060 so why not write it here:)
  28.  
  29. Burst mode
  30. ==========
  31. I was very surprised when I didn't find  'burst mode' bit in CACR register. But
  32. this doesn't mean 060 has no burst...  060  operates in burst mode all the time
  33. :) And what is this burst mode?  If  you  read  my article about 030 timing you
  34. know how it works in the 030 cache:  every  word  or long read has its place in
  35. data cache (unless the data cache isn't disabled and/or frozen of course)... so
  36. if you want to load let's say 32 bytes into data cache you have to do on 030:
  37.  
  38.         tst.w   0(a0)           ;  4 bytes loaded
  39.         tst.w   4(a0)           ;+ 4 bytes
  40.         tst.w   8(a0)           ;+ 4 bytes
  41.         tst.w   12(a0)          ;+ 4 bytes
  42.         :
  43.         :
  44.         tst.w   28(a0)          ;+ 4 bytes = 32 bytes
  45.  
  46. Since every data entry is stored  as  a  long...  you  can use the advantage of
  47. misaligned operands:
  48.  
  49.         tst.w   3(a0)           ;  4+4 bytes loaded
  50.         tst.w   11(a0)          ;+ 4+4 bytes
  51.         tst.w   19(a0)          ;+ 4+4 bytes
  52.         tst.w   27(a0)          ;+ 4+4 bytes = 32 bytes
  53.  
  54. Since we're filling two entries at once  (because of misaligned words). And now
  55. the Burst Mode: this one allows you to load 16 bytes at once if your cache line
  56. is 'clean', that means all entries  are  marked  as  'invalid' and your data is
  57. read from a 16 bytes boundary:
  58.  
  59.         tst.w   (a0)            ;  16 bytes loaded
  60.         tst.w   16(a0)          ;+ 16 bytes = 32 bytes
  61.  
  62. And we can again use advantage of misaligned operands:
  63.  
  64.         tst.w   0*16+15(a0)     ; 32 bytes loaded
  65.         tst.w   2*16+15(a0)     ; next 32 bytes loaded
  66.  
  67. Cool isn't it? :) By the way, you can use this trick on CT2, too, since CT2 has
  68. FastRAM & burst support  for  it.  But  don't  forget  to enable the previously
  69. mentioned bit in the CACR !!!
  70.  
  71. Writing to ST RAM
  72. =================
  73. Yeah, yeah... we have got superb 68060 CPU, superb FastRAM and still we have to
  74. do what? Write to ST RAM! Now someone  could  ask if 68060 and FastRAM helps in
  75. this area, too. So, for very curious people: YES, IT DOES :) How?
  76.  
  77. 1. Store Buffer
  78. ---------------
  79. Even if our 8 KB data cache is  a  lot of space, for copying thousands of bytes
  80. It isn't very useful :) And so  here  comes  our store buffer into play: it's a
  81. four  entry (that means 4 longs)  first-in-first-out  buffer used by writing to
  82. slow memory. So, if we want to write  a  word or long to memory and the databus
  83. is still used by the previous memory  write,  this value will be stored in this
  84. buffer and the program will continue to the next (hopefully not memory operate)
  85. instruction.
  86.  
  87. 2. Instruction overlapping
  88. --------------------------
  89. I touched this topic in 030  timing  article  a  little bit: If your code isn't
  90. only about writing to ST RAM, you  can  use this very nice trick with fantastic
  91. results. I mean here a famous chunky  to  planar routines of course. Let's make
  92. some analysis:
  93.  
  94. For 320*240/TC you need  to  transfer/clear  320*240*2  =  153600 bytes what is
  95. 76800 words. If one word takes  4  cycles  to  write  to memory, we need 307200
  96. cycles. And most demos didn't use 'true'  truecolor: they used lookup table for
  97. 256 colours + additional values for lighting, shading or pixel overlapping...
  98.  
  99. What about 256 colour modes? On  standard  Falcon  we can't use them because of
  100. ... bitplanes. Simply, without FastRAM you have to:
  101. - clear chunky buffer in ST RAM (320*240 bytes = 38400 words)
  102. - do some nice 3D stuff (variable amount of writes)
  103. - copy from chunky buffer to screen memory (2*38400 words since both chunky
  104.   buffer and screen are in ST RAM)
  105.  
  106. This gives us 3*38400 words what is 3*38400*4 = 460800 cycles and still without
  107. instruction timings.. so it's slower than TC..
  108.  
  109. OK, but FastRAM comes into play! The situation looks much much better:
  110. - clearing chunky buffer in FastRAM (19200 longs)
  111. - do some nice 3D stuff (still in FastRAM)
  112. - c2p conversion (19200 longs to transfer = 38400 words)
  113.  
  114. So... if one write to SDRAM is one 66.666 MHz clock cycle what is
  115. 16/66.666 = 0.24 of one 16 MHz clock cycle we get:
  116.  
  117. 19200*0.24 + 38400*4 = 158208 cycles! Let's compare:
  118.  
  119. 320*240/TC: 307 200 cycles + reads from lookup table
  120. 320*240/256: 158 208 cycles
  121.  
  122. Maybe you ask why I'm so sure c2p  conversion will not take some cycles ;) It's
  123. because of instruction overlapping. If you  write  a  long to ST RAM (typically
  124. c2p where we are writing longs) it takes eight 16 MHz cycles:
  125.  
  126. 2*4*(1/16000000) / (1/66666000) ~ 33 66.666  MHz  cycles between each c2p pass.
  127. And be sure in this time you can do everything :)
  128.  
  129. Here we see  that  idea  of  putting  our  truecolor  screen  into  FastRAM has
  130. practically no sense - ok, we have our buffer in SDRAM:
  131.  
  132. - clearing of buffer: 320*240*2 = 38400 longs
  133. - doing stuff in FastRAM...
  134. - copying to ST RAM: 38400 longs to transfer = 76800 words
  135.  
  136. 38400*0.24 + 76800*4 = 316416... we didn't  help ourselves very much... 2 times
  137. slower than 256 colours mode....
  138.  
  139. Caches
  140. ======
  141. Only some words on this topic: unroll  your  loops !!!!!!!!!!!!!! =) And for ST
  142. RAM operations... try to optimize a program pipeline to the max...
  143.  
  144. Superscalar architecture
  145. ========================
  146. People, this thing rules =) It's a little  bit similar to the DSP pipeline, but
  147. with much more freedom. Here's a copy&paste  from  one mail by Amiga guy Thomas
  148. Richter:
  149.  
  150. ---------------
  151. Actually, the '060 UM is sufficient  in  this  topic.  The '060 has two ALUs of
  152. which one has only  a  restricted  instruction  set  (the sOEP).  Most *simple*
  153. operations can run in parallel in the  pEOP and sOEP provided the results don't
  154. depend on each other (and provided you don't trip on a bug in the '060 of which
  155. - unfortunately - there are some).
  156.  
  157. Thus,
  158.  
  159.  add.l d0,d1
  160.  add.l d2,d3
  161.  
  162. can be executed in parallel since "add"  can  be executed in both ALUs, and the
  163. source of the second instruction does not depend on a result of the first.
  164.  
  165. Instructions as "sOEP|pOEP" run on both  ALUs.  Those marked as "pOEP" can only
  166. run on the primary ALU and hence  may  cause stalls. Further-more, the FPU runs
  167. in parallel with the integer unit, it makes  quite some sense to 'fire off' the
  168. FPU and to perform integer arithmetic while the FPU is busy.
  169.  
  170. Thus, programming hint:  Try  to  'interleave'  instructions  from two separate
  171. instruction pipelines to keep both ALUs  busy.  For  example, if you have tight
  172. inner loops, unroll  the  loop  (if  possible)  into  two  parallel instruction
  173. streams.
  174. ---------------
  175.  
  176. I proved this to myself by modifying that  c2p routine which Evil sent me and I
  177. have to say, it's faster! Even with incredible slow ST RAM writes!
  178.  
  179.  
  180. And that is it... just short overview  if  you  are too lazy to read Motorola's
  181. docs ;) What to say at the end...  make sure you have enabled intruction & data
  182. & branch cache, enabled FIFO  buffer  for  data  cache and enabled "superscalar
  183. mode" in PCR !
  184.  
  185. I attached to this article mentioned c2p routine,  I don't know a faster one at
  186. this time ;)
  187.  
  188. CT60 rules !!!!!!!!!!!! =)
  189.  
  190.  
  191. -------------------------------------------------------------------------------
  192.    MiKRO             XE/XL/MegaSTE/Falcon/CT60               mikro.atari.org
  193. -------------------------------------------------------------------------------
  194. </frame>
  195. </body>
  196.