The L1 and L2 on chip caches.

Those are controlled by the CPU itself automatically. You can influence them with assembly, though (using the PREFETCH op)

http://www.intel.com/products/processor/manuals/

EDIT: Although I should mention that it is up to the developer to ignore the cache if necessary (C/C++'s "volatile" keyword - which you will probably never need to use), and to deal with synchronization issues from threading (which you almost never need to worry about as higher level threading synchronization mechanisms like mutexes already do this)

x86/x64 contains quite a few Cache control instructions, more than just the variations of prefetch. However, what I was asking was how would one go about doing cache work (like JIT interpreters do) in C, since I can hardly imagine the Sun JVM uses inline ASM.

Decent compilers will cache variables in registers to avoid loading/storing more than necessary. GCC is in this "decent" category. Usually you have to compile with an optimization flag, eg -O1 or higher. None of this low-level caching affects how your program behaves (it would be a bug in the compiler if it did). It only affects the performance (size and/or speed).

Older, less decent, or simpler compilers don't do any kind of caching and will load/store a variable from/to memory every time it is accessed. C also has the "register" storage modifier keyword (eg, "register int x;") which explicitly tells the compiler to store that variable inside a register rather than main memory. If you look at some older code (80's or earlier) you'll often find "register" used a lot. Nowadays, with good optimizing compilers, you almost never have to use "register" since those compilers will usually allocate registers to variables just as well as or better than the programmer (IMHO).

What christop said. I can't think of too many modern applications where you would want to manually muck around with caching, data/code cache control, or cache policy. Even "register" is more or less completely deprecated at this point, since your compiler is generally smarter than you with regards to how variables should be placed, as christop said. I'd certainly be aware of caching and the value of data access locality (for example, reordering nested loops to exploit array element locality and maximize cache hits), but I wouldn't obsess over it.

None of the others are interesting, though.



JIT doesn't muck with the L1 and L2 cache, just like you shouldn't. A JIT will compile to a chunk of RAM (created with your typical malloc(), nothing special) and execute from there.

You seem to be getting confused with "caching" something and the CPU cache. The CPU cache is something you should design your algorithms to leverage, but *NOT* control or manipulate. "caching" is just a generic concept regarding keeping something in RAM.

Okay, that clears things up a bit.

As for a syntax question, what does it mean to have a data type followed by a star, such as char*<string> or void*?

It means that it is a pointer. A char* is a pointer to a char (or an array of chars). A char** is a pointer to a pointer to a char (or array of chars). char* is pretty much equivilent (though, there are differences that are important) to a char[]. For instance, you can do:
Code:
Also, to get a pointer to a variable, for instance, an int, you would do:
Code: