To complement some of the other answers, I'll try to give you some "real-world" examples, using microcontrollers way way smaller than you would find running OS's like Windows or Linux..
First of all, there is no practical limit to the complexity of the expressions such as the one you wrote, since the compiler (C, C++, C#, Java, etc.) evaluates the expression and turns into a set of instructions similar to the example in metacubed's answer (calculating the inner expression first, on out to the top level). Typical compilers may have limits on parentheses levels, but they are typically 32 or more. Anyhow, essentially infinite in all practical terms.
So on to your example. If you were to input your expression into a compiler, and then compile the code, it would mostly likely not use hardly any code or data space at all. The reason is that any decent compiler will evaluate constant expressions at compile time as much as possible. In your case, the entire expression is constant, so the line
result = 12 / (11 / (4 - 7) * 31) + 8;
would be replaced by
result = 8;
8? Why 8 and not 7.8944? That's what I got on my calculator?
By default, virtually all microprocessors/microcontrollers (I'll use MCU from now on) perform integer arithmetic instead of floating point. (In fact only high end MCUs, for example the Intel chips used in your desktop/laptop, have hardware floating point.)
After calculating the inner part of your expression, you end up with 12 divided by -93, which is 0 in integer arithmetic. Adding that to 8 gives 8. Whereas in the floating point case, you have 12 / -113, which is -0.1056 , added to 8 gives 7.8944.
So to make the example non-trivial, one needs to assign all the constants to variables, and then calculate the expression.. Something like this (I'm using C):
char result, a, b, c, d, e, f;
a = 12; b = 11; c = 4; d = 7; e = 31; f = 8;
result = a / (b / (c - d) * e) + f;
Now that will compile into real code. How much? Depends on the MCU.
On a 32-bit MCU, like the PIC32 (which uses the RISC instruction set called MIPS), it takes 12 instructions (2 per variable) to put all the variables on the stack (since C, by default, puts all local on the stack). It then takes another 20 instructions to calculate the expression. Since the PIC32 has both hardware multiply and divide, those operations take only one instruction. Running at 80 MHz, each of these instructions takes 12.5 ns to execute, so the entire expression is calculated in 0.25 µS.
Each PIC32 instruction takes four bytes, so the entire "program" takes 128 bytes of code space, and 28 bytes of stack space (since there are seven variables).
How much is that? Well, an MCU like the PIC32 typically has several hundred thousand bytes bytes of program space (the one I'm using has 512K), and anywhere from 4K to 128K of RAM. So this program is fairly trivial. And of course compared to an 80x86 micrprocessor running on your desktop, with several GB's of RAM (used for both program and data storage), this program is microscopic in comparison.
When this version of the program is run, the value of "result" printed out is the 8, due to the integer arithmetic discussed earlier.
If one were to change the "char" to "float" in the first line of the code example, this changes thing a lot. The code for storing the variables and calculating the expression doesn't go up very much -- from 32 to 38 instructions; but the main difference is now this code is calling all sorts of floating point subroutines in the C library to do the "real" work. As far as I can tell from the map file (one of the outputs of the compiler), these library routines take up another 532 bytes of code space.
When this version of the program is run, the value of result printed out is the desired value of 7.8944.
Now let's look at a small 8-bit MCU, particularly the PIC16F946. The code to save off the variables and then calculate the result (which took 32 instructions the PIC32) now takes 82 instructions. But wait, the PIC16F946 only has a 8x8 hardware multiply but no hardware divide, so there are helper routines for each.
So you have to add 39 instructions for the multiply routine, and 90 for the divide routine, for a total of 211 instructions. Each of these instructions takes 14 bits (how weird is that?), so to be able to compare with other architectures this would be 185 bytes. Actually that is not all that much larger than the PIC32's 128 bytes, even with the helper routines added in. The 14-bit length of the PIC16 instructions vs the 32-bit length of the PIC32 makes a difference.
However if I change to "char" to "float" as we did for the PIC32, the code size almost quadruples.
A PIC16F MCU has anywhere from 768 bytes to 28KB of program space, and just 25 bytes to 2K bytes of RAM. So unlike the PIC32, this example code will stretch the limits of the lowest end PIC16Fs, and the floating point version of the code would not even fit.
So these very small PICs like this run very small programs -- perhaps performing only one function. But they can cost less than 25Ȼ. A typical car today has over a hundred microcontrollers -- some tiny, some rather sophisticated.
The PIC16F946 series, as well as all other 8-bit PICs, actually has only one register dedicated to arithmetic and logical (AND, OR, NOT) operations and shifts; it is called WREG. Such registers are typically called accumulators. There are 15 additional registers, but they are just used to hold temporary variables, like the initial parameters and intermediate results of our expression.
So you really can do a lot with just one register performing arithmetic and logical operations, because the compiler has unrolled all the complexities of the expression to make it as easy for the target machine to calculate as possible. Many of the original microprocessors in the 1970s, like the 6800, 6502, and 8080 had just one accumulator often called A. The 6809, a follow-up to the 6800, had two named A and B.
