Re: memory reading and writing

From: Gyps (gyps_rueppelli_at_yahoo.com)
Date: 07/16/04 

Date: 16 Jul 2004 08:22:48 -0700

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message news:<nlJJc.6$iR5.1@newsfe3-win.ntli.net>...
> Basically, fast memory is more expensive...but, using the "cache
> memory" scheme, then you can often access memory without any
> delays at all as if you had lots of the expensive fast RAM when
> you don't (well, unless you get a "cache miss")...
But wouldn't you get a cache 'miss' on every 'jmp' call,
other than those for loops and upon all access to big
data structures like arrays and records?

> The idea is quite simple but really rather clever...when memory
> is read from system RAM, a whole "chunk" of memory is actually
> moved across in one go (not just the specific memory location
> you want to read but a larger "chunk" including a bunch of the
> bytes following this in memory as well :)...this is then copied
> into the "caches" on the way to the CPU...
I presume this is done directly by the CPU's MMU and no specific
instructions are needed on the part of the programmer?
(System programmer of course)

> When writing, the CPU writes - again, at fast speed - to the L1
> cache copy...so the CPU actually directly deals with just the L1
> cache which is superfast...although, as noted, this cache memory
> is superfast but it's limited in size...at some point, the
> memory you want to read / write won't be in this cache...
like pointer references to data on the heap right?

> ...the writes are "flushed" back to system RAM in a
> "lazy" fashion (not written immediately but as a "chunk" :)...
Is this as well transparent to the software...?

> Thus, when successive memory accesses are close together - and
> typically they are...
But will this hold true when an asm code accesses a memory
variable declared in the data segment...will it not be,
relatively speaking, quite far off from the actual code?

For example my L1 cache is reported to be 16KB in size.
Would that mean that if I execute a small asm program fully
under 16KB then the whole program is loaded into L1 cache and
run.

In other words, what I am trying to ask is weather there is
any 'preference', hardware and/or software wise, given to
certain memory data over others to be copied to the L1/L2 cache?

Why not keep certain time-critical sections of code like
the timer interrupt handler permanently in the L2 cache...?
Does such a thing actually happen or am I being a idiot here?

> ...although, once you make that first access
> to this region of memory, another "chunk" is loaded into the
> caches and any subsequent memory accesses to that location (or
> to neighbouring memory locations :) will again happen at L1
> cache speeds...so, you get "penalised" on the first access but,
> while that memory remains in the cache, subsequent accesses to
> memory in the same "chunk" will already be loaded into the
> cache...
How exactly does the CPU determine that a 'chunk' of memory
is the L1/L2 caches as opposed to main memory?
Is the logic built into the CPU or is controlled by OS routines?

> yup, doesn't matter too much whether it says 3GHz on the CPU
> itself, it's constantly having to _wait_ for memory, which
> only runs at 133Mhz in this example...
How does 133Mhz translate to actual access time for a single
access?
Is it 1/133000000*2 ?

> Of course, it's not perfect...when you get a "cache miss", the
> system does drop in speed because it has to resort to going to
> the slower access memory...but, hey, with a well-written "cache
> consistent" program that has "locality of reference" to exploit
> the caches to the full then this happens less frequently and
> it's saved you a lot of money in buying your PC and its memory
> ;)...
Sorry, I lost you there. My knowledge of assembly language hasn't
advanced to the point of me writing 'cache consistent' programs...
I have no idea how to do that except to use registers as much as
possible, which all assembly code does anyway...