Alibaba T-Head TH1520 RISC-V CPU & A Few New Arm SoCs Ready For Linux 6.5

[kreijack]

Cool..

I suspect it to be a bit slower than Cortex A72, clock per clock, but at 2.5Ghz it will be maybe faster.
However...building it for that specification is more costly, and probably it will not be built for it..so expect only 2Ghz..in my opinion.

I have some questions

The floating point unit says that its fully in compliance with IEEE-754, but it doesn't support exceptions
What's happen when I divide a number by zero?

It is more interesting. Yes it seems that the riscv doesn't trap in case of division by zero. But this is true also for the INTEGRAL division.
I update your program ( if you write directly 1/0, may be gcc translate this directly in 'inf').

#include <stdio.h>

void idiv(int a, int b) {
        printf("int %d / %d =", a, b);
        fflush(stdout);
        int d = a / b;
        printf("%d\n", d);
        fflush(stdout);
}

void fdiv(float a, float b) {
        printf("float %f / %f =", a, b);
        fflush(stdout);
        float d = a / b;
        printf("%f\n", d);
        fflush(stdout);
}

int main( int argc, char** argv )
{
        fdiv(1, 0);
        fdiv(-1, 0);
        fdiv(0, 0);
        idiv(1, 0);
        idiv(-1, 0);
        idiv(0, 0);

        return 0;
}
​

And I got

# x86_64
float 1.000000 / 0.000000 =inf
float -1.000000 / 0.000000 =-inf
float 0.000000 / 0.000000 =-nan
int 1 / 0 =Floating point exception (core dumped)​

where on riscv (qemu)

# risc-v
float 1.000000 / 0.000000 =inf
float -1.000000 / 0.000000 =-inf
float 0.000000 / 0.000000 =nan
int 1 / 0 =-1
int -1 / 0 =-1
int 0 / 0 =-1
​

So it seems that neither x86_64 nor risc-v trap in case of division by zero if the operation is between floating number. Different in case of integer number..

[tuxd3v]

It is more interesting. Yes it seems that the riscv doesn't trap in case of division by zero. But this is true also for the INTEGRAL division.
I update your program ( if you write directly 1/0, may be gcc translate this directly in 'inf').

Well, fe exceptions seems to be broken...by design maybe, see this.

So it seems that neither x86_64 nor risc-v trap in case of division by zero if the operation is between floating number. Different in case of integer number..

Unfortunately that is the case..and the gnu '-fsignaling-nans' seems just cosmetics..or I got it wrong..

try to enabled fpu exceptions on amd64:

#include <stdio.h>
#include <fenv.h>

void idiv(int a, int b) {
        printf("int %d / %d =", a, b);
        fflush(stdout);
        int d = a / b;
        printf("%d\n", d);
        fflush(stdout);
}

void fdiv(float a, float b) {
        printf("float %f / %f =", a, b);
        fflush(stdout);
        float d = a / b;
        printf("%f\n", d);
        fflush(stdout);
}

int main( int argc, char** argv )
{
       feenableexcept(FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW);

        fdiv(1, 0);
        fdiv(-1, 0);
        fdiv(0, 0);
        idiv(1, 0);
        idiv(-1, 0);
        idiv(0, 0);

        return 0;
}​

when compiling, link with math library, -lm

./program
float 1.000000 / 0.000000 =Floating point exception (core dumped)​

[tuxd3v]

I did check the spec from aliexpress it say it is BXM-4-64 GPU, and was dispointed over the gpu speed only 256 GFLOPS and 16 gigapixels per second.
so the gpu is very week and can not be use for heavy calc, But it is faster what rasbery pi gpu rpi 4 gpu is 13.5 GFLOPS

As others have pointed out, the Idea is to help develop the ecosystem.
Well, the GPU is not just faster...it around 20x faster than rpi4.

The drivers are still being developed, at least is how I understand it.

[kreijack]

Well, fe exceptions seems to be broken...by design maybe, see this.


Unfortunately that is the case..and the gnu '-fsignaling-nans' seems just cosmetics..or I got it wrong..

try to enabled fpu exceptions on amd64:

[...]
feenableexcept(FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW);
[..]

when compiling, link with math library, -lm

./program
float 1.000000 / 0.000000 =Floating point exception (core dumped)​

It still doesn't work: the function is missing due to the fact that the handling of the FP exception is different in risc-v.

​$ gcc -Wall -lm -o c c.c
c.c: In function ‘main’:
c.c:23:9: warning: implicit declaration of function ‘feenableexcept’; did you mean ‘feraiseexcept’? [-Wimplicit-function-declaration]
   23 |         feenableexcept(FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW);
      |         ^~~~~~~~~~~~~~
      |         feraiseexcept
/usr/bin/ld: /tmp/ccL7a35L.o: in function `main':
c.c:(.text+0x12e): warning: feenableexcept is not implemented and will always fail
​

BTW, my tests are done using qemu

[tuxd3v]

It still doesn't work: the function is missing due to the fact that the handling of the FP exception is different in risc-v.
BTW, my tests are done using qemu

Well, yeah maybe they still don't work on RISCV( I don't know of any fpu on RISCV that implement them ),
Maybe qemu doesn't emulate hardware exceptions..

[uxmkt]

The main reason is as a development vehicle, and for that it's fast enough.

That depends on the type of development.

[coder]

So it seems that neither x86_64 nor risc-v trap in case of division by zero if the operation is between floating number. Different in case of integer number..

On Linux/x86-64 the default behavior is not to generate floating point exceptions. You can override this using the API in fenv.h:

#include <fenv.h>

...
    feenableexcept(FE_DIVBYZERO);

The result is you'll get a SIGFPE (8). You can even register a signal handler for this:

#include <signal.h>

​void sighandler(int n)
{
    printf("Got signal: %d\n", n);
    fflush(stdout);
    exit(1);
}

​...
    signal(SIGFPE, &sighandler);

If you set the signal handler without enabling FE_DIVBYZERO, the program will execute until idiv(1, 0), before you get a SIGFPE. If you first enable FE_DIVBYZERO, then it'll raise a SIGFPE immediately when you do your first fdiv(1, 0).

In either case, the signal appears to be fatal. I tried feclearexcept(FE_DIVBYZERO) inside the signal handler (and removing the exit()), but it made no difference. The program just got stuck in a loop, continually calling the signal handler. If you figure out how to clear this state and continue executing, let me know. Not that I really want to do such a thing, but it'd be interesting to know.

[coder]

Well, fe exceptions seems to be broken...by design maybe, see this.

WTF? You call that "broken by design", but then it's somehow okay that this CPU doesn't implement FP exceptions?

If libc is intended to support even CPUs which don't implement FP exceptions, then defaulting FP exceptions to disabled is actually the correct choice! That way, you get the same behavior on both.

[tuxd3v]

WTF? You call that "broken by design", but then it's somehow okay that this CPU doesn't implement FP exceptions?

You are misunderstanding my position..
I think that any Hardware that wants to be taken seriously does need to have hardware exceptions.
However current hardware is made to enable people to advance riscv ecosystem..its different, they have completely different goals..

If libc is intended to support even CPUs which don't implement FP exceptions, then defaulting FP exceptions to disabled is actually the correct choice! That way, you get the same behavior on both.

The tradition is to shift the dirty to "behind the carpet", shifting the problem to the client programmer..
I think that archs have the responsibility to provide ways of detection...what is supported and what is not..

[coder]

You are misunderstanding my position..
I think that any Hardware that wants to be taken seriously does need to have hardware exceptions.
However current hardware is made to enable people to advance riscv ecosystem..its different, they have completely different goals..

Well, if this CPU is only about advancing the ecosystem, then they should've prioritized features over performance.

However, for all we know, the actually tried to implement FPE, but there was some chip bug and they decided just to disallow them instead of respinning the chip. I think they're not simple to implement, on a pipelined CPU.

The tradition is to shift the dirty to "behind the carpet", shifting the problem to the client programmer..
I think that archs have the responsibility to provide ways of detection...what is supported and what is not..

I'm not really sure what you're complaining about. Is it that compile-time warning? These functions do also provide return codes that indicate whether they worked, but I guess the libc maintainers thought that wasn't good enough.