Is it possible for there to be no space for the register variables in your program due to other programs that are already running? Would the program just crash? What would the different effects be on different cpu's? It boggles the mind............
Printable View
Is it possible for there to be no space for the register variables in your program due to other programs that are already running? Would the program just crash? What would the different effects be on different cpu's? It boggles the mind............
>Is it possible for there to be no space for the register variables in your program due to other programs that are already running? Would the program just crash?
is this what your asking?
the keyword register is not a guarantee of a variable being registered, if there are no registers open then they just don't get registered.
ah, they just turn into the auto class, ok. thanks.....I remember reading that now........:D
whatever is currently running will always have all the registers, no?
It will? Ok, I didn't know that.
It will have use of the registers, but it might not be using them all...it depends on the code you have createdQuote:
Originally posted by moi
whatever is currently running will always have all the registers, no?
All you are doing is offering a suggestion on which variables should be stored in registers.....
The compiler knows what it wants to do, how it wants to do it and what registers it wants to use.....the register statement can be ignored if the compiler feels its not possible, or it may work around the situation to give up a register to you by storing more stuff in memory......
This can at time make your code less efficient as your compilers optimization may be hindered....so unless you really know what you are doing its not worth much IMHO......personally, if I wanted to control register use for a period, and as inline assemblers are generally very good, I would prefer to use an __asm{} block....
Fordy is probably right. When I was working on a compression algorithm, I tried to use register variables too. But when I clocked it next to the non-register code, there was no difference. It was my impression that the compiler had ignored my request, though I don't see why, since the entire program used very few variables. The IDE I was using was Dev-C++. In the future, if I really want to reserve a register, I think I'll try an asm block.
I'm going to paint some of this broadly because it's important to understand the concept, but the full details are kind of cumbersome to the noobie.
The term 'register' is misleading. This is just a long-word variable space in the processor. Unlike RAM, it is a physical location where an address or data value is storable.
Because each register has a physical location, there is only 1 of each register. Every CPU has a finite number of 'registers'.
Intel processors tend to have fewer registers than Motorola processors. In intel, you might (in assembly) refer to a register as AX or BX (or about 30 others), depending on if it is used for addresses (pointers) or data. In Motorola, they are usually referred to as A5 or A7, etc.
One register you all are somewhat familiar with is the 'Stack Pointer'. This is a register that keeps track of program progress.
---
Since there are a finite number of registers on the processor, they must be shared between applications running under a single processor. The way they are shared is by a mechanism called a 'stackframe'.
A 'stackframe' is a bit of overhead code (usually a single assembler instruction) that creates additional space either on the Application stack or the O/S stack (depending on who created the stackframe) which is where 'state' gets saved. Since your program must use registers to run (many O/S functions require arguments to be in a specific register when they are called), whatever value was previously in that register must be _saved_ until the function (or whatever) is done using the register. Then the value can be restored.
Usually whenever a function/procedure is entered you will see a stackframe created, registers saved, and then on exit, registers restored and the stackframe destroyed.
---
Registers are available to an application on a first come, first serve basis. When the compiler compiles your code, it notes the variables you've requested to be 'register' variables. That doesn't mean it can satisfy that request. It just means it will try.
The reason the compiler might not be able to fulfill your request that a variable be a 'register' type, is because that register variable might be required for handling an argument in a system call, elsewhere in your function. As such, it there is a conflict, the system call wins and the compiler won't try to satisfy both (it can't).
---
Are register variables faster than normal variables? YES, they most certainly are-- and that' is because of WHERE they are, and the WAY they are accessed. In your program, in any function, local variables will be referenced as an offset to a location on the stack (based on the starting address of the function/procedure.
Example:
When a function is called, the application takes the address of the next assembly instruction and pushes that onto the stack chain (see 'RRRRRRR' above). It then issues a mnemonic to save the current register state in the stackframe the compiler allocated (it's just a matter of expanding the stack a few bytes) -- see 'FFFFFFFF' above. Then the code jumps to the first instruction where the function is located.Code:. . .
SSSSSSSS <-- STACK CHAIN (HIGH ADDRESS)
SSSSSSSS
SSSSSSSS
SSSSSSSS
RRRRRRRR <-- RETURN ADDRESS
FFFFFFFF <-- STACK FRAME (ARGS, RET VAL, VARS & SAVED REGS)
FFFFFFFF
FFFFFFFF
FFFFFFFF
FFFFFFFF
. . .
Upon completion, another mnemonic restores the registers from the stackframe to there previous state, and increments the stack pointer by the size of the stackframe, destroying it. the PC is loaded with the value (RETURN ADDRESS above) on the stack, which automatically points it back wherever it came from. It the processor jumps to that address and executes more of the code.
I say all that because, whenever normal local variables are accessed, they are accessed on the stack as SP + offset. (stack pointer minus a calculated offset generated by the compiler to get to the position on the stack memory that contains the variable). This relative addressing takes time. "address-plus" is called relative.
However, a register is the easiest piece the processor access for data, and is highly optimized and it DOESN'T reside on the stack.
---
You can see exactly which variables end up being 'register' variables by disassembling the code with your compiler (if it has a disassembly feature).