[m-dev.] diff: GCC back-end: add some comments

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Jan 16 14:44:50 AEDT 2001


Estimated hours taken: 0.25

compiler/mlds_to_gcc.m:
	Add some comments, to address Tyson's review comments.

Workspace: /mnt/hg/home/hg/fjh/gcc-cvs/gcc/mercury
Index: compiler/mlds_to_gcc.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/mlds_to_gcc.m,v
retrieving revision 1.17.2.1
diff -u -d -r1.17.2.1 mlds_to_gcc.m
--- compiler/mlds_to_gcc.m	2001/01/14 04:10:21	1.17.2.1
+++ compiler/mlds_to_gcc.m	2001/01/16 03:43:22
@@ -11,9 +11,22 @@
 % actually generates GCC's internal "Tree" representation,
 % and then invokes the GCC back-end to compile it to assembler,
 % without going via an external file.
-% Code using the C interface, however, does get compiled to C;
-% this module invokes mlds_to_c.m to do that.
-
+%
+% Code using the C interface, however, does get compiled to C; this module
+% invokes mlds_to_c.m to do that.  We split off all the parts of the MLDS
+% for `c_code'/`foreign_code' declarations, `c_header_code'/`foreign_decl'
+% declarations, `export' declarations, and procedures defined with
+% `c_code'/`foreign_proc', and pass them to mlds_to_c.m.  That will generate
+% a `<module>.c' file for this module; mercury_compile.m will invoke the C
+% compiler to compile that to `<module>__c_code.o'.  The remainding parts
+% of the MLDS, which don't contain any foreign code, we handle normally,
+% converting them to GCC trees and passing them to the GCC back-end
+% to generate an assembler file.  Calls to procedures defined using
+% `c_code'/`foreign_proc' will end up calling the functions defined in
+% `<module>__c_code.o'.  This works because the calling convention that
+% is used for the MLDS->C back-end is the same as (i.e. binary compatible
+% with) the calling convention that we use here in the MLDS->GCC back-end.
+%
 % Currently this back-end supports grade hlc.gc only.
 %
 % Trailing will probably work too, but since trailing
@@ -76,6 +89,15 @@
 	% The bool returned is `yes' iff the module contained C code.
 	% In that case, we will have output a separate C file which needs
 	% to be compiled with the C compiler.
+	%
+	% XXX Currently the only foreign language we handle is C.
+	%     To make it work properly we'd need to change the
+	%     `ContainsCCode' boolean that we return to instead be a list
+	%     of the foreign languages used, so that mercury_compile.m
+	%     will know which foreign language files have been generated
+	%     which foreign language compilers it needs to invoke,
+	%     and which object files to link into the executable.
+
 :- pred mlds_to_gcc__compile_to_asm(mlds__mlds, bool, io__state, io__state).
 :- mode mlds_to_gcc__compile_to_asm(in, out, di, uo) is det.
 
@@ -327,7 +349,9 @@
 		{ ForeignMLDS = mlds(ModuleName, ForeignCode, Imports,
 			ForeignDefns) },
 		mlds_to_c__output_mlds(ForeignMLDS),
-		% XXX currently the only foreign code we handle is C
+		% XXX currently the only foreign code we handle is C;
+		%     see comments above (at the declaration for
+		%     mlds_to_c__compile_to_asm)
 		{ ContainsCCode = yes },
 		{ NeedInitFn = no }
 	),
@@ -1912,13 +1936,12 @@
 	% typedef struct {
 	%     MR_ConstString      MR_notag_functor_name;
 	%     MR_PseudoTypeInfo   MR_notag_functor_arg_type;
-	% XXX need to add the following field when I do a cvs update:
-	% /***MR_ConstString      MR_notag_functor_arg_name;***/
+	%     MR_ConstString      MR_notag_functor_arg_name;
 	% } MR_NotagFunctorDesc;
 	build_struct_type("MR_NotagFunctorDesc",
 		['MR_ConstString'	- "MR_notag_functor_name",
-		 'MR_PseudoTypeInfo'	- "MR_notag_functor_arg_type"],
-		 %%% 'MR_ConstString'	- "MR_notag_functor_arg_name"],
+		 'MR_PseudoTypeInfo'	- "MR_notag_functor_arg_type",
+		 'MR_ConstString'	- "MR_notag_functor_arg_name"],
 		GCC_Type).
 build_rtti_type(du_functor_desc(_), _, GCC_Type) -->
 	% typedef struct {

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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