[m-rev.] Java back-end milestone
Peter Ross
pro at missioncriticalit.com
Tue Dec 2 21:22:27 AEDT 2003
On Tue, Dec 02, 2003 at 08:59:37PM +1100, Fergus Henderson wrote:
> Index: compiler/mlds_to_java.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/mlds_to_java.m,v
> retrieving revision 1.47
> diff -u -d -r1.47 mlds_to_java.m
> --- compiler/mlds_to_java.m 1 Dec 2003 13:16:53 -0000 1.47
> +++ compiler/mlds_to_java.m 2 Dec 2003 09:42:46 -0000
> @@ -28,8 +28,15 @@
> % (Java does not allow the name of a nested class to be
> % the same as its enclosing class)
> % General code cleanup
> -% handle static ground terms
> -% RTTI (requires static ground terms)
> +% handle static ground terms(?)
> +% RTTI: currently we generate RTTI data which compiles,
> +% but which is not actually usable. The class
> +% hierarchy of the RTTI classes in java/runtime/*.java
> +% needs quite a bit of work. It is implemented in a way
> +% that mirrors what we do for C, but in C we rely on being
> +% able to coerce between different types that have the same
> +% initial fields (e.g. FA_TypeInfo_Struct and TypeInfo_Struct),
> +% and that doesn't work in Java.
> % generate names of classes etc. correctly (mostly same as IL backend)
> % support foreign_import_module for Java
> % handle foreign code written in C
Shouldn't the RTTI for java be very similar to what is done for the .NET
backend? After all both backends have similar problems.
I did a lot of work on implementing a lot of the RTTI in Mercury (see
rtti_implementation.m). All that it should require is that one
implements the foreign_proc functions which are used to access various
fields in the RTTI structures.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list