On 05/11/18 17:03, speff wrote:> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur wrote: >> On 04/11/2018 22:45, speff wrote: >>> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex wrote: >>>> I might have to work on a project involving dsPIC code which I don't >>>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>>> >>>> What's the hip current toolchains/dev boards y'all like to use for PIC >>>> development on Linux or Windows desktops nowatimes? >>> >>> MPLAB-X with their compiler XC-16. It's a bit greedy with resources but okay on a modern machine. There is a free version with no optimization. I am not sure how well the DSP functionality is supported by the compiler, we just used it as a relatively fast 16-bit micro. >> >> I've used the old MPLAB with C30 compiler on dsPICs extensively, though >> my DSP code is in assembler. The optimisers don't seem to do very much, >> Maybe because of the way I write C - certainly code size hardly varies >> between the four levels of optimisation and even goes the wrong way >> between two adjacent levels. >> >> Even with full optimisation, / 2 on an unsigned integer gets compiled as >> an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking >> pathetic. >> >> I've used MPLAB-X with XC-16 too because some newer dsPICs aren't >> supported by the old version. It's very slow to start up, no idea why >> except that so much modern software is shite. IIRC it does have one >> level of optimisation on the free version. >> >> I'd like to know exactly what the optimisers do.The make more assumptions that the programmer understands what they've asked the computer and compiler to do.> I vaguely recall someone analyzing the code and it was "almost" as if they > were deliberately making it use more instructions in the non-optimized version.You need to compare that with unoptimised code for other machines/compilers.
PIC/dsPIC development
Started by ●November 4, 2018
Reply by ●November 5, 20182018-11-05
Reply by ●November 5, 20182018-11-05
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 find it frustrating that you're using a tool where the maker won't tell you what the little check boxes actually do. Cheers -- Clive
Reply by ●November 5, 20182018-11-05
On 05/11/18 18: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?Far too many to list. As one example, start by understanding why /all/ the compiler and linker options are there, and what effect they might have. If you need to choose a compiler, use gcc. N.B. I have zero experience with the PIC devices. I looked at /one/ once and decided that it would be difficult for a C compiler to generate good code for it. AVR looked better in that respect. Yes, that is merely one small datapoint in a vast mass of greyness. I thought of it as a burglar would think of a burglar alarm or dog: a sign to move to easier territory.> I find it frustrating that you're using a tool where the maker won't tell you > what the little check boxes actually do.Yes.
Reply by ●November 6, 20182018-11-06
Oh, that's neat. Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/ "bitrex" <user@example.net> wrote in message news:QuYDD.342307$ql2.336820@fx06.iad...>> Try https://godbolt.org/ you can drop some of your C or C++ code into the >> box and see the asm output for many different compilers for many >> different targets at whatever optimization level, PIC is not one of them >> but it includes ARM, MIPS, AVR and MSP430 compilers. > > It also shows a record of the compiler's passes and steps in the process > of compiling the code, as it breaks the code down from high level to asm > over many passes you can see how it examines and tags the structure of the > code, organizes things into functional blocks, and then attempts to > optimize them >
Reply by ●November 6, 20182018-11-06
On 11/05/2018 03:06 PM, Tom Gardner wrote:> On 05/11/18 18: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? > > Far too many to list. > > As one example, start by understanding why /all/ the compiler > and linker options are there, and what effect they might have. > If you need to choose a compiler, use gcc. > > N.B. I have zero experience with the PIC devices. I looked > at /one/ once and decided that it would be difficult for > a C compiler to generate good code for it. AVR looked better > in that respect.It's a somewhat perverse ISA that seems specially designed for folks who like to hand-write asm and get a big kick out of figuring out some trick that allows them to shave three clock cycles off a linked-list traversal or somethin'. Yawn...> Yes, that is merely one small datapoint in a vast mass > of greyness. I thought of it as a burglar would think of > a burglar alarm or dog: a sign to move to easier territory. > > > >> I find it frustrating that you're using a tool where the maker won't >> tell you what the little check boxes actually do. > > Yes.
Reply by ●November 6, 20182018-11-06
On 06/11/18 06:54, bitrex wrote:> On 11/05/2018 03:06 PM, Tom Gardner wrote: >> On 05/11/18 18: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? >> >> Far too many to list. >> >> As one example, start by understanding why /all/ the compiler >> and linker options are there, and what effect they might have. >> If you need to choose a compiler, use gcc. >> >> N.B. I have zero experience with the PIC devices. I looked >> at /one/ once and decided that it would be difficult for >> a C compiler to generate good code for it. AVR looked better >> in that respect. > > It's a somewhat perverse ISA that seems specially designed for folks who like to > hand-write asm and get a big kick out of figuring out some trick that allows > them to shave three clock cycles off a linked-list traversal or somethin'. Yawn...Yes, that pretty much matches my recollection. Probably arose as a classic case of hardware engineers doing what was easy/cheap for them, and expecting software to work around their mess. I realised 40 years ago (gulp) that the tools were more important than the ISA, and haven't cared much about ISAs since the mid 80s. Having said that, I have my limits - particularly where an ISA makes tools difficult.
Reply by ●November 6, 20182018-11-06
bitrex>>>>> 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? >> >> Far too many to list. >> >> As one example, start by understanding why /all/ the compiler >> and linker options are there, and what effect they might have. >> If you need to choose a compiler, use gcc. >> >> N.B. I have zero experience with the PIC devices. I looked >> at /one/ once and decided that it would be difficult for >> a C compiler to generate good code for it. AVR looked better >> in that respect. > >It's a somewhat perverse ISA that seems specially designed for folks who >like to hand-write asm and get a big kick out of figuring out some trick >that allows them to shave three clock cycles off a linked-list traversal >or somethin'. Yawn...You are totally clueless. I often I do not understand all the crap that goes round about instruction sets. It is, when basics are present, no different from any other. Turing machine or what was it. IF you know the problem at hand AND know the solution what f*cking difference does it make to write a series of commands to achieve that solution. Lemme put it a bit simpler, maybe your wetware can grab it a bit better then: A computah language is very much like a normal language. I speak 4 or 5 languages, English for example is not my native language Many people speak languages, most in fact (I suppose ;). WHAT YOU SAY IN IT IS WHAT MAKES THE DIFFERENCE. Some languages are simpler than others, English being Ferry Zimple for example. In all those languages how to tell somebody to go from A to B on a map is 'go left' 'go right' 'next turn left', etc etc, now in German, now in French, Now in Dutch, Now in ... It is not the words, it is the knowledge. It makes no f*kcing (2 second time f word) difference what language, you are still an idiot if you give the wrong directions and things get lost. The language wars and 'my dialect is so much better than yours' and your dialect is 'perverse' (quoting you), is a sign of the extreme stupidity and misunderstanding YOU have. Now go and play with your see shit,. Signed Bye Mee Just read the f*cking datasheet, INCLUDING the instruction set, write some code in asm, and if that is to difficult for you learn snake language (what's it Rattle or Python or whatever), and buy an raspberry. Is is more work, needs more resources, is more expensive, is slower, is more error prone, less predictable, and does not cover the peripherals. Now you have nothing and feel like an emperor. In plain language referring to the map and directions above, take a bus or taxi. No guarantees though, last time I took a taxi in Eindhoven it got lost, thanked the driver, payed him, asked some locals and walked, Was on time. YMMV. LOL There is a humor in this,
Reply by ●November 6, 20182018-11-06
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. 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.> > 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.
Reply by ●November 6, 20182018-11-06
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. 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?
Reply by ●November 6, 20182018-11-06
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.)> 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.> > 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?That's bound to be the case at some level, except for simple programs.> > Refuse to use unnecessarily complex tools?Or the parts of them that you don't understand. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
