Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27627
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Source code static analysis tool recommendations |
| Date | 2018-02-08 10:46 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <p5h6a2$anu$1@dont-email.me> (permalink) |
| References | (9 earlier) <p5cu9s.3s8.1@stefan.msgid.phost.de> <p5d8ld$6m3$1@dont-email.me> <fdv1ghFlrbbU1@mid.dfncis.de> <p5ecto$hab$1@dont-email.me> <fe1i3rF8vmuU1@mid.dfncis.de> |
On 08/02/18 00:57, Hans-Bernhard Bröker wrote: > Am 07.02.2018 um 09:21 schrieb David Brown: > >> I have seen bugs in a certain massively popular, expensive but nameless >> (to protect the guilty) 8051 compiler in the way it handled integer >> promotions. > > I'm quite sure I'm talking about that very same compiler when I say: no, > those weren't bugs. They were the amply documented effect of that > compiler being run in an explicitly _not_ standard compliant setting. > That is entirely possible. As I say, it was a colleague that asked for help, wondering if his C code was wrong. The C was correct, the compiler was generating object code that did not match the C. But it could well have been as you say, and the compiler was running in a significantly non-standard mode. >> I don't remember the details (it was a colleague that used >> the tool), but it is conceivable that the compiler was running in some >> sort of "MISRA mode" with different semantics for types than standard C. > > No. It was running in a "let's not even pretend this micro is actually > big enough to efficiently implement C without seriously breaking a large > fraction of the rules" mode. > > Many, maybe all the C compilers for small 8-bitters have such a mode, > and often that's their default mode because, frankly, the > standard-conforming mode would be nearly useless for most serious work. > OTOH, those micros, and the projects they're used in, are generally > small enough that you don't really have to go all MISRA on them. Certainly there are some things that standard C requires that would be very painful for handling in these brain-dead devices. A prime example is re-entrant or recursive functions. Without a decent data stack (and, in particular, SP+x addressing modes), it is very inefficient to have local variables in a stack on things like an 8051. So most compilers for these kinds of chips will put the local variables at fixed addresses in ram. Functions cannot then be used recursively. However, dealing with this efficiently does not need a change to the language supported - the compiler can analyse the source code and call paths, see that all or most functions are /not/ used recursively, and generate code taking advantage of that fact. The lazy way to handle it is to say that any recursive functions need to be specially marked (with a pragma, attribute, or whatever). This will be used so rarely in such code that it is not a problem. In the case I had seen here, I think (IIRC) the problem was that the compiler was doing arithmetic on 8-bit types as 8-bit arithmetic - it was not promoting it to 16-bit ints. IMHO there is no justification for this non-standard behaviour. It is simple enough for the compiler to give the correct C logical behaviour while optimising to 8-bit generated code in cases where the high byte is not needed. I have no problem with compilers requiring the use of extensions or extra features to get good code from these devices. Having a "flash" keyword, or distinguishing between short and long pointers - that's fine. Making "double" the same as "float" - less fine, but understandable. But changing the rules for integer promotions and the usual arithmetic conversions? No, that is not appropriate. Other "helpful" ideas I have seen on compilers that I consider broken are to skip the zeroing of uninitialised file-scope data (and hide a tiny note about it deep within the manual), and to make "const" work as a kind of "flash" keyword on a Harvard architecture cpu so that "const char *" and "char *" become completely incompatible.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 13:32 -0800
Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-02 18:24 -0500
Re: Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 17:13 -0800
Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-03 03:40 -0500
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-03 11:45 +0100
Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-03 16:37 +0000
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-04 10:18 +0100
Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-04 15:12 +0000
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-05 18:48 +0100
Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-05 23:18 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-06 19:25 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 22:53 +0100
Re: Source code static analysis tool recommendations Richard Damon <Richard@Damon-Family.org> - 2018-02-06 21:34 -0500
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:06 +0100
Re: Source code static analysis tool recommendations Jack <jack4747@gmail.com> - 2018-02-05 23:32 -0800
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 10:23 +0100
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-06 19:05 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 23:02 +0100
Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-07 02:02 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:21 +0100
Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-08 00:57 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-08 10:46 +0100
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-07 20:04 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 20:54 +0100
Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-08 18:58 +0100
Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-09 09:17 +0100
Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:55 +1100
Re: Source code static analysis tool recommendations Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-02-10 19:59 -0500
Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:49 +1100
csiph-web