[m-dev.] .NET back-end now bootstraps!
fjh at cs.mu.OZ.AU
Fri Feb 21 17:35:19 AEDT 2003
I finally got the .NET back-end to complete a three-stage bootstrap today!
A little bit of manual intervention was required at some points to get
it to build, but in the end the generated stage 2 and stage 3 *.il files
matched exactly, modulo some full path names embedded in the ".line"
directives in the generated IL (which were .../stage2/... and
This is a major test of the functionality and reliability of the Mercury
compiler's .NET back-end (and also a test of the .NET implementation,
of course -- in this case I was using the Microsoft .NET Framework SDK
Unfortunately it only bootstraps correctly if the IL files are assembled
with debugging enabled; if they are not, then at some point the compiler
gets a System.InvalidProgramException. Fixing that is still, uh,
"Future Work" ;-)
I'd like to tell you all how many petacycles the bootstrapping process
took, but unfortunately the click-wrap license for the .NET SDK version
1.0 says that "You may not disclose the results of any benchmark test of
the .NET Framework component of the Product to any third party without
Microsoft's prior written approval".
For reference, here are directions on how to bootstrap the compiler in
- Start things off as usual, e.g.
cvs checkout mercury
cvs checkout tests
At this point I applied the attached patch, but in retrospect
I think that in fact this patch is probably not needed.
- Then put
GRADE = il
in Mmake.params, and if you applied the patch mentioned above
GRADE = il
in Mmake.stage.params, and then do
tools/bootcheck --grade il
I think it *is* necessary to build stage 1 in grade IL
to get stage 2 and 3 to compare OK; there are some issues
with character representation and computation of e.g. string
switch hash tables when cross-compiling to a different
character representation which cause differences between
stage 1 and 2.
- The build or bootcheck may sometimes die due to
"cygpath: error obtaining title Mutex" which seems to
occur intermittently. This can be avoided by invoking
the failing shell command manually (rather than from make),
and then continuing the bootcheck.
Putting "notitle" in the CYGWIN environment variable
might also avoid this problem, but I haven't tried that.
- The bootcheck may die when it gets to the library directory.
If so, do
cd library # or stage2/library or stage3/library
and then continue the bootcheck.
This one is actually a missing dependency in our Mmakefiles
and could easily be fixed.
- The bootcheck may die when it gets to the next stage,
due to not being able to find some DLLs.
cd compiler # or stage2/compiler or stage3/compiler
cd ../browser/*.dll .
cd ../analysis/*.dll .
and then continue the bootcheck again.
This one is another missing dependency in our Mmakefiles
that could also easily be fixed.
- In the directions above, "continue the bootcheck" means to cd back to
the main `mercury' directory, and then do one of
tools/bootcheck --grade il
tools/bootcheck --grade il --keep-stage-2
tools/bootcheck --grade il --keep-stage-2 --keep-stage-3
depending on how far it got last time.
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
-------------- next part --------------
RCS file: /home/mercury1/repository/mercury/Mmake.workspace,v
retrieving revision 1.12
diff -u -d -u -r1.12 Mmake.workspace
--- Mmake.workspace 13 Feb 2003 08:28:42 -0000 1.12
+++ Mmake.workspace 21 Feb 2003 05:59:51 -0000
@@ -102,7 +102,8 @@
MCFLAGS += --options-file $(WORKSPACE)/Mercury.options
-MCFLAGS += --no-mercury-stdlib-dir -I$(LIBRARY_DIR)
+FIX_PATH_FOR_MMC = echo
+MCFLAGS += --no-mercury-stdlib-dir -I`$(FIX_PATH_FOR_MMC) $(LIBRARY_DIR)`
MGNUCFLAGS += --no-mercury-stdlib-dir
C2INITFLAGS += --trace-init-file $(BROWSER_DIR)/$(BROWSER_LIB_NAME).init
C2INITARGS += $(LIBRARY_DIR)/$(STD_LIB_NAME).init \
More information about the developers