Reintroduction of lib9/setfcr*.c

[Marc Simpson]

Rollback commit 5cecf6e knocked out lib9/setfcr*.c, originally introduced in 99784be:

lib9/setfcr-DragonFly-386.c
lib9/setfcr-Linux-arm.c
lib9/setfcr-Linux-power.S
lib9/setfcr-MacOSX-386.c
lib9/setfcr-MacOSX-power.c
lib9/setfcr-NetBSD-386.c
lib9/setfcr-OpenBSD-386.c
lib9/setfcr-Solaris-sparc.c

To build against tip (1055301) on OSX, I had to restore lib9/setfcr-MacOSX-386.c. So,

• Is there a reason for the removal in 5cecf6e?
• If inadvertant, could these files be added back for portability?

[Charles Forsyth]

Most of them were removed because they were suspect. I've added back the Linux-arm one as assembly. I've got a revised MacOSX-386, but still need to test it.

Which system are you using? It might help to test at least one of the varieties.

[Marc Simpson]

Yosemite 10.10.4 (Darwin 14.4.0, x86_64).

[Charles Forsyth]

Here's a tiny program ttfp.c (I couldn't find a way of attaching it directly here). Please could you compile it with gcc -m32 -O -S ttfp.c

#include <stddef.h>
#include <stdlib.h>
#include <math.h>
double k = NAN;
double
f(double g)
{
    return g*2;
}

I'm interested which floating-point instructions OS X uses by default if you compile for 32-bit mode.

[Marc Simpson]

    .section    __TEXT,__text,regular,pure_instructions
    .macosx_version_min 10, 10
    .globl  _f
    .align  4, 0x90
_f:                                     ## @f
## BB#0:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $8, %esp
    movsd   8(%ebp), %xmm0
    addsd   %xmm0, %xmm0
    movsd   %xmm0, -8(%ebp)
    fldl    -8(%ebp)
    addl    $8, %esp
    popl    %ebp
    retl

    .section    __DATA,__data
    .globl  _k                      ## @k
    .align  3
_k:
    .long   0                       ## double NaN
    .long   2146959360


.subsections_via_symbols

[Charles Forsyth]

Good. I thought it would be using SSE. Superficially, the old setfcr was wrong, and I have now got one with SSE instructions. On the other hand, the x86/32 JIT doesn't (yet) know about SSE at all, so it could be that it's just the 387 fpu state that matters for Inferno as it stands, and the OS X kernel will save and restore those registers without worrying about them. It's a strange hybrid. The SSE instructions will be used outside the JIT, for instance in the xec.c interpreter code, but values go to memory between that and the JIT. Presumably setfcr etc should really be setting both sets of control registers at the moment! For now, I'll put the original MacOSX-386.c file back, so the thing will at least compile while sorting this out. Longer term it would be better to switch to SSE for x86 JIT, since nearly everything can be made to use that now, I think.

[Marc Simpson]

Thanks Charles.

Speaking of floating point, Charon crashes on launch with

[$Math] Broken: "sys: fp: exception status=0000 pc=0x47dc7"

which may be related to the FPU issues outlined above.