On 06/11/18 15:10, TTman wrote:> >> >> But then I started coding in binary long time ago, >> so for me asm is a high level language. > > Me too... with front panel switches on an 8 bit mini computer in the early 70's....In that timeframe I was using a 39-bit(!) computer, still to be seen working at the best museum I've come across. My first assembler program was the triumphant reinvention of an FSM to convert one 5-channel paper tape code into another. Worked first time.>> I started with PICs cracking TV smartcards that had those in it. >> So the dirty secrets I should know... Was still legal back then. > > Same again, me too :) > I hate high level languages.. could never get the hang of them...I used Algol60 on that machine. I still remember the epiphany when I realised what the compiler was actually doing.
PIC/dsPIC development
Started by ●November 4, 2018
Reply by ●November 6, 20182018-11-06
Reply by ●November 6, 20182018-11-06
Tom Gardner wrote>Ah, but most people /think/ they understand all the >parts - until someone demonstrates to them that they >have been bitten and not noticed it.I never had a problem with C, I never use Cplushplush, it is crap. C programmers (on Linux) should really read and use libc.info. It is all about that library. I did read K&R still have it as pdf. Things have changed a bit. I try to write he most basic form of C that helps portability, and have -Wall on all the time. Written thousands and thousands and thousands of lines of C code, threaded, not threaded, and never a problem. But I could not have done it without libc.info. And again, if you do not know the solution to a problem, then writing in a higher level language does not solve it either. And if you do, then it really makes little difference what language you command the hardware [or anything else] in. And C syntax and basics .. again.. keep a bit of what's it: 'Ordnung' in your code, and you will be fine. Add comments, write what you do, why you do it. Mostly for myself as years later I maybe have to pick up on the code or use parts of it in other projects, or port it to asm :-). There is no problem. And dare publish your code, if not then it is safe to assume you are hiding from the spotlights with crap. Oh yes I know, 'secret' well, you mean you took the open source and used it without giving back to the community. gcc is open source too. Don't blah blah, show your code.
Reply by ●November 6, 20182018-11-06
On 11/06/2018 10:57 AM, Phil Hobbs wrote:> On 11/6/18 9:38 AM, Tom Gardner wrote: >> On 06/11/18 14:01, Phil Hobbs wrote: >>> On 11/6/18 7:36 AM, Tom Gardner wrote: >>>> On 06/11/18 11:28, David Brown wrote: >>>>> On 05/11/18 19:44, Clive Arthur wrote: >>>>>> On 05/11/2018 18:01, Tom Gardner wrote: >>>>>> >>>>>> <snipped> >>>>>> >>>>>>>> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur >>>>>>>> wrote: >>>>>>>>> I'd like to know exactly what the [dsPIC] optimisers >>>>>>>>> do. >>>>>>> >>>>>>> The make more assumptions that the programmer understands what >>>>>>> they've asked the computer and compiler to do. >>>>>> >>>>>> Yebbut, that's not exactly exact. Any examples? >>>>> >>>>> I am guessing he means that many compilers are more forgiving >>>>> of programmers who don't understand C if they are not >>>>> optimising. A classic example is that some people think that >>>>> if you overflow a signed integer calculation, you get two's >>>>> complement wrapping if the underlying processor supports it >>>>> (they think that "x + y" in C translates to an "ADD" >>>>> instruction in assembly). With the kind of simplistic >>>>> translation-style compilation you often get with no >>>>> optimisation enabled, that can often be correct. With >>>>> optimisation enabled and better analysis of the source code, it >>>>> is frequently not the case. >>>> >>>> Yes, that's the kind of thing, but of course there are many other >>>> examples! >>>> >>>> >>>> >>>>> The C programming world is somewhat split into two kinds of >>>>> programmers. One kind feel that the C language is defined by >>>>> the standards and implementation-specific documentation, and >>>>> this forms a contract between the programmer and the compiler - >>>>> the programmer promises to follow the rules of the standards, >>>>> and the compiler promises to give them the best possible code >>>>> on the assumption that the rules are followed. They work with >>>>> their compiler in order to get the most efficient results. >>>>> >>>>> The other kind of C programmer have a sort of "Humpty Dumpty" >>>>> attitude that "programs mean exactly what I want them to mean" >>>>> and that C is a "high level assembly". Those kinds of >>>>> programmers get upset when compilers "outsmart" them, and are >>>>> continually fighting their tools. >>>> >>>> There's some truth in that, but it is far too black and white. I >>>> believe the vast majority of programmers can be described as: - >>>> want to do a good job - have some humility, but not too much - >>>> have /some/ knowledge of their limitations and of the C/C++ >>>> tool's "quirks", and try to live within them - aren't experts >>>> that really do understand those things >>>> >>>> So, despite their best intentions, it is unlikely that such users >>>> will fully comprehend the C/C++ tools limitations nor their own >>>> limitations, let alone that of other people's code and >>>> libraries. >>>> >>>> >>>>>> I find it frustrating that you're using a tool where the >>>>>> maker won't tell you what the little check boxes actually >>>>>> do. >>>>>> >>>>> >>>>> Compiler manuals often (but not always) have a lot of >>>>> information about what the optimisations do. It is rarely >>>>> possible to give complete details, however - it's just too >>>>> complicated to fit in user documentation. gcc has summaries >>>>> for all the different optimisation flags - there are /many/ of >>>>> them - but it doesn't cover everything. >>>> >>>> That complexity is a serious issue. If given a piece of code, >>>> most developers won't understand which combination of compiler >>>> flag must/mustn't be used. >>> >>> Code that works on some compiler settings and not others gives me >>> the heebie-jeebies. People often talk about "optimizer bugs" that >>> really aren't anything of the sort. Of course vaguely-defined >>> language features such as 'volatile' and old-timey thread support >>> don't help. (Things have been getting better on that front, I >>> think.) >> >> Me too, but it is unclear to me that Things Are Getting Better. If >> they are it is /very/ slow and will in many cases be constrained by >> having to use old variants of a language. >> > > Well, std::atomic is an example. > >> >>> >>>> Now, given that the principal actors are the users, the tools and >>>> the user's organisation, what is an appropriate behaviour for >>>> each actor? >>>> >>>> Take the time and money to become an expert? >>> >>> I don't think you have to be a certified language lawyer to avoid >>> most of that stuff. Just stay paranoid and don't try to be too >>> clever. >> >> That's my attitude, but I'm not sure it is still possible. It isn't >> just a "language lawyer", it is a "language+this compiler" lawyer. >> >> As one example, the C++ FQA (sic) has some tortuous examples. Yes, it >> is belligerent and amusing and a little outdated, but most points hit >> home :( http://yosefk.com/c++fqa/ >> > >> As another, consider that the C++ language *designers* refused to >> admit that C++ templating language was Turing complete - until Erwin >> Unruh rubbed their noses in it by getting the compiler to emit prime >> numbers *during compilation*. >> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >> >> >> >> Key phrase: "...it was *discovered* during the process of >> standardizing..." >> >> If the language designers don't understand their language, it is too >> complex - and is becoming part of the problem. > > Nah. I understand some people like template metaprogramming, but C++ is > now more a family of languages than a single language. Few of us use > all of it, and most (including meself) don't use most of it.Ya but if you're not doing any meta-programming C++ is then hard to recommend as a modern language at all why not just use C99. or Pascal or some other HLL that intrinsically supports objects or object-like abstractions and is let's be real here a lot more pleasant to work with syntactically. The "core" of C++ is a statically-typed 1970s style C-like language that's not intrinsically that remarkable, the other half of the language is a powerful compile-time metaprogramming language you use to fashion the bits of the "core" into zero-overhead abstractions. If you're not using any of that you're missing out, for example templates can be used to implement static polymorphism and have many of the advantages of inheritance-based runtime polymorphism with none of the overhead. Virtual methods have their place even in uP development but it makes sense to use them sparingly particularly on the Harvard architecture with limited SRAM; the standard insists on copying all vtables out of Flash into SRAM at runtime even though in theory this should not be necessary.
Reply by ●November 6, 20182018-11-06
On 06/11/18 15:05, David Brown wrote:> On 06/11/18 15:38, Tom Gardner wrote: >> On 06/11/18 14:01, Phil Hobbs wrote: >>> On 11/6/18 7:36 AM, Tom Gardner wrote: >>>> On 06/11/18 11:28, David Brown wrote: >>>>> On 05/11/18 19:44, Clive Arthur wrote: >>>>>> On 05/11/2018 18:01, Tom Gardner wrote: > > <snipped> > >>>> >>>> That complexity is a serious issue. If given a piece >>>> of code, most developers won't understand which >>>> combination of compiler flag must/mustn't be used. >>> >>> Code that works on some compiler settings and not others gives me the >>> heebie-jeebies. People often talk about "optimizer bugs" that really >>> aren't anything of the sort. Of course vaguely-defined language >>> features such as 'volatile' and old-timey thread support don't help. >>> (Things have been getting better on that front, I think.) >> >> Me too, but it is unclear to me that Things >> Are Getting Better. If they are it is /very/ >> slow and will in many cases be constrained by >> having to use old variants of a language. >> > > One thing that I can think of that is "getting better" is threading in > C11 and C++11. I don't see it being particularly popular in C11 - > people use other methods, and embedded developers are often still using > older C standards. C++11 gives more useful threading features, which > have been extended in later versions - they give more reasons to use the > language's threading functionality rather than external libraries. > > The other new feature (again, from C++11 and C11) is atomic support. > > These are nice, but I think that most people who understands and uses > "atomic" probably already understood how to use "volatile" correctly.Yes, but /very/ slowly. The core multiprocessing concepts were known in the mid 70s, but quite reasonably they didn't make it into K&R C. They first made their way into systems in the early/mid 80s, in Cedar/Mesa and Occam. They were, unfortunately, completely ignored in C++, because it was addressing (and creating) different problems. They were used in mainstream languages/environments in the mid 90s, i.e. almost a quarter of a century ago. Some of the higher-level concepts continue to be included in newer languages. So by a very generous definition, C/C++ is catching up with techniques that were known to be good 30 years ago, and that have been in widespread use for 20 years. Not impressive. The main reason C/C++ continues to be used is history: there's a lot of code out there, and people are familiar with (old versions of) it. Ditto COBOL.
Reply by ●November 6, 20182018-11-06
On 11/06/2018 10:57 AM, Phil Hobbs wrote:> On 11/6/18 9:38 AM, Tom Gardner wrote: >> On 06/11/18 14:01, Phil Hobbs wrote: >>> On 11/6/18 7:36 AM, Tom Gardner wrote: >>>> On 06/11/18 11:28, David Brown wrote: >>>>> On 05/11/18 19:44, Clive Arthur wrote: >>>>>> On 05/11/2018 18:01, Tom Gardner wrote: >>>>>> >>>>>> <snipped> >>>>>> >>>>>>>> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur >>>>>>>> wrote: >>>>>>>>> I'd like to know exactly what the [dsPIC] optimisers >>>>>>>>> do. >>>>>>> >>>>>>> The make more assumptions that the programmer understands what >>>>>>> they've asked the computer and compiler to do. >>>>>> >>>>>> Yebbut, that's not exactly exact. Any examples? >>>>> >>>>> I am guessing he means that many compilers are more forgiving >>>>> of programmers who don't understand C if they are not >>>>> optimising. A classic example is that some people think that >>>>> if you overflow a signed integer calculation, you get two's >>>>> complement wrapping if the underlying processor supports it >>>>> (they think that "x + y" in C translates to an "ADD" >>>>> instruction in assembly). With the kind of simplistic >>>>> translation-style compilation you often get with no >>>>> optimisation enabled, that can often be correct. With >>>>> optimisation enabled and better analysis of the source code, it >>>>> is frequently not the case. >>>> >>>> Yes, that's the kind of thing, but of course there are many other >>>> examples! >>>> >>>> >>>> >>>>> The C programming world is somewhat split into two kinds of >>>>> programmers. One kind feel that the C language is defined by >>>>> the standards and implementation-specific documentation, and >>>>> this forms a contract between the programmer and the compiler - >>>>> the programmer promises to follow the rules of the standards, >>>>> and the compiler promises to give them the best possible code >>>>> on the assumption that the rules are followed. They work with >>>>> their compiler in order to get the most efficient results. >>>>> >>>>> The other kind of C programmer have a sort of "Humpty Dumpty" >>>>> attitude that "programs mean exactly what I want them to mean" >>>>> and that C is a "high level assembly". Those kinds of >>>>> programmers get upset when compilers "outsmart" them, and are >>>>> continually fighting their tools. >>>> >>>> There's some truth in that, but it is far too black and white. I >>>> believe the vast majority of programmers can be described as: - >>>> want to do a good job - have some humility, but not too much - >>>> have /some/ knowledge of their limitations and of the C/C++ >>>> tool's "quirks", and try to live within them - aren't experts >>>> that really do understand those things >>>> >>>> So, despite their best intentions, it is unlikely that such users >>>> will fully comprehend the C/C++ tools limitations nor their own >>>> limitations, let alone that of other people's code and >>>> libraries. >>>> >>>> >>>>>> I find it frustrating that you're using a tool where the >>>>>> maker won't tell you what the little check boxes actually >>>>>> do. >>>>>> >>>>> >>>>> Compiler manuals often (but not always) have a lot of >>>>> information about what the optimisations do. It is rarely >>>>> possible to give complete details, however - it's just too >>>>> complicated to fit in user documentation. gcc has summaries >>>>> for all the different optimisation flags - there are /many/ of >>>>> them - but it doesn't cover everything. >>>> >>>> That complexity is a serious issue. If given a piece of code, >>>> most developers won't understand which combination of compiler >>>> flag must/mustn't be used. >>> >>> Code that works on some compiler settings and not others gives me >>> the heebie-jeebies. People often talk about "optimizer bugs" that >>> really aren't anything of the sort. Of course vaguely-defined >>> language features such as 'volatile' and old-timey thread support >>> don't help. (Things have been getting better on that front, I >>> think.) >> >> Me too, but it is unclear to me that Things Are Getting Better. If >> they are it is /very/ slow and will in many cases be constrained by >> having to use old variants of a language. >> > > Well, std::atomic is an example. > >> >>> >>>> Now, given that the principal actors are the users, the tools and >>>> the user's organisation, what is an appropriate behaviour for >>>> each actor? >>>> >>>> Take the time and money to become an expert? >>> >>> I don't think you have to be a certified language lawyer to avoid >>> most of that stuff. Just stay paranoid and don't try to be too >>> clever. >> >> That's my attitude, but I'm not sure it is still possible. It isn't >> just a "language lawyer", it is a "language+this compiler" lawyer. >> >> As one example, the C++ FQA (sic) has some tortuous examples. Yes, it >> is belligerent and amusing and a little outdated, but most points hit >> home :( http://yosefk.com/c++fqa/ >> > >> As another, consider that the C++ language *designers* refused to >> admit that C++ templating language was Turing complete - until Erwin >> Unruh rubbed their noses in it by getting the compiler to emit prime >> numbers *during compilation*. >> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >> >> >> >> Key phrase: "...it was *discovered* during the process of >> standardizing..." >> >> If the language designers don't understand their language, it is too >> complex - and is becoming part of the problem. > > Nah. I understand some people like template metaprogramming, but C++ is > now more a family of languages than a single language. Few of us use > all of it, and most (including meself) don't use most of it.Consider the following exercise in modularity, I have one generic Interface which can be specialized with any number of modular "plug-in" classes to customize its behavior. Zero-overhead abstraction, in this case the C++ compiler optimzer recognizes that this code can be reduced to a sequence of cout calls so that's what it does. In general with this structure the "Interface" class generates no code, everything required to make any set of variations on the Interface work is deduced at compile-time (as shown by the highlighted lines here): <https://godbolt.org/z/-GQ2OU> #include <iostream> template <template <typename> class Implementation> class Interface { public: template <typename T> void doSomething(const T& a_thing) { std::cout << "Generic preprocessing\n"; static_cast<Implementation<T>*>(this)->doSomething_(a_thing); std::cout << "Generic post-processing\n"; } }; template <typename T> class Impl1 : public Interface<Impl1> { friend class Interface<Impl1>; protected: void doSomething_(const T& a_thing) { // do something here std::cout << "Impl1 is doing something\n"; } }; template <typename T> class Impl2 : public Interface<Impl2> { friend class Interface<Impl2>; protected: void doSomething_(const T& a_thing) { // do something different here std::cout << "Impl2 is doing something\n"; } }; int main() { auto string = std::string{"Hello World"}; auto integer = 42; auto foo = Impl1<int>(); auto bar = Impl2<std::string>(); foo.doSomething(string); bar.doSomething(integer); }
Reply by ●November 6, 20182018-11-06
On 06/11/18 15:44, David Brown wrote:> On 06/11/18 16:16, Tom Gardner wrote: >> On 06/11/18 14:24, David Brown wrote: >>> On 06/11/18 13:36, Tom Gardner wrote: >>>> On 06/11/18 11:28, David Brown wrote: >>>>> On 05/11/18 19:44, Clive Arthur wrote: >>>>>> On 05/11/2018 18:01, Tom Gardner wrote: >>>>>> >>>>>> <snipped> >>>>>> >>>>>>>> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur wrote: >>>>>>>>> I'd like to know exactly what the [dsPIC] optimisers do. >>>>>>> >>>>>>> The make more assumptions that the programmer understands >>>>>>> what they've asked the computer and compiler to do. >>>>>> >>>>>> Yebbut, that's not exactly exact. Any examples? >>>>> >>>>> I am guessing he means that many compilers are more forgiving of >>>>> programmers who don't understand C if they are not optimising. A >>>>> classic example is that some people think that if you overflow a signed >>>>> integer calculation, you get two's complement wrapping if the >>>>> underlying >>>>> processor supports it (they think that "x + y" in C translates to an >>>>> "ADD" instruction in assembly). With the kind of simplistic >>>>> translation-style compilation you often get with no optimisation >>>>> enabled, that can often be correct. With optimisation enabled and >>>>> better analysis of the source code, it is frequently not the case. >>>> >>>> Yes, that's the kind of thing, but of course there are >>>> many other examples! >>>> >>>> >>>> >>>>> The C programming world is somewhat split into two kinds of >>>>> programmers. >>>>> One kind feel that the C language is defined by the standards and >>>>> implementation-specific documentation, and this forms a contract >>>>> between >>>>> the programmer and the compiler - the programmer promises to follow the >>>>> rules of the standards, and the compiler promises to give them the best >>>>> possible code on the assumption that the rules are followed. They work >>>>> with their compiler in order to get the most efficient results. >>>>> >>>>> The other kind of C programmer have a sort of "Humpty Dumpty" attitude >>>>> that "programs mean exactly what I want them to mean" and that C is a >>>>> "high level assembly". Those kinds of programmers get upset when >>>>> compilers "outsmart" them, and are continually fighting their tools. >>>> >>>> There's some truth in that, but it is far too black and >>>> white. I believe the vast majority of programmers can be >>>> described as: >>>> - want to do a good job >>> >>> There are, unfortunately, a good deal who simply want to get paid and >>> couldn't care less about the quality of their work. >>> >>>> - have some humility, but not too much >>> >>> I don't have any humility. I think it is one of my few flaws. >>> >>>> - have /some/ knowledge of their limitations and of >>>> the C/C++ tool's "quirks", and try to live within them >>> >>> Yes. >>> >>>> - aren't experts that really do understand those things >>> >>> Yes. >>> >>> But usually, they can simple avoid the quirks of C. Do you know what >>> happens if your signed integers overflow? The real answer is "it does >>> not matter". If your calculations are overflowing, then bar a very few >>> special cases, your code is broken. At best, a discussion of integer >>> overflow behaviour is a discussion of what the pieces will look like >>> when your program falls apart. >> >> And there you touch on one of the irresolvable dilemmas that >> has bedeviled C/C++ since the early 90s, viz should they be: >> - low-level, i.e. very close to the hardware and what it does >> - high-level, i.e. closer to the abstract specification of the >> specification. >> >> Either is perfectly valid and useful, but there is a problem >> when there is insufficient distinction between the two. >> > > This would all have been so much easier if people had learned what C is > and what it is for, before learning how to use it. > > C has /never/ been a "high level assembler". It has /never/ been a > "portable assembler". It has /never/ been an "alternative assembler". > > C was designed to cover a range of uses. It was designed to be useful > as a portable application and systems programming language. It was also > designed to be useful for low-level code, with implementation-specific > features, extensions and details. It was intended to be suitable for a > fair proportion of code that would otherwise need to be written in > assembler - it was intended to replace the /need/ for assembler for a > lot of code, not to /be/ assembler. > > C is a high level programming language - it is the lowest level high > level programming language. But it is not a low level language - it is > defined in terms of an abstract machine, not in terms of the underlying > hardware. > > Once you understand that, the "dilemma" disappears.I defined my use of high and low level. You are using different definitions, and to *that* extent it is a strawman argument.> You write your code in C, using the features of the high-level abstract > machine. You use - if you want - non-portable features for greater > efficiency on a particular target. And you let the compiler worry about > the details of the low-level efficiency. (But where it matters, you > should learn to understand how your compiler works and what high-level > code you need to get the results you want.) > >> >>> The people that get in trouble with undefined behaviour like this are - >>> for the most part - the smart arses. It's the people who think "I'm not >>> going to test ((x > -5) && (x < 5)) - it's more efficient to test ((x - >>> 2147483644) > 0)". >> >> That used not to be a problem, long ago. >> > > It was never a good idea - now or long ago. > > But it is true that some types of incorrect code worked with the > compilers of long ago, and gave more efficient results than correct > code. And those incorrect versions fail on modern tools, while the > correct versions are more efficient than the incorrect versions ever > were. This makes it hard to write code that is correct, works, and is > efficient on both old and new tools. > > The answer, of course, is to write correct code regardless of the > efficiency - "correct" is always more important than "fast".I definitely agree with that attitude. Too many people don't. The next question is "what is the easiest and most productive way to write correct code?", and the answer to that isn't C/C++.>> It is more of a problem since compilers have advanced to >> work around the language deficiencies, especially those >> related to aliasing, caches, and multiprocessors. >> > > What "language deficiencies" ? > >> And those points are only going to get worse now that >> Moore's "law" has run out of puff. >> >> >>>> So, despite their best intentions, it is unlikely that >>>> such users will fully comprehend the C/C++ tools limitations >>>> nor their own limitations, let alone that of other people's >>>> code and libraries. >>>> >>> >>> True. But it is rarely a problem - except for the smart-arses, who are >>> always a problem regardless of the language or its behaviour. >>> >>> People often talk about C being an "unsafe" language. That is, in many >>> ways, true - it is easy to get things wrong, and write code with bugs, >>> leaks, security holes, etc. But these mostly have nothing to do with >>> the quirks of C, or how compilers optimise. It is just thoughtless or >>> careless coding, because C requires more manual effort than most >>> languages. Buffer overflows, missing or duplicate "free" calls, etc., >>> are nothing to do with misunderstandings about the oddities of the >>> language - it is simply not thinking carefully enough about the code, >>> and the results are the same regardless of optimisation settings. >> >> Ah yes, the "guns don't kill people" argument. Being right-pondian >> (and showered with glass when a local hero took a potshot at a >> Pittsburgh tram!) that has never impressed me. >> > > I too am right-pondian, and have never been a "guns don't kill people" fan. > > But in this analogy, C is a gun. You need to learn to use it safely - > or you should not use it at all. (I have often said that the majority > of C programmers would be better off using other languages - and the > majority of programs written in C would be better if they were written > in other languages.)You have, and we agree there. But back in the real world, too many people think they are good drivers / gun owners / chainsaw swingers etc :( Now, what's the best way to achieve less danger? Just saying "don't do that" doesn't seem very effective.>>>>>> I find it frustrating that you're using a tool where the maker won't >>>>>> tell you what the little check boxes actually do. >>>>>> >>>>> >>>>> Compiler manuals often (but not always) have a lot of information about >>>>> what the optimisations do. It is rarely possible to give complete >>>>> details, however - it's just too complicated to fit in user >>>>> documentation. gcc has summaries for all the different optimisation >>>>> flags - there are /many/ of them - but it doesn't cover everything. >>>> >>>> That complexity is a serious issue. If given a piece >>>> of code, most developers won't understand which >>>> combination of compiler flag must/mustn't be used. >>>> >>> >>> For the most part, if the code requires a particular choice of flags to >>> be used or omitted, the code is wrong. There are exceptions, of course >>> - flags to pick a particular version of the C or C++ standards are >>> important. >> >> It is often required in order to achieve the touted >> performance advantages of C/C++. Without using the >> optimisation flags it isn't unreasonable to think of >> C/C++ compilers as being /pessimising/ compilers! >> > > Sure, it is usually pointless using a C or C++ compiler without > optimisation enabled. And trying to use one for development without > warnings enabled is as smart as typing your code with your arms tied > behind your back. > > But optimisations and warnings are not there for correctness - they are > there for efficiency (and to help you get correct code). If the code > requires particular flags to be /correct/, then usually you have a > problem in the code. (Again, excluding obvious ones like the choice of > standard, or the choice of target processor details.)The problem is that injudicious choice of compiler flags often makes the application (cf code) fail subtly. At that point it doesn't matter if the code or compiler is the problem. It reminds me of the apocryphal joke I first heard said with an Irish accent: "Well, sir. If you want to get /there/, I wouldn't start from /here/".>>>> Now, given that the principal actors are the users, the >>>> tools and the user's organisation, what is an appropriate >>>> behaviour for each actor? >>>> >>>> Take the time and money to become an expert? >>>> >>>> Choose simple(r) tools that do the job adequately? >>>> >>>> Ship products even though there is, despite best intentions, >>>> improper understanding of the tools and code? >>>> >>>> Refuse to use unnecessarily complex tools? >>> >>> Stick to what you know, and try to write code that makes sense. If you >>> don't know the details of how C (and your particular compiler) treats >>> overflows, or casts with different pointer types, or other "dark >>> corners" of the language, then stay out of the dark corners. >>> >>> Ask people when you are stuck. >> >> That presumes you *know* the dark corners. >> See your points above L( >> > > Programming in C requires responsibility (as does any serious > programming). With that, comes the requirement of a certain amount of > insight into your own skills. Qualified people doing useful and > productive work in programming should not be limited by amateurs > bumbling about. You don't insist that carpenters work with rubber > mallets because some muppet might hit his thumb - why do you think > programmers should be hobbled by people who don't know what they are doing?Many environments have the equivalent: with HV electricity you work with one hand in your pocket, with industrial knives you wear chainmail gloves and/or have one hand tethered to the wall behind you! But most environments find ways avoid the need for such measures.>>> Test thoroughly. >> >> Ah, the "inspect quality into a product" mentality :( >> > > No. Testing can help find flaws - it can't find a lack of flaws. But > that does not mean you should skip it!Just so :)>>> Learn to use and love compiler warnings. >> >> Always! > > Agreement at last :-)We agree on many things, but not necessarily the means of achieving them.
Reply by ●November 6, 20182018-11-06
On 06/11/18 15:57, Phil Hobbs wrote:> On 11/6/18 9:38 AM, Tom Gardner wrote: >> On 06/11/18 14:01, Phil Hobbs wrote: >>> On 11/6/18 7:36 AM, Tom Gardner wrote: >>>> On 06/11/18 11:28, David Brown wrote: >>>>> On 05/11/18 19:44, Clive Arthur wrote: >>>>>> On 05/11/2018 18:01, Tom Gardner wrote: >>>>>> >>>>>> <snipped> >>>>>> >>>>>>>> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur >>>>>>>> wrote: >>>>>>>>> I'd like to know exactly what the [dsPIC] optimisers >>>>>>>>> do. >>>>>>> >>>>>>> The make more assumptions that the programmer understands what they've >>>>>>> asked the computer and compiler to do. >>>>>> >>>>>> Yebbut, that's not exactly exact. Any examples? >>>>> >>>>> I am guessing he means that many compilers are more forgiving >>>>> of programmers who don't understand C if they are not >>>>> optimising. A classic example is that some people think that >>>>> if you overflow a signed integer calculation, you get two's >>>>> complement wrapping if the underlying processor supports it >>>>> (they think that "x + y" in C translates to an "ADD" >>>>> instruction in assembly). With the kind of simplistic translation-style >>>>> compilation you often get with no >>>>> optimisation enabled, that can often be correct. With >>>>> optimisation enabled and better analysis of the source code, it >>>>> is frequently not the case. >>>> >>>> Yes, that's the kind of thing, but of course there are many other >>>> examples! >>>> >>>> >>>> >>>>> The C programming world is somewhat split into two kinds of programmers. >>>>> One kind feel that the C language is defined by >>>>> the standards and implementation-specific documentation, and >>>>> this forms a contract between the programmer and the compiler - >>>>> the programmer promises to follow the rules of the standards, >>>>> and the compiler promises to give them the best possible code >>>>> on the assumption that the rules are followed. They work with >>>>> their compiler in order to get the most efficient results. >>>>> >>>>> The other kind of C programmer have a sort of "Humpty Dumpty" >>>>> attitude that "programs mean exactly what I want them to mean" >>>>> and that C is a "high level assembly". Those kinds of >>>>> programmers get upset when compilers "outsmart" them, and are >>>>> continually fighting their tools. >>>> >>>> There's some truth in that, but it is far too black and white. I >>>> believe the vast majority of programmers can be described as: - >>>> want to do a good job - have some humility, but not too much - >>>> have /some/ knowledge of their limitations and of the C/C++ >>>> tool's "quirks", and try to live within them - aren't experts >>>> that really do understand those things >>>> >>>> So, despite their best intentions, it is unlikely that such users >>>> will fully comprehend the C/C++ tools limitations nor their own >>>> limitations, let alone that of other people's code and >>>> libraries. >>>> >>>> >>>>>> I find it frustrating that you're using a tool where the >>>>>> maker won't tell you what the little check boxes actually >>>>>> do. >>>>>> >>>>> >>>>> Compiler manuals often (but not always) have a lot of >>>>> information about what the optimisations do. It is rarely >>>>> possible to give complete details, however - it's just too >>>>> complicated to fit in user documentation. gcc has summaries >>>>> for all the different optimisation flags - there are /many/ of >>>>> them - but it doesn't cover everything. >>>> >>>> That complexity is a serious issue. If given a piece of code, >>>> most developers won't understand which combination of compiler >>>> flag must/mustn't be used. >>> >>> Code that works on some compiler settings and not others gives me >>> the heebie-jeebies. People often talk about "optimizer bugs" that >>> really aren't anything of the sort. Of course vaguely-defined >>> language features such as 'volatile' and old-timey thread support >>> don't help. (Things have been getting better on that front, I >>> think.) >> >> Me too, but it is unclear to me that Things Are Getting Better. If >> they are it is /very/ slow and will in many cases be constrained by having to >> use old variants of a language. >> > > Well, std::atomic is an example.As I've just written in another post, C/C++ is gradually catching up with things that have been known to be good practice for 30 years and in widespread use for >20 years!>>>> Now, given that the principal actors are the users, the tools and >>>> the user's organisation, what is an appropriate behaviour for >>>> each actor? >>>> >>>> Take the time and money to become an expert? >>> >>> I don't think you have to be a certified language lawyer to avoid >>> most of that stuff. Just stay paranoid and don't try to be too >>> clever. >> >> That's my attitude, but I'm not sure it is still possible. It isn't >> just a "language lawyer", it is a "language+this compiler" lawyer. >> >> As one example, the C++ FQA (sic) has some tortuous examples. Yes, it >> is belligerent and amusing and a little outdated, but most points hit >> home :( http://yosefk.com/c++fqa/ >> > >> As another, consider that the C++ language *designers* refused to >> admit that C++ templating language was Turing complete - until Erwin >> Unruh rubbed their noses in it by getting the compiler to emit prime >> numbers *during compilation*. >> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP >> >> >> >> Key phrase: "...it was *discovered* during the process of >> standardizing..." >> >> If the language designers don't understand their language, it is too >> complex - and is becoming part of the problem. > > Nah. I understand some people like template metaprogramming, but C++ is now > more a family of languages than a single language. Few of us use all of it, and > most (including meself) don't use most of it.Ditto. I started with C in the early 80s. I wrote an app in both Objective-C and C++ in the late 80s, and realised Objective-C was far more productive and that C++ was a pain. I continued to monitor C++ in the 90s, and was gobsmacked at how fast high-quality highly-productive libraries became available for Java - and all played nicely with each other. At that time C++ was still arguing over whether it should be possible or impossible to "cast away constness, and congratulating itself on progressing beyond strings being simply char*. At that point I concluded that I never wanted to become an expert in C++.>>>> Choose simple(r) tools that do the job adequately? >> >> I must admit to wanting to go down this route. There are a few signs >> that this is becoming possible, but nothing conclusive for embedded >> programming. >> >> I hope C (and especially C++) end up like COBOL: still there, but the >> new generation has moved on to Better Things. > > >> >> >>>> Ship products even though there is, despite best intentions, improper >>>> understanding of the tools and code? >>> >>> That's bound to be the case at some level, except for simple >>> programs. >> >> True, but... >> >> >>>> Refuse to use unnecessarily complex tools? >>> >>> Or the parts of them that you don't understand. >> >> Ah, but most people /think/ they understand all the parts - until >> someone demonstrates to them that they have been bitten and not >> noticed it. > > Not in C++. I don't know anybody who would claim to understand all of it. Even > Meyers eventually bailed out.Really? Wow! I liked Meyers' style and approach, and that makes me think he has good taste as well!
Reply by ●November 6, 20182018-11-06
On 06/11/18 16:10, bitrex wrote:> The "core" of C++ is a statically-typed 1970s style C-like language that's not > intrinsically that remarkable, the other half of the language is a powerful > compile-time metaprogramming language you use to fashion the bits of the "core" > into zero-overhead abstractions.The variables are typed. The data is untyped. That's necessary to allow you to cast a Camel into a PaintPot.> Virtual methods have their place even in uP development but it makes sense to > use them sparingly particularly on the Harvard architecture with limited SRAM; > the standard insists on copying all vtables out of Flash into SRAM at runtime > even though in theory this should not be necessary.Wow. Really? Yuck.
Reply by ●November 6, 20182018-11-06
On 06/11/2018 16:11, Tom Gardner wrote: <snipped>> The main reason C/C++ continues to be used is history: > there's a lot of code out there, and people are familiar > with (old versions of) it. Ditto COBOL.My experience is different. History, as in existing code, is of little use to me. Existing code which I do use is assembler, eg FFT routines. I use C because the customer demands it, and that is because it is what they learned at college. Luckily, it's only a small part of what I do - with constrained resources, all the DSP bits are assembler. The customer sees C and is happy. Cheers -- Clive
Reply by ●November 6, 20182018-11-06
On 11/06/2018 11:43 AM, Tom Gardner wrote:> On 06/11/18 16:10, bitrex wrote: >> The "core" of C++ is a statically-typed 1970s style C-like language >> that's not intrinsically that remarkable, the other half of the >> language is a powerful compile-time metaprogramming language you use >> to fashion the bits of the "core" into zero-overhead abstractions. > > The variables are typed. The data is untyped. That's necessary to > allow you to cast a Camel into a PaintPot. > > >> Virtual methods have their place even in uP development but it makes >> sense to use them sparingly particularly on the Harvard architecture >> with limited SRAM; the standard insists on copying all vtables out of >> Flash into SRAM at runtime even though in theory this should not be >> necessary. > > Wow. Really? Yuck.at least with gcc it seems to be the case. "This cannot be fixed in GCC as C++ doesn't support ISO/IEC DTR 18037 named address spaces. This feature requires that the C++ front-end knows about ASes and handles them properly. This doesn't imply that ASes are exposed on language level; knowing about ASes "internally" would be sufficient. As it's pretty much clear that C++ WG21 will never accept such qualifiers (not even the C WG14) did, just close this as WON'T FIX. All that can be done is proposing work-arounds: Use "Embedded-C++" coding convention that avoids VTABLEs, or use a device that can host .rodata in flash like families -mmcu=avrtiny and -mmcu=avrxmega3." ref: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745>
