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

On 24 Apr 2006 19:39:12 -0700
"HellsRaison" <spamtrap@xxxxxxxxxx> wrote:

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

The stack(s), as well as all other memory locations are normally accessed
through the caches, and, for the most part, by algorithms which are beyond
the programmer's control. Although, an assembly language programmer does
have access to some cache management instructions.

-- Chuck

.

Relevant Pages

  • Re: Open hardware microprocessor specification RFC
    ... Sure, you can speed it up by optimizations, but DRAM will always be ... I'm not sure what you mean about stack caching... ... you would have to do *any* caching of stacks. ... than DRAM and not mess with the cache. ...
    (comp.lang.forth)
  • Re: Open hardware microprocessor specification RFC
    ... speeding up the row column decode using geometrically scaled ... I'm not sure what you mean about stack caching... ... you would have to do *any* caching of stacks. ... than DRAM and not mess with the cache. ...
    (comp.lang.forth)
  • Re: [2.6 patch] i386: always use 4k stacks
    ... >> So what about arches where single-page stacks aren't viable (for example ... > usage alone and cache locality also are wins. ... The memory usage halves ...
    (Linux-Kernel)
  • Re: Variables on x86 Cache (L1 or L2) rather than Registers?
    ... Assembly Language you could hold variables on the CPU's cache? ... Or is the cache 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. ...
    (comp.lang.asm.x86)
  • Re: ARM920T debugging with linefills disabled leads to lockup
    ... the OpenOCD disables linefills for both caches ... from certain memory locations using system-speed LDM instructions, ... I think disabling the D cache, with enabled mmu, always leads to ...
    (comp.sys.arm)