[MLton] Re: In hope of a release ...

[Adam Goode]

On 10/22/2009 10:11 PM, Wesley W. Terpstra wrote:
> On Fri, Oct 23, 2009 at 3:46 AM, Adam Goode <adam at spicenitz.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mlton.org/pipermail/mlton/attachments/20091022/3cc8dd85/signature.pgp