Request: __attribute__((vector_size))

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Request: __attribute__((vector_size))

tinycc-devel mailing list
See here: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

This is one of those things that doesn't come up in a lot of types of
programming, but is indispensable in some, namely anything to do with 2D
or 3D math. The ability to just write `position += velocity * dt;` style
statements might be one of the most important reasons most game
developers choose C++ over C. It's certainly the only thing keeping me
from using TCC in the development of my own project.

Actually emitting SSE instructions might be beyond the scope of tcc
(Tiny after all), supporting the expressions though would be a huge help.

I sat down yesterday in an attempt to do this myself, but it turns out
I'm not good enough for the job. I couldn't make heads or tails of it.
However, this might be a breeze for someone that knows TCC like the back
of their hand.

So, any takers?


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian

Are you kidding ????

Le 06/01/2020 à 11:01, Rasmus Riiner via Tinycc-devel a écrit :
See here: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

This is one of those things that doesn't come up in a lot of types of programming, but is indispensable in some, namely anything to do with 2D or 3D math. The ability to just write `position += velocity * dt;` style statements might be one of the most important reasons most game developers choose C++ over C. It's certainly the only thing keeping me from using TCC in the development of my own project.

Actually emitting SSE instructions might be beyond the scope of tcc (Tiny after all), supporting the expressions though would be a huge help.

I sat down yesterday in an attempt to do this myself, but it turns out I'm not good enough for the job. I couldn't make heads or tails of it. However, this might be a breeze for someone that knows TCC like the back of their hand.

So, any takers?


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

Michael Matz-4
In reply to this post by tinycc-devel mailing list
Hello,

On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:

> See here: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>
> This is one of those things that doesn't come up in a lot of types of
> programming, but is indispensable in some, namely anything to do with 2D or
> 3D math. The ability to just write `position += velocity * dt;` style
> statements might be one of the most important reasons most game developers
> choose C++ over C. It's certainly the only thing keeping me from using TCC in
> the development of my own project.
>
> Actually emitting SSE instructions might be beyond the scope of tcc (Tiny
> after all), supporting the expressions though would be a huge help.

Without proper support in the backends for vector instructions the
generated code for this extension from TCC would be of abysmal quality.
Technically it wouldn't be too much work to semantically support that, but
the values would need to be committed to memory (instead of vector
registers) and regarded as constant sized arrays (at which point the
function call ABI would be different from the respective native ABI,
which, again, would be hard to fix without proper support for vector insns
in the backends).

That extension really doesn't feel very well suited for a simple compiler
like TCC ;-)  But perhaps it can be done non-intrusively enough.

> I sat down yesterday in an attempt to do this myself, but it turns out
> I'm not good enough for the job. I couldn't make heads or tails of it.
> However, this might be a breeze for someone that knows TCC like the back
> of their hand.
>
> So, any takers?


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian

Hi Michael.
Is the support for data structures and calculations a real "need to" for a compiler ????

regards,

ian

Le 06/01/2020 à 20:36, Michael Matz a écrit :
Hello,

On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:

See here: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

This is one of those things that doesn't come up in a lot of types of programming, but is indispensable in some, namely anything to do with 2D or 3D math. The ability to just write `position += velocity * dt;` style statements might be one of the most important reasons most game developers choose C++ over C. It's certainly the only thing keeping me from using TCC in the development of my own project.

Actually emitting SSE instructions might be beyond the scope of tcc (Tiny after all), supporting the expressions though would be a huge help.

Without proper support in the backends for vector instructions the generated code for this extension from TCC would be of abysmal quality. Technically it wouldn't be too much work to semantically support that, but the values would need to be committed to memory (instead of vector registers) and regarded as constant sized arrays (at which point the function call ABI would be different from the respective native ABI, which, again, would be hard to fix without proper support for vector insns in the backends).

That extension really doesn't feel very well suited for a simple compiler like TCC ;-)  But perhaps it can be done non-intrusively enough.

I sat down yesterday in an attempt to do this myself, but it turns out I'm not good enough for the job. I couldn't make heads or tails of it. However, this might be a breeze for someone that knows TCC like the back of their hand.

So, any takers?


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

Michael Matz-4
Hi,

On Mon, 6 Jan 2020, ian wrote:

> Is the support for data structures and calculations a real "need to" for
> a compiler ????

Um, I don't know how to answer this.  As it seems the alternative to
calculations is guessing, yes, I do think calculations and data structures
are indeed necessary for a compiler, or any program whatsoever.


Ciao,
Michael.

>
> regards,
>
> ian
>
> Le 06/01/2020 à 20:36, Michael Matz a écrit :
>       Hello,
>
>       On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:
>
>             See here:
>             https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>
>             This is one of those things that doesn't come up in
>             a lot of types of programming, but is indispensable
>             in some, namely anything to do with 2D or 3D math.
>             The ability to just write `position += velocity *
>             dt;` style statements might be one of the most
>             important reasons most game developers choose C++
>             over C. It's certainly the only thing keeping me
>             from using TCC in the development of my own project.
>
>             Actually emitting SSE instructions might be beyond
>             the scope of tcc (Tiny after all), supporting the
>             expressions though would be a huge help.
>
>
>       Without proper support in the backends for vector instructions
>       the generated code for this extension from TCC would be of
>       abysmal quality. Technically it wouldn't be too much work to
>       semantically support that, but the values would need to be
>       committed to memory (instead of vector registers) and regarded
>       as constant sized arrays (at which point the function call ABI
>       would be different from the respective native ABI, which, again,
>       would be hard to fix without proper support for vector insns in
>       the backends).
>
>       That extension really doesn't feel very well suited for a simple
>       compiler like TCC ;-)  But perhaps it can be done
>       non-intrusively enough.
>
>             I sat down yesterday in an attempt to do this
>             myself, but it turns out I'm not good enough for the
>             job. I couldn't make heads or tails of it. However,
>             this might be a breeze for someone that knows TCC
>             like the back of their hand.
>
>             So, any takers?
>
>
>
>       Ciao,
>       Michael.
>
>       _______________________________________________
>       Tinycc-devel mailing list
>       [hidden email]
>       https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- [hidden email]
> -- Développeur compulsif
>
>
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian

Michael,

Did I miss something ?
It seemed to me that it was dealing with application side of things.
Like, say, libraries. For the least, as long as compilers does not care about maths or physics....

If I'm wrong, please, explain to me where...

ian

Le 06/01/2020 à 21:46, Michael Matz a écrit :
Hi,

On Mon, 6 Jan 2020, ian wrote:

Is the support for data structures and calculations a real "need to" for a compiler ????

Um, I don't know how to answer this.  As it seems the alternative to calculations is guessing, yes, I do think calculations and data structures are indeed necessary for a compiler, or any program whatsoever.


Ciao,
Michael.


regards,

ian

Le 06/01/2020 à 20:36, Michael Matz a écrit :
      Hello,

      On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:

            See here:
            https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

            This is one of those things that doesn't come up in
            a lot of types of programming, but is indispensable
            in some, namely anything to do with 2D or 3D math.
            The ability to just write `position += velocity *
            dt;` style statements might be one of the most
            important reasons most game developers choose C++
            over C. It's certainly the only thing keeping me
            from using TCC in the development of my own project.

            Actually emitting SSE instructions might be beyond
            the scope of tcc (Tiny after all), supporting the
            expressions though would be a huge help.


      Without proper support in the backends for vector instructions
      the generated code for this extension from TCC would be of
      abysmal quality. Technically it wouldn't be too much work to
      semantically support that, but the values would need to be
      committed to memory (instead of vector registers) and regarded
      as constant sized arrays (at which point the function call ABI
      would be different from the respective native ABI, which, again,
      would be hard to fix without proper support for vector insns in
      the backends).

      That extension really doesn't feel very well suited for a simple
      compiler like TCC ;-)  But perhaps it can be done
      non-intrusively enough.

            I sat down yesterday in an attempt to do this
            myself, but it turns out I'm not good enough for the
            job. I couldn't make heads or tails of it. However,
            this might be a breeze for someone that knows TCC
            like the back of their hand.

            So, any takers?



      Ciao,
      Michael.

      _______________________________________________
      Tinycc-devel mailing list
      [hidden email]
      https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
-- [hidden email]
-- Développeur compulsif



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

Michael Matz-4
Hi,

On Mon, 6 Jan 2020, ian wrote:

> Did I miss something ?
> It seemed to me that it was dealing with application side of things.

Sure, Rasmus asked to have this extension in TCC to be able to use it for
writing libraries or apps; i.e. he asked if TCC could be extended to
compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
   v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
   c = a + b;
   bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the
fact that this extension isn't totally trivial if it shouldn't generate
very low quality code.  If it's okay to generate low quality code and
not adhere to the psABI for parameter passing of these types then it's not
too much work.

If you were asking if such extension is really a must have in a
compiler: no, otherwise it wouldn't be an extension.  It's a nice to have,
and I can see why Rasmus wants it, but it comes at a non-trivial cost to
support it in a small compiler.


Ciao,
Michael.

> Like, say, libraries. For the least, as long as compilers does not care
> about maths or physics....
>
> If I'm wrong, please, explain to me where...
>
> ian
>
> Le 06/01/2020 à 21:46, Michael Matz a écrit :
>       Hi,
>
>       On Mon, 6 Jan 2020, ian wrote:
>
>             Is the support for data structures and calculations
>             a real "need to" for a compiler ????
>
>
>       Um, I don't know how to answer this.  As it seems the
>       alternative to calculations is guessing, yes, I do think
>       calculations and data structures are indeed necessary for a
>       compiler, or any program whatsoever.
>
>
>       Ciao,
>       Michael.
>
>
>             regards,
>
>             ian
>
>             Le 06/01/2020 à 20:36, Michael Matz a écrit :
>                   Hello,
>
>                   On Mon, 6 Jan 2020, Rasmus Riiner via
>             Tinycc-devel wrote:
>
>                         See here:
>                        
>             https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>
>                         This is one of those things that doesn't
>             come up in
>                         a lot of types of programming, but is
>             indispensable
>                         in some, namely anything to do with 2D
>             or 3D math.
>                         The ability to just write `position +=
>             velocity *
>                         dt;` style statements might be one of
>             the most
>                         important reasons most game developers
>             choose C++
>                         over C. It's certainly the only thing
>             keeping me
>                         from using TCC in the development of my
>             own project.
>
>                         Actually emitting SSE instructions might
>             be beyond
>                         the scope of tcc (Tiny after all),
>             supporting the
>                         expressions though would be a huge help.
>
>
>                   Without proper support in the backends for
>             vector instructions
>                   the generated code for this extension from TCC
>             would be of
>                   abysmal quality. Technically it wouldn't be
>             too much work to
>                   semantically support that, but the values
>             would need to be
>                   committed to memory (instead of vector
>             registers) and regarded
>                   as constant sized arrays (at which point the
>             function call ABI
>                   would be different from the respective native
>             ABI, which, again,
>                   would be hard to fix without proper support
>             for vector insns in
>                   the backends).
>
>                   That extension really doesn't feel very well
>             suited for a simple
>                   compiler like TCC ;-)  But perhaps it can be
>             done
>                   non-intrusively enough.
>
>                         I sat down yesterday in an attempt to do
>             this
>                         myself, but it turns out I'm not good
>             enough for the
>                         job. I couldn't make heads or tails of
>             it. However,
>                         this might be a breeze for someone that
>             knows TCC
>                         like the back of their hand.
>
>                         So, any takers?
>
>
>
>                   Ciao,
>                   Michael.
>
>                  
>             _______________________________________________
>                   Tinycc-devel mailing list
>                   [hidden email]
>                  
>             https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>             --
>             -- [hidden email]
>             -- Développeur compulsif
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- [hidden email]
> -- Développeur compulsif
>
>
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian-2

Hi.

Ok, thanks for explanation (and btw sorry for yesterday, I was a lil bit tired), but then it makes me think that I'm not so wrong.
Defining an addition operation for vectors is defining a group for this operation and this data structure.
So it becomes something more like an object than a raw structure.
And the use of the standard "+" symbol makes me very suspicious about this.

So. Further then, why not defining a group for multiplication (and "*" symbol...) too ?
And, finally, what if s/o would just concatenate the structures (like `(append '(1 2 3 4) '(4 5 6 7))` for instance) ?

I'm really still not sure the compiler should be extended for this, because it makes a lot of assumptions about the purpose of the structure.

Have a nice day 😊

ian

Le 07/01/2020 à 01:33, Michael Matz a écrit :
Hi,

On Mon, 6 Jan 2020, ian wrote:

Did I miss something ?
It seemed to me that it was dealing with application side of things.

Sure, Rasmus asked to have this extension in TCC to be able to use it for writing libraries or apps; i.e. he asked if TCC could be extended to compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
  v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
  c = a + b;
  bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the fact that this extension isn't totally trivial if it shouldn't generate very low quality code.  If it's okay to generate low quality code and not adhere to the psABI for parameter passing of these types then it's not too much work.

If you were asking if such extension is really a must have in a compiler: no, otherwise it wouldn't be an extension.  It's a nice to have, and I can see why Rasmus wants it, but it comes at a non-trivial cost to support it in a small compiler.


Ciao,
Michael.

Like, say, libraries. For the least, as long as compilers does not care
about maths or physics....

If I'm wrong, please, explain to me where...

ian

Le 06/01/2020 à 21:46, Michael Matz a écrit :
      Hi,

      On Mon, 6 Jan 2020, ian wrote:

            Is the support for data structures and calculations
            a real "need to" for a compiler ????


      Um, I don't know how to answer this.  As it seems the
      alternative to calculations is guessing, yes, I do think
      calculations and data structures are indeed necessary for a
      compiler, or any program whatsoever.


      Ciao,
      Michael.


            regards,

            ian

            Le 06/01/2020 à 20:36, Michael Matz a écrit :
                  Hello,

                  On Mon, 6 Jan 2020, Rasmus Riiner via
            Tinycc-devel wrote:

                        See here:
                       
            https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

                        This is one of those things that doesn't
            come up in
                        a lot of types of programming, but is
            indispensable
                        in some, namely anything to do with 2D
            or 3D math.
                        The ability to just write `position +=
            velocity *
                        dt;` style statements might be one of
            the most
                        important reasons most game developers
            choose C++
                        over C. It's certainly the only thing
            keeping me
                        from using TCC in the development of my
            own project.

                        Actually emitting SSE instructions might
            be beyond
                        the scope of tcc (Tiny after all),
            supporting the
                        expressions though would be a huge help.


                  Without proper support in the backends for
            vector instructions
                  the generated code for this extension from TCC
            would be of
                  abysmal quality. Technically it wouldn't be
            too much work to
                  semantically support that, but the values
            would need to be
                  committed to memory (instead of vector
            registers) and regarded
                  as constant sized arrays (at which point the
            function call ABI
                  would be different from the respective native
            ABI, which, again,
                  would be hard to fix without proper support
            for vector insns in
                  the backends).

                  That extension really doesn't feel very well
            suited for a simple
                  compiler like TCC ;-)  But perhaps it can be
            done
                  non-intrusively enough.

                        I sat down yesterday in an attempt to do
            this
                        myself, but it turns out I'm not good
            enough for the
                        job. I couldn't make heads or tails of
            it. However,
                        this might be a breeze for someone that
            knows TCC
                        like the back of their hand.

                        So, any takers?



                  Ciao,
                  Michael.

                 
            _______________________________________________
                  Tinycc-devel mailing list
                  [hidden email]
                 
            https://lists.nongnu.org/mailman/listinfo/tinycc-devel

            --
            -- [hidden email]
            -- Développeur compulsif



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
-- [hidden email]
-- Développeur compulsif


--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

tinycc-devel mailing list
In reply to this post by Michael Matz-4
I would say that it is okay to generate low quality code, that it's better than nothing, as long the implementation doesn't impact the rest of the compiler too much... but of course that is from my biased point of view.

Which is that the only thing presently keeping TCC compile times out of my reach is that a bunch of code akin to this in C++:

    vec2 v4 = vel + a3 * dt;
    vec2 p4 = pos + v4 * dt;
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
    *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));


Would have to be rewritten to something like this for plain C:

    vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
    vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * (1.0 / 6.0));
    *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * (1.0 / 6.0));


Operator overloading doesn't fit C, and I'm glad it's not in there, but then the only way to fix this particular inefficiency is with some kind of built-in array math, perhaps as an extension... which is exactly what the GCC extension would provide. The extension goes a bit too far perhaps, what with supporting every basic type as a vector element, I can see why they did that though. For TCC, it might be sensible to limit the possible element types to 32bit floats or integers, and cap the possible vector length to 4...

I'm not sure what I would do in your position, implementing the extension (or a subset of it) might not be what's ultimately best for the project, but hopefully you can see where I'm coming from. Compile times for basic C++ programs take entire seconds with the available compilers, whereas I could literally tcc -run and be in-game, with immediate feedback, nearly instantly.
I could bite the bullet and start using function syntax for basic vector operations, I just wanted to confirm whether the GCC extension is outside the scope of TCC, or not, first. I don't actually use any C++ features over C, other than operator overloading and a little bit of function overloading (which I could do just fine without). It feels like so close, yet so far, you know?

Rasmus.

----- Reply to message -----
Sure, Rasmus asked to have this extension in TCC to be able to use it for
writing libraries or apps; i.e. he asked if TCC could be extended to
compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
c = a + b;
bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the
fact that this extension isn't totally trivial if it shouldn't generate
very low quality code. If it's okay to generate low quality code and
not adhere to the psABI for parameter passing of these types then it's not
too much work.

If you were asking if such extension is really a must have in a
compiler: no, otherwise it wouldn't be an extension. It's a nice to have,
and I can see why Rasmus wants it, but it comes at a non-trivial cost to
support it in a small compiler.


Ciao,
Michael.
 
 

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian

Hi.

I stay at my position, and keep saying it has nothing to deal with a compiler !
It deals with assumptions concerning the main aim of data structures.
It seems that you know how to code it, so if tcc can compile this it's fine and enough.
But, FOR SURE, it does not have to translate an index-by-index array elements sum !!!


Regards, ian.


Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :
I would say that it is okay to generate low quality code, that it's better than nothing, as long the implementation doesn't impact the rest of the compiler too much... but of course that is from my biased point of view.

Which is that the only thing presently keeping TCC compile times out of my reach is that a bunch of code akin to this in C++:

    vec2 v4 = vel + a3 * dt;
    vec2 p4 = pos + v4 * dt;
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
    *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));


Would have to be rewritten to something like this for plain C:

    vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
    vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * (1.0 / 6.0));
    *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * (1.0 / 6.0));


Operator overloading doesn't fit C, and I'm glad it's not in there, but then the only way to fix this particular inefficiency is with some kind of built-in array math, perhaps as an extension... which is exactly what the GCC extension would provide. The extension goes a bit too far perhaps, what with supporting every basic type as a vector element, I can see why they did that though. For TCC, it might be sensible to limit the possible element types to 32bit floats or integers, and cap the possible vector length to 4...

I'm not sure what I would do in your position, implementing the extension (or a subset of it) might not be what's ultimately best for the project, but hopefully you can see where I'm coming from. Compile times for basic C++ programs take entire seconds with the available compilers, whereas I could literally tcc -run and be in-game, with immediate feedback, nearly instantly.
I could bite the bullet and start using function syntax for basic vector operations, I just wanted to confirm whether the GCC extension is outside the scope of TCC, or not, first. I don't actually use any C++ features over C, other than operator overloading and a little bit of function overloading (which I could do just fine without). It feels like so close, yet so far, you know?

Rasmus.

----- Reply to message -----
Sure, Rasmus asked to have this extension in TCC to be able to use it for
writing libraries or apps; i.e. he asked if TCC could be extended to
compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
c = a + b;
bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the
fact that this extension isn't totally trivial if it shouldn't generate
very low quality code. If it's okay to generate low quality code and
not adhere to the psABI for parameter passing of these types then it's not
too much work.

If you were asking if such extension is really a must have in a
compiler: no, otherwise it wouldn't be an extension. It's a nice to have,
and I can see why Rasmus wants it, but it comes at a non-trivial cost to
support it in a small compiler.


Ciao,
Michael.
 
 

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

uso ewin
On Thu, Jan 9, 2020 at 3:55 PM ian <[hidden email]> wrote:

>
> Hi.
>
> I stay at my position, and keep saying it has nothing to deal with a compiler !
> It deals with assumptions concerning the main aim of data structures.
> It seems that you know how to code it, so if tcc can compile this it's fine and enough.
> But, FOR SURE, it does not have to translate an index-by-index array elements sum !!!
>
>
> Regards, ian.
>

I have a different point of view:

I saw that kind of extension as somewhat similar to what float/double are in C:
Machine don't have a float data type, they have registry, memory and
instructions,
that allow to do floating point arithmetic on registry.

Float support are more or less compiler that does assumption
concerning the aim of some data.
That's why they add a type in C I guess.

And as vector extension, you could code float operation in C, but it
would be hard to tell the
compiler to use the float specific instructions.

I see this extension as similar: it add a type that do some assumption
of some data and
allow to use some instruction on them.

The main difference is that only a few processor support instruction on matrix.
(But I guess that if intel had some kind of vector operation when C
was created this would be part of the standard)

I don't think it's a must have (far from it), nor I think tcc should
support vector extension,
but if the support is done in a non intrusive way, I don't see why not.

Matthias,

>
> Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :
>
> I would say that it is okay to generate low quality code, that it's better than nothing, as long the implementation doesn't impact the rest of the compiler too much... but of course that is from my biased point of view.
>
> Which is that the only thing presently keeping TCC compile times out of my reach is that a bunch of code akin to this in C++:
>
>     vec2 v4 = vel + a3 * dt;
>     vec2 p4 = pos + v4 * dt;
>     vec2 a4 = entity_acceleration(p4, v4, entity);
>
>     *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
>     *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));
>
> Would have to be rewritten to something like this for plain C:
>
>     vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
>     vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
>     vec2 a4 = entity_acceleration(p4, v4, entity);
>
>     *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * (1.0 / 6.0));
>     *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * (1.0 / 6.0));
>
> Operator overloading doesn't fit C, and I'm glad it's not in there, but then the only way to fix this particular inefficiency is with some kind of built-in array math, perhaps as an extension... which is exactly what the GCC extension would provide. The extension goes a bit too far perhaps, what with supporting every basic type as a vector element, I can see why they did that though. For TCC, it might be sensible to limit the possible element types to 32bit floats or integers, and cap the possible vector length to 4...
>
> I'm not sure what I would do in your position, implementing the extension (or a subset of it) might not be what's ultimately best for the project, but hopefully you can see where I'm coming from. Compile times for basic C++ programs take entire seconds with the available compilers, whereas I could literally tcc -run and be in-game, with immediate feedback, nearly instantly.
> I could bite the bullet and start using function syntax for basic vector operations, I just wanted to confirm whether the GCC extension is outside the scope of TCC, or not, first. I don't actually use any C++ features over C, other than operator overloading and a little bit of function overloading (which I could do just fine without). It feels like so close, yet so far, you know?
>
> Rasmus.
>
> ----- Reply to message -----
>
> Sure, Rasmus asked to have this extension in TCC to be able to use it for
> writing libraries or apps; i.e. he asked if TCC could be extended to
> compile code like this:
>
> ---------------------
> typedef int v4si __attribute__ ((vector_size (16)));
> void foo (void) {
> v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
> c = a + b;
> bar(c[0], c[1], c[2], c[3]);
> }
> ---------------------
>
> For that TCC would need to be extended somewhat, and I was alluding to the
> fact that this extension isn't totally trivial if it shouldn't generate
> very low quality code. If it's okay to generate low quality code and
> not adhere to the psABI for parameter passing of these types then it's not
> too much work.
>
> If you were asking if such extension is really a must have in a
> compiler: no, otherwise it wouldn't be an extension. It's a nice to have,
> and I can see why Rasmus wants it, but it comes at a non-trivial cost to
> support it in a small compiler.
>
>
> Ciao,
> Michael.
>
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- [hidden email]
> -- Développeur compulsif
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian

Hi back Matt,

My main point is so far "why not implement then a * operator dedicated to vectors" ????
Believe me, from what I did in languages programmation, overwiting such a standard operaor is ALWAYS a very bad idea......

Regards

Le 09/01/2020 à 16:50, uso ewin a écrit :
On Thu, Jan 9, 2020 at 3:55 PM ian [hidden email] wrote:
Hi.

I stay at my position, and keep saying it has nothing to deal with a compiler !
It deals with assumptions concerning the main aim of data structures.
It seems that you know how to code it, so if tcc can compile this it's fine and enough.
But, FOR SURE, it does not have to translate an index-by-index array elements sum !!!


Regards, ian.

I have a different point of view:

I saw that kind of extension as somewhat similar to what float/double are in C:
Machine don't have a float data type, they have registry, memory and
instructions,
that allow to do floating point arithmetic on registry.

Float support are more or less compiler that does assumption
concerning the aim of some data.
That's why they add a type in C I guess.

And as vector extension, you could code float operation in C, but it
would be hard to tell the
compiler to use the float specific instructions.

I see this extension as similar: it add a type that do some assumption
of some data and
allow to use some instruction on them.

The main difference is that only a few processor support instruction on matrix.
(But I guess that if intel had some kind of vector operation when C
was created this would be part of the standard)

I don't think it's a must have (far from it), nor I think tcc should
support vector extension,
but if the support is done in a non intrusive way, I don't see why not.

Matthias,

Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :

I would say that it is okay to generate low quality code, that it's better than nothing, as long the implementation doesn't impact the rest of the compiler too much... but of course that is from my biased point of view.

Which is that the only thing presently keeping TCC compile times out of my reach is that a bunch of code akin to this in C++:

    vec2 v4 = vel + a3 * dt;
    vec2 p4 = pos + v4 * dt;
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
    *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));

Would have to be rewritten to something like this for plain C:

    vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
    vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * (1.0 / 6.0));
    *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * (1.0 / 6.0));

Operator overloading doesn't fit C, and I'm glad it's not in there, but then the only way to fix this particular inefficiency is with some kind of built-in array math, perhaps as an extension... which is exactly what the GCC extension would provide. The extension goes a bit too far perhaps, what with supporting every basic type as a vector element, I can see why they did that though. For TCC, it might be sensible to limit the possible element types to 32bit floats or integers, and cap the possible vector length to 4...

I'm not sure what I would do in your position, implementing the extension (or a subset of it) might not be what's ultimately best for the project, but hopefully you can see where I'm coming from. Compile times for basic C++ programs take entire seconds with the available compilers, whereas I could literally tcc -run and be in-game, with immediate feedback, nearly instantly.
I could bite the bullet and start using function syntax for basic vector operations, I just wanted to confirm whether the GCC extension is outside the scope of TCC, or not, first. I don't actually use any C++ features over C, other than operator overloading and a little bit of function overloading (which I could do just fine without). It feels like so close, yet so far, you know?

Rasmus.

----- Reply to message -----

Sure, Rasmus asked to have this extension in TCC to be able to use it for
writing libraries or apps; i.e. he asked if TCC could be extended to
compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
c = a + b;
bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the
fact that this extension isn't totally trivial if it shouldn't generate
very low quality code. If it's okay to generate low quality code and
not adhere to the psABI for parameter passing of these types then it's not
too much work.

If you were asking if such extension is really a must have in a
compiler: no, otherwise it wouldn't be an extension. It's a nice to have,
and I can see why Rasmus wants it, but it comes at a non-trivial cost to
support it in a small compiler.


Ciao,
Michael.




_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
-- [hidden email]
-- Développeur compulsif
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

Ivo van Poorten
On Thu, 9 Jan 2020 17:19:10 +0100 ian <[hidden email]> wrote:
> My main point is so far "why not implement then a * operator dedicated
> to vectors" ????
> Believe me, from what I did in languages programmation, overwiting
> such a standard operaor is ALWAYS a very bad idea......

I fully agree. Who am I? I just lurk on this mailinglist, but operator
overloading is something I hope stays out of C forever. If you have
ever had to wade through a multitude of header files to figure out what
an operator does on a certain object, I think you'll know what I mean.
So never add it to C. It's a slippery slope.

Regards,
Ivo

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: Request: __attribute__((vector_size))

ian
In reply to this post by uso ewin

Hi again, and after re-reading.... (and I admit, a few hours sleeping 😉)

I do get the point, when you compare it to the floats. But I see a major difference :
a float is a scalar value, not a data structure (in that case, even if as you wrote that the float is one too, it's still a scalar).
To do the things the right way, the compiler then should define a new data-type (say vec or so), and new general standard operations upon it.
And we get back to my first point : it wouldn't be C anymore, but something more like C++.

The compiler does not have to deal with user defined data-structures, and must not overload operators. Here are the assumptions. You can easily understand that + is well defined for floating numbers, as for integer (even big nums, which is from a library, not a standard type), but for algebraic data types it makes assumptions.
Again, what if I just want to concatenate the datas ? Not do a vectorial addition, but use it like arrays or lists ?

Regards,


ian

Le 09/01/2020 à 16:50, uso ewin a écrit :
On Thu, Jan 9, 2020 at 3:55 PM ian [hidden email] wrote:
Hi.

I stay at my position, and keep saying it has nothing to deal with a compiler !
It deals with assumptions concerning the main aim of data structures.
It seems that you know how to code it, so if tcc can compile this it's fine and enough.
But, FOR SURE, it does not have to translate an index-by-index array elements sum !!!


Regards, ian.

I have a different point of view:

I saw that kind of extension as somewhat similar to what float/double are in C:
Machine don't have a float data type, they have registry, memory and
instructions,
that allow to do floating point arithmetic on registry.

Float support are more or less compiler that does assumption
concerning the aim of some data.
That's why they add a type in C I guess.

And as vector extension, you could code float operation in C, but it
would be hard to tell the
compiler to use the float specific instructions.

I see this extension as similar: it add a type that do some assumption
of some data and
allow to use some instruction on them.

The main difference is that only a few processor support instruction on matrix.
(But I guess that if intel had some kind of vector operation when C
was created this would be part of the standard)

I don't think it's a must have (far from it), nor I think tcc should
support vector extension,
but if the support is done in a non intrusive way, I don't see why not.

Matthias,

Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :

I would say that it is okay to generate low quality code, that it's better than nothing, as long the implementation doesn't impact the rest of the compiler too much... but of course that is from my biased point of view.

Which is that the only thing presently keeping TCC compile times out of my reach is that a bunch of code akin to this in C++:

    vec2 v4 = vel + a3 * dt;
    vec2 p4 = pos + v4 * dt;
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
    *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));

Would have to be rewritten to something like this for plain C:

    vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
    vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
    vec2 a4 = entity_acceleration(p4, v4, entity);

    *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * (1.0 / 6.0));
    *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * (1.0 / 6.0));

Operator overloading doesn't fit C, and I'm glad it's not in there, but then the only way to fix this particular inefficiency is with some kind of built-in array math, perhaps as an extension... which is exactly what the GCC extension would provide. The extension goes a bit too far perhaps, what with supporting every basic type as a vector element, I can see why they did that though. For TCC, it might be sensible to limit the possible element types to 32bit floats or integers, and cap the possible vector length to 4...

I'm not sure what I would do in your position, implementing the extension (or a subset of it) might not be what's ultimately best for the project, but hopefully you can see where I'm coming from. Compile times for basic C++ programs take entire seconds with the available compilers, whereas I could literally tcc -run and be in-game, with immediate feedback, nearly instantly.
I could bite the bullet and start using function syntax for basic vector operations, I just wanted to confirm whether the GCC extension is outside the scope of TCC, or not, first. I don't actually use any C++ features over C, other than operator overloading and a little bit of function overloading (which I could do just fine without). It feels like so close, yet so far, you know?

Rasmus.

----- Reply to message -----

Sure, Rasmus asked to have this extension in TCC to be able to use it for
writing libraries or apps; i.e. he asked if TCC could be extended to
compile code like this:

---------------------
typedef int v4si __attribute__ ((vector_size (16)));
void foo (void) {
v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
c = a + b;
bar(c[0], c[1], c[2], c[3]);
}
---------------------

For that TCC would need to be extended somewhat, and I was alluding to the
fact that this extension isn't totally trivial if it shouldn't generate
very low quality code. If it's okay to generate low quality code and
not adhere to the psABI for parameter passing of these types then it's not
too much work.

If you were asking if such extension is really a must have in a
compiler: no, otherwise it wouldn't be an extension. It's a nice to have,
and I can see why Rasmus wants it, but it comes at a non-trivial cost to
support it in a small compiler.


Ciao,
Michael.




_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
-- [hidden email]
-- Développeur compulsif
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- [hidden email]
-- Développeur compulsif

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel