Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from the context. I would like to make the
case for my position here, in a separate thread, because the other
thread is just getting too
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision.
Consider 8 * 10 / 4
in an infinite precision
On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck wrote:
> Richard,
>
> You advocate that I should be using an infinite precision
> representation and I advocate a finite precision representation where
> the precision is taken from the context. I would like to make the
> case for my position here, i
On 04/08/2013 06:46 AM, Richard Biener wrote:
On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck wrote:
Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from the context. I would like t
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediate value is
outside this range.
all intermedi
On 04/08/2013 04:56 AM, Florian Weimer wrote:
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is
division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision.
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
What do you mean when you say "constant a
On 04/08/2013 09:03 AM, Robert Dewar wrote:
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediat
On 4/8/2013 9:24 AM, Kenneth Zadeck wrote:
So then how does a language like ada work in gcc? My assumption is
that most of what you describe here is done in the front end and by the
time you get to the middle end of the compiler, you have chosen types
for which you are comfortable to have any
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer)
On 04/08/2013 09:52 AM, Robert Dewar wrote:
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is "in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
expect the math to be done within that type,
On 04/08/2013 10:12 AM, Robert Dewar wrote:
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is "in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
On Mon, Apr 8, 2013 at 2:43 PM, Kenneth Zadeck wrote:
>
> On 04/08/2013 06:46 AM, Richard Biener wrote:
>>
>> On Sun, Apr 7, 2013 at 7:16 PM, Kenneth Zadeck
>> wrote:
>>>
>>> Richard,
>>>
>>> You advocate that I should be using an infinite precision
>>> representation and I advocate a finite prec
On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
My confusion is what you mean by "we"? Do you mean "we" the writer of
the program, "we" the person invoking the compiler by the use command
line options or "we", your company's implementation of ada?
Sorry, bad usage, The gcc implementation of Ada
On 4/8/13, Kenneth Zadeck wrote:
> The other problem, which i invite you to use the full power of
> your c++ sorcery on, is the one where defining an operator so
> that wide-int + unsigned hwi is either rejected or properly
> zero extended. If you can do this, I will go along with
> your suggesti
On 4/8/13, Richard Biener wrote:
> I advocate the infinite precision signed representation as one
> solution to avoid the issues that come up with your implementation
> (as I currently have access to) which has a representation
> with N bits of precision encoded with M <= N bits and no sign
> info
On 4/8/13, Robert Dewar wrote:
> On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
> > On 04/08/2013 10:12 AM, Robert Dewar wrote:
> > > On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
> > > > yes but the relevant question for the not officially
> > > > static integer constants is "in what precision are thos
On 4/8/2013 5:12 PM, Lawrence Crowl wrote:
(BTW, you *really* don't need to quote entire messages, I find
it rather redundant for the entire thread to be in every message,
we all have thread following mail readers!)
Correct me if I'm wrong, but the Ada standard doesn't require any
particular ma
In some sense you have to think in terms of three worlds:
1) what you call "compile-time static expressions" is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time static expressions because that is what th
On 4/8/2013 5:46 PM, Kenneth Zadeck wrote:
In some sense you have to think in terms of three worlds:
1) what you call "compile-time static expressions" is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
> That may be so in C, in Ada it would be perfectly reasonable to use
> infinite precision for intermediate results in some cases, since the
> language standard specifically encourages this approach.
gcc lacks an infinite precision plus operator?!
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifically encourages this approach.
gcc lacks an
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifi
On 4/8/2013 7:46 PM, Kenneth Zadeck wrote:
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in som
On Mon, Apr 8, 2013 at 10:39 PM, Lawrence Crowl wrote:
> On 4/8/13, Kenneth Zadeck wrote:
>> The other problem, which i invite you to use the full power of
>> your c++ sorcery on, is the one where defining an operator so
>> that wide-int + unsigned hwi is either rejected or properly
>> zero exten
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG expanded code listing clearly shows in
Ada source form, what is going on.
Isn't this a
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG expanded code listing clearly shows in
Ada s
On 04/09/2013 02:41 PM, Robert Dewar wrote:
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG
On Tue, Apr 9, 2013 at 5:36 PM, Lawrence Crowl wrote:
>
> On Apr 9, 2013 2:02 AM, "Richard Biener" wrote:
>>
>> On Mon, Apr 8, 2013 at 10:39 PM, Lawrence Crowl wrote:
>> > On 4/8/13, Kenneth Zadeck wrote:
>> >> The other problem, which i invite you to use the full power of
>> >> your c++ sorcer
On Apr 10, 2013, at 12:38 AM, Richard Biener wrote:
> Yeah, I think we want to test ~(T)0<(T)0 here.
Thanks Lawrence, in the next version of the patch, you will discover this at
the bottom if you look hard. :-)
On 04/10/2013 12:02 PM, Mike Stump wrote:
On Apr 10, 2013, at 12:38 AM, Richard Biener wrote:
Yeah, I think we want to test ~(T)0<(T)0 here.
Thanks Lawrence, in the next version of the patch, you will discover this at
the bottom if you look hard. :-)
actually closer to the middle.
33 matches
Mail list logo
