[C++11] Reclaiming fixed-point suffixes for user-defined literals.

[C++11] Reclaiming fixed-point suffixes for user-defined literals.

[3dw4rd]

Greetings,

Now that C++11 user-defined literals are in trunk I was thinking about reclaiming some of the numeric suffixes that are currently recognized by gcc in the preprocessor.  The C++11 spec stipulates that any suffix that is recognized by the implementation is not allowable as a user-defined literal suffix in c++.  This prevents C++ from hijacking 123LL, 1.234L, etc.  On the other hand, there are several numeric literal suffixes that are recognized and used as gnu extensions.

One class of suffixes stands out in this connection: fixed-point literals.  These end in 'k' or 'r' and can optionally be unsigned by starting with 'u' and optionally have a size 'h', 'l', 'll'.  The difference for these suffixes is that fixed-point literals are explicitly rejected by the c++ front end.  Attempts to use such literals:
int i= 1.23k;
results in 'error: fixed-point types not supported in C++'.

So I ask the question:  Should I make a simple change to libcpp to allow fixed-point literal suffixes to pass to the user-defined literal code in c++11 mode?

Thanks,

Ed Smith-Rowland

P.S. There are other suffixes that might be reclaimed as well such as 'i', 'I', 'j', 'J' for complex integral or floating point imaginary numbers and others.  These might be more difficult or impossible to reclaim for C++11 because these might be allowed and used in gnu-C++ and it might break existing code.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 04/11/11 20:35, 3dw4rd@verizon.net wrote:
> Greetings,
>
> Now that C++11 user-defined literals are in trunk I was thinking
> about reclaiming some of the numeric suffixes that are currently
> recognized by gcc in the preprocessor.  The C++11 spec stipulates
> that any suffix that is recognized by the implementation is not
> allowable as a user-defined literal suffix in c++.  This prevents C++
> from hijacking 123LL, 1.234L, etc.  On the other hand, there are
> several numeric literal suffixes that are recognized and used as gnu
> extensions.
>
> One class of suffixes stands out in this connection: fixed-point
> literals.  These end in 'k' or 'r' and can optionally be unsigned by
> starting with 'u' and optionally have a size 'h', 'l', 'll'.  The
> difference for these suffixes is that fixed-point literals are
> explicitly rejected by the c++ front end.  Attempts to use such
> literals: int i= 1.23k; results in 'error: fixed-point types not
> supported in C++'.
>
> So I ask the question:  Should I make a simple change to libcpp to
> allow fixed-point literal suffixes to pass to the user-defined
> literal code in c++11 mode?
>
> Thanks,
>
> Ed Smith-Rowland
>
> P.S. There are other suffixes that might be reclaimed as well such as
> 'i', 'I', 'j', 'J' for complex integral or floating point imaginary
> numbers and others.  These might be more difficult or impossible to
> reclaim for C++11 because these might be allowed and used in gnu-C++
> and it might break existing code.
>

gcc has a tradition of allowing C-compatible features from C++ to be 
supported in C, and useful features from C to be supported in C++. 
Typically these being life as gcc extensions, but they sometimes move 
into the standards (an easy example being gcc's support for C++ comments 
in C from long before C99 came out).  An example is gcc's support for 
C99-style "_Complex" floating point types in C++.

Is there a good reason why the fixed point types (and decimal types, and 
extended float types) are not supported in C++ as a gcc extension?  It 
strikes me that from the users' viewpoint it would be best for these 
features to be available in C++ as well.  If the actual implementation 
of this would be difficult (I have no idea of the effort involved here), 
then the next best thing is to reserve the suffixes to avoid breaking 
things in the future, and to avoid user confusion.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Ed Smith-Rowland]

On 11/05/2011 08:36 AM, David Brown wrote:
> On 04/11/11 20:35, 3dw4rd@verizon.net wrote:
>> Greetings,
>>
>> Now that C++11 user-defined literals are in trunk I was thinking
>> about reclaiming some of the numeric suffixes that are currently
>> recognized by gcc in the preprocessor.  The C++11 spec stipulates
>> that any suffix that is recognized by the implementation is not
>> allowable as a user-defined literal suffix in c++.  This prevents C++
>> from hijacking 123LL, 1.234L, etc.  On the other hand, there are
>> several numeric literal suffixes that are recognized and used as gnu
>> extensions.
>>
>> One class of suffixes stands out in this connection: fixed-point
>> literals.  These end in 'k' or 'r' and can optionally be unsigned by
>> starting with 'u' and optionally have a size 'h', 'l', 'll'.  The
>> difference for these suffixes is that fixed-point literals are
>> explicitly rejected by the c++ front end.  Attempts to use such
>> literals: int i= 1.23k; results in 'error: fixed-point types not
>> supported in C++'.
>>
>> So I ask the question:  Should I make a simple change to libcpp to
>> allow fixed-point literal suffixes to pass to the user-defined
>> literal code in c++11 mode?
>>
>> Thanks,
>>
>> Ed Smith-Rowland
>>
>> P.S. There are other suffixes that might be reclaimed as well such as
>> 'i', 'I', 'j', 'J' for complex integral or floating point imaginary
>> numbers and others.  These might be more difficult or impossible to
>> reclaim for C++11 because these might be allowed and used in gnu-C++
>> and it might break existing code.
>>
>
> gcc has a tradition of allowing C-compatible features from C++ to be 
> supported in C, and useful features from C to be supported in C++. 
> Typically these being life as gcc extensions, but they sometimes move 
> into the standards (an easy example being gcc's support for C++ 
> comments in C from long before C99 came out).  An example is gcc's 
> support for C99-style "_Complex" floating point types in C++.
>
> Is there a good reason why the fixed point types (and decimal types, 
> and extended float types) are not supported in C++ as a gcc 
> extension?  It strikes me that from the users' viewpoint it would be 
> best for these features to be available in C++ as well.  If the actual 
> implementation of this would be difficult (I have no idea of the 
> effort involved here), then the next best thing is to reserve the 
> suffixes to avoid breaking things in the future, and to avoid user 
> confusion.
>
>
>
I think that fixed-point numbers would be an excellent addition to C++.  
The question is how to do it and what the semantics are.

On one hand we could probably let the C fixed-point types and keywords 
and literals work in C++. IIRC C fixed-point extensions are rather 
limited in terms of what sizes and precisions are allowed.

On the other hand, if we let C++ user-defined literals handle the 
literals then this opens the door to a pure library solution that would 
allow arbitrary size and precision and base for example.  I tend to 
think the C++ committee would be more in favor of this because they tend 
to push library changes over language enhancements for flexibility.  
This would likely be a template library of some kind.

Maybe there's a way to support both.  IIRC the template specializations 
for complex use the corresponding _Complex types under the hood.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 05/11/11 18:29, Ed Smith-Rowland wrote:
> On 11/05/2011 08:36 AM, David Brown wrote:
>> On 04/11/11 20:35, 3dw4rd@verizon.net wrote:
>>> Greetings,
>>>
>>> Now that C++11 user-defined literals are in trunk I was thinking
>>> about reclaiming some of the numeric suffixes that are currently
>>> recognized by gcc in the preprocessor. The C++11 spec stipulates
>>> that any suffix that is recognized by the implementation is not
>>> allowable as a user-defined literal suffix in c++. This prevents C++
>>> from hijacking 123LL, 1.234L, etc. On the other hand, there are
>>> several numeric literal suffixes that are recognized and used as gnu
>>> extensions.
>>>
>>> One class of suffixes stands out in this connection: fixed-point
>>> literals. These end in 'k' or 'r' and can optionally be unsigned by
>>> starting with 'u' and optionally have a size 'h', 'l', 'll'. The
>>> difference for these suffixes is that fixed-point literals are
>>> explicitly rejected by the c++ front end. Attempts to use such
>>> literals: int i= 1.23k; results in 'error: fixed-point types not
>>> supported in C++'.
>>>
>>> So I ask the question: Should I make a simple change to libcpp to
>>> allow fixed-point literal suffixes to pass to the user-defined
>>> literal code in c++11 mode?
>>>
>>> Thanks,
>>>
>>> Ed Smith-Rowland
>>>
>>> P.S. There are other suffixes that might be reclaimed as well such as
>>> 'i', 'I', 'j', 'J' for complex integral or floating point imaginary
>>> numbers and others. These might be more difficult or impossible to
>>> reclaim for C++11 because these might be allowed and used in gnu-C++
>>> and it might break existing code.
>>>
>>
>> gcc has a tradition of allowing C-compatible features from C++ to be
>> supported in C, and useful features from C to be supported in C++.
>> Typically these being life as gcc extensions, but they sometimes move
>> into the standards (an easy example being gcc's support for C++
>> comments in C from long before C99 came out). An example is gcc's
>> support for C99-style "_Complex" floating point types in C++.
>>
>> Is there a good reason why the fixed point types (and decimal types,
>> and extended float types) are not supported in C++ as a gcc extension?
>> It strikes me that from the users' viewpoint it would be best for
>> these features to be available in C++ as well. If the actual
>> implementation of this would be difficult (I have no idea of the
>> effort involved here), then the next best thing is to reserve the
>> suffixes to avoid breaking things in the future, and to avoid user
>> confusion.
>>
>>
>>
> I think that fixed-point numbers would be an excellent addition to C++.
> The question is how to do it and what the semantics are.
>
> On one hand we could probably let the C fixed-point types and keywords
> and literals work in C++. IIRC C fixed-point extensions are rather
> limited in terms of what sizes and precisions are allowed.
>
> On the other hand, if we let C++ user-defined literals handle the
> literals then this opens the door to a pure library solution that would
> allow arbitrary size and precision and base for example. I tend to think
> the C++ committee would be more in favor of this because they tend to
> push library changes over language enhancements for flexibility. This
> would likely be a template library of some kind.
>
> Maybe there's a way to support both. IIRC the template specializations
> for complex use the corresponding _Complex types under the hood.
>

You are right that the standard C fixed-point types are limited, whereas 
a good C++ template based solution would be more flexible.  But the aim 
of the C types is that - where possible - they should be implemented 
using hardware processor support.  Many embedded processors, especially 
ones geared towards DSP, have direct support for scaled integer 
arithmetic.  The aim of N1169 is to provide standard C types that match 
the commonly used formats, to make fixed point code easier to write and 
more portable.

A C++ template class for "_Fract" support would be straightforward to 
write, and could easily support the formats in N1169.  But it would be 
very hard to do so in a way that generates small and fast code without 
resorting to inline assembly for targets that have hardware support for 
such features.

As you say, it is possible that both could be supported - using a 
template class to provide a generic solution, and using the C "_Fract" 
types for specialized classes.  The first step to that, however, is to 
allow the standard C "_Fract" types to work in C++ as a gcc extension.

The same principle applies to the decimal types and extended float types 
supported by C.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 05/11/11 18:29, Ed Smith-Rowland wrote:
> On 11/05/2011 08:36 AM, David Brown wrote:
>> On 04/11/11 20:35, 3dw4rd@verizon.net wrote:
>>> Greetings,
>>>
>>> Now that C++11 user-defined literals are in trunk I was thinking
>>> about reclaiming some of the numeric suffixes that are currently
>>> recognized by gcc in the preprocessor. The C++11 spec stipulates
>>> that any suffix that is recognized by the implementation is not
>>> allowable as a user-defined literal suffix in c++. This prevents C++
>>> from hijacking 123LL, 1.234L, etc. On the other hand, there are
>>> several numeric literal suffixes that are recognized and used as gnu
>>> extensions.
>>>
>>> One class of suffixes stands out in this connection: fixed-point
>>> literals. These end in 'k' or 'r' and can optionally be unsigned by
>>> starting with 'u' and optionally have a size 'h', 'l', 'll'. The
>>> difference for these suffixes is that fixed-point literals are
>>> explicitly rejected by the c++ front end. Attempts to use such
>>> literals: int i= 1.23k; results in 'error: fixed-point types not
>>> supported in C++'.
>>>
>>> So I ask the question: Should I make a simple change to libcpp to
>>> allow fixed-point literal suffixes to pass to the user-defined
>>> literal code in c++11 mode?
>>>
>>> Thanks,
>>>
>>> Ed Smith-Rowland
>>>
>>> P.S. There are other suffixes that might be reclaimed as well such as
>>> 'i', 'I', 'j', 'J' for complex integral or floating point imaginary
>>> numbers and others. These might be more difficult or impossible to
>>> reclaim for C++11 because these might be allowed and used in gnu-C++
>>> and it might break existing code.
>>>
>>
>> gcc has a tradition of allowing C-compatible features from C++ to be
>> supported in C, and useful features from C to be supported in C++.
>> Typically these being life as gcc extensions, but they sometimes move
>> into the standards (an easy example being gcc's support for C++
>> comments in C from long before C99 came out). An example is gcc's
>> support for C99-style "_Complex" floating point types in C++.
>>
>> Is there a good reason why the fixed point types (and decimal types,
>> and extended float types) are not supported in C++ as a gcc extension?
>> It strikes me that from the users' viewpoint it would be best for
>> these features to be available in C++ as well. If the actual
>> implementation of this would be difficult (I have no idea of the
>> effort involved here), then the next best thing is to reserve the
>> suffixes to avoid breaking things in the future, and to avoid user
>> confusion.
>>
>>
>>
> I think that fixed-point numbers would be an excellent addition to C++.
> The question is how to do it and what the semantics are.
>
> On one hand we could probably let the C fixed-point types and keywords
> and literals work in C++. IIRC C fixed-point extensions are rather
> limited in terms of what sizes and precisions are allowed.
>
> On the other hand, if we let C++ user-defined literals handle the
> literals then this opens the door to a pure library solution that would
> allow arbitrary size and precision and base for example. I tend to think
> the C++ committee would be more in favor of this because they tend to
> push library changes over language enhancements for flexibility. This
> would likely be a template library of some kind.
>
> Maybe there's a way to support both. IIRC the template specializations
> for complex use the corresponding _Complex types under the hood.
>

You are right that the standard C fixed-point types are limited, whereas 
a good C++ template based solution would be more flexible.  But the aim 
of the C types is that - where possible - they should be implemented 
using hardware processor support.  Many embedded processors, especially 
ones geared towards DSP, have direct support for scaled integer 
arithmetic.  The aim of N1169 is to provide standard C types that match 
the commonly used formats, to make fixed point code easier to write and 
more portable.

A C++ template class for "_Fract" support would be straightforward to 
write, and could easily support the formats in N1169.  But it would be 
very hard to do so in a way that generates small and fast code without 
resorting to inline assembly for targets that have hardware support for 
such features.

As you say, it is possible that both could be supported - using a 
template class to provide a generic solution, and using the C "_Fract" 
types for specialized classes.  The first step to that, however, is to 
allow the standard C "_Fract" types to work in C++ as a gcc extension.

The same principle applies to the decimal types and extended float types 
supported by C.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Gabriel Dos Reis]

On Sat, Nov 5, 2011 at 2:30 PM, David Brown
> A C++ template class for "_Fract" support would be straightforward to write,
> and could easily support the formats in N1169.  But it would be very hard to
> do so in a way that generates small and fast code without resorting to
> inline assembly for targets that have hardware support for such features.

is this some sort of "here an outlanding statement and you would
have to prove a negative to prove me right" or do you have more
factual evidence to back your statement?

> As you say, it is possible that both could be supported - using a template
> class to provide a generic solution, and using the C "_Fract" types for
> specialized classes.  The first step to that, however, is to allow the
> standard C "_Fract" types to work in C++ as a gcc extension.
>
> The same principle applies to the decimal types and extended float types
> supported by C.

that is one possibility.  However there is a difference between
restricted "extension" and full fledged extensions.  I can see
how a restricted version would work in C++ as an extension, but
I doubt that is what you want.  I can also see how unrestricted
extension (which you seemed to advocate) brings more headache
where a library solution is seamless.

Keeping adding builtin type specifiers to a language is not a
sustainable and responsible way to grow a large language
for the real world.  I appreciate we may disagree on that point.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 05/11/11 21:43, Gabriel Dos Reis wrote:
> On Sat, Nov 5, 2011 at 2:30 PM, David Brown
>> A C++ template class for "_Fract" support would be straightforward to write,
>> and could easily support the formats in N1169.  But it would be very hard to
>> do so in a way that generates small and fast code without resorting to
>> inline assembly for targets that have hardware support for such features.
>
> is this some sort of "here an outlanding statement and you would
> have to prove a negative to prove me right" or do you have more
> factual evidence to back your statement?
>

It is an estimation.

Some processors have particular instructions or mode flag settings that 
let them handle fixed point data very efficiently, such as by doing 
multiplication and shift at the same time, handling saturated 
arithmetic, or using special "accumulator" registers for particular 
features.

It is certainly /conceivable/ that gcc will generate such instructions 
automatically, but I would be very surprised - and extremely impressed.

Take an example using a processor I know well, the AVR (it is an 8-bit 
device, which is a little unusual for gcc).  It has an instruction will 
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed 
16-bit integer - basically combining an 8-bit x 8-bit to 16-bit multiply 
with a left shift.  So to do a "signed short _Fract" multiply, you have 
a single instruction and discard the least significant byte.

Simulating the same operation in generic C would be something like :

int8_t multShortFract(int8_t a, int8_t b) {
	int16_t c = (int16_t) a * b;
	return (c >> 7);
}


Now, I have enormous respect for the gcc (and related libraries and 
tools) developers, and I am regularly surprised by how smart the 
compiler is.  But using such features of the target requires specific code.

The advantage of using C's "signed short _Fract" here is that gcc /will/ 
use the optimal instruction in such cases (assuming, of course, that 
support is added for the target in question).  If it doesn't have such 
support, it can do the calculation using something similar to the C 
above - slower but correct.


>> As you say, it is possible that both could be supported - using a template
>> class to provide a generic solution, and using the C "_Fract" types for
>> specialized classes.  The first step to that, however, is to allow the
>> standard C "_Fract" types to work in C++ as a gcc extension.
>>
>> The same principle applies to the decimal types and extended float types
>> supported by C.
>
> that is one possibility.  However there is a difference between
> restricted "extension" and full fledged extensions.  I can see
> how a restricted version would work in C++ as an extension, but
> I doubt that is what you want.  I can also see how unrestricted
> extension (which you seemed to advocate) brings more headache
> where a library solution is seamless.
>

I am not sure what you mean by a "restricted extension" and a "full 
fledged extension".  But I do appreciate that extensions cause issues 
that libraries do not.

> Keeping adding builtin type specifiers to a language is not a
> sustainable and responsible way to grow a large language
> for the real world.  I appreciate we may disagree on that point.
>

It is always difficult for people to see all aspects of something like 
this - and it is important to do so when figuring out what to implement. 
  That's what discussions like this are for!

Let me try to put forward the viewpoint of the embedded programmer, 
since these are the people who would use such features.  I fully 
appreciate that other people see things differently, and that there are 
often good reasons for doing something that seems wrong from my 
viewpoint.  And I also fully appreciate there is a very big difference 
between agreeing that something is the best solution, and actual 
implementation.


In embedded systems, C is often used for smaller systems, with bigger 
systems using C++.  There are also people who use C for big systems, and 
those that use C++ for small systems.  And lots of code is a mixture.

The key issue is that it is, quite frankly, a pain in the a** that C++ 
is not closer to a superset of C.  Originally, C++ was a superset - 
excluding a few points that can easily be avoided in well-written code. 
  These days, the two language standards have moved gradually further 
away from each other.  Obviously C++ is going to get features that C 
does not - that's fair enough.  But it is seldom that there is a good 
reason for C++ not supporting the additions to C standards.

Some of the differences are just mind-boggling - C1x has got a 
"_Static_assert" addition, while C++11 has "static_assert".  They do the 
same thing, but have a different keyword.  Don't these people /talk/ to 
each other?  Do they make differences like this deliberately to annoy 
people - both users and toolwriters?

gcc has always countered that to some extend, by allowing additional C 
features to be used in C++.  But even there there are limitations - 
there are plenty of gcc extensions to C that are very useful, and for 
some reason only work in C and not C++.

As a programmer, when I write portable code in C I want it to be valid 
C++ as well.  This gives the most flexibility, and the most efficient 
use of my code.  I don't want to have to re-write code to do the same 
thing in each language, or to re-learn the differences.

So to make "_Fract" and "_Accum" really useful, I need to be able to use 
it in C and C++ code, and know that the types are compatible across the 
two languages, and that the generated code will be equally efficient. 
Frankly, as a user I don't really care whether it is implemented by a 
C++ library, a gcc extension, mind-numbing macros, or whatever.  It is 
absolutely fine if the details are hidden within a "stdfix.h" header 
file.  But what I /don't/ want to end up with is a type called "signed 
short _Fract" in C and "_fract<8>" in C++, or being unable to pass data 
between the languages, or having to have C++ call external C functions 
just to get efficient implementations.


Sorry for the rant - it is not aimed at you or anyone involved in gcc,

David

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 05/11/11 21:43, Gabriel Dos Reis wrote:
> On Sat, Nov 5, 2011 at 2:30 PM, David Brown
>> A C++ template class for "_Fract" support would be straightforward to write,
>> and could easily support the formats in N1169.  But it would be very hard to
>> do so in a way that generates small and fast code without resorting to
>> inline assembly for targets that have hardware support for such features.
>
> is this some sort of "here an outlanding statement and you would
> have to prove a negative to prove me right" or do you have more
> factual evidence to back your statement?
>

It is an estimation.

Some processors have particular instructions or mode flag settings that 
let them handle fixed point data very efficiently, such as by doing 
multiplication and shift at the same time, handling saturated 
arithmetic, or using special "accumulator" registers for particular 
features.

It is certainly /conceivable/ that gcc will generate such instructions 
automatically, but I would be very surprised - and extremely impressed.

Take an example using a processor I know well, the AVR (it is an 8-bit 
device, which is a little unusual for gcc).  It has an instruction will 
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed 
16-bit integer - basically combining an 8-bit x 8-bit to 16-bit multiply 
with a left shift.  So to do a "signed short _Fract" multiply, you have 
a single instruction and discard the least significant byte.

Simulating the same operation in generic C would be something like :

int8_t multShortFract(int8_t a, int8_t b) {
	int16_t c = (int16_t) a * b;
	return (c >> 7);
}


Now, I have enormous respect for the gcc (and related libraries and 
tools) developers, and I am regularly surprised by how smart the 
compiler is.  But using such features of the target requires specific code.

The advantage of using C's "signed short _Fract" here is that gcc /will/ 
use the optimal instruction in such cases (assuming, of course, that 
support is added for the target in question).  If it doesn't have such 
support, it can do the calculation using something similar to the C 
above - slower but correct.


>> As you say, it is possible that both could be supported - using a template
>> class to provide a generic solution, and using the C "_Fract" types for
>> specialized classes.  The first step to that, however, is to allow the
>> standard C "_Fract" types to work in C++ as a gcc extension.
>>
>> The same principle applies to the decimal types and extended float types
>> supported by C.
>
> that is one possibility.  However there is a difference between
> restricted "extension" and full fledged extensions.  I can see
> how a restricted version would work in C++ as an extension, but
> I doubt that is what you want.  I can also see how unrestricted
> extension (which you seemed to advocate) brings more headache
> where a library solution is seamless.
>

I am not sure what you mean by a "restricted extension" and a "full 
fledged extension".  But I do appreciate that extensions cause issues 
that libraries do not.

> Keeping adding builtin type specifiers to a language is not a
> sustainable and responsible way to grow a large language
> for the real world.  I appreciate we may disagree on that point.
>

It is always difficult for people to see all aspects of something like 
this - and it is important to do so when figuring out what to implement. 
  That's what discussions like this are for!

Let me try to put forward the viewpoint of the embedded programmer, 
since these are the people who would use such features.  I fully 
appreciate that other people see things differently, and that there are 
often good reasons for doing something that seems wrong from my 
viewpoint.  And I also fully appreciate there is a very big difference 
between agreeing that something is the best solution, and actual 
implementation.


In embedded systems, C is often used for smaller systems, with bigger 
systems using C++.  There are also people who use C for big systems, and 
those that use C++ for small systems.  And lots of code is a mixture.

The key issue is that it is, quite frankly, a pain in the a** that C++ 
is not closer to a superset of C.  Originally, C++ was a superset - 
excluding a few points that can easily be avoided in well-written code. 
  These days, the two language standards have moved gradually further 
away from each other.  Obviously C++ is going to get features that C 
does not - that's fair enough.  But it is seldom that there is a good 
reason for C++ not supporting the additions to C standards.

Some of the differences are just mind-boggling - C1x has got a 
"_Static_assert" addition, while C++11 has "static_assert".  They do the 
same thing, but have a different keyword.  Don't these people /talk/ to 
each other?  Do they make differences like this deliberately to annoy 
people - both users and toolwriters?

gcc has always countered that to some extend, by allowing additional C 
features to be used in C++.  But even there there are limitations - 
there are plenty of gcc extensions to C that are very useful, and for 
some reason only work in C and not C++.

As a programmer, when I write portable code in C I want it to be valid 
C++ as well.  This gives the most flexibility, and the most efficient 
use of my code.  I don't want to have to re-write code to do the same 
thing in each language, or to re-learn the differences.

So to make "_Fract" and "_Accum" really useful, I need to be able to use 
it in C and C++ code, and know that the types are compatible across the 
two languages, and that the generated code will be equally efficient. 
Frankly, as a user I don't really care whether it is implemented by a 
C++ library, a gcc extension, mind-numbing macros, or whatever.  It is 
absolutely fine if the details are hidden within a "stdfix.h" header 
file.  But what I /don't/ want to end up with is a type called "signed 
short _Fract" in C and "_fract<8>" in C++, or being unable to pass data 
between the languages, or having to have C++ call external C functions 
just to get efficient implementations.


Sorry for the rant - it is not aimed at you or anyone involved in gcc,

David

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Joseph S. Myers]

On Sun, 6 Nov 2011, David Brown wrote:

> Some of the differences are just mind-boggling - C1x has got a
> "_Static_assert" addition, while C++11 has "static_assert".  They do the same
> thing, but have a different keyword.  Don't these people /talk/ to each other?
> Do they make differences like this deliberately to annoy people - both users
> and toolwriters?

In C1X, <assert.h> defines the static_assert macro to expand to 
_Static_assert, just as C99 <stdbool.h> defines bool to _Bool.  This way 
you can include the header and write code compatible with both languages, 
without automatically breaking any code that previously defined those 
identifiers in its own way.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Jonathan Wakely]

On 6 November 2011 15:03, David Brown wrote:
>  Obviously C++ is going to get features that C does not - that's fair
> enough.  But it is seldom that there is a good reason for C++ not supporting
> the additions to C standards.
>
> Some of the differences are just mind-boggling - C1x has got a
> "_Static_assert" addition, while C++11 has "static_assert".  They do the
> same thing, but have a different keyword.  Don't these people /talk/ to each
> other?  Do they make differences like this deliberately to annoy people -
> both users and toolwriters?

What usually happens is that if C has claimed a new keyword already
C++ will reuse it.  When C++ has added a new keyword such as
static_assert the C committee has preferred to add keywords in the
reserved namespace.  That's an engineering decision, based on the risk
of breaking user code and weighed up against the reward of having more
convenient names.  The C++ committee are generally less fond of
macros, so less willing to solve the problem via e.g.
#define static_assert _Static_assert

> gcc has always countered that to some extend, by allowing additional C
> features to be used in C++.  But even there there are limitations - there
> are plenty of gcc extensions to C that are very useful, and for some reason
> only work in C and not C++.

I don't know how you're using "plenty" but I don't think there are
that many, and the reason is obvious: the C and C++ front ends are not
the same code.

If a useful extension is missing from G++ you can create an
enhancement request in bugzilla.

> As a programmer, when I write portable code in C I want it to be valid C++
> as well.  This gives the most flexibility, and the most efficient use of my
> code.  I don't want to have to re-write code to do the same thing in each
> language, or to re-learn the differences.
>
> So to make "_Fract" and "_Accum" really useful, I need to be able to use it
> in C and C++ code, and know that the types are compatible across the two
> languages, and that the generated code will be equally efficient. Frankly,
> as a user I don't really care whether it is implemented by a C++ library, a
> gcc extension, mind-numbing macros, or whatever.  It is absolutely fine if
> the details are hidden within a "stdfix.h" header file.  But what I /don't/
> want to end up with is a type called "signed short _Fract" in C and
> "_fract<8>" in C++, or being unable to pass data between the languages, or
> having to have C++ call external C functions just to get efficient
> implementations.

I think a better example is atomics support in C++11 and C11, where
std::atomic<int> aka std::atomic_int can be exactly the same
representation as _Atomic int and are compatible, but the C++ library
solution also allows std::atomic<FooBar> which C doesn't.  A *lot* of
work went into ensuring the C++ atomics support included a subset that
would be implementable in C.

Why couldn't the same be done for _Fract?

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Jonathan Wakely]

On 6 November 2011 15:40, Jonathan Wakely wrote:
>
> I think a better example is atomics support in C++11 and C11, where
> std::atomic<int> aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic<FooBar> which C doesn't.  A *lot* of
> work went into ensuring the C++ atomics support included a subset that
> would be implementable in C.
>
> Why couldn't the same be done for _Fract?

My point here, in case it wasn't clear, is that a C++ compiler doesn't
need to support _Atomic as a specifier, but code can be written to
work with both C and C++ anyway.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Ed Smith-Rowland]

On 11/06/2011 10:40 AM, Jonathan Wakely wrote:
> On 6 November 2011 15:03, David Brown wrote:
>
>
> What usually happens is that if C has claimed a new keyword already
> C++ will reuse it.  When C++ has added a new keyword such as
> static_assert the C committee has preferred to add keywords in the
> reserved namespace.  That's an engineering decision, based on the risk
> of breaking user code and weighed up against the reward of having more
> convenient names.  The C++ committee are generally less fond of
> macros, so less willing to solve the problem via e.g.
> #define static_assert _Static_assert
>
>> As a programmer, when I write portable code in C I want it to be valid C++
>> as well.  This gives the most flexibility, and the most efficient use of my
>> code.  I don't want to have to re-write code to do the same thing in each
>> language, or to re-learn the differences.
>>
>> So to make "_Fract" and "_Accum" really useful, I need to be able to use it
>> in C and C++ code, and know that the types are compatible across the two
>> languages, and that the generated code will be equally efficient. Frankly,
>> as a user I don't really care whether it is implemented by a C++ library, a
>> gcc extension, mind-numbing macros, or whatever.  It is absolutely fine if
>> the details are hidden within a "stdfix.h" header file.  But what I /don't/
>> want to end up with is a type called "signed short _Fract" in C and
>> "_fract<8>" in C++, or being unable to pass data between the languages, or
>> having to have C++ call external C functions just to get efficient
>> implementations.
> I think a better example is atomics support in C++11 and C11, where
> std::atomic<int>  aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic<FooBar>  which C doesn't.  A *lot* of
> work went into ensuring the C++ atomics support included a subset that
> would be implementable in C.
>
> Why couldn't the same be done for _Fract?
>
I think it would be very possible to have a general template library for 
C++ that would handle a range of sizes and granularities.  There would 
be a few combinations that would correspond to the C types.  These would 
use the hardware implementation by template specialization.

I think the deeper issue is that there are two communities who are 
interested in fixed-point math.  1. Embedded system folks who need an 
efficient replacement for floating point that matches their hardware.  
2. Systems programmers and financial types who want fixed-point like in 
COBOL and Ada where you specify granularity and number of digits.  I'm 
saying both groups can be accommodated with care.  I think even source 
compatibility could be achieved with home headers.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 06/11/11 16:40, Jonathan Wakely wrote:
> On 6 November 2011 15:03, David Brown wrote:
>>   Obviously C++ is going to get features that C does not - that's fair
>> enough.  But it is seldom that there is a good reason for C++ not supporting
>> the additions to C standards.
>>
>> Some of the differences are just mind-boggling - C1x has got a
>> "_Static_assert" addition, while C++11 has "static_assert".  They do the
>> same thing, but have a different keyword.  Don't these people /talk/ to each
>> other?  Do they make differences like this deliberately to annoy people -
>> both users and toolwriters?
>
> What usually happens is that if C has claimed a new keyword already
> C++ will reuse it.  When C++ has added a new keyword such as
> static_assert the C committee has preferred to add keywords in the
> reserved namespace.  That's an engineering decision, based on the risk
> of breaking user code and weighed up against the reward of having more
> convenient names.  The C++ committee are generally less fond of
> macros, so less willing to solve the problem via e.g.
> #define static_assert _Static_assert
>

Yes, I can understand that there /are/ good reasons behind these 
decisions - but it can be quite frustrating for the humble user who 
merely sees inconsistencies.

And I do appreciate that many of these inconsistencies are hidden by 
using header files (as mentioned by Joseph Myers in his reply), making 
the differences mostly irrelevant to users.

Perhaps I have been getting too worked up about small things here, and 
missing out on the major points, such as the efforts made to keep things 
consistent through the use of header files.  I still find it odd that 
features are added in different ways in each language, then headers are 
used to nullify the differences - but I thank you for your explanation 
of /why/ there are these differences.

>> gcc has always countered that to some extend, by allowing additional C
>> features to be used in C++.  But even there there are limitations - there
>> are plenty of gcc extensions to C that are very useful, and for some reason
>> only work in C and not C++.
>
> I don't know how you're using "plenty" but I don't think there are
> that many, and the reason is obvious: the C and C++ front ends are not
> the same code.
>
> If a useful extension is missing from G++ you can create an
> enhancement request in bugzilla.
>

I make the assumption that if a feature is in the C front end and not 
the C++ front end, then there is a reason for that - though the reason 
may be as simple as "no one has asked for this feature, so no one has 
made it".

I suppose my desire to see a consistent _Fract implementation between C 
and C++ is such an enhancement request, though it is made in this list 
rather than bugzilla.

>> As a programmer, when I write portable code in C I want it to be valid C++
>> as well.  This gives the most flexibility, and the most efficient use of my
>> code.  I don't want to have to re-write code to do the same thing in each
>> language, or to re-learn the differences.
>>
>> So to make "_Fract" and "_Accum" really useful, I need to be able to use it
>> in C and C++ code, and know that the types are compatible across the two
>> languages, and that the generated code will be equally efficient. Frankly,
>> as a user I don't really care whether it is implemented by a C++ library, a
>> gcc extension, mind-numbing macros, or whatever.  It is absolutely fine if
>> the details are hidden within a "stdfix.h" header file.  But what I /don't/
>> want to end up with is a type called "signed short _Fract" in C and
>> "_fract<8>" in C++, or being unable to pass data between the languages, or
>> having to have C++ call external C functions just to get efficient
>> implementations.
>
> I think a better example is atomics support in C++11 and C11, where
> std::atomic<int>  aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic<FooBar>  which C doesn't.  A *lot* of
> work went into ensuring the C++ atomics support included a subset that
> would be implementable in C.
>
> Why couldn't the same be done for _Fract?
>

If it can, then that would be marvellous, giving C++ users the choice of 
the same efficient _Fract's as C (on platforms that support efficient 
implementations, of course) and greater flexibility.  My original 
concern in this thread was that if the "r" and "k" _Fract suffixes were 
freed for general use in C++, it would be difficult to use them later.

Thanks,

David

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 06/11/11 16:40, Jonathan Wakely wrote:
> On 6 November 2011 15:03, David Brown wrote:
>>   Obviously C++ is going to get features that C does not - that's fair
>> enough.  But it is seldom that there is a good reason for C++ not supporting
>> the additions to C standards.
>>
>> Some of the differences are just mind-boggling - C1x has got a
>> "_Static_assert" addition, while C++11 has "static_assert".  They do the
>> same thing, but have a different keyword.  Don't these people /talk/ to each
>> other?  Do they make differences like this deliberately to annoy people -
>> both users and toolwriters?
>
> What usually happens is that if C has claimed a new keyword already
> C++ will reuse it.  When C++ has added a new keyword such as
> static_assert the C committee has preferred to add keywords in the
> reserved namespace.  That's an engineering decision, based on the risk
> of breaking user code and weighed up against the reward of having more
> convenient names.  The C++ committee are generally less fond of
> macros, so less willing to solve the problem via e.g.
> #define static_assert _Static_assert
>

Yes, I can understand that there /are/ good reasons behind these 
decisions - but it can be quite frustrating for the humble user who 
merely sees inconsistencies.

And I do appreciate that many of these inconsistencies are hidden by 
using header files (as mentioned by Joseph Myers in his reply), making 
the differences mostly irrelevant to users.

Perhaps I have been getting too worked up about small things here, and 
missing out on the major points, such as the efforts made to keep things 
consistent through the use of header files.  I still find it odd that 
features are added in different ways in each language, then headers are 
used to nullify the differences - but I thank you for your explanation 
of /why/ there are these differences.

>> gcc has always countered that to some extend, by allowing additional C
>> features to be used in C++.  But even there there are limitations - there
>> are plenty of gcc extensions to C that are very useful, and for some reason
>> only work in C and not C++.
>
> I don't know how you're using "plenty" but I don't think there are
> that many, and the reason is obvious: the C and C++ front ends are not
> the same code.
>
> If a useful extension is missing from G++ you can create an
> enhancement request in bugzilla.
>

I make the assumption that if a feature is in the C front end and not 
the C++ front end, then there is a reason for that - though the reason 
may be as simple as "no one has asked for this feature, so no one has 
made it".

I suppose my desire to see a consistent _Fract implementation between C 
and C++ is such an enhancement request, though it is made in this list 
rather than bugzilla.

>> As a programmer, when I write portable code in C I want it to be valid C++
>> as well.  This gives the most flexibility, and the most efficient use of my
>> code.  I don't want to have to re-write code to do the same thing in each
>> language, or to re-learn the differences.
>>
>> So to make "_Fract" and "_Accum" really useful, I need to be able to use it
>> in C and C++ code, and know that the types are compatible across the two
>> languages, and that the generated code will be equally efficient. Frankly,
>> as a user I don't really care whether it is implemented by a C++ library, a
>> gcc extension, mind-numbing macros, or whatever.  It is absolutely fine if
>> the details are hidden within a "stdfix.h" header file.  But what I /don't/
>> want to end up with is a type called "signed short _Fract" in C and
>> "_fract<8>" in C++, or being unable to pass data between the languages, or
>> having to have C++ call external C functions just to get efficient
>> implementations.
>
> I think a better example is atomics support in C++11 and C11, where
> std::atomic<int>  aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic<FooBar>  which C doesn't.  A *lot* of
> work went into ensuring the C++ atomics support included a subset that
> would be implementable in C.
>
> Why couldn't the same be done for _Fract?
>

If it can, then that would be marvellous, giving C++ users the choice of 
the same efficient _Fract's as C (on platforms that support efficient 
implementations, of course) and greater flexibility.  My original 
concern in this thread was that if the "r" and "k" _Fract suffixes were 
freed for general use in C++, it would be difficult to use them later.

Thanks,

David

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Marc Glisse]

On Sun, 6 Nov 2011, David Brown wrote:

> My original concern in this thread was that if the "r" and "k" _Fract 
> suffixes were freed for general use in C++, it would be difficult to use 
> them later.

The C++ standard already reserves all the suffixes that don't start with 
an underscore for future normalization. I interpret that as: defining your 
own suffix k should print a warning instead of an error.

I don't believe this is worth changing (if the error message is readable 
enough) until there is a plan for actually using that suffix.

-- 
Marc Glisse

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Jonathan Wakely]

On 6 November 2011 16:10, David Brown wrote:
> Perhaps I have been getting too worked up about small things here, and
> missing out on the major points, such as the efforts made to keep things
> consistent through the use of header files.  I still find it odd that
> features are added in different ways in each language, then headers are used
> to nullify the differences - but I thank you for your explanation of /why/
> there are these differences.

The main reason is that the committees are composed of different
people.  People get involved with standardisation efforts for the
language(s) they care about, and doing extra work to maintain
compatibility with a language you don't care about is hard to find
motivation for.

> I make the assumption that if a feature is in the C front end and not the
> C++ front end, then there is a reason for that - though the reason may be as
> simple as "no one has asked for this feature, so no one has made it".

Exactly.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Joern Rennecke]

Quoting David Brown <david.brown@hesbynett.no>:

> Take an example using a processor I know well, the AVR (it is an 8-bit
> device, which is a little unusual for gcc).  It has an instruction will
> multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
> 16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
> multiply with a left shift.  So to do a "signed short _Fract" multiply,
> you have a single instruction and discard the least significant byte.
>
> Simulating the same operation in generic C would be something like :
>
> int8_t multShortFract(int8_t a, int8_t b) {
> 	int16_t c = (int16_t) a * b;
> 	return (c >> 7);
> }

If you can make up your mind if the result is 8 or 16 bit, generating the
instruction should be standard fare for the combiner pass.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Gabriel Dos Reis]

On Sun, Nov 6, 2011 at 10:07 AM, Ed Smith-Rowland <3dw4rd@verizon.net> wrote:

> I think it would be very possible to have a general template library for C++
> that would handle a range of sizes and granularities.  There would be a few
> combinations that would correspond to the C types.  These would use the
> hardware implementation by template specialization.

There is widespread (unfounded) belief in some community
that a library datatype MUST be inefficient, because otherwise
it would have been builtin.  By the same token, there is a
widespread belief that if a builtin datatype cannot be library based.
Often, these people get into complete disbelief disorder when it is
reveled to them, that on quite descent platforms, the support
for a builtin type will be mostly library.  Conversely, they do not want to
believe that a library facility can receive special treatment from a compiler.
Unless that facility is from C, in which case it is OK, because C is
builtin anyway.

Someone mentioned _Bool and _Static_assert and wonders whether
C and C++ standards committees talk to each other.  They do.  At
least they have formal liaisons.   What is less appreciated though is
that the two community have different cultures
There are lot of reasons why they come to
different solutions (and the respective communities would expect
different solutions.)  The cultures are very different.  The C++
community tend to believe in libraries and general abstraction
facilities with wide range application.  The C community tend to believe
more in builtin type specifiers.

The fact that the communities intersect is no guarantee that they
have to come to the same solutions.  Furthermore, it is often
under-appreciated that C++ has vibrant embedded system
community (even issued embedded system TR) and templates
 are far more prominent roles there than the urban legends let it
know, or one would guess from some depiction of "the" embedded world.

Someone mentioned _Complex.  But _Complex has its own
issues with C++ language rules and library.

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Hans-Peter Nilsson]

On Sun, 6 Nov 2011, Joern Rennecke wrote:

> Quoting David Brown <david.brown@hesbynett.no>:
>
> > Take an example using a processor I know well, the AVR (it is an 8-bit
> > device, which is a little unusual for gcc).  It has an instruction will
> > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
> > 16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
> > multiply with a left shift.  So to do a "signed short _Fract" multiply,
> > you have a single instruction and discard the least significant byte.
> >
> > Simulating the same operation in generic C would be something like :
> >
> > int8_t multShortFract(int8_t a, int8_t b) {
> > 	int16_t c = (int16_t) a * b;
> > 	return (c >> 7);
> > }
>
> If you can make up your mind if the result is 8 or 16 bit, generating the
> instruction should be standard fare for the combiner pass.

Looks like a pretty typical Q7 (or Q1.7) multiplication to me
unless I miss something...  Would be a nice thing to have those
Q1.<N-1> formats as native GCC-extension types including
vectorized versions.  No, not planning it.

And having intermediate calculations in a wider mode does not
constituate lack of making ones mind up. :)
Though I believe that cast of "a" is ineffective, IIUC.

brgds, H-P

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 08/11/2011 05:27, Hans-Peter Nilsson wrote:
> On Sun, 6 Nov 2011, Joern Rennecke wrote:
>
>> Quoting David Brown<david.brown@hesbynett.no>:
>>
>>> Take an example using a processor I know well, the AVR (it is an 8-bit
>>> device, which is a little unusual for gcc).  It has an instruction will
>>> multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
>>> 16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
>>> multiply with a left shift.  So to do a "signed short _Fract" multiply,
>>> you have a single instruction and discard the least significant byte.
>>>
>>> Simulating the same operation in generic C would be something like :
>>>
>>> int8_t multShortFract(int8_t a, int8_t b) {
>>> 	int16_t c = (int16_t) a * b;
>>> 	return (c>>  7);
>>> }
>>
>> If you can make up your mind if the result is 8 or 16 bit, generating the
>> instruction should be standard fare for the combiner pass.
>

If the compiler can generate fractional arithmetic code directly from 
such expressions, then it is indeed a good step towards implementing 
such types as a pure C++ class without needing to use compiler extensions.

However, this is a simple case.  It gets a lot more complicated with 
"_Accum" types, with saturating types, and especially when mixing them. 
  It also gets more complicated when you start to have series of 
expressions, constant folding, etc.  I am not saying the compiler 
couldn't generate optimal code (on a target with hardware support for 
these operations) out from carefully written generic C++ code - but I do 
think it would be easier to get good code if the compiler views these 
types as "native".

The guts of gcc already know about types like "signed short _Fract", and 
can handle them well (at least for some targets).  It is always easier 
for the compiler when it has more knowledge than if it has to guess 
based on code patterns - so using "signed short _Fract" means it can see 
the real type early in the process rather than in a later "combine" pass.

> Looks like a pretty typical Q7 (or Q1.7) multiplication to me
> unless I miss something...  Would be a nice thing to have those
> Q1.<N-1>  formats as native GCC-extension types including
> vectorized versions.  No, not planning it.
>

Yes, it is Q1.7 multiplication.  And there is already a type for it in 
C, though gcc doesn't (yet) support it for all targets (I haven't 
checked recent versions).  It is "signed short _Fract" from TR 18037.
<http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html>

> And having intermediate calculations in a wider mode does not
> constituate lack of making ones mind up. :)

Correct - the return type is clearly int8_t.  The wider intermediate 
mode is a necessity of C.

> Though I believe that cast of "a" is ineffective, IIUC.
>

Also correct - "a" will be promoted automatically to an "int" (which is 
always at least 16-bit).  From long habit in embedded programming, I 
tend to be a bit more explicit about such conversions.  A real-world 
library would be written somewhat differently, of course (at the very 
least, it would use "int_fast16_t").

> brgds, H-P
>

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 08/11/2011 05:27, Hans-Peter Nilsson wrote:
> On Sun, 6 Nov 2011, Joern Rennecke wrote:
>
>> Quoting David Brown<david.brown@hesbynett.no>:
>>
>>> Take an example using a processor I know well, the AVR (it is an 8-bit
>>> device, which is a little unusual for gcc).  It has an instruction will
>>> multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
>>> 16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
>>> multiply with a left shift.  So to do a "signed short _Fract" multiply,
>>> you have a single instruction and discard the least significant byte.
>>>
>>> Simulating the same operation in generic C would be something like :
>>>
>>> int8_t multShortFract(int8_t a, int8_t b) {
>>> 	int16_t c = (int16_t) a * b;
>>> 	return (c>>  7);
>>> }
>>
>> If you can make up your mind if the result is 8 or 16 bit, generating the
>> instruction should be standard fare for the combiner pass.
>

If the compiler can generate fractional arithmetic code directly from 
such expressions, then it is indeed a good step towards implementing 
such types as a pure C++ class without needing to use compiler extensions.

However, this is a simple case.  It gets a lot more complicated with 
"_Accum" types, with saturating types, and especially when mixing them. 
  It also gets more complicated when you start to have series of 
expressions, constant folding, etc.  I am not saying the compiler 
couldn't generate optimal code (on a target with hardware support for 
these operations) out from carefully written generic C++ code - but I do 
think it would be easier to get good code if the compiler views these 
types as "native".

The guts of gcc already know about types like "signed short _Fract", and 
can handle them well (at least for some targets).  It is always easier 
for the compiler when it has more knowledge than if it has to guess 
based on code patterns - so using "signed short _Fract" means it can see 
the real type early in the process rather than in a later "combine" pass.

> Looks like a pretty typical Q7 (or Q1.7) multiplication to me
> unless I miss something...  Would be a nice thing to have those
> Q1.<N-1>  formats as native GCC-extension types including
> vectorized versions.  No, not planning it.
>

Yes, it is Q1.7 multiplication.  And there is already a type for it in 
C, though gcc doesn't (yet) support it for all targets (I haven't 
checked recent versions).  It is "signed short _Fract" from TR 18037.
<http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html>

> And having intermediate calculations in a wider mode does not
> constituate lack of making ones mind up. :)

Correct - the return type is clearly int8_t.  The wider intermediate 
mode is a necessity of C.

> Though I believe that cast of "a" is ineffective, IIUC.
>

Also correct - "a" will be promoted automatically to an "int" (which is 
always at least 16-bit).  From long habit in embedded programming, I 
tend to be a bit more explicit about such conversions.  A real-world 
library would be written somewhat differently, of course (at the very 
least, it would use "int_fast16_t").

> brgds, H-P
>

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Hans-Peter Nilsson]

(Not CC:ing the quoted newsgroup, sorry.)

On Tue, 8 Nov 2011, David Brown wrote:
> If the compiler can generate fractional arithmetic code directly from such
> expressions, then it is indeed a good step towards implementing such types as
> a pure C++ class without needing to use compiler extensions.

Right, but don't hold your breath.  Getting a native type in
place for all targets seems to be more important.

> The guts of gcc already know about types like "signed short _Fract", and can
> handle them well (at least for some targets).

By default too few to matter, it seems, MIPS and ARM.  Not even
sure any of it works elsewhere.  Missing from the AVR port too
(yes, that's you cue. :)  For acceptance, IMHO better get it
working universally by open-coding the implementation without
requiring --enable-* options.

>  It is always easier for the
> compiler when it has more knowledge than if it has to guess based on code
> patterns - so using "signed short _Fract" means it can see the real type early
> in the process rather than in a later "combine" pass.

Certainly.

> > Looks like a pretty typical Q7 (or Q1.7) multiplication to me
> > unless I miss something...  Would be a nice thing to have those
> > Q1.<N-1>  formats as native GCC-extension types including
> > vectorized versions.  No, not planning it.
> >
>
> Yes, it is Q1.7 multiplication.  And there is already a type for it in C,
> though gcc doesn't (yet) support it for all targets (I haven't checked recent
> versions).

I checked my tree above (up-to-date modulo a few hours).

>  It is "signed short _Fract" from TR 18037.
> <http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html>

There you go!  I thought it had other semantics.  Actually the
type would be target-dependent, but all the targets (both ARM
and MIPS :) have it that way.  Somewhat awkward: the intuitive
choice would have been "signed char _Fract" IMHO.

brgds, H-P

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[David Brown]

On 08/11/2011 15:24, Hans-Peter Nilsson wrote:
> (Not CC:ing the quoted newsgroup, sorry.)
>
> On Tue, 8 Nov 2011, David Brown wrote:
>> If the compiler can generate fractional arithmetic code directly from such
>> expressions, then it is indeed a good step towards implementing such types as
>> a pure C++ class without needing to use compiler extensions.
>
> Right, but don't hold your breath.  Getting a native type in
> place for all targets seems to be more important.

Agreed.

>
>> The guts of gcc already know about types like "signed short _Fract", and can
>> handle them well (at least for some targets).
>
> By default too few to matter, it seems, MIPS and ARM.  Not even
> sure any of it works elsewhere.  Missing from the AVR port too
> (yes, that's you cue. :)  For acceptance, IMHO better get it
> working universally by open-coding the implementation without
> requiring --enable-* options.
>

Agreed.

I had actually thought the fixed point types were part of the 
up-and-coming C1x standard, but it seems they are not - they are just 
part of a draft "TR 18037".  Maybe that will make it into the C 
standards eventually.

I had been thinking that since they are in a C standard, it's only a 
matter of time before gcc supports them on all targets.

>>   It is always easier for the
>> compiler when it has more knowledge than if it has to guess based on code
>> patterns - so using "signed short _Fract" means it can see the real type early
>> in the process rather than in a later "combine" pass.
>
> Certainly.
>
>>> Looks like a pretty typical Q7 (or Q1.7) multiplication to me
>>> unless I miss something...  Would be a nice thing to have those
>>> Q1.<N-1>   formats as native GCC-extension types including
>>> vectorized versions.  No, not planning it.
>>>
>>
>> Yes, it is Q1.7 multiplication.  And there is already a type for it in C,
>> though gcc doesn't (yet) support it for all targets (I haven't checked recent
>> versions).
>
> I checked my tree above (up-to-date modulo a few hours).
>
>>   It is "signed short _Fract" from TR 18037.
>> <http://gcc.gnu.org/onlinedocs/gcc/Fixed_002dPoint.html>
>
> There you go!  I thought it had other semantics.  Actually the
> type would be target-dependent, but all the targets (both ARM
> and MIPS :) have it that way.  Somewhat awkward: the intuitive
> choice would have been "signed char _Fract" IMHO.
>

I can understand why you say that - but from my point of view, "signed 
char _Fract" is as horrible as "signed short _Fract".  What is really 
needed is an equivalent to "stdint.h" to give specific, fixed sizes to 
these - then programmers can rely on them.  Something like

typedef signed short _Fract fract1q7;
typedef unsigned short _Fract ufract0q7;

Otherwise there will be more madness in the ranks of embedded programmers...


Actually, I suspect that the reality of the situation is that the time 
for these types has gone.  They will be useful to a few, but people will 
continue to use their ugly, type-unsafe, macro-ridden, target-specific 
fixed point libraries - either written themselves or by the manufacturer 
of the target chip.  Steadily more chips support single-precision 
floating point in hardware, making fixed point redundant for many uses. 
  I still think it would be nice to see full support in gcc - both for C 
and C++.  But I think that by the time they are well supported on a 
range of compilers and targets, and therefore useful for general 
portable embedded code, most code that could use them will use floating 
point in stead.


> brgds, H-P
>

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Joseph S. Myers]

On Tue, 8 Nov 2011, David Brown wrote:

> The guts of gcc already know about types like "signed short _Fract", and can
> handle them well (at least for some targets).  It is always easier for the

Actually, I'd say they are handled badly.  The approach of separate 
machine modes for them going right into the back end is not a good 
approach at all; at an appropriate point, fixed-point *types* should be 
lowered to fixed-point *operations* on generic types (some would just be 
existing operations, some would be saturating operations, some would be 
multiply-and-shift).  See the discussion of the ARM fixed-point support 
<http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00846.html>; duplicating 
(for every target) support for implementing a fixed-point operation using 
a generic integer operation is not sensible.

(Fractional types do make sense as an API; treating saturation as a type 
property rather than an operation property is a more doubtful aspect of TR 
18037.  But in both cases there should be a lowering pass.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Joseph S. Myers]

On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:

> (yes, that's you cue. :)  For acceptance, IMHO better get it
> working universally by open-coding the implementation without
> requiring --enable-* options.

Making something involving new types - and so ABI impact - universal 
without actually agreeing the ABI for each target with appropriate ABI 
maintainers or interest groups for that target is not a good idea.  It 
leads to ABI incompatibility with other compilers, and to inefficient and 
poorly specified ABIs that are "whatever GCC happens to implement if you 
don't think about it" like we have on several targets for complex 
types....  (I spent quite some time reverse engineering and documenting 
the peculiarities of the ABIs for 32-bit Power GNU/Linux that arose in 
that way; now documented in the Power.org ABI specification.)

(It is however desirable that supporting fixed point or decimal floating 
point for a new target ought not to require more from that target than 
appropriate definitions of the ABI.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Hans-Peter Nilsson]

On Tue, 8 Nov 2011, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:
>
> > (yes, that's you cue. :)  For acceptance, IMHO better get it
> > working universally by open-coding the implementation without
> > requiring --enable-* options.
>
> Making something involving new types - and so ABI impact - universal
> without actually agreeing the ABI for each target with appropriate ABI
> maintainers or interest groups for that target is not a good idea.  It
> leads to ABI incompatibility with other compilers, and to inefficient and
> poorly specified ABIs that are "whatever GCC happens to implement if you
> don't think about it" like we have on several targets for complex
> types....

I'd hope ABI issues would be solved trivially by mapping to the
same-sized integer type, the one ISTR you mentioned would be a
good idea to keep before lowering the operations ;) but I guess
I see your point.

brgds, H-P

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Joseph S. Myers]

On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:

> > Making something involving new types - and so ABI impact - universal
> > without actually agreeing the ABI for each target with appropriate ABI
> > maintainers or interest groups for that target is not a good idea.  It
> > leads to ABI incompatibility with other compilers, and to inefficient and
> > poorly specified ABIs that are "whatever GCC happens to implement if you
> > don't think about it" like we have on several targets for complex
> > types....
> 
> I'd hope ABI issues would be solved trivially by mapping to the
> same-sized integer type, the one ISTR you mentioned would be a
> good idea to keep before lowering the operations ;) but I guess
> I see your point.

The ABI also needs to say which is the same-sized type - and how many 
integer and fractional bits there are - and there's no guarantee that the 
psABI maintainers will actually make it behave like the same-sized integer 
type.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.

[Miles Bader]

David Brown <david@westcontrol.com> writes:
> If the compiler can generate fractional arithmetic code directly
> from such expressions, then it is indeed a good step towards
> implementing such types as a pure C++ class without needing to use
> compiler extensions.
...
> I am not saying the compiler couldn't generate optimal code (on a
> target with hardware support for these operations) out from
> carefully written generic C++ code - but I do think it would be
> easier to get good code if the compiler views these types as
> "native".

Of course, even if a special compiler representation turns out to be
necessary for optimal performance, that doesn't mean that the _syntax_
has to be something wacky (whereas C has little choice).

It would be perfectly reasonable to have the public interface be a
thin library wrapper around unadvertised builtin types -- and that's
probably quite preferable as it would enable a portable pure library
solution for compilers that do not contain special support.

-Miles

-- 
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]