Changes between Version 1 and Version 2 of IMB
- Timestamp:
- 2009-05-01T12:49:49Z (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
IMB
v1 v2 1 2 == Invalidating Instruction Caches and Flushing Write Buffers == 1 = Invalidating Instruction Caches and Flushing Write Buffers = 3 2 4 3 Let's consider two scenarios: 5 4 6 5 7 == = Scenario 1: ===6 == Scenario 1: == 8 7 9 8 … … 18 17 is not maintained between data and instruction caches) 19 18 20 == = Scenario 2: ===19 == Scenario 2: == 21 20 1. execute memory block M (previously filled with instructions) 22 21 2. modify memory block M … … 29 28 instruction prefetch buffers (instruction queues) 30 29 31 == = Architecure Overview ===30 == Architecure Overview == 32 31 ||'''Architecture'''||'''Unified cache'''||'''D$ write-through'''||'''VAC'''||'''Scenario 1''' ||'''Scenario 2''' ||'''VAC aliases''' ||'''Cache shootdown'''|| 33 32 ||[#amd64 amd64] || Can be both || Configured write-back|| Yes ||[#amd64 HW solution]||[#amd64 HW solution]|| HW solution || No || … … 40 39 41 40 42 == = Notes ===41 == Notes == 43 42 44 === = amd64 ====43 === amd64 === 45 44 See AMD x86-64 Architecture Programmer's Manual, Volume 2, System Programming, page 211, Self-Modifying Code: 46 45 … … 51 50 The solution might be to simply issue a write barrier after a self-modifying code. Are we really sure that in SMP systems the store buffers cannot forward writes to other caches? In that case a no-op would be necessary to handle self-modifying code. 52 51 53 === = arm32 ====52 === arm32 === 54 53 55 54 All parameters (whether the cache is unified, write through and/or virtually-addressed) is implementation-defined. No real ARM machine is currently supported by HelenOS. Hardware coherency checking is minimal. … … 59 58 See ARM Architecture Reference Manual, page B5-10 (552). Chapter 5-5, Memory Coherency 60 59 61 === = ia32 ====60 === ia32 === 62 61 See IA-32 Intel Architecture Software Developer's Manual, Volume 3, 10.6. Self-Modifying Code: 63 62 … … 68 67 The solution is the same as for [#amd64 amd64]. 69 68 70 === = ia64 ====69 === ia64 === 71 70 See Intel Itanium Architecture Software Developer's Manual, 2.5 Updating Code Images, page 2:404. 72 71 73 72 74 === = mips32 ====73 === mips32 === 75 74 For info on 4K cores, see MIPS32 4KTM Processor Core Family Software User’s Manual, 7.5 Memory Coherence Issues: 76 75 … … 81 80 The SYNC instruction may also be useful to software enforcing memory coherence, as it flushes the 4K’s write buffers. 82 81 83 === = ppc32 ====82 === ppc32 === 84 83 85 84 See PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors, chapter 5, page 209: Cache Model and Memory … … 94 93 95 94 96 === = sparc64 ====95 === sparc64 === 97 96 On UltraSPARC (sun4u) processors, the D$ is write-through. 98 97 … … 104 103 SPARC-V9 specifies that the FLUSH instruction has no latency on the issuing processor. In other words, a store to instruction space prior to the FLUSH instruction is visible immediately after the completion of FLUSH. MEMBAR #!StoreStore is required to ensure proper ordering in multi-processing system when the memory model is not TSO. When a MEMBAR #!StoreStore, FLUSH sequence is performed, UltraSPARC guarantees that earlier code modifications will be visible across the whole system. 105 104 106 = = Links ==105 = Links = 107 106 [http://yarchive.net/comp/self_modify.html Self-modifying code (John R. Mashey, John Reiser, Dennis Ritchie)]
