mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-18 23:35:25 +00:00
7e91a8db83
Some notes on the calling of handwritten C code from Mercury, and its consequences for garbage collection (and vice versa).
37 lines
1.2 KiB
Plaintext
37 lines
1.2 KiB
Plaintext
When handwritten code is called from Mercury, the garbage collection
|
|
scheduler doesn't know anything about the code, so it cannot replace
|
|
the succip on the stack (if there is one) with the collector's address.
|
|
|
|
If the handwritten code calls no other code, then this is fine, the
|
|
scheduler knows it can replace the succip variable and when a
|
|
proceed() occurs execution will return to mercury code which it
|
|
knows about.
|
|
|
|
If handwritten code calls other handwritten code, we have a problem,
|
|
as succip will be saved on the stack and we don't know where on
|
|
the stack it is stored. So we use a global variable 'saved_succip' which
|
|
is succip is saved into. Care must be taken to save saved_succip on the
|
|
stack so it doesn't get clobbered.
|
|
So
|
|
detstackvar(1) = (int) succip;
|
|
becomes
|
|
detstackvar(1) = (int) saved_succip;
|
|
saved_succip = (int) succip;
|
|
|
|
and, when restoring,
|
|
succip = (int) detstackvar(1);
|
|
becomes
|
|
succip = saved_succip;
|
|
saved_succip = detstackvar(1);
|
|
|
|
(With appropriate LVALUE_CASTs).
|
|
|
|
In this way, garbage collection always knows where the succip is stored
|
|
in handwritten code.
|
|
|
|
The gabage collection code must check that the current execution is not
|
|
still in a handwritten predicate - if it is, it must re-schedule (essentially
|
|
just the same as before).
|
|
|
|
|