Is method scope and variable scope Just a construct of a high level language. So is it just a way for humans to write better programs with complexity, rather than large procedural code? So does scope exist at the assembly level.
1 Answers
So does scope exist at the assembly level.
Yes.
A problem with speaking about assembly language with generality is that there are so many different languages: there are hundreds of assembly languages — approaching a dozen for x86 alone, and then factor in all the other processors that ever existed, both real and theoretical/educational.
That being said, assembly language also has names, and contexts within which name resolution is more or less limited, i.e. scopes.
Some assemblers support the notion of a method (with some form of begin/end pair) within which local names can be declared that aren't accessible in other methods — while other assemblers have no notion of method at all, just locations that are labeled with names: in particular, they don't identify the end of a method so there is no concept of method scope.
Most assemblers allow minimally for file-scope vs. cross-file-scope (extern or glob[a]l) names. Some assemblers support macros with local names as well; some support record definitions where field names are only valid within certain record referencing constructs.
Some assemblers have a notion of local labels (often simply numbered rather than given rich names) that are valid only in between file-scope (named) labels. And some of these allow you to specify upon reference whether the local label to be matched occurs forwards from the reference or backwards from it, which also forms a sort of scope.
Most structured programming languages support nested scopes with the block statement construct, e.g. each { } pair introduces a new scope. I don't know of any assembly language that supports such arbitrarily nested scopes (except maybe web assembly, wasm, as it is structured!).
However, in assembly language, names are usually used for code and global data, whereas many local variables are simply assigned to registers or stack-based memory locations, and as such name resolution does not really apply — the names of these variables appear only in comments and programmers' heads.
Of course, there is (virtually) no name binding at runtime; name resolution has been performed by the compiler/assembler/linker/loader and the hardware sees only numbers that indicate storage locations.
Related