Commit Graph

18 Commits

Author SHA1 Message Date
Peter Ross
77a1261d3b Merge the foreign_type pragma changes from the dotnet branch to the main
Estimated hours taken: 10
Branches: main

Merge the foreign_type pragma changes from the dotnet branch to the main
branch, plus do some more development work to generalise the change.

compiler/prog_data.m:
    Add a type to hold the data from parsing a pragma foreign_type decl.

compiler/prog_io_pragma.m:
    Parse the pragma foreign_type.  This code is currently commented
    out, while we decide on the syntax.

compiler/hlds_data.m:
    Add a new alternative to hlds_type_body where the body of the type
    is a foreign type.

compiler/make_hlds.m:
    Place the foreign_type pragmas into the HLDS.

compiler/foreign.m:
    Implement to_type_string which replaces export__type_to_type_string,
    unlike export__type_to_type_string foreign__to_type_string takes an
    argument specifying which language the representation is meant to be
    in.  to_type_string also needs to take a module_info to handle
    foreign_types correctly.  To avoid the need for the module_info to
    be passed around the MLDS backend we provide a new type
    exported_type which provides enough information for an alternate
    version of to_type_string to be called.

compiler/export.m:
    Delete export__type_to_type_string.

compiler/llds.m:
    Since foreign__to_type_string needs a module_info, we add a new
    field to pragma_c_arg_decl which is the result of calling
    foreign__to_type_string.  This avoids threading the module_info
    around various llds passes.

compiler/mlds.m:
    Record with in the mercury_type the exported_type, this avoids
    passing the module_info around the MLDS backend.
    Also add the foreign_type alternative to mlds__type.
    Update mercury_type_to_mlds_type so that it handles types which are
    foreign types.

compiler/mlds_to_il.m:
    Convert a mlds__foreign_type into an ilds__type.

compiler/ilds.m:
    The CLR spec requires that System.Object and System.String be
    treated specially in the IL assembly so add them as simple types.

compiler/ilasm.m:
    Before outputting a class name into the IL assembly check whether it
    it can be simplified to a builtin type, and if so output that name
    instead as required by the ECMA spec.
    Changes for the addition of string and object as simple types.

doc/reference_manual.texi:
    Document the new pragma, this is currently commented out because it
    refers to syntax that has not yet been finalised.

compiler/fact_table.m:
compiler/llds_out.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_simplify_switch.m:
compiler/ml_switch_gen.m:
compiler/ml_unify_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_gcc.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
compiler/pragma_c_gen.m:
compiler/rtti_to_mlds.m:
    Changes to handle using foreign__to_type_string.

compiler/hlds_out.m:
compiler/intermod.m:
compiler/magic_util.m:
compiler/ml_type_gen.m:
compiler/recompilation_usage.m:
compiler/recompilation_version.m:
compiler/term_util.m:
compiler/type_ctor_info.m:
compiler/unify_proc.m:
    Changes to handle the new hlds_type_body.

compiler/mercury_to_mercury.m:
    Output the pragma foreign_type declaration.

compiler/module_qual.m:
    Qualify the pragma foreign_type declarations.

compiler/modules.m:
    Pragma foreign_type is allowed in the interface.
2001-10-24 13:34:41 +00:00
Tyson Dowd
8ec5c48d3a Fix semidet C# code to use SUCCESS_INDICATOR.
Estimated hours taken: 10
Branches: main

Fix semidet C# code to use SUCCESS_INDICATOR.

Represent mlds__native_bool_type as bool, not int32.

In the library, fix incorrect uses of MC++ to implement functions -- these
weren't being caught because they returned int32, and we assumed
this was a semidet return value, not an actual integer.

These incorrect uses were all buggy -- functions don't work in MC++.
The compiler is now catches cases where functions returning int are
implemented in MC++ -- but it won't catch cases where
IL's bool type is returned, but that should not be a such a problem.

compiler/ilasm.m:
	Handle the output of boolean integer constants.

compiler/ml_code_gen.m:
	Add SUCCESS_INDICATOR to the locals of the MLDS for semidet C# code,
	copy SUCCESS_INDICATOR into succeeded after the execution of the
	user's code.

compiler/mlds_to_csharp.m:
	Implement assignments (so we can copy SUCCESS_INDICATOR to
	succeeded).

compiler/mlds_to_il.m:
	Copy return values into SUCCESS_INDICATOR for forwarded
	predicates (it will then be copied into succeeded).
	This all gets optimized away in the generated IL anyway.

	Represent native_bool_type as bool, not int32.
	Check for MC++ functions returning bool (not int32).
	Output true and false as boolean constants for 1 and 0.

compiler/mlds_to_mcpp.m:
	Map bool to MR_Bool, not MR_Integer.

library/int.m:
	Implement much of the code in Mercury rather than C# or MC++.
	The more efficient C bindings remain, but for other backends we
	fall back on the Mercury bindings.

library/io.m:
	Implement io__get_stream_id as a pred in MC++.
	It is easier to keep this as MC++ at the moment as that is what
	the rest of the io.m code is implemented in (including the
	Mercury stream data structure).

library/std_util.m:
	Add some missing assignments to SUCCESS_INDICATOR.
2001-10-17 05:10:42 +00:00
Tyson Dowd
416ca83320 Merge changes to add attributes to the HLDS, MLDS and ILDS from the
Estimated hours taken: 2
Branches: main

Merge changes to add attributes to the HLDS, MLDS and ILDS from the
dotnet-foreign branch.  We don't merge the changes to add syntax for
attributes, as the syntax is still very experimental.

compiler/hlds_pred.m:
compiler/prog_data.m:
	Add attributes to the pred_info (they are a bit like markers,
	but are more than just boolean flags).

compiler/ilasm.m:
	Add custom attributes to appropriate positions (on assemblies,
	IL types and methods).

compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_util.m:
compiler/mlds.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_gcc.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
	Add mlds__attributes, which are the MLDS version of custom attributes.
	Convert hlds_pred__attributes into mlds__attributes.
	Add a list of mlds__attributes to the mlds__function defn.

compiler/mlds_to_il.m:
	Convert MLDS attributes to IL custom attributes.
2001-08-24 15:44:57 +00:00
Fergus Henderson
0a206a1066 Fix a couple of bugs in the IL back-end that caused it to generate incorrect
Estimated hours taken: 2
Branches: main

Fix a couple of bugs in the IL back-end that caused it to generate incorrect
refences to constructor names when --high-level-data was enabled.
One was that it was using the base class type rather than the
derived type for the appropriate constructor.
The other was that it was using "." rather than "/" as the class qualifier
when referencing nested classes.
(This change is only a partial fix for the latter problem.)

compiler/ilds.m:
	Change the structured_type so that nested classes are stored
	a separate field from the namespace-qualified top-level class.

	Rename "append_class_name" as "append_toplevel_class_name",
	and add a new routine "append_nested_class_name".

compiler/ilasm.m:
	Output "/" rather than "." as the class qualifier for nested classes.

compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
	Minor changes to handle the new definition of structured_type.

compiler/mlds_to_il.m:
	Handle the new definition of structured_type.
	Use the MaybeCtorName field of new_object instructions
	to determine the type to allocate.
2001-08-13 01:39:33 +00:00
Peter Ross
bd19fe9e3e Optionally generate strongly named assemblies on the IL backend.
Estimated hours taken: 8
Branches: main

Optionally generate strongly named assemblies on the IL backend.

Strongly named assemblies are required by some aspects of the .NET
framework.  For example, when creating COM+ components.

We use the fact that you are allowed use the same key pair to sign more
then one assembly.  The key pair we use is the one used to sign the
mercury std library.  This allows us to place the correct public key
token in the `.assembly extern' reference.

README.DotNet:
    Document how to generate a strongly named assembly.

compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
    If --sign-assembly is enabled output a custom attribute which
    references the strong name key file `mercury.sn'.

compiler/mlds_to_il.m:
    If --sign-assembly is enabled add the correct decls to all the
    `.assembly extern' declarations.

compiler/modules.m:
    If --sign-assembly we need to generate a dependency between the IL
    file and the strong name key file `mercury.sn', also add the
    variable ILASM_KEYFLAG-<module> so that we add the option to sign
    the assembly with the key file `mercury.sn'.

compiler/options.m:
    Add --sign-assembly.

library/Mmakefile:
    Install the library strong name file as `mercury.sn' in the dll
    install directory.

scripts/Mmake.rules:
    Add a rule to copy mercury.sn into the local subdirectory.  This is
    needed so that cpp and csharp modules can reference this file.

scripts/Mmake.vars.in:
    Add the ILASM_KEYFLAG variables.
2001-08-12 13:29:17 +00:00
Fergus Henderson
bac2c89776 Improve the support for generating verifiable code and/or efficient but
Branches: main
Estimated hours taken: 30

Improve the support for generating verifiable code and/or efficient but
unverifiable code for the IL back-end.

We now allocate nondet environments on the stack by default, but they will get
allocated on the heap if you specify --verifiable-code.

compiler/options.m:
	Add several new options:
		--verifiable-code
		--il-funcptr-types
		--il-refany-fields
		--il-byref-tailcalls
		--put-nondet-env-on-heap
	Currently these are all not officially documented, for various reasons,
	so I have not yet added grade components for any of these options.

compiler/handle_options.m:
	Set --put-nondet-env-on-heap if --verifiable-code is specified,
	unless both --il-funcptr-types and --il-refany-fields are specified.

compiler/ml_elim_nested.m:
	Support the --put-nondet-env-on-heap option:
	allocate the environment on the stack by default.

compiler/mlds_to_il.m:
	Add a new field to the il_data_rep_type to handle the different
	representations for the environment pointer types.
	Add a new procedure get_il_data_rep for computing it.
	Handle casts to/from `refany' by generating the appropriate IL
	instructions, `mkrefany'/`refanyval'.
	Handle casts to/from unmanaged pointers (native_uint) --
	these are just a noop in IL, `.castclass' doesn't work for them.

compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
	Use get_il_data_rep rather than constructing it manually.
2001-08-02 19:50:37 +00:00
Tyson Dowd
cdbbaa5ac2 Support multiple language foreign_procs in the one file.
Estimated hours taken: 16
Branches: main

Support multiple language foreign_procs in the one file.

If there is more then one applicable foreign_proc for a
given clause, select the most "preferred" programming
language to use as the implementation.

Currently only the IL backend has multiple languages
supported by the backend, and C# is preferred over MC++.

compiler/options.m:
compiler/handle_options.m:
	Rename backend_foreign_language as backend_foreign_languages,
	and use it to record the list of foreign languages the selected
	backend can handle.
	Remove --use-foreign-language as it doesn't do anything right now.

compiler/foreign.m:
	Update code to use the list of backend foreign languages.
	Add prefer_foreign_language function, to compute the preferred
	foreign language ordering for each backend.
	Move simple_foreign_language_string here from globals.m,
	and add foreign_language_file_extension and
	foreign_language_module_name functions.

	(much of the rest of the code in this module is intended to deal with
	the case where the backend *doesn't* handle the foreign
	language, but we don't have any working support for that at the
	moment).

compiler/globals.m:
	Add globals__io_get_backend_foreign_languages and
	globals__get_backend_foreign_languages.

compiler/make_hlds.m:
	Handle selection of foreign_proc code depending upon the preferred
	language.
	Rename a few *_foreign_code predicates as *_foreign_proc
	predicates.
	Handle the extra field in clause.

compiler/ml_code_gen.m:
compiler/mlds.m:
	Generate different mlds__foreign_code for each language (only
	one language is selected for each predicate, but there can be
	multiple languages in the onle module).
	and put them in a map which is indexed on foreign language.

compiler/modules.m:
	Generate appropriate dependencies for foreign language modules.
	We now record which languages a list of items uses (taking into
	account the preferred foreign language for foreign_proc).
	We also allow for the fact that some foreign_proc declarations
	won't generate any external modules.


compiler/hlds_pred.m:
	Add an extra field to clause which records which language this
	clause has been implemented in.

compiler/assertion.m:
compiler/clause_to_proc.m:
compiler/dead_proc_elim.m:
compiler/goal_util.m:
compiler/hlds_out.m:
compiler/inlining.m:
compiler/intermod.m:
compiler/modes.m:
compiler/polymorphism.m:
compiler/purity.m:
compiler/typecheck.m:
compiler/unify_proc.m:
	Handle the extra field in clause.


compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_gcc.m:
compiler/mlds_to_mcpp.m:
	Select the appropriate mlds__foreign code from the map and
	generate code for it.
2001-07-20 14:14:30 +00:00
Tyson Dowd
b994075a22 Add support for foreign_proc("il", ....)
Estimated hours taken: 50
Branches: main


Add support for foreign_proc("il", ....)

To use it, you need to give the options
	--use-foreign-language il
	--backend-foreign-language il

Begin documenting foreign_proc.


compiler/foreign.m:
compiler/globals.m:
	Handle the addition of il as a language option.

compiler/inlining.m:
	Mention that we don't allow il code to be inlined yet and give a
	pointer into ml_code_gen.m which has the reason along with the
	offending code.

compiler/il_peephole.m:
compiler/ilasm.m:
	Handle the addition of il_asm_code as inlineable code.

compiler/ilds.m:
	Add a handwritten scope to the different scope types.

compiler/ml_code_gen.m:
	Handle the generation of code for IL foreign language interfacing.
	Put the max_stack_size attribute into IL foreign language code.
	Document the problem with inlining.

compiler/ml_elim_nested.m:
	Handle the new field in blocks indicating whether the block contains
	handwritten code.

compiler/mlds.m:
	Add lang_il as a possible target language.
	Add attributes to target code (max_stack_size is the only one so far).

compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
	Handle the addition of il as a language option.

compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
	Generate inline code for foreign_proc using IL.

compiler/prog_data.m:
	Add il as a language option.

	Add extra attributes to the pragma_foreign_proc_attributes.
	Currently there is just one extra attribute, max_stack_size.

compiler/prog_io_pragma.m:
	Parse max_stack_size as an attribute on foreign_proc.
	Improve error message output: previously we tried to parse the
	third term of a foreign_proc, and then tried to parse the second term
	(which we will accept for "c_code" but not foreign_proc).
	But we should give the error message as if the "c_code" handling is
	not present, as this will eventually go away.
	Check for foreign_language attributes such as max_stack_size.

doc/reference_manual.texi:
	Add a section for foreign_proc (and other multi-language foreign
	language interfacing pragmas).
	At the moment we have some reasonable documentation for "C" and
	"IL" foreign_proc, and some documentation on foreign_decl and
	foreign_code for C.

doc/user_guide.texi:
	The language and implementation specific documentation of
	the foreign language interface.
2001-07-18 10:21:03 +00:00
Tyson Dowd
bf0ed70782 Use a new mlds__function_body type to represent function bodies, as the old
Estimated hours taken: 0.75
Branches: main

Use a new mlds__function_body type to represent function bodies, as the old
usage of maybe/1 was error prone ("no" meant the function had been declared
using :- pragma external, not merely that the body was missing).

compiler/mlds.m:
	Add mlds__function_body type.

compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_gcc.m:
compiler/mlds_to_il.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
	Handle this change.
2001-07-12 15:44:58 +00:00
Peter Ross
9b73bb8c47 For decl_flags_to_classattrs calculate the access flags correctly.
Estimated hours taken: 0.25
Branches: main

mlds_to_il.m:
    For decl_flags_to_classattrs calculate the access flags correctly.

mlds.m:
    Add a new function wrapper_class_name, which returns the name of the
    class to wrap global functions and data inside for backends which
    require this.

mlds_to_csharp.m:
mlds_to_mcpp.m:
    Use the new function, and update the comments.
2001-07-11 10:24:37 +00:00
Peter Ross
a6d5d61cb5 Refactor the top level of mlds_to_il so that we only do one pass over
Estimated hours taken: 40
Branches: main

Refactor the top level of mlds_to_il so that we only do one pass over
the MLDS to generate the ILDS.  As a side effect of this change nondet
code now works again.

compiler/mlds_to_il.m:
    Do a MLDS to MLDS transformation which places all the procedures and
    data into the mercury_code class.  Then modify all the qualifiers to
    take account of this change to the code.
    Rewrite the top level so that it only does one pass over the MLDS
    data structure.
    Examine the flags when deciding which attributes to place on a
    method, field or class.

compiler/mlds.m:
    Add a new field to mlds__class_defn which is the list of
    defns which are constructors for this class.
    Add the functions mlds__append_mercury_code and mlds__append_name
    which append either "mercury_code" or an arbitary string to the
    module qualifier of a name.

compiler/ml_elim_nested.m:
    Rather then hardcoding the generation of the constructor for the
    environment class, we generate it here as an MLDS method.
    On the IL backend the mercury code is placed in a seperate class to
    the environment data, so the env_type decls must be public so as to
    be accessible from the code.

compiler/ml_code_util.m:
    Wrapper functions should be static methods not instance methods.
    Fix ml_gen_label_func_decl_flags to make this true.

compiler/rtti_to_mlds.m:
    Rtti data structures should be one_copy (ie static) not per_instance.

compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/mlds_to_c.m:
compiler/mlds_to_gcc.m:
compiler/mlds_to_java.m:
    Misc changes to handle the additon of a list of constructors to the
    mlds__class_defn.

compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
    Use the function class_name rather then mercury_module_name_to_mlds.
2001-07-09 15:55:07 +00:00
Peter Ross
5c2103005e The .NET backend requires that names are not only qualified with their
Estimated hours taken: 4
Branches: main

The .NET backend requires that names are not only qualified with their
namespace but the source package the name comes from.  In this change we
back out a previous solution to this problem and implement a much
neater solution where we hide the package name in the abstract type
mlds_module_name.

This solution is neater because the package name shouldn't change once
the name is defined.  All that we may have to change is the qualifiers
to the name.

compiler/mlds.m:
    Add the package name to the abstract type mlds_module_name.

compiler/ml_call_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_il.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
compiler/rtti_to_mlds.m:
    Back out previous solution.
2001-06-22 09:14:39 +00:00
Peter Ross
bdad224cf7 Add the self rval (ie this pointer in C++) for use on OO backends.
Estimated hours taken: 0.5
Branches: main

Add the self rval (ie this pointer in C++) for use on OO backends.

compiler/mlds.m:
    Add the self rval.

compiler/ml_elim_nested.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_il.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
    Code to handle the new rval.
2001-06-21 10:33:55 +00:00
Peter Ross
f092670758 The .NET backend requires that names are not only qualified with their
Estimated hours taken: 16
Branches: main

The .NET backend requires that names are not only qualified with their
namespace but the source package the name comes from.  In this change we
add to the name type the name of the source package which this name is
defined in.  This change will be needed for implementing foreign_class
in the .NET backend where it will no longer be possible to determine
the package name from the fully qualified name.

compiler/mlds.m:
    Add the new field to the mlds__fully_qualified_name type.

compiler/ml_call_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_tailcall.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/mlds_to_c.m:
compiler/mlds_to_csharp.m:
compiler/mlds_to_il.m:
compiler/mlds_to_java.m:
compiler/mlds_to_mcpp.m:
compiler/rtti_to_mlds.m:
    Propogate the changes around.
2001-06-08 09:13:45 +00:00
Tyson Dowd
0abfaafd11 Various fixes for --grade il.
Estimated hours taken: 2.5
Branches: main

Various fixes for --grade il.

compiler/mlds_to_il.m:
	Only add "mercury_code" suffixes to a module name if it is
	necessary.  This allows us to omit "mercury_code" when generating
	field references correctly for classes that are generated for
	user-defined types when using --high-level-data.

	Generate code for new_object using the class-based approach (as
	opposed to the low-level data array based approach).

	Fix the code for generating fieldrefs so that we use the
	module name in the named_field to generate a classname.

compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
	Minor changes to handle the new interface to
	mlds_module_name_to_class_name.
2001-05-24 07:03:52 +00:00
Peter Ross
ae679d5189 Add a missing public declaration when declaring the mercury_code class.
Estimated hours taken: 0.2
Branches: main

compiler/mlds_to_csharp.m:
    Add a missing public declaration when declaring the mercury_code class.
2001-05-08 10:20:35 +00:00
Tyson Dowd
838119ab5f Address Fergus's review comments, mostly fixing the output of
Estimated hours taken: 0.4
Branches: main

compiler/mlds_to_csharp.m:
	Address Fergus's review comments, mostly fixing the output of
	types and calling sorry/2 when appropriate.
2001-05-07 15:26:05 +00:00
Tyson Dowd
76ac44335d Implement a C# interface for the .NET backend.
Estimated hours taken: 45
Branches: main

Implement a C# interface for the .NET backend.

To use it, you currently need to set
	--backend-foreign-language csharp --use-foreign-language csharp
in your MCFLAGS.

The C# foreign language interface works by introducing a new sort of
MLDS statement called outline_foreign_proc.  outline_foreign_proc is expected
to be turned into a separate procedure in a separate file.  This is
quite different to normal foreign code which has been renamed as inline
target code, as it is really intended to be generated inline, inside the
generated code.

Because outline_foreign_proc is expected to be generated outside the
normal code, we don't need to generate variable renamings,
initializations, casts and other complicated interfacing code.

Any marshalling is done by the backend, which knows how to marshall
arguments across the boundary into the outline code and back.  In the
case of marshalling to C# from the .NET backend, we currently don't do
anything special (part of the point of .NET is that data
representation don't have to change very often just because you are
using different languages, so this is a property we should try to
preserve).

The actual implementation of the foreign code is therefore very simple.
Simply generate an appropriate procedure, and insert the user's code in
the middle.

The bulk of this change to delay the mangling of MLDS var names, so we
can still use the original user's var name when we output the outline
procedure (since the user's foreign code will refer to these var names,
it's important to keep them around).

compiler/foreign.m:
	Handle the csharp foreign language.

compiler/globals.m:
	Fix an XXX about converting to lowercase to do language name
	comparisons.
	Add new predicates to make conversion of foreign languages
	to strings more uniform.

compiler/handle_options.m:
	Don't set backend_foreign_language to the default if it has
	already been set by hand.

compiler/ml_call_gen.m:
compiler/ml_code_gen.m:
compiler/ml_code_util.m:
	Delay the mangling of MLDS var names by keeping the variable
	number around until the output phase.

	Slightly generalize the handling of foreign language interfacing.
	Handle C# foreign language interfacing.

	Add value_output_vars to the ml_gen_info, which are the variables
	returned rather than passed by reference.  We need to know
	these variables for C# interfacing so that we can handle the return
	value of the forwarding function.

	Mark the beginning and end of the MLDS foreign language processing as
	a "sub-module" (in comments at least).  Later I may put this code
	into a separate module.

	Rename some predicates from c_code to foreign_code.

compiler/ml_elim_nested.m:
compiler/ml_optimize.m:
compiler/ml_string_switch.m:
compiler/ml_type_gen.m:
compiler/ml_unify_gen.m:
compiler/ml_util.m:
compiler/rtti_to_mlds.m:
	Handle the new var_name type, and the new target_code constructors.

compiler/mlds.m:
	Add outline_foreign_proc which is handled differently to the old
	target_code (which has been renamed inline_target_code).

	Change the definiton for mlds__var_name.

compiler/mlds_to_c.m:
	Factor out mlds_output_to_file.
	Handle the new var_name type, and the new target_code constructors.

compiler/mlds_to_csharp.m:
	A new module to generate C# code suitable for foreign language
	interfacing.  This is largely lifted from the MC++ code, with a few
	changes to the output syntax.

compiler/mlds_to_il.m:
	Return the set of foreign languages processed instead of a bool
	saying wither MC++ was present.  This is so we can generate the
	appropriate output .cs or .cpp files, and because we need to keep
	track of all the external assembly references we need to put in the
	.il file.

	Handle the inline_target_code and mlds__var_name changes.

compiler/mlds_to_ilasm.m:
	Output .cpp and .cs files conditionally.
	Factor out output_to_file.
	Move MC++ output code to mlds_to_mcpp.m

compiler/mlds_to_java.m:
	Factor out output_to_file.
	Handle the new var_name type, and the new target_code constructors.

compiler/mlds_to_mcpp.m:
	New file to handle generating MC++ code suitable for foreign language
	interfacing.

compiler/options.m:
	Add a way of setting the backend-foreign-language option.

compiler/passes_aux.m:
	Add output_to_file which is used by the MLDS backend to generate
	output files.

compiler/prog_data.m:
	Uncomment csharp as a foreign language.
2001-05-02 11:36:41 +00:00