Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 1 and Version 2 of IMB


Ignore:
Timestamp:
2009-05-01T12:49:49Z (10 years ago)
Author:
Jiri Svoboda
Comment:

Make use of L1 headings.

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 =
    32
    43Let's consider two scenarios:
    54
    65
    7 === Scenario 1: ===
     6== Scenario 1: ==
    87
    98
     
    1817is not maintained between data and instruction caches)
    1918
    20 === Scenario 2: ===
     19== Scenario 2: ==
    2120 1. execute memory block M (previously filled with instructions)
    2221 2. modify memory block M
     
    2928instruction prefetch buffers (instruction queues)
    3029
    31 === Architecure Overview ===
     30== Architecure Overview ==
    3231||'''Architecture'''||'''Unified cache'''||'''D$ write-through'''||'''VAC'''||'''Scenario 1'''    ||'''Scenario 2'''    ||'''VAC aliases'''   ||'''Cache shootdown'''||
    3332||[#amd64 amd64]    || Can be both       || Configured write-back|| Yes     ||[#amd64 HW solution]||[#amd64 HW solution]|| HW solution        || No                  ||
     
    4039
    4140
    42 === Notes ===
     41== Notes ==
    4342
    44 ==== amd64 ====
     43=== amd64 ===
    4544See AMD x86-64 Architecture Programmer's Manual, Volume 2, System Programming, page 211, Self-Modifying Code:
    4645
     
    5150The 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.
    5251
    53 ==== arm32 ====
     52=== arm32 ===
    5453
    5554All 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.
     
    5958See ARM Architecture Reference Manual, page B5-10 (552). Chapter 5-5, Memory Coherency
    6059
    61 ==== ia32 ====
     60=== ia32 ===
    6261See IA-32 Intel Architecture Software Developer's Manual, Volume 3, 10.6. Self-Modifying Code:
    6362
     
    6867The solution is the same as for [#amd64 amd64].
    6968
    70 ==== ia64 ====
     69=== ia64 ===
    7170See Intel Itanium Architecture Software Developer's Manual, 2.5 Updating Code Images, page 2:404.
    7271
    7372
    74 ==== mips32 ====
     73=== mips32 ===
    7574For info on 4K cores, see MIPS32 4KTM Processor Core Family Software User’s Manual, 7.5 Memory Coherence Issues:
    7675
     
    8180  The SYNC instruction may also be useful to software enforcing memory coherence, as it flushes the 4K’s write buffers.
    8281
    83 ==== ppc32 ====
     82=== ppc32 ===
    8483
    8584See PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors, chapter 5, page 209: Cache Model and Memory
     
    9493
    9594
    96 ==== sparc64 ====
     95=== sparc64 ===
    9796On UltraSPARC (sun4u) processors, the D$ is write-through.
    9897
     
    104103  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.
    105104
    106 == Links ==
     105= Links =
    107106[http://yarchive.net/comp/self_modify.html Self-modifying code (John R. Mashey, John Reiser, Dennis Ritchie)]