[m-dev.] Linkage of static data

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Feb 26 15:45:21 AEDT 2000


On 26-Feb-2000, Thomas Conway <conway at cs.mu.OZ.AU> wrote:
> The handling of the linkage scope (static vs global) for static structures
> (ie stack layout strcutures) seems to be a bit of a mess. There are two
> mechanisms - one that records the linkage in the strcuture, and the other
> that uses the predicate linkage/2. The former is described as being
> redundant in the comments, being replaced by the latter. On the other hand,
> I need some stack layouts (the ones for exported procedures) to have
> global scope, so linkage/2 seems like an inadequate mechanism. My thought
> is to remove the linkage/2 mechanism and rely on the linkage scope from
> the structure.

How do you plan to handle the issue described in the comment above
linkage/2?

% Note that we need to know the linkage not just at the definition,
% but also at every use, because if the use is prior to the definition,
% then we need to declare the name first, and the linkage used in that
% declaration must be consistent with the linkage in the definition.

Off-hand I don't any easy way of solving that issue using the linkage
scope from the structure, so I think you need to keep linkage/2.

If you need some stack layouts to have global scope when deep profiling
is enabled, one possible solution would be just to make _all_ stack layouts
have global scope when deep profiling is enabled.

Another solution, a little more complicated but potentially resulting
in the generated code being more efficient, would be to include the
linkage in the data_name (rather than in the comp_gen_c_data).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list