Architecture: Difference between revisions
| (5 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
*Reliable (the probability of undetected and detected errors can be meaningfully bounded), and | *Reliable (the probability of undetected and detected errors can be meaningfully bounded), and | ||
*Reprogrammable at a purely symbolic, as opposed to physical, level | *Reprogrammable at a purely symbolic, as opposed to physical, level | ||
Digital, finite transformations will be performed by processing units connected to memories (stores) and I/O devices. | [[Digital]], finite transformations will be performed by processing units connected to memories (stores) and I/O devices. | ||
*By '''digital''', we mean that [http://en.wikipedia.org/wiki/Irrational_number irrational numbers] cannot be faithfully reproduced in variables, nor [http://en.wikipedia.org/wiki/Analog_signal analog signals] in samples -- we can work directly (without approximation) only with [http://en.wikipedia.org/wiki/Countable_set countable sets] (see the [[real computing]] of Blum et al for another perspective). | *By '''[[digital]]''', we mean that [http://en.wikipedia.org/wiki/Irrational_number irrational numbers] cannot be faithfully reproduced in variables, nor [http://en.wikipedia.org/wiki/Analog_signal analog signals] in samples -- we can work directly (without approximation) only with [http://en.wikipedia.org/wiki/Countable_set countable sets] (see the [[real computing]] of Blum et al for another perspective). | ||
*By '''finite''', we mean that a given store can contain only a [http://en.wikipedia.org/wiki/Finite_set finite set] of strings having finite [http://en.wikipedia.org/wiki/Shannon's_source_coding_theorem Shannon Entropy] -- essentially, finite integers. By combining the two, our domain becomes finite sets of finite [http://en.wikipedia.org/wiki/Algorithmic_complexity_theory algorithmic complexity theory] (or so I understand things to work) -- the so-called [http://en.wikipedia.org/wiki/Computable_number computable numbers]. | *By '''finite''', we mean that a given store can contain only a [http://en.wikipedia.org/wiki/Finite_set finite set] of strings having finite [http://en.wikipedia.org/wiki/Shannon's_source_coding_theorem Shannon Entropy] -- essentially, finite integers. By combining the two, our domain becomes finite sets of finite [http://en.wikipedia.org/wiki/Algorithmic_complexity_theory algorithmic complexity theory] (or so I understand things to work) -- the so-called [http://en.wikipedia.org/wiki/Computable_number computable numbers]. | ||
*'''Processing units''' expose simple functional building blocks (maps from finite sets of integers to finite sets of integers) and communication primitives through which connected devices might be manipulated. An [http://en.wikipedia.org/wiki/Instruction_set_architecture instruction set architecture (ISA)] defines the syntax and semantics of these finite languages. | *'''Processing units''' expose simple functional building blocks (maps from finite sets of integers to finite sets of integers) and communication primitives through which connected devices might be manipulated. An [http://en.wikipedia.org/wiki/Instruction_set_architecture instruction set architecture (ISA)] defines the syntax and semantics of these finite languages. | ||
| Line 17: | Line 17: | ||
===Bit-level parallelism=== | ===Bit-level parallelism=== | ||
===Register-level parallelism=== | ===Register-level parallelism=== | ||
* See the [[SIMD]] | * See the [[SIMD|SIMD page]]. | ||
===Instruction Level parallelism=== | ===Instruction Level parallelism=== | ||
===Memory Level parallelism=== | ===Memory Level parallelism=== | ||
| Line 29: | Line 30: | ||
** In a computer architecture context, "cache" usually refers only to the (possibly-multilevel) caches of main memory. | ** In a computer architecture context, "cache" usually refers only to the (possibly-multilevel) caches of main memory. | ||
** In an OS context, "cache" might refer to any store. | ** In an OS context, "cache" might refer to any store. | ||
* Data units: Generally known as registers, this memory is directly available to execution units. It is capable of being updated every cycle, although such a supply might be impossible. Read and write ports directly connects the register file to combinatorial hardware and main memory. On some architectures, instructions can directly reference memory. | * Data units: Generally known as registers, this memory is directly available to execution units. It is capable of being updated every cycle, although such a supply might be impossible. Read and write ports directly connects the register file to [[Combinatorial devices|combinatorial hardware]] and main memory. On some architectures, instructions can directly reference memory. | ||
Memory hierarchies are highly discretized. Storage offered by different memories usually involves quantitative shifts measured in orders of magnitude, as does time required to access them -- nanoseconds for small on-die SRAMs, microseconds for uncached access to system [[DRAM]], milliseconds for hard drive accesses, fractions of a second for network transfers (hey, it still beats the post office). | Memory hierarchies are highly discretized. Storage offered by different memories usually involves quantitative shifts measured in orders of magnitude, as does time required to access them -- nanoseconds for small on-die SRAMs, microseconds for uncached access to system [[DRAM]], milliseconds for hard drive accesses, fractions of a second for network transfers (hey, it still beats the post office). | ||
| Line 40: | Line 41: | ||
Similarly, the main memory's cache is often split into an instruction cache and data cache, with their own ports (and possibly different implementations and sizes), yielding improved access times and fewer structural hazards (instructions can be fetched, while in another unit data are accessed, without structural hazards or expensive logic). A unified cache can make more complete use of the memory available, however, especially for very small programs, effectively trading the risk of conflicts for greater capacity. | Similarly, the main memory's cache is often split into an instruction cache and data cache, with their own ports (and possibly different implementations and sizes), yielding improved access times and fewer structural hazards (instructions can be fetched, while in another unit data are accessed, without structural hazards or expensive logic). A unified cache can make more complete use of the memory available, however, especially for very small programs, effectively trading the risk of conflicts for greater capacity. | ||
Reads are the common case -- 1 instruction cache hit (barring trace caches, etc) for every instruction issued, and loads usually substantially outweighing stores for data cache (or unified cache) access. They're also faster (assuming the data is in cache): the processor needn't specify the width of the load, and the data can be loaded while the tag is being checked -- if the tag doesn't match, no harm is done. Writes must wait for the tag to be verified. Write-combining can be performed in unflushed write buffers or dirty lines of a write-back cache, saving memory bandwidth. Writing policies include: | Reads are the common case -- 1 instruction cache hit (barring trace caches, etc) for every instruction issued, and loads usually substantially outweighing stores for data cache (or unified cache) access. They're also faster (assuming the data is in cache): the processor needn't specify the width of the load, and the data can be loaded while the tag is being checked -- if the tag doesn't match, no harm is done. Writes must wait for the tag to be verified. Write-combining can be performed in unflushed write buffers or dirty lines of a write-back cache, saving memory bandwidth. Writing policies (configured on the x86 via [[MTRR]]s or [[PAT]]s) include: | ||
* Write-through: the write propagates out throughout the store abstraction (ie, from L1 cache, over an exclusive L2 cache, to system [[DRAM]]). Simple to implement, as writes need no buffers and loads resulting in evictions never force writebacks. Cache and backing store exhibit data coherence (observers never see a different value in memory than what's in cache), a useful property in the presence of multiple cores or DMA. In order to write at the full speed of the cache, writes must be buffered; for a load which overwhelms the write buffer, or in its absence, the processor will see write stalls above and beyond the cache timings even for cached data. | * Write-through: the write propagates out throughout the store abstraction (ie, from L1 cache, over an exclusive L2 cache, to system [[DRAM]]). Simple to implement, as writes need no buffers and loads resulting in evictions never force writebacks. Cache and backing store exhibit data coherence (observers never see a different value in memory than what's in cache), a useful property in the presence of multiple cores or DMA. In order to write at the full speed of the cache, writes must be buffered; for a load which overwhelms the write buffer, or in its absence, the processor will see write stalls above and beyond the cache timings even for cached data. | ||
* Write-back: the write is only applied to the cache. Memory is updated when the line is replaced. Minimizes latency for the attached execution unit -- potential write throughput is equivalent to that of the cache. Saves memory bandwidth and power, but requires a coherency protocol (with its own state requirements). Minimally, a dirty bit indicates that the line need be written back upon eviction. In the presence of multiple, independent caches at the same level of a store abstraction, full cache coherency protocols such as MESI are used. Write-back caches also tend to employ write buffers (so that reads might be prioritized; see below), also known as "victim buffers" by AMD (not to be concerned with victim caches, small fast direct-mapped stores into which all evicted lines go, not just dirty ones -- the goal of this latter is to minimize the impact of conflict misses, not eliminate blocking on writebacks). | * Write-back: the write is only applied to the cache. Memory is updated when the line is replaced. Minimizes latency for the attached execution unit -- potential write throughput is equivalent to that of the cache. Saves memory bandwidth and power, but requires a coherency protocol (with its own state requirements). Minimally, a dirty bit indicates that the line need be written back upon eviction. In the presence of multiple, independent caches at the same level of a store abstraction, full cache coherency protocols such as MESI are used. Write-back caches also tend to employ write buffers (so that reads might be prioritized; see below), also known as "victim buffers" by AMD (not to be concerned with victim caches, small fast direct-mapped stores into which all evicted lines go, not just dirty ones -- the goal of this latter is to minimize the impact of conflict misses, not eliminate blocking on writebacks). | ||
| Line 77: | Line 78: | ||
[[Category: x86]] | [[Category: x86]] | ||
[[Category: CS GRE Prep]] | [[Category: CS GRE Prep]] | ||
[[CATEGORY: Hardware]] | |||