Re: [Tinycc-devel] C11 __STD_NO_THREADS__ and __STD_NO_ATOMICS__ are not defined
Hi, C11 defines thoses macros (section 6.10.8.3) with __STDC_ prefix (not __STD_) and they exist with tcc when you pass –std=c11 flag. They are undefined with default flags. See libtcc.c(1842) C. From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of UnknownGamer40464 . Sent: Friday, January 10, 2020 05:44 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] C11 __STD_NO_THREADS__ and __STD_NO_ATOMICS__ are not defined These macros do not appear to be defined by the compiler, resulting in code that selects for custom implementations instead using the nonexistent standard versions anyways, despite the compiler not supporting either one. Without these definitions, I can't have TCC select for a custom implementation of the C11 threading or atomics API. Would it be possible to have the compiler define them? Also thanks for all your work so far keeping TCC alive. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] C11 __STD_NO_THREADS__ and __STD_NO_ATOMICS__ are not defined
These macros do not appear to be defined by the compiler, resulting in code that selects for custom implementations instead using the nonexistent standard versions anyways, despite the compiler not supporting either one. Without these definitions, I can't have TCC select for a custom implementation of the C11 threading or atomics API. Would it be possible to have the compiler define them? Also thanks for all your work so far keeping TCC alive. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request: __attribute__((vector_size))
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 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
Re: [Tinycc-devel] Request: __attribute__((vector_size))
On Thu, 9 Jan 2020 17:19:10 +0100 ian 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 Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request: __attribute__((vector_size))
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 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
Re: [Tinycc-devel] Request: __attribute__((vector_size))
On Thu, Jan 9, 2020 at 3:55 PM ian 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
> T
Re: [Tinycc-devel] Request: __attribute__((vector_size))
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
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
--
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Request: __attribute__((vector_size))
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
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
