interpreting C datastructures as Mercury terms

Thomas Charles CONWAY conway at cs.mu.OZ.AU
Thu May 7 15:16:46 AEST 1998


Here's one for you all.

In the new profiler that I'm working on, I generate a big tree-like
structure representing the calltree of the program. This structure
is generated by C code in the runtime (with cooperation from the
generated code). It would be nice for the profiler tool to be able
to use io__read or io__read_binary to read in the data generated
by the profiling run. Correspondingly it would be nice to be able
to have the runtime call back to Mercury to write out the structure
with io__write{,_binary} at the end of the profiling run. For this
to work, the C representation of the tree must be such that I can
write a collection of Mercury type definitions that have a corresponding
structure. So far, there are two problems with this:

1) Array-like structures.
There are structures that have the form
typedef struct FOO {
	Word	this;
	Word	that;
	Word	**others;
} Foo;

The problem that this represents is that I can't write a single
Mercury type that represents all the different arities that Foo
could have. I guess using a Mercury array representation would be
possible, but anyway this one isn't the really interesting case.

2) List-like structures.
There are a number of structures that are of the form:
typedef struct BAR {
	strcut BAR	*next;
	Word		*this;
	Word		*that;
} Bar;

Now, you could write the following type declaration:

:- type bar
	--->	bar(bar, this_type, that_type)
	;	nil.

However, the tag assignment rules mean that all the recursive pointers
need to be tagged which is a pain in C. If we could convince the compiler
to use the opposite to the usual tag assignment (ie 0 to bar/n and 1 to nil)
the problem would go away - rather than using NULL to represent the empty
list of Bars, we use 1 (appropriately macroized and cast of course) and
the bar-pointers can be used without explicit tagging.

Is there a nice way of convincing the compiler to use this kind of tag
assignment?

Thomas
-- 
Thomas Conway <conway at cs.mu.oz.au>
Nail here [] for new monitor.  )O+



More information about the developers mailing list