[m-rev.] for review: C# backend
Julien Fischer
juliensf at csse.unimelb.edu.au
Tue Sep 14 15:17:46 AEST 2010
Hi Peter,
I've had a look through this diff and it looks ok. (I have some
reservations regarding the re-use of the java_names module for C# -- see
below.) Provided you've bootchecked the compiler in at least one of the
other MLDS grades, feel free to commit.
Julien.
On Mon, 13 Sep 2010, Peter Wang wrote:
> Start a C# backend, adapted from mlds_to_java.m.
>
> Some `pragma foreign_*' declarations are commented out in this change because
> no bootstrap compiler will yet accept "C#" in the language specification.
>
> The compiler already supported C# foreign_procs for the IL backend, but the IL
> backend and this new backend do not agree on naming and calling conventions so
> the changes to the existing C# foreign_procs will further break the IL backend.
> Nobody cares.
>
> Only tested so far with Mono on Linux.
>
> compiler/mlds_to_cs.m:
> New module. In the CVS Attic there exists an obsolete file named
> mlds_to_csharp.m (replaced by mlds_to_managed.m) which we don't want to
> conflict with.
>
> For C# we need to know if a `pragma foreign_type' is a value or
> reference type. Currently this is done by accepting a fake keyword
> `valuetype' before the type name, like for IL.
>
> compiler/ml_backend.m:
> compiler/mercury_compile.m:
> compiler/mercury_compile_mlds_back_end.m:
> Hook up the C# backend.
>
> compiler/globals.m:
> Add `target_csharp' as a target language.
>
> compiler/options.m:
> Add `--csharp' and `--csharp-only' options and their synonyms.
>
> compiler/handle_options.m:
> Handle `target_csharp' like `target_java', except for features which
> are still to be implemented.
>
> compiler/add_pragma.m:
> Allow C# as a `pragma foreign_export' language.
>
> Allow C# for `pragma foreign_export_enum'.
>
> Conform to changes.
>
> compiler/hlds_data.m:
> compiler/prog_data.m:
> compiler/prog_io_pragma.m:
> Accept C# as a language for `pragma foreign_type'.
>
> Accept `csharp' as the name of a grade in trace parameters.
>
> compiler/make_hlds_passes.m:
> Reuse most of the code for implementing mutables on Java for C#.
>
> compiler/mlds.m:
> Add a new MLDS target language, `ml_target_csharp'.
>
> Conform to changes.
>
> compiler/ml_foreign_proc_gen.m:
> Generate foreign_procs for C#.
>
> compiler/foreign.m:
> Update predicates to support C# targets.
>
> compiler/c_util.m:
> Make `quote_string' use hexadecimal escapes in C# string literals.
>
> compiler/parse_tree.m:
> compiler/java_names.m:
> Add C# equivalents for predicates in this module. `java_names' is a
> misleading module name, but the predicates for C# and Java share some
> code and may possibly be combined in the future.
I don't think the amount of code duplication in question is significant.
Having the C# code live in the same module as the Java stuff is
confusing IMO, and should be avoided. (Indeed, the mixture of C and
Java stuff that already exists in the compiler is similarly confusing.)
(I don't mind if this fixed in a separate change.)
>
> compiler/rtti.m:
> Add predicates to return the names of RTTI structures in C#.
>
> compiler/simplify.m:
> Handle the trace parameter `grade(csharp)'.
>
> compiler/compile_target_code.m:
> compiler/make.dependencies.m:
> compiler/make.m:
> compiler/make.module_target.m:
> compiler/make.program_target.m:
> compiler/make.util.m:
> Add some support for building of executables and libraries with
> `--target csharp'.
>
> compiler/ml_global_data.m:
> compiler/ml_optimize.m:
> compiler/ml_proc_gen.m:
> compiler/ml_switch_gen.m:
> compiler/ml_type_gen.m:
> compiler/ml_unify_gen.m:
> compiler/add_pred.m:
> compiler/add_type.m:
> compiler/granularity.m:
> compiler/inlining.m:
> compiler/intermod.m:
> compiler/lambda.m:
> compiler/mercury_compile_middle_passes.m:
> compiler/mercury_to_mercury.m:
> compiler/ml_code_util.m:
> compiler/ml_disj_gen.m:
> compiler/mlds_to_c.m:
> compiler/mlds_to_il.m:
> compiler/mlds_to_java.m:
> compiler/modules.m:
> compiler/pragma_c_gen.m:
> compiler/prog_foreign.m:
> compiler/special_pred.m:
> compiler/write_deps_file.m:
> Conform to changes.
>
> library/builtin.m:
> library/rtti_implementation.m:
> library/type_desc.m:
> Implement RTTI procedures for the new backend, which uses a high-level
> data representation (like the Java backend). The existing C# code was
> designed for the IL backend, which used a low-level representation of
> the RTTI data structures.
>
> Most (if not all) of the the "new" code is exactly the same as the Java
> versions, with only syntactic changes.
>
> Rename the C# class `void_0' to `Void_0' to match the naming convention
> used by mlds_to_cs.m.
>
> library/array.m:
> Update the existing C# code to work with the new backend.
>
> Use `object[]' as the type of all arrays, rather than trying to use
> specific types. The problem is one we encountered on the Java backend:
> when creating a new array based on the type of a single element, we
> don't know whether the new array should contain elements of the class
> or superclass.
>
> library/bool.m:
> Export `bool' constants to C#.
>
> library/exception.m:
> Update the existing C# code to work with the new backend.
>
> Move the `mercury.runtime.Exception' C# class to mercury_dotnet.cs.
>
> library/float.m:
> Add C# implementations of `is_nan' and `is_inf'.
>
> library/list.m:
> Add methods for manipulating lists from hand-written C# code.
>
> library/string.m:
> Add C# implementations of string procedures which were missing.
>
> library/dir.m:
> library/io.m:
> library/library.m:
> Update the existing C# code to work with the new backend.
>
> library/private_builtin.m:
> Update the existing C# code to work with the new backend.
>
> Delete the static constants which are duplicated in mercury_dotnet.cs.
> The mlds_to_cs.m will emit references to the constants in the latter
> only.
>
> library/backjump.m:
> library/bitmap.m:
> library/mutvar.m:
> library/par_builtin.m:
> library/region_builtin.m:
> library/store.m:
> library/thread.m:
> library/thread.semaphore.m:
> library/time.m:
> library/univ.m:
> Make these modules compile with the C# backend.
>
> runtime/mercury_dotnet.cs.in:
> Add RTTI classes to the `mercury.runtime' namespace, equivalent to
> those on the Java backend.
>
> Use enumerations `MR_TYPECTOR_REP_*' and `MR_SECTAG_*' constants so we
> can switch on them.
>
> Add the `UnreachableDefault' exception class.
>
> Hide old classes which are unused with the new backend behind
> #ifdef !MR_HIGHLEVEL_DATA.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to: mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions: mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------
More information about the reviews
mailing list