From wesley at terpstra.ca  Fri Feb 12 10:00:31 2010
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Fri Feb 12 10:00:35 2010
Subject: [MLton] Spill in x86 codegen
Message-ID: <162de7481002121000s110141c6jfa0806732b26f28b@mail.gmail.com>

There's a bug relating to '-format library' in the x86 codegen. I had
to reserve the register ebx to point to the global offset table in PIC
code. Things seem to work most of the time, but some programs run into
a Spill exception. The only two regression tests that demonstrate the
problem are conversion and fixed-integer.

./build/bin/mlton -format library ./regression/conversion.sml
chooseRegister:
entries:
%esp MEM<l>{StaticNonTemp}[(c_stackP)+(0x0)] 1054 false NO
%ebx MEM<l>{StaticNonTemp}[(_GLOBAL_OFFSET_TABLE_)+(0x0)] 2013 true NO
%dh MEM<b>{Stack}[(MEM<l>{GCStateHold}[((gcState+0x8))+(0x0)])+(0x50)]
999 true NO
%ebp MEM<l>{GCStateHold}[((gcState+0x8))+(0x0)] 989 false NO
%ecx MEM<l>{GCStateHold}[((gcState+0x0))+(0x0)] 2013 false NO
reserved:
%ebx
%esp
%eax
%ax
%al
%ah
%ecx
%cx
%cl
%ch
%edx
%dx
%dl
%dh
fltstack:
size = b
supports = []
saves = [%dh]
force = [%ebx, %bx, %bl, %bh, %edi, %di, %esi, %si]
reserved = [%dh, %dl, %dx, %edx, %ch, %cl, %cx, %ecx, %ah, %al, %ax,
%eax, %esp, %ebx]
depth = 1
Raising Spill in chooseRegister

As the error message shows, ebx contains the _GLOBAL_OFFSET_TABLE_, as
it should. Don't release MLton yet please. :)

From matthew.fluet at gmail.com  Mon Feb 15 09:19:43 2010
From: matthew.fluet at gmail.com (Matthew Fluet)
Date: Mon Feb 15 09:20:18 2010
Subject: [MLton] Re: [MLton-commit] r7419
In-Reply-To: <E1Nh4ER-000569-VR@mlton.org>
References: <E1Nh4ER-000569-VR@mlton.org>
Message-ID: <af2d9f671002150919k331e33e0ke3500c36e1379db0@mail.gmail.com>

On Mon, Feb 15, 2010 at 11:55 AM, Wesley Terpstra <wesley@mlton.org> wrote:
> Another multiple target bug.
>
> This says to build the two output files by executing the rule twice.
> front-end/mlb.grm.sig front-end/mlb.grm.sml: front-end/mlb.grm
> ? ? ? ?$(MAKE) -C front-end mlb.grm.sig mlb.grm.sml
>
> This describes a target-group rule that generates two files at once.
> front-end/%.grm.sig front-end/%.grm.sml: front-end/%.grm
> ? ? ? ?$(MAKE) -C front-end $(<F).sig $(<F).sml
>
> ... though you'd think they behave the same since they look alike, they don't.

Nice fixes.

Is there a way to describe a target-group that generates multiple
files at once, where the files aren't necessarily simple variations on
a name stem?

From matthew.fluet at gmail.com  Mon Feb 15 09:21:38 2010
From: matthew.fluet at gmail.com (Matthew Fluet)
Date: Mon Feb 15 09:22:12 2010
Subject: [MLton] Re: [MLton-commit] r7416
In-Reply-To: <E1Nh2O1-0006NB-Sd@mlton.org>
References: <E1Nh2O1-0006NB-Sd@mlton.org>
Message-ID: <af2d9f671002150921v76b598e3k5e31b8aee017a0ed@mail.gmail.com>

On Mon, Feb 15, 2010 at 9:57 AM, Wesley Terpstra <wesley@mlton.org> wrote:
> Fix Makefile to work with 'make -j X'.
> gdtoa/*.o was rebuilt in-place as pic, gdb, and normal.
> This made it break if compiled concurrently.
>
>
> ----------------------------------------------------------------------
>
> U ? mlton/trunk/runtime/Makefile
>
> ----------------------------------------------------------------------
>
> Modified: mlton/trunk/runtime/Makefile
> ===================================================================
> --- mlton/trunk/runtime/Makefile ? ? ? ?2010-02-13 12:47:42 UTC (rev 7415)
> +++ mlton/trunk/runtime/Makefile ? ? ? ?2010-02-15 14:57:21 UTC (rev 7416)
> @@ -217,6 +217,15 @@
> ? ? ? ?$(shell find basis -type f | grep '\.h$$')
> ?BASISCFILES := ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ?$(shell find basis -type f | grep '\.c$$')
> +GDTOACFILES := ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? dmisc.c ? ?g__fmt.c ? misc.c ? ? strtoIdd.c ?strtopdd.c ?strtorf.c ? ? ?\
> + ? ? ? dtoa.c ? ? gmisc.c ? ?smisc.c ? ?strtoIf.c ? strtopf.c ? strtorQ.c ? ? ?\
> + ? ? ? g_ddfmt.c ?g_Qfmt.c ? strtod.c ? strtoIg.c ? strtopQ.c ? strtorx.c ? ? ?\
> + ? ? ? g_dfmt.c ? g_xfmt.c ? strtodg.c ?strtoIQ.c ? strtopx.c ? strtorxL.c ? ? \
> + ? ? ? gdtoa.c ? ?g_xLfmt.c ?strtodI.c ?strtoIx.c ? strtopxL.c ?sum.c ? ? ? ? ?\
> + ? ? ? gethex.c ? hd_init.c ?strtof.c ? strtoIxL.c ?strtord.c ? ulp.c ? ? ? ? ?\
> + ? ? ? g_ffmt.c ? hexnan.c ? strtoId.c ?strtopd.c ? strtordd.c
> +GDTOACFILES := $(patsubst %,gdtoa/%,$(GDTOACFILES))

A less brittle list of files?

GDTOAHFILES :=                                                  \
        gdtoa/arith.h $(shell gzip -dc gdtoa.tgz | tar tf - | grep
'gdtoa/[^/]*\.h$$')
GDTOACFILES :=                                                  \
        $(filter-out gdtoa/arithchk.c,$(shell gzip -dc gdtoa.tgz | tar
tf - | grep 'gdtoa/[^/]*\.c$$'))

From wesley at terpstra.ca  Mon Feb 15 09:57:32 2010
From: wesley at terpstra.ca (Wesley W. Terpstra)
Date: Mon Feb 15 09:58:06 2010
Subject: [MLton] Makefile madness
Message-ID: <162de7481002150957x20ea75b2m1ca8cb573d453244@mail.gmail.com>

So I've completed a few fixes to get 'make -j 15' working. It's not a
huge speed-up, because the Makefile does many steps in each rule
(using for loops) and the self-compile is not parallel. However, it
most importantly stops the build from breaking when your make is
parallel by default. Unfortunately, as you can see in the attached
top-level Makefile the changes are a bit invasive. I've committed all
the non-invasive stuff already to HEAD. I leave to others the decision
of whether or not committing the last fixes is a good idea before the
next release.

I also feel my changes (invasive as they are) are wholly inadequate.
The MLton build system is a quite a mess and my changes are more like
a band-aide than a fix. We have duplicated work in each Makefile, and
the system loses track of dependencies that happen in sub-folders.
This means, for example, that a change to the basis library neither
gets copied into the build folder nor triggers a rebuild of the
compiler. Probably it would be a good idea to replace the mess we have
with a well written non-recursive makefile after the next release.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 14113 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20100215/d6234475/Makefile.obj
From Michael.Norrish at nicta.com.au  Wed Feb 17 00:57:14 2010
From: Michael.Norrish at nicta.com.au (Michael Norrish)
Date: Wed Feb 17 00:57:25 2010
Subject: [MLton] Makefile madness
In-Reply-To: <162de7481002150957x20ea75b2m1ca8cb573d453244@mail.gmail.com>
References: <162de7481002150957x20ea75b2m1ca8cb573d453244@mail.gmail.com>
Message-ID: <4B7BAF6A.1050001@nicta.com.au>

On 16/02/10 4:57 , Wesley W. Terpstra wrote:
> Probably it would be a good idea to replace the mess we have
> with a well written non-recursive makefile after the next release.

As in "Recursive make considered harmful" ?

http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

Michael

From hkBst at gentoo.org  Sun Feb 21 04:52:10 2010
From: hkBst at gentoo.org (Marijn Schouten (hkBst))
Date: Tue Feb 23 05:58:05 2010
Subject: [MLton] Makefile madness
In-Reply-To: <4B7BAF6A.1050001@nicta.com.au>
References: <162de7481002150957x20ea75b2m1ca8cb573d453244@mail.gmail.com>
	<4B7BAF6A.1050001@nicta.com.au>
Message-ID: <201002211352.10917.hkBst@gentoo.org>

On Wednesday 17 February 2010 09:57:14 Michael Norrish wrote:
> On 16/02/10 4:57 , Wesley W. Terpstra wrote:
> > Probably it would be a good idea to replace the mess we have
> > with a well written non-recursive makefile after the next release.
> 
> As in "Recursive make considered harmful" ?
> 
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

Now seems to be at: http://miller.emu.id.au/pmiller/books/rmch/

Marijn