John said that they found that the language didn't define the operation.
*THAT* is evidence, or if it's not, you're calling him a liar. Now which is it?Read.
Then the result *is* undefined. If you don't think rounding direction is important...
Except it didn't.
Can you kindly point us to an ARM development/debug/jtag suite that includes a certified perfect compiler? Where all operations are unambiguous?
How does it know to do arithmetic or logical shift? Can I *tell* it which to use? I can in PowerBasic. And I can logical shift a signed integer if I really want to.
Nice words, "catch lurking" , "quirk" and "problem here." Good summary of C.
C is a 40-year-old language designed to run on a PDP-11. Heck, it's practically a PDP-11 assembler. I bought a lot of PDP-11s, 100 at least. The base 11/20 came with 8 kbytes of core memory. An expansion chassis could load it up to 64K. The language is designed around the limits of the PDP-11.
A book describing the possible ambiguities of C would be, roughly, 50 times as long as a book describing the language itself. Microsoft can't write reliable C, and that's become a national security issue.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
He seems to be calling me a stupid liar.
Anyway, I probably found all the bugs by the traditional method, lots of testing, ane we shipped it to a laser company on Tuesday.
Luckily, it has 5 pots (on the end not shown) that can set all the timings. In the default POT mode, the pots get digitized, lowpass filtered, and the values are scaled into the same form (like, integer picoseconds or millivolts) as USB commands use. So, pretty early on in the math chain, I can turn the pots to sweep the delays and widths and amplitudes and all. So checking for corner cases and monoticity and such is easy, compared to typing settings or writing apps to poke in test cases over USB. I can random fiddle the pots, too, but it's harder to write software that random fiddles, and harder to track the results.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
We told it to divide a signed sum by positive 4096, and it didn't. Nobody would get this wrong by hand, or using a calculator.
Optimizations are great - we obviously assumed it *would* optimize the division - but not of it does it wrong. It didn't divide by 4096. I suppose that, if we'd used 4097, or 4096.001, it would have worked right. Maybe.
It's not flawed, it's compiler dependant, namely ambiguous with permission to be ambiguous.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
ISO/IEC 9899:1999 (E) 6.5.5 specifies "truncation toward zero" . Also that "if the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a".
Divide by zero is undefined. I don't see anything that's implementation dependent in that section of the standard.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Cargill
Korosho.
the
these
their
=20
=46ortunately i missed that era.
trained
mentality.
Better
code.
But this isn't dependant on undergrad scale projects. It uses existing publicly available code.
=20
Unfortunate but true. The school projects where i had to work as part of a group were graduate school level courses.
that
=20
Huzza! That is a "fun" day for me.
they
use it
Not talking about suits per se, but first line supervisors of working programmers. Maybe some second level, but not very often.
Not only that, but buying the tools and training staff in the use thereof is likely to improve not just the quality it maybe will improve the existing schedule as well. Of course the sh**heads would just compress the schedule then.
more
FADEC
the
the
the
atheir
fixes.
and
I only do mediocre at that without tools.
Mmmm nice. I haven't had that good of tools of that kind.
teaching
cost
=20
of
write,
make it
Gorsh.
GUI
fun
early.
in
I tend to like TCL/TK wrappers around CLI programs. Properly done it deals with both ncurses and X interfaces.
Really? Lets see. DEADBEEF arithmetically right shifted 12 will result in FFFDEADB. Looks a lot like rounding toward zero to me. As for not identical to an actual divide, i don't think so. I have had to chase = that as the gate and transistor level.
If you want to thoroughly test it write the test code in assembler and = run it.
?-)
was=20
other=20
=20
and=20
Why don't i believe you?
See:
I see no such mishmash in a recent draft standard. Nor has there been = any reason to change the relevant language (page 94 in the pdf viewer).
?-)
We multiplied two numbers into a signed product, and told it to divide that by 4096. It didn't. Disbelieve that if it makes you happy.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
=20
Some of them did. One was so outspoken that it cost him dearly. =20
See:=20
?-)
And you trust this assertion by the bloviator that he or his coding monkey found something in "C for Dummys" that confirmed his prejudice.
You are a bigger fool than I first thought.
I have already pointed you to the IBM reference page on the treatment of manifest constants in ANSI C signed integer arithmetic. They are supposed to be promoted to signed quantities provided that they will fit without overflow (and if they don't fit all bets are off).
Since 4096 is >12.
He doesn't have a clue what he is talking about and neither do you.
He hasn't *shown* anything of the sort. He has asserted wildly that what he says is true but backed it up with no evidence at all!
The code generator is supposed to generate code that implements the original expression which in the original code was of the form x/4096. The change to a bit shift was a later stage compiler optimisation.
But that is more likely a code generator fault.
-- Regards, Martin Brown
You looked it up in "C for Dummys"? Until you can quote a reference that supports your position you are just digging a bigger hole.
And in particular 6.3.1.3 and 6.4.4.1 p56 where it states categorically that a manifest decimal constant is of signed integer type in ANSI C.
If he had used a hexadecimal or octal constant there would be an implicit type conversion ambiguity but since 4096 > I see no such mishmash in a recent draft standard. Nor has there been any
What I disbelieve is that the root cause of this problem is as you have asserted due to ambiguities in the language. Thanks to Joseph I am now able to point to the WG14 report to confirm and support my position.
Incidentally what happens if you substitute /4096 with >>12 ?
That would eliminate the peephole optimiser from the game entirely.
-- Regards, Martin Brown
The first thing you should have tried was either 4095 or 4097 and then that would establish whether or not the fault lies in the basic code generator, peephole optimiser or at the implicit type conversion phase. Decimal constants are supposed to be signed according to the standard.
Then eliminate the peephole optimiser entirely and code it as x>>12.
You have asserted without any evidence that this fault stems from a language defect when in fact you haven't even done the right tests. Incompetent can be added to your other properties.
It is defined in ANSI C. You choose to use defective tools.
-- Regards, Martin Brown
It is a fence post error when you compare dividing by 0x1000 signed with the corresponding bit shift on twos complement negative numbers. The only case where the two methods will agree is when the operand is such that it has all zero bits in the remainder of the division.
I think you know what I mean here but to avoid further ambiguity a concrete example with a divisor large enough to show both effects.
If we compare divide by 4 and >>2 on twos complement negative integers
int /4 >>2 8bit
-10 -2 -3 0xF6 -9 -2 -3 0xF7 -8 -2 -2 0xF8 -7 -1 -2 0xF9 -6 -1 -2 0xFA -5 -1 -2 0xFB -4 -1 -1 0xFC -3 0 -1 0xFD -2 0 -1 0xFE -1 0 -1 0xFF 0 0 0 0x00 1 0 0 0x01 2 0 0 0x02 3 0 0 0x03 4 1 1 0x04 5 1 1 0x05 6 1 1 0x06 7 1 1 0x07 8 2 2 0x08
Note that /4 rounds towards zero creating a block of seven zeroes whereas arithmetic shift gives 4 states for every output value. Leading FFFFFF removed for clarity.
And the C snippet code to do it (yes I know printf is deprocated)
int i,j,k; for (i=-10; i>2; printf("%3i %3i %3i %X\n", i,j,k,i); }
Putting it another way -1 is invariant under arithmetic right shift. (and so is zero)
-- Regards, Martin Brown
I don't think there are any perfect C compilers, but so far I haven't found much to complain about in the IAR offering. I actually chose them because I had too many problems downloading another vendors product...
You can write C code unambiguously if you want to and spell things out. The modern C++ compilers actually help in that respect. Most will warn about mixed mode arithmetic expressions if asked to do so.
Good summary of your very likely defective code if negative results are a possibility at that point and you have used integer division to scale it then it probably does not do what you intended.
Martin Richards BCPL (dates from 1967 on IBM kit) which was stripped to B by Ken Thompson at Bell Labs was the grand parent of C. In its day BCPL was a very elegant portable compiler that was easy to bootstrap onto new hardware quickly. C evolved from B later about 1970 to cater for the additional features of the PDP-11. BCPL was still in common use at some universities in the UK as late as 1980.
It is actually the original philosophy of BCPL which was running on minimalist hardware that has given C some of its quirky features.
See for example the quote at the end of the Wiki article
"In 1979 implementations of BCPL existed for at least 25 architectures; in 2001 it sees little use.
The philosophy of BCPL can be summarised by quoting from the book BCPL, the language and its compiler:
The philosophy of BCPL is not one of the tyrant who thinks he knows best and lays down the law on what is and what is not allowed; rather, BCPL acts more as a servant offering his services to the best of his ability without complaint, even when confronted with apparent nonsense. The programmer is always assumed to know what he is doing and is not hemmed in by petty restrictions.
The design, and philosophy, of BCPL strongly influenced B, which in turn influenced C.
There are rumours that BCPL actually stood for "Bootstrap Cambridge Programming Language", however CPL was never created since development stopped at BCPL, and the acronym was reinterpreted for the BCPL book."
These ideas made sense when we were fighting for every last byte and serious compromises were made to get things to fit in core.
They view time to market as more important than correctness. That is a business decision for the suits. I have already said that I think industry chose the wrong path with C and that strongly typed minimal languages like Modula2 (and the much larger Ada) offer a much better programming model if you care about security and program correctness.
However, the fault you ran into was almost certainly a defective compiler implementation and not a fault in the C language.
-- Regards, Martin Brown
though.
chas.
cing is
ch is
e. You
r.
or
ahift
ing would
is
I was looking at an 20+ year old K&R, latest standard calls for round toward zero
it sound like you think the compiler is free to invent a random number and set the cpu on fire if you divide a signed number, it is not it has to produce a divide that works for both signed and unsigned numbers, the undefined is that if you have an old compiler it is free to choose which way it rounds the msb
agreed, the question is not whether it did or not, but why.
the compiler should not have done it, so either the variables were not not defined as signed, or the compiler is broken which I think is a bit unlikely since it would break most code if it can't do divide correctly
-Lasse
The design of C minimalizes source length, number of tokens, and provides the minimum usable set of inherent operations, all the better to let the linker do more work than the compiler. That made sense when core memories were tiny and programmers were all brilliant. Neither is true any more.
You can see the PDP-11 instruction set peeking out from behind C. Early PDP-11 programmers (and that includes me... I had something like serial number 110) used a lot of tricks at first, like autoincrement and autodecrement pointers to walk around data structures, and computed pointers to code, which generally turned out to be dangerous. Even DECs early FORTRAN compilers did tricks like that. Later, we learned to do more indexing, table-driven dispatches, stuff like that, using hardly more code but making things much safer. C is mired in those days, and it has dragged the programming culture with it.
40 years is way too long. Pascal and ADA were clobbered by the joys of typing cryptic, buggy code real, real fast. Being careful and correct is just too much work for most people.VHDL is heavily based on ADA.
In that we asked it to divide, and it didn't produce the value that would result from the division, I agree. It optimized the division to a right shift, and it was the wrong right shift.
But what if we had used >> ? Would it have correctly done a signed shift?
Paul named a constant, signed 32-bit integer of value 4096, and put that into the denominator of the expression. That compiled to a signed right shift. Barbaric.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
Error!!! 4095 would have overflowed the data destined for our 16-bit DAC.
or 4097
Yes, 4097 is safe, as 4096.001 would be safe. Do try to be careful about the realities.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
Digging a hole? I shipped a neat pulse generator, first PCB etch, and plan to ship a lot more of them. The customer paid in advance. The stupid C compiler cost us a day.
C is a bug factory.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.