1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
<html>
<head>
<title>
Information On Garbage Collection And C Code
</title>
</head>
<body
bgcolor="#ffffff"
text="#000000"
>
<hr>
<!-------------------------->
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.
<p>
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.
<p>
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. <br>
So
<pre>
detstackvar(1) = (int) succip;
</pre>
becomes
<pre>
detstackvar(1) = (int) saved_succip;
saved_succip = (int) succip;
</pre>
and, when restoring,
<pre>
succip = (int) detstackvar(1);
</pre>
becomes
<pre>
succip = saved_succip;
saved_succip = detstackvar(1);
</pre>
(With appropriate LVALUE_CASTs).
<p>
In this way, garbage collection always knows where the succip is stored
in handwritten code.
<p>
The garbage 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).
<p>
<hr>
<!-------------------------->
Last update was $Date: 1997/04/03 05:17:37 $ by $Author: aet $@cs.mu.oz.au. <br>
</body>
</html>
|
