Lcc win overflow handling

[jacob navia]

Keith Thompson a écrit :

Sure, but there's a difference between an ordinary extension (with
no guarantee of commonality from one implementation to another) and
a standardized but optional feature, like C99's IEC 60559 support,
which allows you to write code that's portable to all implementations
that support the feature.

But now that I think about it, I dislike the idea of making it an
"optional feature" in the sense that one implementation might support
it another might not. What I might like to see is a mandatory
feature, in the sense that all implementations must support it,
that imposes no costs on *programs* that don't use it.

#pragma STDC OVERFLOW_CHECK(off) // You see? It is optional

I meant optional in the sense that can be turned off.

 

[Keith Thompson]

Keith Thompson a écrit :

#pragma STDC OVERFLOW_CHECK(off) // You see? It is optional

Quibble: The syntax is:

#pragma STDC OVERFLOW_CHECK OFF

Does your proposal define a default value, or is it
implementation-defined?

I meant optional in the sense that can be turned off.

Good, I'm glad we cleared that up without bloodshed. }

 

[Nick Keighley]

Richard Heathfield a écrit :

do you optional feature of the language or optional feature at
translation time?

Incredible

The same people that at each message write

PORTABILITY PORTABILITY

I think it depends what you mean by "optional"

and always brand anything lcc-win proposes as "unportable extensions"
propose... well to have extensions to plug in a hole in the language

Why?

Because I see that nobody is even starting to argue against this being
a big hole in the specs.

Why not close it with an optional construct that allows to check for
overflow for specified functions?

My proposal doesn't need any code modifications and could mean just a
global command line option, as it is in lcc-win now.

as others have pointed out, it is not clear what you are proposing
should be added to the standard

The increased granularity of a per function on/off setting would
further reduce the run time penalty to almost nothing.

When I started lcc-win, a recompilation of the compiler with itself took
25 seconds.
impressive

Now, it takes 2 seconds. From 1995 to 2009 we have a factor of 10 of
performance increase.

even more impressive! Is overflow very likely in a compiler?

Many other CPU families are similar.

If C is to be used in environments where accuracy of results is
important then this option is an absolute necessity. Not everybody
is programming games...

games probably require more accuracy than you imagine. They
are effectivly simulators.

 

[Nick Keighley]

Yes, we care about correct results, and yes, there may be times where
overflow detection is useful, even necessary.  It has simply been my
experience that properly designed code very, very rarely needs it, as the
code will be designed to prevent that very situation from ever arising in
the first place.

well put. I've seen overflow on bad input but I don't remember it on a
calculation (unless was factorials for the "fun" of it). More often
I've
seen divide by zero. And I've seen a fair amount of Bad Things done
with floating point.

 

[Bart]

[snips]

The key is not to detect overflows.  The key is to understand the domain
your code needs to work over, to pick appropriate types and operations
for the code over that domain, and to ensure that the data actually fits
that domain.  If you've done that, overflow becomes effectively
impossible in the first place, so worrying about how to detect it becomes
essentially irrelevant - yet you still get correct results.

You're ignoring bugs. Overflow detection (of the automatic kind) can
be a useful tool in a debug version of an application, in the same way
that array bounds checking can be.

 

[Keith Thompson]

[snips]

The key is not to detect overflows.  The key is to understand the domain
your code needs to work over, to pick appropriate types and operations
for the code over that domain, and to ensure that the data actually fits
that domain.  If you've done that, overflow becomes effectively
impossible in the first place, so worrying about how to detect it becomes
essentially irrelevant - yet you still get correct results.

You're ignoring bugs. Overflow detection (of the automatic kind) can
be a useful tool in a debug version of an application, in the same way
that array bounds checking can be.

And then you can turn off the checking for the production version of
the code.

Like a parachute that's only for use in the flight simulator.

 

[Bart]

[snips]
The key is not to detect overflows.  The key is to understand the domain

You're ignoring bugs. Overflow detection (of the automatic kind) can
be a useful tool in a debug version of an application, in the same way
that array bounds checking can be.

And then you can turn off the checking for the production version of
the code.

Like a parachute that's only for use in the flight simulator.

No, more like a diagnostics box that tells you why you crashed or that
you were in danger of crashing.

I'm starting to understand Jacob's frustration at a group that either
completely dismisses the idea of this check, or proposes impractical
'standard C' versions of the checking code.

I agree overflow checking is not very exciting, and only catches a
small class of errors (eg. overflow of A*B, due to A or B having the
wrong value, but A*B can also give a wrong value that doesn't
overflow). But it can't do any harm to have it available as an extra
tool.

I mentioned elsewhere that I applied my own overflow check inside an
interpreter. Suppose that code (the code responsible for executing "A
+B" for example) was written in C, and I wanted to use the signed
overflow check to switch to a wider int datatype.

What's the best way of doing that in C at present, bearing in mind
that integer addition has to be kept as fast as possible, so using the
14-term expression proposed by Richard Heathfield is completely out of
the question?

(I'm only interested in running on x86-family processors, since those
are the only ones I can buy.)

 

[Stephen Sprunk]

On the other hand, we could simply use variable types where the issue
doesn't come up. If we're handing prices in cents, using 32-bit integers
and allowing for the possibility of negatives (i.e. using signed, rather
than unsigned values), a simple 32-bit long allows us to process values
up to some $21 million... which is going to be absolutely sufficient for
most stores.

Murphy's Law is inescapable.

A former startup I worked for had a payroll system based on a 32-bit
signed (long int) count of cents for each line item. It worked fine for
years -- until we were acquired. For legal and tax reasons that aren't
relevant here, they decided to buy our options back via a one-time
payroll bonus rather than let them vest and be exercised. Everything
worked perfectly for us peons, but when it came time to pay the
founder/CEO, his bonus of ~$270M crashed the payroll system because it
overflowed the long int counter.

Of course, we could allow for the possibility of the occasional really
large order, and jump to 64 bit values; that allows us orders large
enough the combined finances of the planet could not possibly overflow
the result.

That was the solution to the above problem because simply using bigger
ints for everything was easier/cheaper than checking for overflow -- and
checking alone isn't enough; you still have to _do_ something about the
overflow you detected, so why not just use that code path all the time?

Murphy will strike again, though; it won't take long for Zimbabwe's
hyperinflation to overflow a 64-bit counter...

S

 

[Ben Bacarisse]

[snips]

The key is not to detect overflows.  The key is to understand the domain
You're ignoring bugs. Overflow detection (of the automatic kind) can
be a useful tool in a debug version of an application, in the same way
that array bounds checking can be.

And then you can turn off the checking for the production version of
the code.

Like a parachute that's only for use in the flight simulator.

No, more like a diagnostics box that tells you why you crashed or that
you were in danger of crashing.

I'm starting to understand Jacob's frustration at a group that either
completely dismisses the idea of this check, or proposes impractical
'standard C' versions of the checking code.

I don't understand this frustration. I don't think the idea has been
"completely dismissed" by this group and a portable C check might be useful for
people who don't have any other option.

Were I to propose language feature "X", the useful replies will be
among the critical ones. Sure, it is nice to get a ringing
endorsement of one's ideas, but such an endorsement does not help get
anything into the C standard. If I have not thought of a problem that
is pointed out, or not considered an alternative mechanism that
someone suggests, then I will be glad to be better informed. And if I
have been round that design loop, I am no worse off. Some of critical
responses might be useful, but none of the positive ones are.

If Jacob's objective is to get something into C, then most of the
negative feedback is useful because it will surely come at some point
in shepherding the proposal though. If he wants the best overflow
detection in his compiler, then seeing alternative proposals might be
useful. If he is sure that he already has the best possible design,
what does he care what lesser thinkers think?

I agree overflow checking is not very exciting, and only catches a
small class of errors (eg. overflow of A*B, due to A or B having the
wrong value, but A*B can also give a wrong value that doesn't
overflow). But it can't do any harm to have it available as an extra
tool.

Absolutely not. It could be harmful, however, to have things in the
language standard that are not well designed. I am not commenting on
this specific design. My impression is that most people agree that it
is a good idea (in general) but they disagree on how best to reflect
the feature in the language.

I mentioned elsewhere that I applied my own overflow check inside an
interpreter. Suppose that code (the code responsible for executing "A
+B" for example) was written in C, and I wanted to use the signed
overflow check to switch to a wider int datatype.

What's the best way of doing that in C at present, bearing in mind
that integer addition has to be kept as fast as possible, so using the
14-term expression proposed by Richard Heathfield is completely out of
the question?

(I'm only interested in running on x86-family processors, since those
are the only ones I can buy.)

You already know the best way to do it. If you need a single portable
solution then a manual check is the only way so it can't be "out of
the question". If you can make do with, say, Jacob's compiler then
you already have the solution, so why consider anything else? If you
need to do it on multiple implementations of C, then you have no
choice but to see what they all offer and use implementation-specific
code for each one. You know this.

No one is saying that this is the best option, but it is disingenuous
to suggest that people here are blocking a good idea that would
otherwise solve a real-world problem you have.

You won't get a compiler that conforms to the next C standard for many
years and it will be even longer before you can rely on the standard
for a widely portable solution. Furthermore, I can't image that
anything said here will have the slightest adverse effect on whether a
proposal from Jacob gets accepted or not. Comments here may help to
improve any proposal that he puts forward (by, for example, bring up
cases he has not considered) but it will stand or fall on its merits,
not on the reception it gets on c.l.c.

 

[Keith Thompson]

[snips]

The key is not to detect overflows.  The key is to understand the domain
You're ignoring bugs. Overflow detection (of the automatic kind) can
be a useful tool in a debug version of an application, in the same way
that array bounds checking can be.

And then you can turn off the checking for the production version of
the code.

Like a parachute that's only for use in the flight simulator.

No, more like a diagnostics box that tells you why you crashed or that
you were in danger of crashing.

You suggested, I think, enabling overflow checks only in a debug
version of an application, not in a production version. If your
planes crash only during development, that's great. If you're worried
about them crashing in production, then you won't get the diagnostics
after a crash because you've disabled them. Or did I misunderstand
you?

(Someone has compared overflow checking to a parachute that opens on
impact.)

I'm starting to understand Jacob's frustration at a group that either
completely dismisses the idea of this check, or proposes impractical
'standard C' versions of the checking code.

I certainly haven't dismissed the idea of language-level overflow
checking, and I don't recall anyone else doing so either. Quite to
the contrary, I and others have been trying to help design a facility
that will work as well as possible.

As for the impractical standard C versions of checking code, those
have generally been posted in response to questions about how you'd do
overflow checking in standard C. The complexity of such code
demonstrates the problem we're trying to solve.

[...]

What's the best way of doing that in C at present, bearing in mind
that integer addition has to be kept as fast as possible, so using the
14-term expression proposed by Richard Heathfield is completely out of
the question?

(I'm only interested in running on x86-family processors, since those
are the only ones I can buy.)

I don't know the answer to that question. If you can assume that
signed integer arithmetic is done only in 2's-complement, with
overflows wrapping around in the usual 2's-complement way (where
INT_MAX + 1 == INT_MIN), then you can probably check for overflow
after the fact more easily than by pre-checking the operands.
But such checking can easily be broken by compiler optimizations that
assume signed overflow invokes undefined behavior, and therefore
that the compiler is free to perform code transformations based on
the assumption that overflow doesn't happen.

One solution might be to write small assembly functions that check the
appropriate CPU flags and give you an overflow indication. Code using
such functions is going to be annoyingly verbose, but if your compiler
can inline the functions it should be reasonably efficient.

The frustration is that overflow checking is something that's
typically not very difficult for a given CPU, but that low-level
functionality isn't exposed by the C language.

If you're looking for a practical solution given C as it currently
exists, you might need to ask in a forum that deals with x86
programming or with the particular compiler you're using.

 

[Bart]

Bart <[email protected]> writes:

[Trapping overflows in interpreter hypothetically written in C]

What's the best way of doing that in C at present, bearing in mind
that integer addition has to be kept as fast as possible, so using the
14-term expression proposed by Richard Heathfield is completely out of
the question?

....

One solution might be to write small assembly functions that check the
appropriate CPU flags and give you an overflow indication.  Code using
such functions is going to be annoyingly verbose, but if your compiler
can inline the functions it should be reasonably efficient.

I was just coming up with a practical example that would greatly
benefit from overflow checking, since, despite your comments, it does
seem to be dismissed by some who 'just don't get it' (see most recent
'past discussion' thread).

(As it happens, I'm using Asm for this project. When I tried C once,
it was just too slow. And to achieve speed and fluency, I need to do
various naughty things in the language which most people here would
strongly disapprove of.

An overflow check in the Asm code, would consist of a single
conditional jump [for single precision integer arithmetic], which will
*only* jump on overflow (unlike Jacob's code which will nearly always
jump.)

The frustration is that overflow checking is something that's
typically not very difficult for a given CPU, but that low-level
functionality isn't exposed by the C language.

For my purposes C isn't low-level enough. We need something more along
the lines of the Machine-Oriented languages that used to be around.

 

[jacob navia]

Bart a écrit :

An overflow check in the Asm code, would consist of a single
conditional jump [for single precision integer arithmetic], which will
*only* jump on overflow (unlike Jacob's code which will nearly always
jump.)

The jump is a forward jump, so it will be mispredicted as not taken.
When it is taken a pileline flush is done. This makes for that huge 4%.

I could greatly improve performance by doing a jo (as you do) to several
labels. Note that I have to push the line number and the function name
so that the overflow function can report them. You do not have that
problem.

 

[Bart]

Bart a écrit :

An overflow check in the Asm code, would consist of a single
conditional jump [for single precision integer arithmetic], which will
*only* jump on overflow (unlike Jacob's code which will nearly always
jump.)

The jump is a forward jump, so it will be mispredicted as not taken.
When it is taken a pileline flush is done. This makes for that huge 4%.

I could greatly improve performance by doing a jo (as you do) to several
labels. Note that I have to push the line number and the function name
so that the overflow function can report them. You do not have that
problem.

In my case, one of the registers contains the program counter of the
bytecode. That plus a database of source linenumbers/addresses let's
me locate the error.

You don't have this luxury in tight, compiled code, which really needs
a call.cc instruction to preserve the program counter.

In the absence of that, lots of local error-handling labels would be
needed as you suggest, one per checked operation. Perhaps putting
these all together would help cache locality of the normal
instructions. (Or perhaps not, Intel cpu optimisation being a black
art.)

 

[Stephen Sprunk]

If Jacob's objective is to get something into C, then most of the
negative feedback is useful because it will surely come at some point
in shepherding the proposal though. If he wants the best overflow
detection in his compiler, then seeing alternative proposals might be
useful. If he is sure that he already has the best possible design,
what does he care what lesser thinkers think?

It's been my experience that those most convinced of their own
correctness (and thus least likely to listen to others) are those most
likely to be wrong.

My .sig quote is also quite relevant.

S

 

[user923005]

The quote is: "Stupid people surround themselves with smart people.
Smart people surround themselves with smart people who disagree with
them." And it doesn't make sense. Not the first bit, anyway. If we
accept the second part, then the stupid people won't be able to get
near the smart people, because all the smart people are already
surrounded by smart people who disagree with them.

It's an interesting geometry problem, and I think it will depend on
our definition of 'surround'.

Consider a honeycomb pattern where we place smart and stupid people
into cells.

If we define 'surround' as 'completely enclosed by a continuous
polygon of cells of type X' then I can easily envision configurations
where both conditions are true.

It can also depend upon our definition of smart. Does smart mean some
exact IQ number? Or does it have a relative meaning (e.g. IQ is N
points higher than me)? (IOW smarter). The second condition makes
the problem much more difficult.

 

[Stephen Sprunk]

That's a good first-order approximation.

Of course, it isn't that simple. We learn. There is much about C of
which I am absolutely certain, and about which I will brook no
disagreement. Nevertheless, I'm right!

Or so you think ;-)

But the curious thing is that, even as late as the Autumn of 1998, I
knew *everything* about C. Anyone who disagreed with me was wrong by
definition. (That's your first approximation, of course.) By early
1999, however, I was subscribing to comp.lang.c. Over the next year
or so, C suddenly grew much bigger and much more complicated (and no,
I'm not talking about C99), and suddenly I knew an awful lot less
about it. Fortunately, I was able to adapt to this new reality. Many
people, alas, don't seem able to take that step.

"The only true knowledge lies in knowing that you know nothing."
--Socrates

There was a psychology study done a few years ago that showed an
interesting statistic: graphing _actual_ grades on a test vs. the
students' _expected_ grades showed an inverse relationship: the better a
student knew the subject, the more they realized how much they didn't
know and their grade expectations went down; those who didn't have a
clue thought they knew everything and would get excellent grades. Only
B/C students were able to accurately predict their results.

The quote is: "Stupid people surround themselves with smart people.
Smart people surround themselves with smart people who disagree with
them." And it doesn't make sense. Not the first bit, anyway. If we
accept the second part, then the stupid people won't be able to get
near the smart people, because all the smart people are already
surrounded by smart people who disagree with them.

If you're going to be pedantic about it, yes, that's true; however,
human relationships (and language) are not so exact.

In any case, a "should" was implied by the original context, according
to the quotee. I had found that in past research (there was a debate
about exactly who said it first, and I wanted to get the attribution
right), but I decided not to amend the quote for space reasons. I'll do
so for you below...

S

 

[Seebs]

There was a psychology study done a few years ago that showed an
interesting statistic: graphing _actual_ grades on a test vs. the
students' _expected_ grades showed an inverse relationship: the better a
student knew the subject, the more they realized how much they didn't
know and their grade expectations went down; those who didn't have a
clue thought they knew everything and would get excellent grades. Only
B/C students were able to accurately predict their results.

Dunning-Kruger effect.

-s

 

[Tech07]

It's been my experience that those most convinced of their own
correctness (and thus least likely to listen to others) are those most
likely to be wrong.

Straight away I can identify 2 potential forces (there may be more): 1.)
Paradigm: One so totally believes something that he/she is blinded or
hindered to "seeing" anything else but. Needs "help" "seeing", maybe.
Probably doesn't trust or believe you though. 2.) Politics: needs no
explanation, in USA it doesn't at least. For example, "pulling the wool over
someone's eyes" for monetary reasons, is "political".

That said, you said: something about "correctness". And do tell about this
big chip on your shoulder called, "most others are wrong". (rhetorical ).

 

[Tech07]

That's a good first-order approximation.

Explain this "first-order" stuff. Is is like "due to.."?

Of course, it isn't that simple.

Surely not "professor".

We learn.

Who's "we"? Is there a distinct remoteness there?

There is much about C of
which I am absolutely certain,

Sounds like a bible study now.

and about which I will brook no
disagreement. Nevertheless, I'm right!

But the curious thing is that, even as late as the Autumn of 1998, I
knew *everything* about C.

Don't look now, but his contrived resume is looking for campaign funds. LOL!

Anyone who disagreed with me was wrong by
definition.

"In your mind", you mean.

(That's your first approximation, of course.) By early
1999, however, I was subscribing to comp.lang.c.

Dude?! Are you campaigning for position or what? What's your point! Stop
wasting peoples' time!

Over the next year
or so, C suddenly grew much bigger and much more complicated (and no,
I'm not talking about C99),

Apparently you don't like C99 (?)... bring it up in a SEPARATE thread.

and suddenly I knew an awful lot less
about it.

You learned more about "it's all in there". The language didn't change that
much. You were still growing toward becoming a "journeyman" in your
greenbean state.

Fortunately, I was able to adapt to this new reality.

The journey of a programmer as written by you?

Many
people, alas, don't seem able to take that step.

Ah, was that "the clincher" statement? Very weak. "Needs "more"", said your
high school English composition teacher.

 

[Tech07]

Dunning-Kruger effect.

You mean him trying to peddle off "there was a Xological study" as truth? I
stopped reading the second he started selling snake oil.