CompuServe Messages

since I also have a GVP and was interested enough to track that down as well, I can answer your questions. The 68030 has two on chip caches, each 256 bytes in size, one for instructions and one for data. Let us assume we did a cold reboot, and that we have told the CPU that both caches are turned on. The CPU will attempt to read it's first instruction from a hardwired location in memory. The first thing the chip does on any memory access is to look at the cache and see if a previous copy of it is around. Since we are starting from power-up, nothing is there, so the CPU reads the instruction from memory. Next, as it is figuring out what the instruction is, is keeps a copy of it in the cache. From here on out, things proceed normally with the CPU reading instructions and data from memory to execute the programs that the OS or the user has told it to do. In every case, it will check to see if an instruction or piece of data is in the appropriate cache, and if it is, use it from there. If not, it will have to go out to memory and read it from there, which takes longer than if it has that information on-chip. If the cache is full when it needs to keep a copy of some information on-chip, the CPU will figure out what hasn't been used in a while (using a Least Recently Used algorithm, usually abreviated LRU) and write over with the new information. This keeps the caches loaded with the most relevent information since most programs use the same instructions over and over again (as in loops) and the same data (as in the address of a string, or a data block, etc). So if a programmer uses some planning, he can code to make sure that his program takes advantage of this. Some do (Khalid). Now, related to the caches is a particular memory access technique called BURST mode. When you have a cache miss, i.e. it couldn't find the data or instruction in the cache, a smart chip designer will realize that it is quite often the case that not only will the CPU be using the instruction or data asked for, but the next few words after that, in many cases. The optimum amount of additional information to grab is subject to debate, and depends on a _lot_ of factors, but in the case of the 68030 it was decided that if the BURST mode is turned on, and memory can support it, the CPU will not only grab one 32 bit word, but the next three as well, i.e. 16 bytes. Since the memory is set up to do this very quickly, i.e. it only takes four clock cycles to grab 16 bytes in BURST mode instead of 8 clock cycles to grab them individually, you usually get a measurable payback from turning this mode on. Now, there is a problem with certain boards and the way caches work. The 68030 assumes that the information in the cache reflects the information out in memory. If a chip, not the CPU, out there in the system changes the contents of a memory location and the CPU isn't aware that it needs to go out there and reload the change, you can get some pretty strange things happening. In the case of our GVP's, the Chip memory is specifically locked out from being cached, since the custom chips can change the contents of these locations with the CPU being none the wiser. This isn't true of the Bridgeboard, or similiar products, that live in the Fast RAM address space and can merrily change the contents of the memory presented to the CPU at will. So it is very easy for the CPU to have one number stored in the cache as being at a particular location on the BB, while the BB has changed that value. Programs blow up when the information has been invalidated right out from under their feet. The only way around this, short of having a BB jumper on the GVP accelerator, is to turn off the data cache so that the CPU never ever makes that bad assumption. Personally, I'd rather have a jumper to block out caching that 2 MB of system memory, but I'm not the engineer at GVP. As for how they affect AutoPilot, what they will do is speed up the programs execution provided that small, tight loops and repeated data accesses to the same data are used. This occurs naturally enough, so some speed up is inevitable. If Steve has optimized the program, the speed up can become more dramatic in many cases. I don't know enough about the internals of AP to say one way or the other, nor have I done any testing. Hopefully, I haven't made any egregious mistakes in this explanation. "You do trust me, don't you? Of course you do." — "To Play the King" (BBC)