home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / documentation / documents / a252swp < prev    next >
Internet Message Format  |  1999-04-27  |  22KB
  1. From: john@acorn.co.uk (John Bowler)
  2. Subject: Re: Multiprocessing Archimedes??
  3. Date: 16 Aug 91 11:10:50 GMT
  4.  
  5. torq@GNU.AI.MIT.EDU (Andrew Mell) writes:
  6. >I notice that the Arm3 has a new instruction over the Arm2 which is
  7. >SWP. It swaps a byte or a word between register and external memory.
  8. >(uninterruptible between the read and write)
  9.   ^^^^^^^^^^^^^^^
  10.  
  11. Indeed, but not necessarily not interleavable with other memory operations
  12. (sorry about the double negative :-).  In particular, to fully support the
  13. SWP on a system with multiple memory bus masters the memory control logic
  14. which decides which bus master has access to the memory next would have to
  15. force an interlock between the memory read and memory write of the SWP
  16. instruction.  Now, the ARM3 has a LOCK pin for this, but to support
  17. multi-processors you need to connect it to something :-).
  18.  
  19. >All very interesting you might say, but it intrigues me as this sort
  20. >of instruction is usually only used in multiprocessor systems as a 
  21. >software semaphore.
  22. >
  23. >Why did Acorn add this instruction to the Arm3?
  24.  
  25. Because a long time ago, when we were very young (;-) we tried to write a
  26. multi-threaded OS (ARX) and we ``found'' (sic, thought)  that it was
  27. spending a lot of time going into supervisor mode and disabling interrupts
  28. so that it could implement mutexes (for user mode code - including the OS,
  29. which ran in user mode too).  In theory SWP allows user code to implement
  30. mutexes efficiently.
  31.  
  32. As far as I am concerned the MP aspects of SWP are bonuses (clearly these
  33. were considered at the same time - or the LOCK pin wouldn't be there).
  34. Notice that SWP always bypasses the cache; again this is MP support, however
  35. there is an ommission here in that it is impossible to do a (reliable) read
  36. from external memory (you might get the cache contents instead!)
  37.  
  38. John Bowler (jbowler@acorn.co.uk)
  39.  
  40.  
  41. From: john@acorn.co.uk (John Bowler)
  42. Subject: Re: Multiprocessing Archimedes??
  43. Date: 19 Aug 91 16:25:33 GMT
  44.  
  45. julian@bridge.welly.gen.nz writes:
  46. >john@acorn.co.uk (John Bowler) writes:
  47. >
  48. >> Notice that SWP always bypasses the cache; again this is MP support, however
  49. >> there is an ommission here in that it is impossible to do a (reliable) read
  50. >> from external memory (you might get the cache contents instead!)
  51. >
  52. >If you're using it to implement semaphores, this is not a problem, as you'd
  53. >never need to access the semaphore with any instruction other than SWP.
  54.  
  55. Yes; there is no problem with the semaphore, but the semaphore must be
  56. protecting some state which is shared.  When a processor has claimed that
  57. semaphor it probably needs to read the state and to obtain consistent
  58. results when it reads it.  If the data is in cacheable memory the only way
  59. it can do that is to use sequences of the form:-
  60.  
  61.              SWP rx, rx, [raddr]         ; read a value out
  62.              STR rx, [raddr]             ; and put it back... :-(
  63.  
  64. The alternative is to allocate shared data in uncacheable memory.  This
  65. requires some OS intervention (a user program cannot simply allocate
  66. shareable data structures out of its own heap unless the whole heap is
  67. uncacheable) and uncacheable data obviously has a performance hit.
  68.  
  69. >BTW. You wouldn't happen to know the instruction format for SWP, by any
  70. >     chance? If a software emulator can be written for it for ARM2 machines
  71. >     (like the FPE - or even add it to the FPE) then we can all start using
  72. >     it.
  73.  
  74. RISC iX 1.2 emulates the SWP instruction on machines which do not support
  75. it.  RISC OS doesn't.  The assembler syntax is:-
  76.  
  77.          SWP{cond}{B}      Rd, Rm, [Rn]
  78.  
  79. the semantics (except for the cache behaviour and so on) are:-
  80.  
  81.          MOV              <temp>, Rm
  82.          LDR{cond}{B}     Rd, [Rn]
  83.          STR{cond}{B}     <temp>, [Rn]
  84.  
  85. (ie the SWP Rx, Rx, [Raddr] example above *does* store the *old* Rx value
  86. in [Raddr]... :-).
  87.  
  88. The instruction format is:-
  89.  
  90.      bit 31                                                        bit 0
  91.        c.o.n.d.0.0.0.1 0.B.0.0.n.n.n.n d.d.d.d.0.0.0.0 1.0.0.1.m.m.m.m
  92.  
  93.        c.o.n.d - the condition
  94.        B       - 0 = swap word
  95.                  1 = swap byte
  96.        n.n.n.n - Rn
  97.        d.d.d.d - Rd
  98.        m.m.m.m - Rm
  99.  
  100. Data aborts (from the memory manager) leave Rd/Rm as they were before.
  101. SWP bypasses the ARM3 cache, although the write operation still updates
  102. the cache (if the address is cached).  I don't know whether the read
  103. will cause the rest of that part of the cache to be updated (I assume
  104. not, and the programmer should not care :-)
  105.  
  106. John Bowler (jbowler@acorn.co.uk)
  107.  
  108.  
  109.  
  110. From: dseal@armltd.co.uk (David Seal)
  111. Subject: Re: ARM3 instructions.
  112. Date: 4 Sep 92 15:01:12 GMT
  113.  
  114. In article <4422@gos.ukc.ac.uk> amsh1@ukc.ac.uk (Brian May#2) writes:
  115.  
  116. >  I don't have an Archie myself but have used them quite a lot in the past.
  117. >I was recently mucking about with a friend's A5000, trying to find the new
  118. >instructions that turned the cache on and off. I found them, they were
  119. >co-processor instructions with the processor itself as (I think) number 0.
  120.  
  121. Coprocessor 15, in fact.
  122.  
  123. >  Anyway, as I was disassembling away I found a new instruction (well, I had
  124. >never come across it before). It was 'SWP' and I imagine it swaps registers
  125. >with registers, maybe with memory as well? I can't remember. If it does
  126. >reg<->mem as well, and is uninterruptable, perhaps it is for use as a
  127. >semaphore in multi-processor systems?
  128.  
  129. The SWP instruction was new to the ARM2as macrocell. I believe ARM3 was the
  130. first full chip which contained it. More recent macrocells and chips like
  131. ARM6, ARM60, ARM600 and ARM610 also contain it.
  132.  
  133. It only swaps a register with a memory location (either a byte or a word),
  134. and not two registers. It can however read the new contents of the memory
  135. location from one register, and write the old contents of the memory
  136. location to another register - i.e. it doesn't have to do a pure swap. This
  137. may be the source of your idea that it can swap two registers. It is indeed
  138. uninterruptable, and yes, it is intended for semaphores.
  139.  
  140. >  Of course I won't be the first person to notice this so I wondered, could
  141. >someone post some info on this, and also on the co-processor instructions
  142. >relevant to the CPU itself?
  143.  
  144. The SWP instruction:
  145.   Bits 31..28: Usual condition field
  146.   Bits 27..23: 00010
  147.   Bit 22:      0 for a word swap, 1 for a byte swap
  148.   Bits 21..20: 00
  149.   Bits 19..16: Base register (addresses the memory location involved)
  150.   Bits 15..12: Destination register (where the old memory contents go)
  151.   Bits 11..4:  00001001
  152.   Bits 3..0:   Source register (where the new memory contents come from)
  153.  
  154.   Byte swaps use the bottom byte of the source and destination registers,
  155.   and clear the top three bytes of the destination register. There are
  156.   various rules about how R15 works in each register position, similar to
  157.   those for LDR and STR instructions. The destination and source registers
  158.   are allowed to be the same for a pure swap. I don't know offhand what
  159.   would happen if the base register were equal to one or both of the others,
  160.   but I don't think I'd recommend doing it!
  161.  
  162.   Assembler syntax is (using <> around optional sections):
  163.     SWP<cond><B> Rdest,Rsrc,[Rbase]
  164.  
  165. The ARM3 cache control registers are all coprocessor 15 registers, accessed
  166. by MRC and MCR instructions in non-user modes. (They will produce invalid
  167. operation traps in user mode.)
  168.  
  169. Coprocessor 15 register 0 is read only and identifies the chip - e.g.:
  170.   Bits 31..24: &41 - designer code for ARM Ltd.
  171.   Bits 23..16: &56 - manufacturer code for VLSI Technology Inc.
  172.   Bits 15..8:  &03 - identifies chip as an ARM3.
  173.   Bits 7..0:   &00 - revision of chip.
  174.  
  175. Coprocessor 15 register 1 is simply a write-sensitive location - writing any
  176. value to it flushes the cache.
  177.  
  178. Coprocessor 15 register 2: a miscellaneous control register.
  179.   Bit 0 turns the cache on (if 1) or off (if 0).
  180.   Bit 1 determines whether user mode and non-user modes use the same address
  181.     mapping. Bit 1 is 1 if they do, 0 if they have separate address
  182.     mappings. It should be 1 for use with MEMC.
  183.   Bit 2 is 0 for normal operation, 1 for a special "monitor mode" in which
  184.     the processor is always run at memory speed and all addresses and data
  185.     are put on the external pins, even if the memory request was satisfied
  186.     by the cache. This allows external hardware like a logic analyser to
  187.     trace the program properly.
  188.   Other bits are reserved for future expansion. Code which is trying to set
  189.     the whole control register (e.g. at system initialisation time) should
  190.     write these bits as zeros to ensure compatibility with any such future
  191.     expansions. Code which is just trying to change one or two bits (e.g.
  192.     turn the cache on or off) should read this register, modify the bits
  193.     concerned and write it back: this ensures that it won't have unexpected
  194.     side effects in the future like turning as-yet-undefined features off.
  195.   This register is reset to all zeros when the ARM3 is reset.
  196.  
  197. Coprocessor 15 register 3: controls whether areas of memory are cacheable,
  198.     in 2 megabyte chunks. All accesses to an uncacheable area of memory go
  199.     to the real memory and not to the cache - this is a suitable setting
  200.     e.g. for areas containing memory-mapped IO, or for doubly mapped areas
  201.     of memory.
  202.   Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are cacheable, 0 if they
  203.     are not.
  204.   Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are cacheable, 0 if they
  205.     are not.
  206.   :
  207.   :
  208.   Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are cacheable, 0 if
  209.     they are not.
  210.  
  211. Coprocessor 15 register 4: controls whether areas of memory are updateable,
  212.     in 2 megabyte chunks. All write accesses to a non-updateable area of
  213.     memory go to the real memory only, not to the cache - this is a suitable
  214.     setting for areas of memory that contain ROMs, for instance, since you
  215.     don't want the cached values to be altered by an attempt to write to the
  216.     ROM. (Or, as in MEMC, by an attempt to write to write-only locations
  217.     that share an address with the read-only ROMs.)
  218.   Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are updateable, 0 if
  219.     they are not.
  220.   Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are updateable, 0 if
  221.     they are not.
  222.   :
  223.   :
  224.   Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are updateable, 0 if
  225.     they are not.
  226.  
  227. Coprocessor 15 register 5: controls whether areas of memory are disruptive,
  228.     in 2 megabyte chunks. Any write access to a disruptive area of memory
  229.     will cause the cache to be flushed. This is a suitable setting for areas
  230.     of memory which if written, could cause cache contents to become invalid
  231.     in some way. E.g. on MEMC, writing to the physically addressed memory at
  232.     addresses &2000000-&2FFFFFF will also usually change a virtually
  233.     addressed location's contents: if this location is in cache, a
  234.     subsequent attempt to read it would read the old value. To avoid this
  235.     problem, the physically addressed memory should be marked as disruptive
  236.     in a MEMC system. Similarly, any remapping of memory on a MEMC or other
  237.     memory controller should act disruptively, since the cache contents are
  238.     liable to have become invalid.
  239.   Bit 0 is 1 if virtual addresses &0000000-&01FFFFF are disruptive, 0 if
  240.     they are not.
  241.   Bit 1 is 1 if virtual addresses &0200000-&03FFFFF are disruptive, 0 if
  242.     they are not.
  243.   :
  244.   :
  245.   Bit 31 is 1 if virtual addresses &3E00000-&3FFFFFF are disruptive, 0 if
  246.     they are not.
  247.  
  248. Coprocessor 15 registers 3-5 are in an undefined state after power-up: they
  249. must be programmed correctly before the cache is turned on.
  250.  
  251. Note that you should check the identity code in coprocessor 15 register 0
  252. identifies the chip as an ARM3 before assuming that the other registers can
  253. be used as stated above, unless you are absolutely certain your code can
  254. only ever be run on an ARM3. Otherwise you are likely to run into problems
  255. with other chips - e.g. an ARM600 uses the same coprocessor 15 registers to
  256. control its cache and MMU, but in a completely different way. Just about the
  257. only thing they do have in common is that coprocessor 15 register 0 contains
  258. an identification code as described above.
  259.  
  260. David Seal
  261. dseal@armltd.co.uk
  262.  
  263. All opinions are mine only...
  264.  
  265.  
  266.  
  267. From: mhardy@acorn.co.uk (Michael Hardy)
  268. Subject: Re: Risc-OS Documentation
  269. Date: 15 Aug 91 09:45:14 GMT
  270. Organization: Acorn Computers Ltd, Cambridge, England
  271.  
  272.  
  273. ARM3 SUPPORT
  274. ============
  275.  
  276.  
  277. Introduction and Overview
  278. =========================
  279.  
  280. The ARM3Support module provides commands to control the use of the ARM3 
  281. processor's cache, where one is fitted to a machine. The module will
  282. immediately  kill itself if you try to run it on a machine that only has an
  283. ARM2 processor fitted.
  284.  
  285.  
  286. Summary of facilities
  287. ---------------------
  288.  
  289. * Commands are provided: one to configure whether or not the cache is
  290. enabled at  a power-on or reset, and the other to independently turn the
  291. cache on or off.
  292.  
  293. There is also a SWI to turn the cache on or off. A further SWI forces the
  294. cache to be  flushed. Finally, there is also a set of SWIs that control how
  295. various areas of  memory interact with the cache.
  296.  
  297. The default setup is such that all RISC OS programs should run unchanged
  298. with  the ARM3's cache enabled. Consequently, you are unlikely to need to
  299. use the SWIs  (beyond, possibly, turning the cache on or off).
  300.  
  301.  
  302. Notes
  303. -----
  304.  
  305. A few poorly-written programs may not work correctly with ARM3 processors, 
  306. because they make assumptions about processor timing or clock rates.
  307.  
  308.  
  309. Finding out more
  310. ----------------
  311.  
  312. For more details of the ARM3 processor, see the Acorn RISC Machine family
  313. Data  Manual. VLSI Technology Inc. (1990) Prentice-Hall, Englewood Cliffs,
  314. NJ, USA: ISBN  0-13-781618-9.
  315.  
  316.  
  317.  
  318.  
  319.  
  320. SWI Calls
  321. =========
  322.  
  323.  
  324.  
  325. Cache_Control (SWI &280)
  326. ========================
  327.  
  328. Turns the cache on or off
  329.  
  330.  
  331. On entry
  332. --------
  333. R0 = EOR mask
  334. R1 = AND mask
  335.  
  336.  
  337. On exit
  338. -------
  339. R0 = old state (0 => cacheing was disabled, 1 => cacheing was enabled)
  340.  
  341.  
  342. Interrupts
  343. ----------
  344. Interrupts are disabled
  345. Fast interrupts are enabled
  346.  
  347.  
  348. Processor mode
  349. --------------
  350. Processor is in SVC mode
  351.  
  352.  
  353. Re-entrancy
  354. -----------
  355. Not defined
  356.  
  357.  
  358. Use
  359. ---
  360. This call turns the cache on or off. Bit 0 of the ARM3's control register 2
  361. is altered  by being masked with R1 and then exclusive ORd with R0: ie new
  362. value = ((old  value AND R1) XOR R0). Bit 1 of the control register is also
  363. set, forcing the memory  controller to use the same translation table for
  364. both User and Supervisor Modes  (as indeed the MEMC chip should). Other bits
  365. of the control register are set to  zero.
  366.  
  367.  
  368. Related SWIs
  369. ------------
  370. None
  371.  
  372.  
  373. Related vectors
  374. ---------------
  375. None
  376.  
  377.  
  378.  
  379. Cache_Cacheable (SWI &281)
  380. ==========================
  381.  
  382. Controls which areas of memory may be cached
  383.  
  384.  
  385. On entry
  386. --------
  387. R0 = EOR mask
  388. R1 = AND mask
  389.  
  390.  
  391. On exit
  392. -------
  393. R0 = old value (bit n set => 2MBytes starting at n*2MBytes are cacheable)
  394.  
  395.  
  396. Interrupts
  397. ----------
  398. Interrupts are disabled
  399. Fast interrupts are enabled
  400.  
  401.  
  402. Processor mode
  403. --------------
  404. Processor is in SVC mode
  405.  
  406.  
  407. Re-entrancy
  408. -----------
  409. Not defined
  410.  
  411.  
  412. Use
  413. ---
  414. This call controls which areas of memory may be cached (ie are cacheable).
  415. The  ARM3's control register 3 is altered by being masked with R1 and then
  416. exclusive  ORd with R0: ie new value = ((old value AND R1) XOR R0). If bit n
  417. of the control  register is set, the 2MBytes starting at n*2MBytes are
  418. cacheable.
  419.  
  420. The default value stored is &FC007FFF, so ROM, the RAM disc and logical
  421. non-screen RAM are  cacheable, but I/O space, physical memory and logical
  422. screen  memory are not.
  423.  
  424. (You may find a value of &FC007CFF - which disables cacheing the RAM disc -
  425. gives better performance.)
  426.  
  427.  
  428. Related SWIs
  429. ------------
  430. Cache_Updateable (SWI &282), Cache_Disruptive (SWI &283)
  431.  
  432.  
  433. Related vectors
  434. ---------------
  435. None
  436.  
  437.  
  438.  
  439. Cache_Updateable (SWI &282)
  440. ===========================
  441.  
  442. Controls which areas of memory will be automatically updated in the cache
  443.  
  444.  
  445. On entry
  446. --------
  447. R0 = EOR mask
  448. R1 = AND mask
  449.  
  450.  
  451. On exit
  452. -------
  453. R0 = old value (bit n set => 2MBytes starting at n*2MBytes are cacheable)
  454.  
  455.  
  456. Interrupts
  457. ----------
  458. Interrupts are disabled
  459. Fast interrupts are enabled
  460.  
  461.  
  462. Processor mode
  463. --------------
  464. Processor is in SVC mode
  465.  
  466.  
  467. Re-entrancy
  468. -----------
  469. Not defined
  470.  
  471.  
  472. Use
  473. ---
  474. This call controls which areas of memory will be automatically updated in
  475. the  cache when the processor writes to that area (ie are updateable). The
  476. ARM3's control  register 4 is altered by being masked with R1 and then
  477. exclusive ORd with R0: ie  new value = ((old value AND R1) XOR R0). If bit n
  478. of the control register is set, the  2MBytes starting at n*2MBytes are
  479. updateable.
  480.  
  481.  
  482. The default value stored is &00007FFF, so logical non-screen RAM is
  483. updateable,  but ROM/CAM/DAG, I/O space, physical memory and logical screen
  484. memory are  not.
  485.  
  486.  
  487. Related SWIs
  488. ------------
  489. Cache_Cacheable (SWI &281), Cache_Disruptive (SWI &283)
  490.  
  491.  
  492. Related vectors
  493. ---------------
  494. None
  495.  
  496.  
  497.  
  498. Cache_Disruptive (SWI &283)
  499. ===========================
  500.  
  501. Controls which areas of memory cause automatic flushing of the cache on a
  502. write
  503.  
  504.  
  505. On entry
  506. --------
  507. R0 = EOR mask
  508. R1 = AND mask
  509.  
  510.  
  511. On exit
  512. -------
  513. R0 = old value (bit n set => 2MBytes starting at n*2MBytes are disruptive)
  514.  
  515.  
  516. Interrupts
  517. ----------
  518. Interrupts are disabled
  519. Fast interrupts are enabled
  520.  
  521.  
  522. Processor mode
  523. --------------
  524. Processor is in SVC mode
  525.  
  526.  
  527. Re-entrancy
  528. -----------
  529. Not defined
  530.  
  531.  
  532. Use
  533. ---
  534. This call controls which areas of memory cause automatic flushing of the
  535. cache  when the processor writes to that area (ie are disruptive). The
  536. ARM3's control  register 5 is altered by being masked with R1 and then
  537. exclusive ORd with R0: ie  new value = ((old value AND R1) XOR R0). If bit n
  538. of the control register is set, the  2MBytes starting at n*2MBytes are
  539. updateable.
  540.  
  541. The default value stored is &F0000000, so the CAM map is disruptive, but 
  542. ROM/DAG, I/O space, physical memory and logical memory are not. This causes 
  543. automatic flushing whenever MEMC's page mapping is altered, which allows 
  544. programs written for the ARM2 (including RISC OS itself) to run unaltered,
  545. but at  the expense of unnecessary flushing on page swaps.
  546.  
  547.  
  548. Related SWIs
  549. ------------
  550. Cache_Cacheable (SWI &281), Cache_Updateable (SWI &282)
  551.  
  552.  
  553. Related vectors
  554. ---------------
  555. None
  556.  
  557.  
  558.  
  559. Cache_Flush (SWI &284)
  560. ======================
  561.  
  562. Flushes the cache
  563.  
  564.  
  565. On entry
  566. --------
  567. -
  568.  
  569.  
  570. On exit
  571. -------
  572. -
  573.  
  574.  
  575. Interrupts
  576. ----------
  577. Interrupts are disabled
  578. Fast interrupts are enabled
  579.  
  580.  
  581. Processor mode
  582. --------------
  583. Processor is in SVC mode
  584.  
  585.  
  586. Re-entrancy
  587. -----------
  588. Not defined
  589.  
  590.  
  591. Use
  592. ---
  593. This call flushes the cache by writing to the ARM3's control register 1.
  594.  
  595.  
  596. Related SWIs
  597. ------------
  598. None
  599.  
  600.  
  601. Related vectors
  602. ---------------
  603. None
  604.  
  605.  
  606.  
  607.  
  608.  
  609. * Commands
  610. ==========
  611.  
  612.  
  613.  
  614. *Cache
  615. ======
  616.  
  617. Turns the cache on or off, or gives the cache's current state
  618.  
  619.  
  620. Syntax
  621. ------
  622. *Cache [On|Off]
  623.  
  624.  
  625. Parameters
  626. ----------
  627. On or Off
  628.  
  629.  
  630. Use
  631. ---
  632. *Cache turns the cache on or off. With no parameter, it gives the cache's
  633. current  state.
  634.  
  635.  
  636. Example
  637. -------
  638. *Cache Off
  639.  
  640.  
  641. Related commands
  642. ----------------
  643. *Configure Cache
  644.  
  645.  
  646. Related SWIs
  647. ------------
  648. Cache_Control (SWI &280)
  649.  
  650.  
  651. Related vectors
  652. ---------------
  653. None
  654.  
  655.  
  656.  
  657. *Configure Cache
  658. ================
  659.  
  660. Sets the configured cache state to be on or off
  661.  
  662.  
  663. Syntax
  664. ------
  665. *Configure Cache On|Off
  666.  
  667.  
  668. Parameters
  669. ----------
  670. On or Off
  671.  
  672.  
  673. Use
  674. ---
  675. *Configure Cache sets the configured cache state to be on or off.
  676.  
  677.  
  678. Example
  679. -------
  680. *Configure Cache On
  681.  
  682.  
  683. Related commands
  684. ----------------
  685. *Cache
  686.  
  687.  
  688. Related SWIs
  689. ------------
  690. Cache_Control (SWI &280)
  691.  
  692.  
  693. Related vectors
  694. ---------------
  695. None
  696.  
  697. ******************************************************************************
  698.  
  699. I hope this helps.
  700.  
  701. - Michael J Hardy           Email:      mhardy@acorn.co.uk
  702.  
  703.   Acorn Computers Ltd       Telephone:  +44 223 214411
  704.   Cambridge TechnoPark      Fax:        +44 223 214382
  705.   645 Newmarket Road        Telex:      81152 ACNNMR G
  706.   Cambridge CB5 8PB
  707.   England                   Disclaimer: All opinions are my own, not Acorn's
  708.  
  709.  
  710.  
  711. From: osmith@acorn.co.uk (Owen Smith)
  712. Subject: Re: Risc-OS Documentation
  713. Date: 13 Aug 91 15:06:19 GMT
  714.  
  715. The ARM3 SWIs really aren't all that interesting, and I've just totally
  716. failed to find a documentation file for them. However, as a tester, here
  717. is a bit of BASIC (courtesy of Brian Brunswick) which marks the RAM disk
  718. area as not cacheable. This in fact makes it go faster.
  719.  
  720. SYS "Cache_Cacheable", 0, &fffffcff
  721. SYS "Cache_Updateable", 0, &fffffcff
  722.  
  723. The reason it goes faster is that because such large amounts of data are
  724. being slurped around, the memory copy loop tends to get flushed out of
  725. the cache, particularly since it is a long piece of loop unrolled code
  726. (for speed on an ARM2). So you end up with a cache full of data, very little
  727. of which is ever accessed again before it gets flushed out of the cache by
  728. some more data. The loop does an LDM and STM 10 registers at a time in
  729. RamFS, so in theory there are two words that get cached (ARM3 read 4 words
  730. at a time), but this saving is swallowed up by the cache synchronisation
  731. delays.
  732.  
  733. You have to be careful though. Brian has his own re-sizing ram disk
  734. which uses the system sprite area. Marking the system sprite are as not
  735. cacheable makes it go slower. We (Brian and I) think this is because he
  736. uses the C function memcpy(), in which the LDM and STM is 4 registers
  737. at a time. Since this is a multiple of four, it hits the ARM bug where
  738. it loads 5 words and then throws the fifth one away, which results in
  739. loading 8 words on an ARM3 (it always reads 4 word chunks even with the
  740. cache off). So with the cache off, you load 8 then throw 4 away, load the
  741. next 8 (including the 4 you just threw away) and throw 4 away etc. So
  742. you are effectively reading all the data twice. With the cache on this
  743. goes down to once. Yes the code will probably get flushed out, but it
  744. is a tight loop (not unrolled) so it is not very likely and the cost of
  745. reloading the code is less than the saving on the data loads.
  746.  
  747. The moral of this is to be careful with the ARM3 SWIs, and don't just
  748. think that it ought to go faster, do timings, in lots of different screen
  749. modes.
  750.  
  751. Owen.
  752.  
  753.