yes your concept holds true from high level language POV. except there's no fancy "global, local, subroutines, OOP, classing etc fancy high level language concept" at the hardware level, its all will be translated to raw opcodes, registers, ram, stack, binary manipulation etc.
Just not true I'm afraid. True there is no machine code opcode for a local or global variable but the mechanism they work on is tied very tightly to the cpu structure. A Global variable would be an address in Ram (or Rom) would (normally) be fixed and is allocated for the at run time. A local on the other hand is never assigned an address (unless you class the stack pointer) and only exists while the function is running.A function call may pass 3 parameters a,b and c. These are pushed on to the stack along with the return address and the function called. Inside the function the parameters are popped off the stack used and finally the function exited by popping the return address into the program counter. The parameters a,b, and c STILL exist on the stack but the stack pointer is now pointing to something else ( the return address in this case) and so are invisible to the system. It is possible to manipulate the stack and indeed you do at times need to do so but it is thwart with danger and will lead to instability or crashes if not done correctly. As an aside 'Stack Fishing' was a very effective method of finding Registration numbers of software used by the reverse engineering community at one time as the reg number was pushed on the stack along side the user entered number then popped off and compared resulting in a pass fail. They then simply back tracked through the stack to get the number....Simples (Sic)!