[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