Re: Variables on x86 Cache (L1 or L2) rather than Registers?



"HellsRaison" <spamtrap@xxxxxxxxxx> wrote:

I'm in a beginners Computer Science class, and I was wondering if in
Assembly Language you could hold variables on the CPU's cache? Rather
than just the registers?

Or is the cache (L1/L2) where the stacks are located?

Memory is very, very slow, and you don't want the processor waiting around
for stuff to come from that slow memory. So, any time you read anything
from memory (including instructions, stack, and data), the memory
controller reads a big chunk around that address into the caches. When you
read the next byte, it can be read directly from the cache, which is VERY
high speed.

Caching is all handled automatically. You can only touch it indirectly,
and then only a very few extremely high-performance programs do so.
--
- Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

.



Relevant Pages

  • Re: Cached memory never gets released
    ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
    (Linux-Kernel)
  • Re: Problem: Creating a raw binary string
    ... > While its true that a 64-bit cpu will move twice the data per instruction it ... > Memory bus width plays an important role here and unless it too is widened / ... You are forgetting the two levels of cache in the processor. ... The memory chips are addressed in Row col fashion. ...
    (alt.comp.lang.borland-delphi)
  • Re: Is Greenspun enough?
    ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
    (comp.lang.lisp)
  • Re: Superstitious learning in Computer Architecture
    ... Without a LOT of logic or some other better approach, re-executing the instructions requires re-decoding and it ties up the cache memory bus transferring more data as instructions than the instructions are working on. ... The concept of cache is fundamentally flawed in that it STILL restricts access to one word per clock cycle, when a single modern ALU can easily use 5 plus whatever is eaten up with instruction accesses. ... The size of an optimizing compiler is proportional to the SQUARE of the size of the language times the SQUARE of the complexity of the machine - because all interactions must be considered. ...
    (comp.arch.arithmetic)
  • Re: FPGA-based hardware accelerator for PC
    ... I know that in most cases the CPU ... that it contsins no cache, as BRAMs are too precious resources to be wasted ... The BRAMs are what define the opportunity, ... many threads with full associativity of memory lines using hashed MMU ...
    (comp.arch.fpga)