Minix do NOT have FPU ?

[BeakGwangMoon]

#include <stdio.h>

Hi, All

int main (void) {
double i = 0.0;

printf (" i = %g\n", i);

}

this code can be compile, link.
but can't run.

PM: coredump signal 4 for 631 / a.out
a.out 109847 0x804821b 0x804813b 0x804800b5 0x1
Illegal instruction (core dumped)

Why core dumped ?
Do you have any plan to support FPU ?

With kind regards,
moon

[Antoine LECA]

BeakGwangMoon wrote:
> #include <stdio.h>

> int main (void) {
> double i = 0.0;
>
> printf (" i = %g\n", i);
>
> }
>
> this code can be compile, link.
> but can't run.

It runs here (with clang-2.9nb6 on P4), without even adding -lm
$ clang m.c
$ ./a.out
i = 0

I just added return 0; at the end, I do not believe this changes anything.

> PM: coredump signal 4 for 631 / a.out
> a.out 109847 0x804821b 0x804813b 0x804800b5 0x1
> Illegal instruction (core dumped)
> Why core dumped ?

Above message said because SIGILL was raised, which usually happens when
CPU raises the #UD ("undefined opcode") exception, on the code at
virtual address 0804821b

Using last clang-2.9nb6, I see it compiles the above code as
movl $0, %eax
cvtsi2sd %eax, %xmm0
movl $0, -4(%ebp)
movsd %xmm0, -16(%ebp)
movsd -16(%ebp), %xmm0
movl %esp, %ecx
movsd %xmm0, 4(%ecx)
movl $.L.str, (%ecx)
movl %eax, -20(%ebp) # 4-byte Spill
calll printf
movl %eax, -24(%ebp) # 4-byte Spill
movl -20(%ebp), %eax # 4-byte Reload

and I guess your CPU does not have support for those instructions.

> Do you have any plan to support FPU ?

MINIX 3 *requires* a FPU (Pentium-class CPU actually), and always had.
Only thing is that in addition, it seems it currently requires SSE2 by
default, probably because of the options used to compile clang.


Antoine

[Ben Gras]

All,

> Do you have any plan to support FPU ?

MINIX 3 *requires* a FPU (Pentium-class CPU actually), and always had.
Only thing is that in addition, it seems it currently requires SSE2 by
default, probably because of the options used to compile clang.

True; and/but that's why -march=i586 is added to the default base system and pkgsrc compilation flags, so that the generic minix distribution should not require any SSE cpu by default.

[prasannatsmkumar]

If there is no FPU support compilers used to add fixed point
arithmetic (based on how turbo C does this). Not sure if this applies
still. Now all the machines have FPU I guess and it seems Minix also
supports FPU. I am interested in knowing the cause for SIGILL (just
for academic purpose).

> --
> You received this message because you are subscribed to the Google Groups
> "minix3" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/minix3/-/YsPiydFPklIJ.
>
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to
> minix3+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/minix3?hl=en.

[BeakGwangMoon]

Thank Ben Gras and Antoine.

My computer is a Real H/W.
Minix is 3.2.0, Clang is 2.9. 306MB Memory

cat /proc/cpuinfo

processor :0
vendor_id:GenuineIntel
model name: Intel
cpu family: 6
model: 8
stepping: 6
cpu MHz: 797
flags: pni monitor ds_cpl vmx smx est tm2 cx16 xptr pdcm dca popcnt

I have to check my computer, clang.

With kind regards,
moon

[BeakGwangMoon]

I just Now compiled with flag -march=i586 my code.

It runs.

At Next time, I have to read doc, man more , and write thread.

With kind regards,
moon

[Antoine LECA]

BeakGwangMoon wrote:
> vendor_id:GenuineIntel
> model name: Intel
> cpu family: 6
> model: 8
> stepping: 6

This is Pentium III if I am not mistaken (meaning SSE1, not 2)

> cpu MHz: 797
> flags: pni monitor ds_cpl vmx smx est tm2 cx16 xptr pdcm dca popcnt

Mmm... "PNI"? Prescott New Instructions? without any SSEx flags?
No FPU, no PSE, no TSC (all required for MINIX to works OK)?

Something looks suspect in the decoding here...


Antoine

[Antoine LECA]

prasannatsmkumar wrote:
> If there is no FPU support compilers used to add fixed point
> arithmetic (based on how turbo C does this).

It was used for the i86, but was dropped from iAPX286 since that chip
had support for #NP (coprocessor not present) exception which very
conveniently achieved the same effect without any additional work from
the compiler, just a bit of OS (or libc) support. Also, i486 added
hardware interface to even closely imitate the PC/AT design (INT13.)

NetBSD (inheriting from PDP11 Unix here) had some option to behave the
way you said, which is to use -lm on the command line to include the
"math emulator"; nowadays it just includes mathematical functions.

As you note, all CPUs since >10 years have a FPU, and all the releases
of MINIX3 require it, so all of this is only of historic relevance.

> I am interested in knowing the cause for SIGILL

Read my message: the CPU did not support SSE2, the compiler generated
code which made use of those opcodes. The gory details are in Intel
IA-32 manuals (>1000 p.), about exceptions and instruction support.


Antoine

[prasannatsmkumar]

Thanks for the info antonie. Now things are clear. Why SSE2 is needed
for just "double i = 0.0"? I am not able to get the funda behind that.
Precisely what is the need of using xmm0 register?

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.

[Antoine LECA]

prasannatsmkumar wrote:
> Why SSE2 is needed for just "double i = 0.0"?

The original SSE only handled 32-bit floating-point quantities (float);
when you want to use the SSE technology for double a.k.a. 64-bit
floating-point quantities, you need at least SSE2. If you do not have
it, you need to use the alternate NPX/x87 technology, which uses a stack
machine instead of register files, so is not as easy to optimize for the
compiler.

> Precisely what is the need of using xmm0 register?

Here, really nothing at all since the ABI prescribes the passing of
parameters through the stack anyway!
But on the other hand we did not use -O either; so the compiler went the
quickest path, and loaded 0 into XMM0 when compiling 'local=0', then
later pushed XMM0 to the stack to call printf().


Antoine

[prasannatsmkumar]

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>

Oh Okay. With less optimisation (optimisation turned off) the code
could have run. Is that safe to assume? If the CPU architecture is
specified I guess the compiler would have taken the appropriate option
(as it knows the cpu does not have SSE2).

[Antoine LECA]

prasannatsmkumar wrote:
> Oh Okay. With less optimisation (optimisation turned off) the code
> could have run.

In this particular case, likely to be yes IMHO.

> Is that safe to assume?

In the general case, of course not: if you ask the compiler to target
some determinate processor and features, you can expect the generated
code to potentially take into account all the opportunities allowed by
the targeted processor, and you cannot expect the generated code to run
on any inferior processor. Even turning optimizations off.

> If the CPU architecture is
> specified I guess the compiler would have taken the appropriate option

This is the general idea, yes; if it does not, it's called a bug ;-)

> (as it knows the cpu does not have SSE2).

Basically it works this way, yes: you need to specify the target
processor (here should have been `-march=pentium3`), the compiler
deduces the set of features available on target (here, deduces that SSE2
are lacking) and generates code appropriately.

Note there is also a nice option, `-march=native`, which "guesses" the
correct best fit for the current machine.


Antoine

[Erik van der Kouwe]

Hi,

> Oh Okay. With less optimisation (optimisation turned off) the code
> could have run. Is that safe to assume? If the CPU architecture is
> specified I guess the compiler would have taken the appropriate option
> (as it knows the cpu does not have SSE2).

The compiler should not consider the platform you're currently running
on as you'll want the compiled code to be runnable on other systems as
well. In that case it is more appropriate that the operating system
sets the default options according to the hardware it itself will run
on. This setting has been incorrect in the past (causing similar
errors in the binary packages) but should be correct now. If you're
compiling code for your own usage then you should simply explicitly
specify the target platform.

With kind regards,
Erik