register int *foo asm ("a5");

Naturally the register name is CPU-dependent, so you would need to conditionalize your program according to CPU type. The a5 register would be a good choice on a Motorola 68000 for a variable of pointer type. On machines with register windows, choose a global register that is not affected magically by the function call mechanism.

In addition, operating systems on one type of CPU may differ in how they name the registers; then you would need additional conditionals. For example, some Motorola 68000 operating systems call the register, %a5.

Defining such a register variable does not reserve the register; it remains available for other uses in place s where flow control determines the variable's value is not live. However, these registers are made unavailable for use in the reload pass; excessive use of this feature leaves the compiler too few available registers to compile certain functions. 

This option does not guarantee that GNU CC will generate code that has this variable in the register you specify at all times. You may not code an explicit reference in an asm statement and assume it will always refer to this variable.

Stores into local register variables may be deleted when they appear to be dead according to data flow analysis. References to local register variables may be deleted or moved or simplified.

It is not safe for one function that uses a global register variable to call another such function, foo, by way of a third function, lose, that was compiled without knowledge of this variable (i.e., in a different source file in which the variable wasn’t declared). This is because lose might save the register and put some other value there. For example, you can’t expect a global register variable to be available in the comparison-function that you pass to qsort, since qsort might have put something else in that register. (If you are prepared to recompile qsort with the same global register variable, you can solve this problem.)

If you want to recompile qsort or other source files which do not actually use your global register variable, so that they will not use that register for any other purpose, then it suffices to specify the compiler option,  ‘-ffixed-reg.’ You need not actually add a global register declaration to their source code.

A function which can alter the value of a global register variable cannot safely be called from a function compiled without this variable, because it could clobber the value the caller expects to find there on return. Therefore, the function which is the entry point into the part of the program that uses the global register variable must explicitly save and restore the value which belongs to its caller. On most machines, longjmp will restore to each global register variable the value it had at the time of the setjmp. On some machines, however, longjmp will not change the value of global register variables.

To be portable, the function that called setjmp should make other arrangements to save the values of the global register variables, and to restore them in a longjmp. This way, the same thing will happen regardless of what longjmp does. All global register variable declarations must precede all function definitions. If such a declaration could appear after function definitions, the declaration would be too late to prevent the register from being used for other purposes in the preceding functions. Global register variables may not have initial values, because an executable file has no means to supply initial contents for a register. On the SPARC, there are reports that g3 ... g7 are suitable registers, but certain library functions, such as getwd, as well as the subroutines for division and remainder, modify g3 and g4. g1 and g2 are local temporaries. On the Motorola 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of course, it will not do to use more than a few of those.