In hope of a release ...

[Wesley W. Terpstra]

Just a heads-up:

Since summer has come to a close a new release of MLton should be happening soon. To that end I'm going to start pushing svn builds of MLton to debian/experimental and try to get it built on more of the debian architectures. With the restructured c-types.ml system from Matthew I think it should be relatively easy to get it going on most of the debian targets using the C codegen... I hope.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Matthew Fluet-4]

It is fortunate that the ports have been going so smoothly.  I would
have cautioned against it ... introducing new, and mostly untested,
platforms shortly before a release is not a recipe for stability.

There are a few other items that I would like to finish before
releasing.  One is the performance bugs identified by Reactive
Systems.  Another is a regression failure with signals on Mac OS X
10.5 (Leopard), which I believe is due to a broken sigaltstack, but
have had difficulty isolating.

On Tue, Oct 13, 2009 at 4:17 AM, Wesley W. Terpstra <wesley@...> wrote:

> Just a heads-up:
>
> Since summer has come to a close a new release of MLton should be happening
> soon. To that end I'm going to start pushing svn builds of MLton to
> debian/experimental and try to get it built on more of the debian
> architectures. With the restructured c-types.ml system from Matthew I think
> it should be relatively easy to get it going on most of the debian targets
> using the C codegen... I hope.
>
> _______________________________________________
> MLton mailing list
> MLton@...
> http://mlton.org/mailman/listinfo/mlton
>

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Wed, Oct 14, 2009 at 11:57 PM, Matthew Fluet <matthew.fluet@...> wrote:

It is fortunate that the ports have been going so smoothly.  I would
have cautioned against it ... introducing new, and mostly untested,
platforms shortly before a release is not a recipe for stability.

Well, I'd argue that porting an otherwise portable project to new platforms usually helps turn up hidden bugs that can bite you later. Those two alignment issues, for example. There's also a segfault on kfreebsd-amd64, which I'll wager also stems from an actual bug in MLton (supposing I can find it).

Of the remaining debian targets:
  mips(el) -- known to work because I've cross-compiled it to build embedded stuff for ages, but no porter machine is available with debian that I can bootstrap it on. hoping to find someone to loan me shell access.
  arm/m68k -- insufficient memory, so not included
  hurd-i386 -- adding hurd support would require actual new code, so no sense trying to get this in

There are a few other items that I would like to finish before
releasing.  One is the performance bugs identified by Reactive
Systems.  

If it's reproducible I can take a whack at it. Which issue is this? link?
 

Another is a regression failure with signals on Mac OS X
10.5 (Leopard), which I believe is due to a broken sigaltstack, but
have had difficulty isolating.

What's the failure mode?

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Tue, Oct 13, 2009 at 10:17 AM, Wesley W. Terpstra <wesley@...> wrote:
> To that end I'm going to start pushing svn builds of MLton to
> debian/experimental and try to get it built on more of the debian
> architectures.

I'm done. The status and build logs (including regressions) can be found at:
https://buildd.debian.org/~luk/status/package.php?p=mlton

The only architecture MLton isn't working on is arm[el]. These systems
haven't enough memory and their floating point isn't rounded by a
control word, so I don't see MLton in their future.

Regressions pass completely on all targets except hurd-i386 where
http://bugs.debian.org/551470 prevents some regressions from
completing.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Henry Cejtin]

Truly excellent.  I can't wait to get updated MLtons on my Debian testing machine
via a simple apt-get.  Thanks for all the work.



----- Original Message ----
From: Wesley W. Terpstra <wesley@...>
To: mlton@...
Sent: Wednesday, October 21, 2009 7:51:03 PM
Subject: [MLton] Re: In hope of a release ...

On Tue, Oct 13, 2009 at 10:17 AM, Wesley W. Terpstra <wesley@...> wrote:
> To that end I'm going to start pushing svn builds of MLton to
> debian/experimental and try to get it built on more of the debian
> architectures.

I'm done. The status and build logs (including regressions) can be found at:
https://buildd.debian.org/~luk/status/package.php?p=mlton

The only architecture MLton isn't working on is arm[el]. These systems
haven't enough memory and their floating point isn't rounded by a
control word, so I don't see MLton in their future.

Regressions pass completely on all targets except hurd-i386 where
http://bugs.debian.org/551470 prevents some regressions from
completing.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton


_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Adam Goode-4]

On 10/21/2009 08:51 PM, Wesley W. Terpstra wrote:

> On Tue, Oct 13, 2009 at 10:17 AM, Wesley W. Terpstra <wesley@...> wrote:
>> To that end I'm going to start pushing svn builds of MLton to
>> debian/experimental and try to get it built on more of the debian
>> architectures.
>
> I'm done. The status and build logs (including regressions) can be found at:
> https://buildd.debian.org/~luk/status/package.php?p=mlton
>
> The only architecture MLton isn't working on is arm[el]. These systems
> haven't enough memory and their floating point isn't rounded by a
> control word, so I don't see MLton in their future.
>

Hmm, the Fedora builders (running on Marvell hardware) definitely have
enough memory (1GHz machines, 2GB RAM). I agree about the floating point
though, I put a patch into MLton to throw an exception if setting the
rounding mode is not available, but due to limitations in glibc on some
ARM hardware, this can silently fail to set. But it was definitely fun
getting it to build:

http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=12752

And only a factor of 5 slowdown in build time!


Adam



_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Fri, Oct 23, 2009 at 3:46 AM, Adam Goode <adam@...> wrote:
>> The only architecture MLton isn't working on is arm[el]. These systems
>> haven't enough memory and their floating point isn't rounded by a
>> control word, so I don't see MLton in their future.
>
> Hmm, the Fedora builders (running on Marvell hardware) definitely have
> enough memory (1GHz machines, 2GB RAM).

The debian arm buildd have 512MB. If they had 1GB I would've probably
ported it to them anyway. ;)

> I put a patch into MLton to throw an exception if setting the
> rounding mode is not available, but due to limitations in glibc on some
> ARM hardware, this can silently fail to set.

I was under the impression that arm assembler instructions embedded
the rounding mode into their opcode. ie: mul_round_to_zero %r0,4. Are
you saying some arm processors have 'normal' IEEE operations that
consult a control word?

Why didn't you submit the patches needed by your port for inclusion?

> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=12752

How many archs does fedora have buildds for?

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Adam Goode-4]

On 10/22/2009 10:11 PM, Wesley W. Terpstra wrote:
> On Fri, Oct 23, 2009 at 3:46 AM, Adam Goode <adam@...> wrote:
> The debian arm buildd have 512MB. If they had 1GB I would've probably
> ported it to them anyway. ;)

You should see if you can get Marvell to donate some machines to Debian.
They run the Fedora ARM builders currently.

> I was under the impression that arm assembler instructions embedded
> the rounding mode into their opcode. ie: mul_round_to_zero %r0,4. Are
> you saying some arm processors have 'normal' IEEE operations that
> consult a control word?

Well, there are 2 things. First, in software floating point (the
default), rounding mode is optional. Only round to zero is required.
With hardware VFP, there is a control word. But as an optimization, you
get 2 sets of instructions: ones that honor the control word, and ones
that always to round to zero. The round to zero instructions are only
used in the cases where C requires it (for casting), so that you don't
need to save/restore the rounding mode for casting. Otherwise, the
rounding mode should be as in IEEE.

We use fesetround from C99, but there is a bug in how glibc handles this
on ARM, depending on how things were compiled and what the hardware is:

  Behavior of fesetround with non-default rounding:

   Compiled for softfloat, no VFP hardware: returns failure (good!)
   Compiled for VFP, no VFP hardware: fails to run (good!)
   Compiled for VFP, VFP hardware present: sets rounding mode (good!)
   Compiled for softfloat, VFP hardware present: silent failure (bad!)

glibc will always set the VFP if it is present, even if floating point
is software. This can be fixed with making libgcc dynamically linked,
and picking the correct floating point library at runtime instead of
compile time, but this is not done yet.

More background here:
http://sourceware.org/ml/libc-ports/2009-04/msg00020.html

>
> Why didn't you submit the patches needed by your port for inclusion?
>

They're in there: r7081, r7082. It broke some minor things that were
fixed up later by others.


>> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=12752
>
> How many archs does fedora have buildds for?
>

http://fedoraproject.org/wiki/Architectures

Primary Architectures
 x86 (32-bit)
 x86_64 (64-bit)
 ppc (32-bit)
 ppc64 (64-bit)

Secondary Architectures
 ARM
 IA64 (inactive)
 S390
 SPARC
 Parisc (inactive?)

As of Fedora 13, ppc/ppc64 is going to be a secondary arch too. Releases
don't get delayed by problems in secondary arches.



As a related note, your work will be great for the secondary arches in
Fedora, especially S390 which I started to look at but I didn't have
access to hardware. I would love to have a new release!



Adam



_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Fri, Oct 23, 2009 at 4:44 AM, Adam Goode <adam@...> wrote:
> Well, there are 2 things. First, in software floating point (the
> default), rounding mode is optional. Only round to zero is required.
> With hardware VFP, there is a control word. But as an optimization, you
> get 2 sets of instructions: ones that honor the control word, and ones
> that always to round to zero. The round to zero instructions are only
> used in the cases where C requires it (for casting), so that you don't
> need to save/restore the rounding mode for casting. Otherwise, the
> rounding mode should be as in IEEE.

This sounds much bettter than I'd thought. The software version sounds
like it would be non-conforming re: the basis. The hardware version
can support a full MLton port.

> We use fesetround from C99, but there is a bug in how glibc handles this
> on ARM, depending on how things were compiled and what the hardware is:
>
>  Behavior of fesetround with non-default rounding:
>
>   Compiled for softfloat, no VFP hardware: returns failure (good!)
>   Compiled for VFP, no VFP hardware: fails to run (good!)
>   Compiled for VFP, VFP hardware present: sets rounding mode (good!)
>   Compiled for softfloat, VFP hardware present: silent failure (bad!)

So if a program is compiled to use hardware floating point there is no
problem aside from excluding the weaker machines? Is the presence of
VFP correlated with the presence of >=256MB of RAM? If yes, then could
we just assume any machine using MLton has VFP hardware?

> glibc will always set the VFP if it is present, even if floating point
> is software. This can be fixed with making libgcc dynamically linked,
> and picking the correct floating point library at runtime instead of
> compile time, but this is not done yet.

So if you specified software float and there is hardware available,
programs transparently start using hardware? The fesetround then fails
b/c it doesn't set the hardware control word only the flag the
software floating point sees..?

Another solution might be to check for VFP hardware in fesetround and
if present set the control word. fesetround() always needs inline
assembler anyway.

> http://sourceware.org/ml/libc-ports/2009-04/msg00020.html

> They're in there: r7081, r7082.
Of course they are. -.-

> Primary Architectures
>  ppc64 (64-bit)

Has MLton ever been compiled on ppc64?

> As a related note, your work will be great for the secondary arches in
> Fedora, especially S390 which I started to look at but I didn't have
> access to hardware. I would love to have a new release!

Debian has s390 porter boxes. You can probably request access from the
relevant admin if you wanted it. Incidentally, s390 is *fast*. It
compiles MLton faster than kfreebsd-i386 despite lacking a native
codegen.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Ville Laurikari]

On Fri, Oct 23, 2009 at 08:35:59AM +0200, Wesley W. Terpstra wrote:
> Has MLton ever been compiled on ppc64?

On ppc64 AIX, yes.  Don't know about Linux.

--
http://hashedbits.com/

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Adam Goode-4]

On 10/23/2009 02:35 AM, Wesley W. Terpstra wrote:
> This sounds much bettter than I'd thought. The software version sounds
> like it would be non-conforming re: the basis. The hardware version
> can support a full MLton port.
>

Well, I would say it could be barely conforming, since the basis appears
to tolerate implementations to throw an exception rather than implement
rounding modes.

> So if a program is compiled to use hardware floating point there is no
> problem aside from excluding the weaker machines? Is the presence of
> VFP correlated with the presence of >=256MB of RAM? If yes, then could
> we just assume any machine using MLton has VFP hardware?
>

Unfortunately, VFP is still very much an optional feature. In fact, if
you have an XScale, I don't think it is even available.

> So if you specified software float and there is hardware available,
> programs transparently start using hardware? The fesetround then fails
> b/c it doesn't set the hardware control word only the flag the
> software floating point sees..?

There is no transparent use yet, but this is possible when glibc is
compiled in multilib mode. There are a few issues to work out, but it
could be done. I looked at it months ago, but nothing recently. This
would solve the problem with rounding modes: if you have hardware,
you'll automatically use it, if not, fesetround will fail and MLton will
throw the exception. Right now if you have hardware, fesetround will
succeed but the rounding mode will be effectively ignored.

>
> Another solution might be to check for VFP hardware in fesetround and
> if present set the control word. fesetround() always needs inline
> assembler anyway.
>

Yes, that is what fesetround does. Unfortunately, it can't know if
you're actually going to use the VFP from then on! By default, you
don't, so the rounding mode is set in the hardware you're not using.

>
> Has MLton ever been compiled on ppc64?
>

I have not compiled it there. I suppose I could try to get an account
somewhere, but haven't gotten around to it.

> Debian has s390 porter boxes. You can probably request access from the
> relevant admin if you wanted it. Incidentally, s390 is *fast*. It
> compiles MLton faster than kfreebsd-i386 despite lacking a native
> codegen.

Nice! I should check to see if Fedora offers these things. The emulator
is SLOW.



Adam



_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Tue, Oct 27, 2009 at 4:02 AM, Adam Goode <adam@...> wrote:

>> So if you specified software float and there is hardware available,
>> programs transparently start using hardware? The fesetround then fails
>> b/c it doesn't set the hardware control word only the flag the
>> software floating point sees..?
>
> There is no transparent use yet, but this is possible when glibc is
> compiled in multilib mode. There are a few issues to work out, but it
> could be done. I looked at it months ago, but nothing recently. This
> would solve the problem with rounding modes: if you have hardware,
> you'll automatically use it, if not, fesetround will fail and MLton will
> throw the exception. Right now if you have hardware, fesetround will
> succeed but the rounding mode will be effectively ignored.

I'm still puzzled as to why the software floating point doesn't
support fesetround. The software emulation could test its own 'control
word' (aka global variable) as easily as (easier than?) hardware.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Adam Goode-4]

On 10/27/2009 03:02 AM, Wesley W. Terpstra wrote:

> On Tue, Oct 27, 2009 at 4:02 AM, Adam Goode <adam@...> wrote:
>>> So if you specified software float and there is hardware available,
>>> programs transparently start using hardware? The fesetround then fails
>>> b/c it doesn't set the hardware control word only the flag the
>>> software floating point sees..?
>>
>> There is no transparent use yet, but this is possible when glibc is
>> compiled in multilib mode. There are a few issues to work out, but it
>> could be done. I looked at it months ago, but nothing recently. This
>> would solve the problem with rounding modes: if you have hardware,
>> you'll automatically use it, if not, fesetround will fail and MLton will
>> throw the exception. Right now if you have hardware, fesetround will
>> succeed but the rounding mode will be effectively ignored.
>
> I'm still puzzled as to why the software floating point doesn't
> support fesetround. The software emulation could test its own 'control
> word' (aka global variable) as easily as (easier than?) hardware.

The software floating point only supports default rounding, since that
is all that is required for ARM EABI compliance. For gcc, it
is the implementation here, once described to me as "magic":

http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-sf.S?revision=148210&view=markup
http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-df.S?revision=148210&view=markup


Adam



_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Adam Goode-4]

On 10/27/2009 03:02 AM, Wesley W. Terpstra wrote:

> On Tue, Oct 27, 2009 at 4:02 AM, Adam Goode <adam@...> wrote:
>>> So if you specified software float and there is hardware available,
>>> programs transparently start using hardware? The fesetround then fails
>>> b/c it doesn't set the hardware control word only the flag the
>>> software floating point sees..?
>>
>> There is no transparent use yet, but this is possible when glibc is
>> compiled in multilib mode. There are a few issues to work out, but it
>> could be done. I looked at it months ago, but nothing recently. This
>> would solve the problem with rounding modes: if you have hardware,
>> you'll automatically use it, if not, fesetround will fail and MLton will
>> throw the exception. Right now if you have hardware, fesetround will
>> succeed but the rounding mode will be effectively ignored.
>
> I'm still puzzled as to why the software floating point doesn't
> support fesetround. The software emulation could test its own 'control
> word' (aka global variable) as easily as (easier than?) hardware.

And remember,
"Only the default rounding mode is intended for best performances"


Adam




_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Wesley W. Terpstra]

On Wed, Oct 28, 2009 at 2:02 AM, Adam Goode <adam@...> wrote:
> The software floating point only supports default rounding, since that
> is all that is required for ARM EABI compliance. For gcc, it
> is the implementation here, once described to me as "magic":
>
> http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-sf.S?revision=148210&view=markup
> http://gcc.gnu.org/viewcvs/trunk/gcc/config/arm/ieee754-df.S?revision=148210&view=markup

I can see that they tried to heavily optimize it. The SoftFloat
package [1] manages to do things in C for all rounding modes. I guess
they wanted faster FP.

[1] http://www.jhauser.us/arithmetic/SoftFloat.html

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton