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 / ART46.SCR < prev    next >
Encoding:
Text File  |  1989-06-08  |  10.9 KB  |  241 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=3590>
  8. <bgcolor=-1>
  9. <background=0> 
  10. <link_color=000>
  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=3590 b=-1 c=-1>
  18.  
  19.  
  20. --- - -- - --------------------------------------------------------------------
  21. <f1><c000>                     68030 <f0>
  22. <f1><c000>    ST RAM and things around it <f0>
  23. ---------------------------------------------------------------------- ---- - -
  24.  
  25. I tell you the truth - I'm  always  reading  about  how slow ST RAM is and that
  26. Fast RAM is something unbeatable etc, but  I  never knew WHY. There is only one
  27. Falcon timing document - the one published  by  Rodolphe Czuba with CT2. But in
  28. my eyes, this doc is so  short/unclear  and SHITTILY translated, there's no way
  29. to get the idea for non-hw freaks like me.  But one nice day I told myself: "It
  30. can't be so hard... other ppl understood  that,  I can too" :-) So I downloaded
  31. both uk and fr version of the mentioned doc and started to read...
  32.  
  33. OK, after some weeks :) I've got  that  damned  idea... I have to say I haven't
  34. got any oscilloscope or  any  other  device  to  verify  my  results, but there
  35. shouldn't be big differences. From time to time I use some numbers by Rodolphe.
  36. So, let's start!
  37.  
  38. Let's talk something about timing tables at first:
  39.  
  40. We want to know how many cycles the move.l (an)+,d0 instruction is. If you take
  41. a look into official timing tables by Motorola (and rewritten by Zyx/Inferiors,
  42. JHL/TRSI, aRt/TBL and others):
  43.  
  44. MOVE    EA,Dn   0       0       2(0/0/0)        2(0/1/0)
  45.  
  46. and for EA calculation:
  47.  
  48.         (An)+   0       1       3(1/0/0)        3(1/0/0)
  49.                 ----------------------------------------
  50.                                 5(1/0/0)        5(1/1/0)
  51.  
  52. From this example you can see:
  53. - no overlapping will occur
  54. - move (an)+,dn takes 5 bus-cycles at all (cache setting doesn't matter)
  55. - data reading takes 1 bus-cycle
  56. - i-prefetching takes 0 (if it's in i-cache) or 1 (if isn't) bus-cycle
  57. - data writing takes 0 bus-cycles
  58.  
  59. According to Motorola, this table assumes:
  60. - 32 bit data bus
  61. - 1 bus-cycle = 2 clock (cpu) periods
  62. - 2 i-prefetches per 1 bus cycle
  63. - long aligned operands incl. system stack
  64. - no wait states
  65. - data cache disabled
  66.  
  67. Instruction prefetch means "loading"  of  the  instruction  into CPU, including
  68. additional <ea> extensions. In the  simplest  case,  one instruction prefetch =
  69. one word prefetch (since basic instruction on 68k  is 16 bit). In case of movem
  70. instruction for example, CPU has to prefetch  one long = 2 word prefetches. But
  71. we see, it still takes the same time  (it isn't important if we transfer a word
  72. or long with 32 bit  data  bus)  Conclusion:  it  doesn't  matter if we have to
  73. prefetch one or two words for a complete instruction, it takes the same time.
  74.  
  75. bus activity:  1*2 (data read) + 0*2 (prefetching) = 2 in cache-case or
  76.                1*2 (data read) + 1*2 (prefetching) = 4 in non-cache-case
  77.  
  78. So, number of internal cycles for execution:
  79. all cycles - bus activity = 5 - 2 = 3 for cache-case or
  80.                             5 - 4 = 1 for non-cache-case
  81.  
  82. Please note there's no dependency  between  internal  cycles for both cache and
  83. non-cache cases. Sometimes it's faster executing/decoding with cache, sometimes
  84. without cache. Ofcourse we're talking only  about internal cycles and very fast
  85. (2 clock periods per 32 bit) RAM  access,  in  case of slow memory you will see
  86. that difference. Also keep in  mind  values  for i-prefetching are AVERAGE ones
  87. for odd/even word -> final value  is  always  less  or equal to the current bus
  88. status. In practice: let's take our movem  example.  In  all cases it is min. 2
  89. words long, right? But in calculations, it's always divided into 2 i-prefetches
  90. -> i-prefetching takes 2*2 = 4 clock  periods  and  real bus status is only 1*2
  91. clock periods. (in case of long aligned  operands  and 32 bit data bus ofcourse
  92. !!!) Also don't be surprised if you get result of 0 internal cycles sometime.
  93.  
  94. But hey, that's our dream machine and not Falcon030! =) Reference for us should
  95. be:
  96.  
  97. - 16 bit data bus
  98. - 1 WORD bus-cycle = 4 clock periods (according to Czuba's doc)
  99. - refreshing every 15.6 us [wait states] (again Czuba's doc)
  100.  
  101. This stuff implies that the table above is  bad. At least the overall number of
  102. cycles. There's a need for some changes:
  103.  
  104. - if you have 32 bit data bus, doesn't matter if you read (long aligned)
  105.   long or word - it still takes the same time. In our case it DOES matter
  106.   since 1 bus read = 1 WORD read, NOT LONG
  107. - as you can see, bus activity is 2 times longer (2 vs 4 clock periods)
  108.  
  109. So correct timing should look like this:
  110.  
  111. move.w (an)+,dn 0       1        7(1/0/0)        9(1/1/0)
  112. move.l (an)+,dn 0       1       11(2/0/0)       13(2/1/0)
  113.  
  114. How I got these numbers?
  115.  
  116. bus activity for move.w:
  117. 1*4 (data read) + 0*4 (prefetching) = 4 in cache-case or
  118. 1*4 (data read) + 1*4 (prefetching) = 8 in non-cache-case
  119.  
  120. bus activity for move.l:
  121. 2*4 (data read) + 0*4 (prefetching) = 8  in cache-case or
  122. 2*4 (data read) + 1*4 (prefetching) = 12 in non-cache-case
  123.  
  124. And from example above we know this move takes 3 (cache) / 1 (non-cache)
  125. internal cycles: 4+3=7 / 8+1=9 (move.w) and 8+3=11 / 12+1=13 (move.l)
  126.  
  127. Here we see we needn't care  about  1-word vs 2-word instructions anymore since
  128. our bus can transfer only words :) That means if an instruction takes one word,
  129. it needs 1*4 clock periods, if it  takes  two words, it needs 2*4 clock periods
  130. etc.
  131.  
  132. We're more than 2 times slower than an 'original' 68030 in long transfer ! Here
  133. I stop talking  about  timing  tables,  it's  more  complicated  than you could
  134. expect, I mean especially  pipelining  &  intruction/data  cache  stuff, it's a
  135. topic for separate article. (mail me and I'll write about it)
  136.  
  137. So, back to ST-RAM:
  138.  
  139. The Falcon is equiped with  Motorola  68030@16  MHz  and  16 bit data bus. That
  140. means CPU can access to RAM only 1  word  per bus-cycle. The one bus-cycle is 4
  141. clock periods long -> CPU can  read/write  one  word every 4th clock period (in
  142. the next text I assume 16  MHz  clock  period  = 1 cycle). Luckily, during this
  143. time CPU isn't halted  totally  -  if  CPU  doesn't  access any external source
  144. (ST/TT RAM, hardware regs, ...) you  can  execute some other instructions which
  145. are doing stuff in CPU (this should  allow  use  of  the data cache, too, but I
  146. didn't get  very  good  results..)  By  the  way,  instructions...  the fastest
  147. instruction on 030 takes 2  cycles,  but  you  can't  use these two intructions
  148. during the bus write since  you  have  got  less  than  4  cycles, I don't know
  149. exactly why.. Or, you can write to ST-RAM one long (that means <8 cycles pause)
  150. and here you have time for three  2-cycles instructions.. not very much, I know
  151. =)
  152.  
  153. So, if 1 cycle is 1/16000000 s  =  62.5  *  10^-9  s  = 62.5 ns and CPU needs 4
  154. cycles for RAM access, complete  reading/writing  is  4  *  62.5 = 250 ns long.
  155. Remember our SIMMs have usually 80 ns,  that  means  CPU can access to this RAM
  156. 3.125 times faster ! And this is only beginning of time wasting :)
  157.  
  158. 1 word = 2 bytes -> we can  transfer  2  bytes per 4 cycles -> 1/2 byte[4 bits]
  159. per cycle. If one cycle is 62.5 ns:
  160.  
  161. 0.5/62.5ns = 8 000 000 bytes per second. Fiction.
  162.  
  163. Let's take a look at the move.l (an)+,dn again. We calculated in worst case (no
  164. instruction cache) it takes 13 cycles, right? What is the max reading speed?
  165.  
  166. 16000000/13 longs/s = 16000000*4/13 bytes/s = 4 923 076 bytes/s. Shame!
  167.  
  168. Do you think it can't be worse? Okie, let's continue...
  169.  
  170. Here is another bus-cycle-stealer: DMA.  DMA  means  Direct Memory Access. That
  171. 'direct' means if DMA device wants something from  RAM, CPU can fuck up and has
  172. to wait until the DMA device  has  finished.  In  Falcon we have 3 DMA devices:
  173. Videl, Blitter and Sound DMA. I'm not going to talk about Blitter or SDMA since
  174. these chips aren't necessary for  EVERY  application,  but  grafix we need from
  175. time to time :-)
  176.  
  177. Eeeehhh... what example to  give?  I  think  320x240xTC  could be interresting,
  178. couldn't it?
  179.  
  180. 320 x 240 x 2 bytes = 153600 bytes = 38400 longs. Videl access to video-data in
  181. so called BURST mode, that means 17 longs  per one Videl (!) access. This BURST
  182. mode looks like:
  183.  
  184. 1st long = 2 (RAS cycle = init) + 1 (CAS cycle = data)  =  3 cycles
  185. 2nd ~ 17th long =                 16 (CAS cycles)       = 16 cycles
  186.                                                           ---------
  187.                                                           19 cycles
  188. (thanks to Rodolphe for this explanation)
  189.  
  190. So one BURST access = 19 cycles.
  191. 38400/17 = 2259 BURST accesses and 2259 * 19 = 42921 cycles per screen.
  192.  
  193. That gives us 42921 * 60 =  2  575  260  cycles  per second for Videl (!!!). 60
  194. stands for 60 Hz ofcourse. 50 could be for 50 Hz, 100 for 100 Hz etc
  195.  
  196. Due to DMA stealing we lose: 16000000 - 2575260 = 13 424 740 cycles/s !!!
  197.  
  198. So, what about our move.l ?
  199.  
  200. 13424740/13 longs/s = 13424740*4/13 bytes/s = 4 130 689 bytes per second...
  201.  
  202. Are you still thinking Falcon is fantastically developed? =) Ok...
  203.  
  204. This example assumes all  your  RAM  reading  is  sequential, that means you're
  205. reading address n+$0, n+$2, n+$4, n+$6 etc.  Maybe  you think: "nah and what? I
  206. have all my data together and  my  program  doesn't  jump every time". Hahah my
  207. little lady! =) How does your RAM accessing look?
  208.  
  209. lea     something,a0
  210. move.l  d0,(a0)+
  211. move.l  d3,(a0)+
  212. :
  213. :
  214. for example. But remember  the  CPU  fetches  instructions from your code-space
  215. (text-segment), then writes some long data  to  ANOTHER area, then fetches next
  216. instruction, ... etc. And we still assume  all  your code and data is word/long
  217. aligned ! (for more info  about  aligning  see below) For non-sequential access
  218. you have  to  add  2  cycles  for  precharge  time  (again  Czuba's  number) to
  219. instruction time. In our case:
  220.  
  221. 13424740/(13+2) longs/s = 13424740*4/(13+2) bytes/s = 3 579 930 bytes/s...
  222.  
  223. Our 256 byte chache can solve these  troubles with precharging. If you put your
  224. loop  into  the  instruction  cache,  the  data  bus  will  be  used  only  for
  225. reading/writing data. If you're really,  really  lucky  boy, in case of reading
  226. you can put both program  and  read  data  in  the  instr/data cache and no bus
  227. transfer will be done.  In  case  of  writing,  data  is  ALWAYS transferred to
  228. memory, since our cache works in so called 'write-through' mode. 040 and higher
  229. works in 'write-back'  mode,  here  it  isn't  always  necessary  to access RAM
  230. (better internal logic)
  231.  
  232. Now, we killed the last cycle in our  Falcon  :-)  Ah, not the last - there are
  233. still those stupid wait  states...  but  as  Rodolphe  wrote, they don't affect
  234. calculations a lot. If you want some additional info how to implement them into
  235. timing tables, I refer you to the 68030 User's Manual by Motorola.
  236.  
  237. <link=art46b.scr>Go to NEXT PART</l>                                  
  238. </frame>
  239. </body>
  240.  
  241.