BH@SU-AI@sri-unix (10/26/82)
From: Brian Harvey <BH at SU-AI> Date: 22 Oct 1982 0752-PDT When I started working on a PDP-11/70, I was told by someone or other that the architecture of that machine was such that cache references were actually FASTER than register references, and therefore ints should NOT be declared as register ints. Registers should still be used for pointers which are being referenced through because that can be done in one instruction if the pointer is in a register. Question: what is the right register strategy for the Vax? Does it vary between models?
swatt (10/27/82)
From: Brian Harvey <BH at SU-AI> Date: 22 Oct 1982 0752-PDT When I started working on a PDP-11/70, I was told by someone or other that the architecture of that machine was such that cache references were actually FASTER than register references, and therefore ints should NOT be declared as register ints. Registers should still be used for pointers which are being referenced through because that can be done in one instruction if the pointer is in a register. Question: what is the right register strategy for the Vax? Does it vary between models? Someone gave you bad advice -- ALL references in pdp-11 architecture are register-based. You CAN'T get to cache without first fetching a value out of a register. If you're talking about C, and the choice is between "register" and "auto" integers, the statement: register int foo = 0; will be: clr r4 and int foo = 0; will be: clr -4(r5) You can look in the timing section of any pdp-11 processor handbook and prove to yourself how much time the register declaration saves. Both compile into one instruction, but what counts is the number of memory cycles needed to fetch and store all the operands. What the processor handbook will give is the cost of each memory cycle and the time to add for each one if NOT found in cache. So the base times assume 100% cache hit. I'm not that familiar with VAX, but the addressing scheme seems to be the same. Note that DEC does not publish VAX instruction times. - Alan S. Watt