Code written in different languages can interact in a number of ways.
At the source level, cross-compilation from one language into the other can be done for some combinations of languages (for example, Google's GWT includes a java-to-javascript compiler; the Glasgow Haskell compiler can compile to C; early versions of C++ compiled to C). Most of the time, however this is not really feasible.
Languages that share a virtual platform, such as the JVM or the .NET runtime, can usually interact through mechanisms exposed by the platform - for example all JVM languages can access Java libraries and use them to communicate among each other, and they can call methods and use classes created in any other JVM language.
Many programming languages, including Python, offer a mechanism to interface with native libraries, typically written in C. Using such a mechanism, it is possible to call native functions from another, more high-level, language. Popular libraries often have bindings readily available. This technique is usually referred to as a "Foreign Function Interface". The Python-into-C interface is the CFFI.
Another option is to build two completely separate programs and have them interact at runtime. There are various mechanisms to achieve this; the easiest is through a pipe (look into the subprocess module for python): basically, one program calls the other, sending input to its stdin and reading the result back from its stdout. This makes one program a subprocess of the other; if you need both to be long-lived and started independently, data can be passed back and forth through named pipes, (local) network sockets, shared files, and (depending on the platform) other means. Which one is best depends.
Best Answer
Let's look at what the ISO C standard actually says (I'll refer to the 2011 edition, a draft of which is available as N1570.
6.7.1p6:
Note that it says nothing about storing the object in a CPU register.
Elsewhere, the standard says that an external declaration may not use the
registerkeyword; it can only be used for variables declared inside the body of a function.Attempting to take the address of a
register-qualified object is not allowed. (That means that declaring an array withregister, though it's legal, is not particularly useful; you have to take its address to be able to do indexing).Apart from that, a compiler is free to ignore the
registerkeyword, treating it as equivalent toauto. You can apply theregisterkeyword to any variable you like (as long as it's defined locally), regardless of its type or size -- but the only thing the compiler is obligated to do is to complain if you try to take its address.A compiler is also free to store anything it likes in CPU registers, whether you use the
registerkeyword or not, as long as the behavior is the same as if the variable were stored in memory. This includes storing a variable in a register for its entire lifetime (if the code happens not to try to compute its address), or retrieving its value from a register where the compiler knows it happens to be stored rather than re-loading from memory.The common wisdom these days is that compilers are better than humans at deciding which variables should be placed in registers for greater speed, so the
registerkeyword is of limited usefulness. In the Old Days, when systems were so small and slow that compilers couldn't afford to do that kind of analysis and dinosaurs roamed the Earth,registercould be very useful. With modern compilers, not so much.