The C2 description is of a possible implementation of dynamic scoping, not of dynamic scoping.
Dynamic scoping can work simply by saving and restoring a global variable (or a thread-local one, if need be). There is no need for a search through frames.
If there is an environment consisting of linked frames, they do not have to coincide with activation frames. They are frames in a dynamic environment. If a function doesn't bind anything in the dynamic environment, it doesn't contribute any new frame. So the dynamic environment can be considerably shallower than the call stack.
In the TXR Lisp, I maintain a global variable (a C variable) called dyn_env. It points to the top of the dynamic environment stack. A dynamic variable is bound by extending this stack. The old value dyn_env is saved on the run-time stack, and is restored later.
dyn_env is also part of the "extended_jmp_buf" context. This means that if a dynamic control transfer takes place (exception or other), dyn_env will be correctly restored to the value at the target site.
> so the function might hit different variables depending on where it is called from.
Not really. Well, look, if a function accesses an unbound variable, that can be diagnosed. The remaining question is whether a given dynamic variable being accessed (which we know exists due to the lack of any unbound variable diagnostics) is the global instance in the top-level environment, or a locally overridden one. That's what we don't necessarily know in a given function, and we are not supposed to care.
Dynamic scoping can work simply by saving and restoring a global variable (or a thread-local one, if need be). There is no need for a search through frames.
If there is an environment consisting of linked frames, they do not have to coincide with activation frames. They are frames in a dynamic environment. If a function doesn't bind anything in the dynamic environment, it doesn't contribute any new frame. So the dynamic environment can be considerably shallower than the call stack.
In the TXR Lisp, I maintain a global variable (a C variable) called dyn_env. It points to the top of the dynamic environment stack. A dynamic variable is bound by extending this stack. The old value dyn_env is saved on the run-time stack, and is restored later.
dyn_env is also part of the "extended_jmp_buf" context. This means that if a dynamic control transfer takes place (exception or other), dyn_env will be correctly restored to the value at the target site.
> so the function might hit different variables depending on where it is called from.
Not really. Well, look, if a function accesses an unbound variable, that can be diagnosed. The remaining question is whether a given dynamic variable being accessed (which we know exists due to the lack of any unbound variable diagnostics) is the global instance in the top-level environment, or a locally overridden one. That's what we don't necessarily know in a given function, and we are not supposed to care.