[m-dev.] for review: MLDS back-end stuff

[Tyson Dowd]

On 04-Aug-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Tyson, could you please review this?
> 
> The file mlds_to_c.m is still quite incomplete at this point,
> but I will nevertheless commit this change as soon as it has been
> reviewed, because Tyson wants access to mlds_to_c.m.

I have some specific comments below, but in general this change is fine,
Feel free to commit now and address these comments at your leisure.

> 
> -------------------------------------------------------------------------------
> 
> Estimated hours taken: 30
> 
> A batch of changes related to the development of the new MLDS back-end.
> 
> compiler/notes/compiler_design.html:
> 	Reorganize the documentation to reflect the multi-target /
> 	multiple back-end nature of the compiler.
> 	Document mlds.m and the new modules c_util.m and mlds_to_c.m.
> 
> compiler/mlds_to_c.m:
> 	New module.  This converts MLDS to C/C++ code.
> 	This version compiles, but it is still quite incomplete;
> 	there's lots of parts which are still not yet implemented.
> 
> compiler/llds_out.m:
> compiler/c_util.m:
> 	Move some procedures from llds_out.m into a new module c_util.m,
> 	so that they can also be used by mlds_to_c.m.
> 
> compiler/mlds.m:
> 	- Add new functions for use by mlds_to_c.m:
> 		* get_prog_context/1, for getting the prog_context from an
> 		  mlds__context
> 		* get_module_name/1, for getting the module name from the mlds
> 		* module_name_to_sym_name/1, for converting an mlds_module_name
> 		  to a sym_name
> 	- Change the mlds__func_signature type to 
> 		* allow multiple return values, for consistency with the
> 		  MLDS `return' statement;
> 	        * include the names of the parameters.
> 	- Undo the premature over-optimization of making the `constness'
> 	  and `finality' flags share the same flag bit.
> 



> -<p>
> +<ul>
> +<li> 1. parsing (source files -> HLDS)
> +<li> 2. semantic analysis and error checking (HLDS -> annotated HLDS)
> +<li> 3. high-level transformations (annotated HLDS -> annotated HLDS)
> +<li> 4. code generation (annotated HLDS -> target representation)
> +<li> 5. low-level optimizations
> +     (target representation -> target representation)
> +<li> 6. output code (target representation -> target code)
> +</ul>

You should probably use the HTML ordered list <OR> tag if you want this.

>  
>  Note that in reality the separation is not quite as simple as that.
>  Although parsing is listed as step 1 and semantic analysis is listed
> @@ -54,18 +52,65 @@
>  
>  <p>
>  
> +In addition, the compiler is actually a multi-targeted compiler
> +with several different back-ends.  When you take the different
> +back-ends into account, the structure looks like this:
> +
> +<ul type=disc>
> +<li> front-end
> +     <ul type=disc>
> +     <li> 1. parsing (source files -> HLDS)
> +     <li> 2. semantic analysis and error checking (HLDS -> annotated HLDS)
> +     <li> 3. high-level transformations (annotated HLDS -> annotated HLDS)
> +     </ul>
> +<li> back-ends
> +     <ul type=disc>
> +     <li> a. LLDS back-end
> +          <ul type=disc>
> +          <li> 4a. code generation (annotated HLDS -> LLDS)
> +          <li> 5a. low-level optimizations (LLDS -> LLDS)
> +          <li> 6a. output code (LLDS -> C)
> +          </ul>
> +     <li> b. MLDS back-end
> +          <ul type=disc>
> +          <li> 4b. code generation (annotated HLDS -> MLDS)
> +          <li> 5b. MLDS transformations (MLDS -> MLDS)
> +          <li> 6b. output code
> +	       (MLDS -> C or eventually MLDS -> Java, etc.)
> +          </ul>
> +     <li> c. RL back-end
> +          <ul type=disc>
> +          <li> 4c. code generation (annotated HLDS -> RL)
> +          <li> 5c. low-level optimizations (RL -> RL)
> +          <li> 6c. output code (RL -> RL-bytecode)
> +          </ul>
> +     <li> d. bytecode back-end
> +          <ul type=disc>
> +          <li> 4d. code generation (annotated HLDS -> bytecode)
> +          </ul>
> +     </ul>
> +</ul>

Likewise here.  You can provide the OL TYPE attribute to get different
sorts of list numbering.


> Index: compiler/mlds_to_c.m
> ===================================================================
> RCS file: mlds_to_c.m
> diff -N mlds_to_c.m
> --- /dev/null	Wed Aug  4 15:41:20 1999
> +++ mlds_to_c.m	Mon Aug  2 19:51:27 1999


> +:- pred mlds_output_to_file(string, pred(io__state, io__state),
> +				io__state, io__state).
> +:- mode mlds_output_to_file(in, pred(di, uo) is det, di, uo) is det.
> +
> +mlds_output_to_file(FileName, Action) -->
> +	globals__io_lookup_bool_option(verbose, Verbose),
> +	globals__io_lookup_bool_option(statistics, Stats),
> +	maybe_write_string(Verbose, "% Writing to file `"),
> +	maybe_write_string(Verbose, FileName),
> +	maybe_write_string(Verbose, "'...\n"),
> +	maybe_flush_output(Verbose),
> +	io__tell(FileName, Res),
> +	( { Res = ok } ->
> +		Action,
> +		io__told,
> +		maybe_write_string(Verbose, "% done.\n"),
> +		maybe_report_stats(Stats)
> +	;
> +		maybe_write_string(Verbose, "\n"),
> +		{ string__append_list(["can't open file `",
> +			FileName, "' for output."], ErrorMessage) },
> +		report_error(ErrorMessage)
> +	).


This is extremely generic and should really be moved to a utility 
module someday.


A general comment on mlds_to_c.m is that it provides some structure that
will be largely duplicated by mlds_to_anything_else.m and also some
useful code that would be nice to re-use in mcorba (which also generates and
outputs C/C++ code).  What exactly to do about this isn't clear at the
moment.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't eveyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------