home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / acorn / tech / 1454 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.7 KB
  1. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mucs!cs.man.ac.uk!endecotp
  2. From: endecotp@cs.man.ac.uk (Phil Endecott)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Re: ARM risc speed?
  5. Message-ID: <endecotp.728134671@cs.man.ac.uk>
  6. Date: 27 Jan 93 11:37:51 GMT
  7. References: <1993Jan20.151326.23097@infodev.cam.ac.uk> <1993Jan20.163935.29452@dcs.warwick.ac.uk> <1993Jan21.114022.5930@cs.nott.ac.uk> <2804@eagle.ukc.ac.uk>
  8. Sender: news@cs.man.ac.uk
  9. Lines: 93
  10.  
  11. spt1@ukc.ac.uk (S.P.Thomas) writes:
  12.  
  13. >In article <1993Jan21.114022.5930@cs.nott.ac.uk> smb@cs.nott.ac.uk (Simon Burrows) writes:
  14. >>A while ago Acorn sent out some guidelines on code sequences which should
  15. >>no longer be used if compatibility with future processors is to be maximised.
  16. >>They were issued before the ARM250 was brought out, so probably apply to that?
  17.  
  18. >I am very interested in this,
  19. >as I've built an, um "experimental" lazy functional language compiler
  20. >that generates ARM assembler as its target code.
  21.  
  22. You probably don't have anything to worry about.  Presumably your code runs
  23. only in user mode; the principle restriction is about accessing banked
  24. registers after a mode change, and this doesn't affect user mode code.
  25.  
  26. >In a similar vain, one of the optimisations I do is to cause the
  27. >code to be generated such that the starting addresses of the
  28. >code sequences that can be jumped to are aligned to have an address
  29. >of &XXXXXX4.  This maximises the number of consequtive (sp?) sequential
  30. >memory cycles when using MEMC1a.  I have three main questions.
  31.  
  32. As well as reducing the number of non-sequential MEMC accesses, this will
  33. improve the performance of the ARM3's cache, as cache lines are aligned
  34. quadwords.  If you jump to a non-aligned location, the cache will be loaded
  35. with the preceeding words from the alignment boundry.  If these don't
  36. contain useful code you are wasting that part of the cache.
  37.  
  38. The DEC Alpha architecrture handbook has an interesting diagram showing
  39. that half of the code brought into the VAX cache when running LINPAC is
  40. never executed for this reason.  They suggest that as well as aligning
  41. branch targets, rarely executed code should be put out-of-line. They
  42. indicate that the compiler should be able to profile its code to determine
  43. which half of each if-then-else construct is the more frequently executed
  44. part; this also helps to reduce the number of branches that a program
  45. encounters.  Could your functional language compiler do this ?
  46.  
  47. >1) The effect of this alignment is quite significant on an ARM2
  48. >machine.  Would the effect be as significant on an ARM3 (or ARM250,
  49. >although I suspect the answer is yes, in this case)?
  50.  
  51. Yes on the ARM3; probably more so than on the ARM2 for the reason mentioned
  52. above.  The ARM250 will behave exactly as the ARM2+MEMC.
  53.  
  54. >2) In the next generation of memory controllers, are different rules
  55. >likely to apply?  If so (I suspect this is highly likely), can anyone
  56. >give me an idea what they might be?
  57.  
  58. No-one knows, but the variables that can be adjusted include the sequential
  59. burst length and the cache line length.
  60.  
  61. >3) Is it possible that certain orderings of instructions are "better"
  62. >than others (ie, faster), even though they achieve the same effect?  For
  63. >example
  64.  
  65. >        ADR    ad1,blk1                    ADR    ad1,blk1
  66. >        LDMIA  ad1,{r0-r7}   compared      ADR    ad2,blk2
  67. >        ADR    ad1,blk2        with        LDMIA  ad1,{r0-r7}
  68. >        STMIA  ad1,{r0-r7}                 STMIA  ad2,{r0-r7}
  69.  
  70. On all the current ARMs, these instruction sequencies will take exactly the
  71. same time.  The ARM pipeline is quite simple with single stage execute and
  72. even dependencies between adjacent instructions don't slow it down.
  73. However if in the future an ARM was built with a more sophisticated
  74. pipeline like the Alpha or the MIPS chips have or with a Harvard
  75. architecture (separate instruction and data memory ports), then sequencies
  76. that avoid dependencies would run faster.
  77.  
  78. On the ARM600 and 610, the write buffer does have an impact on the speed of
  79. some sequencies.  For example :
  80.  
  81.     ADR ad1,blk1            ADR ad1,blk1
  82.     STMIA ad1,{r0-r15}      ADR ad2,blk2
  83.     ADR ad2,blk2            STMIA ad1,{r0-r15}
  84.     STMIA ad2,{r0-r15}      STMIA ad2,{r0-r15}
  85.  
  86. Although the write buffer very rarely fills in 'typical' code, if you tried
  87. to run either of these code sequencies it would fill up because you are
  88. trying to transfer 32 registers in 4 instructions.  You can reduce the
  89. effect of this by spreading out the STMs as far as possible; the left hand
  90. example will run slightly faster.
  91.  
  92.  
  93. >These sort of sequences occur a great deal in the code I'm generating.
  94. >If there is a difference, what are the rules?
  95.  
  96. There is no effect on the ARM2, ARM3 or ARM250.
  97.  
  98.  
  99. >Keep well,
  100.  
  101. >Stephen Thomas
  102.  
  103. --Phil.
  104.