[Oberon] Oberon for a C++ user.

[John R. Strohm]

A thought, which just occurred to me, which is not fully baked, not even 
half-baked.  This may have been discussed previously, and I missed it at the 
time.

Are we hurting ourselves in this discussion by assuming a particular 
implementation or code generation strategy for a procedure variable?

When we load a module, we define a number of externally-visible symbols. 
Some of those may become the right-hand-sides of assignments to procedure 
variables.

The naïve implementation just loads the actual code address into the 
procedure variable, so that an indirect jump goes directly to the 
newly-loaded code.

Can we finesse the problem by, instead, as part of the module-loading 
process, loading a set of thunks (for lack of a better term: perhaps you 
prefer trampolines), one for each externally-visible procedure, that exist 
to redirect a procedure variable call?  Then, when the module is unloaded, 
instead of reclaiming the thunks, we make them branch to trap routines 
instead.  If we then load a new version of the module, the thunks are still 
around, and can be reconnected to the newly-loaded code.

--John R. Strohm


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus