embeddedgurus.com: "An open letter to the developers of the MPLAB IDE"

[mariush]

A compiler without optimisation is not a compiler. It is crippleware because you can't use it for any serious project. Hence there is no free C compiler for 8 bit PIC. Hence Microchip's success doesn't come from providing free tools.

You have a funny definition for a compiler.

A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code).[1] The most common reason for wanting to transform source code is to create an executable program.

The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine code). If the compiled program can run on a computer whose CPU or operating system is different from the one on which the compiler runs, the compiler is known as a cross-compiler. A program that translates from a low level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter. A language rewriter is usually a program that translates the form of expressions without a change of language.

A compiler is likely to perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis (Syntax-directed translation), code generation, and code optimization.

http://whatis.techtarget.com/definition/compiler

A compiler is a special program that processes statements written in a particular programming language and turns them into machine language or "code" that a computer's processor uses. Typically, a programmer writes language statements in a language such as Pascal or C one line at a time using an editor . The file that is created contains what are called the source statements . The programmer then runs the appropriate language compiler, specifying the name of the file that contains the source statements.

When executing (running), the compiler first parses (or analyzes) all of the language statements syntactically one after the other and then, in one or more successive stages or "passes", builds the output code, making sure that statements that refer to other statements are referred to correctly in the final code. Traditionally, the output of the compilation has been called object code or sometimes an object module . (Note that the term "object" here is not related to object-oriented programming .) The object code is machine code that the processor can process or "execute" one instruction at a time.

Optimization is NOT a requirement, it's just an optional feature. It's a nice to have feature, but it's just that.  Just because you think it's a must, doesn't make it so.

[neslekkim]

especially as the 8 bit architecture is so terribly inefficient anyway.

how?
For it's use, it doesn't seem so "inefficient", you don't choose 8bit today for big tasks, and you shouldnt choose big platforms for small tasks, so for it's use, I think it is more than adequate.

[hans]

I think he refers to the general architecture of the PIC18 and downwards devices, which fall all under the XC8 compiler.

The non-C style instruction set, limited hardware stack, banked RAM, only 1 accumulator register means it's not very efficient.
It's like a person with 1 wounded arm & no trouser pockets. Imagine how your days will become.. you'll always have to put stuff down and pick it back up and basically can't "multi task".
The Hi-Tech (XC8) compiler is reasonably good at allocating these "items" though.. it does a call tree analysis to see which variables overlap and which don't, and use as little RAM for local variables and function arguments.

But it's still wounded.

This is basically a non-issue for software stack these days, because you can just keep push-ing and pop-ing things to and from the stack and only have to worry you don't mess up the stack alignment, and that it's large enough in the most deepest/largest call made.

And I think mentioned earlier here, this architecture combined with 1 accumulator, is why the XC8 is such a specific compiler for this platform and there is no GCC port.

As an example, I think this is what he means with inefficient:

Code: [Select]

  4815                           ;client.c: 118: packet->packet.data[0] = 2;
  4816  0303  0835                movf HandlePacket@packet,w
  4817  0304  3E06                addlw 6
  4818  0305  0086                movwf 6
  4819  0306  3002                movlw 2
  4820  0307  0187                clrf 7
  4821  0308  0081                movwf 1
  4822  0309                     l2540: Ouch, 6 words for just a deadsimple pointer operation, even in "PRO" mode!

Where as this takes 2 instructions on a PIC24 (like any modern core that's optimized for C work) chip:

Code: [Select]

22:                                packet->packet.data[0] = 2;
004864  B3C024     MOV #0x2, W4
004866  984474     MOV.B W4, [W8+7]

[nctnico]

The first problem you run into on an 8 bit platform is speed (been there, done that). Having the best compiler is crucial to have any chance of finishing a project in a reasonable time. IOW not getting stuck / sidetracked with endless hand optimisation or writing assembly code because that is just frustrating in the end even if it is a hobby project. Using something else is easier said than done. I've seen kludges with over 10 PICs to do a job which a faster 32 bit controller did much better.

[dannyf]

A compiler without optimisation is not a compiler.

That's why it is important to have a common set of definitions before stating your positions.

To me, a compiler isn't a compiler unless it can toast my bread to my satisfaction, .

So whatever compiler there is to your fancy, it is not a compiler.

[dannyf]

The first problem you run into on an 8 bit platform is speed (been there, done that).

I thought the first problem on any platform is to find a qualified programmer who knows how to pick the right part for a given job.

[dannyf]

Yet there are probably millions of products out there with 8b PIC's in them. Go figure.

Many times, I run my 8-bit chips at less than 1Mhz, because otherwise it would be too fast.

[22swg]

Looking back several decades to build it yourself you started in machine code mine was an 8b RCA cmos cpu , in those days you needed  external ROM and RAM plus peripherals driver chips CRT, UART, floppy etc. and you had the chicken / egg  complication of getting a boot subroutine into eeprom, after spending big bucks on Z80 and 6502 imagine the joy of finding cheap mcu’s with a host of features that just fitted the home brew hobby  I am OK with MPLAB X and recently the PIC24 plus the free tools. Perhaps if the moaners had struggled to get a a single LED to light  then…   

Should be an attach from Elektor Magazine Aug 1978   ... "2716 UVPROM 40GBP !!!! "

[dannyf]

Perhaps if the moaners had struggled to get a a single LED to light  then…   

Those moaners are too interesting in moaning to light up a led.

Should be an attach from Elektor Magazine Aug 1978   ... "2716 UVPROM 40GBP !!!! "

Good old days of electronics.

[JTR]

As an example, I think this is what he means with inefficient:

Code: [Select]

  4815                           ;client.c: 118: packet->packet.data[0] = 2;
  4816  0303  0835                movf HandlePacket@packet,w
  4817  0304  3E06                addlw 6
  4818  0305  0086                movwf 6
  4819  0306  3002                movlw 2
  4820  0307  0187                clrf 7
  4821  0308  0081                movwf 1
  4822  0309                     l2540: Ouch, 6 words for just a deadsimple pointer operation, even in "PRO" mode!

Where as this takes 2 instructions on a PIC24 (like any modern core that's optimized for C work) chip:

Code: [Select]

22:                                packet->packet.data[0] = 2;
004864  B3C024     MOV #0x2, W4
004866  984474     MOV.B W4, [W8+7]

Well that is sort of a misleading comparison. The code for the PIC24 assumes that the pointer is already in W8 while the code for the enhanced mid-range pic does not assume the pointer is in FSR1 and uses extra instructions to place the pointer there.
 
If the pointer was in FSR1 already (apples to apples comparison) then the code could be as simple as:

    movlw   2
    movwi   6[FSR1]

Of course, one could rightly argue that the poor register set of the enhanced mid-range pics means that it was far less likely that the pointer base would be preloaded in (only one of two) base index registers so the original comparison is right in a "typical" context. Still, if one is providing benchmarks there is a need to provide all the details required for a meaningful context. 

[andersm]

From the XC8 v1.32 release notes:

New Free-mode optimization An additional optimization has been added to improve removal of redundant bank selection instructions when using Free mode. The effect of this optimization will only be observable when the assembler optimizers are enabled.

I have no idea how much this actually improves the generated code, but I guess sometimes complaining on online forums does help.

[mariush]

I don't see any significant change between 1.31 and 1.32 just comparing assembly of a project.

Program space and data space usage are exactly the same. 

The only difference I notice in the assembly listings is some changes in the floating point multiplication functions xc8 includes, some optimizations for speed there and some tweaks for PIC18F mcus.


There was really a good jump from 1.30 to 1.31.. 1.30 does have a lot of useless MOVLB  and CLRF counter instructions (mostly) which don't show on 1.31 anymore.

Here's the usage to compare... 

Code: [Select]


Microchip MPLAB XC8 C Compiler (Free Mode) V1.30
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration

:: warning: (1273) Omniscient Code Generation not available in Free mode

Memory Summary:
    Program space        used   CAFh (  3247) of  4000h words   ( 19.8%)
    Data space           used    87h (   135) of   400h bytes   ( 13.2%)
    EEPROM space         None available
    Data stack space     used     0h (     0) of   2A7h bytes   (  0.0%)
    Configuration bits   used     2h (     2) of     2h words   (100.0%)
    ID Location space    used     0h (     0) of     4h bytes   (  0.0%)


Running this compiler in PRO mode, with Omniscient Code Generation enabled,
produces code which is typically 40% smaller than in Free mode.
The MPLAB XC8 PRO compiler output for this code could be 1089 words smaller.
See http://microchip.com for more information.

---

Microchip MPLAB XC8 C Compiler (Free Mode) V1.32
Part Support Version: 1.32 (A)
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration

:: warning: (1273) Omniscient Code Generation not available in Free mode

Memory Summary:
    Program space        used   C7Eh (  3198) of  4000h words   ( 19.5%)
    Data space           used    80h (   128) of   400h bytes   ( 12.5%)
    EEPROM space         None available
    Data stack space     used     0h (     0) of   2AEh bytes   (  0.0%)
    Configuration bits   used     2h (     2) of     2h words   (100.0%)
    ID Location space    used     0h (     0) of     4h bytes   (  0.0%)



[SirNick]

I've looked at PICs a couple of times but there wasn't really anything compelling to draw me away from AVRs.  Having read how much of a fiasco the compiler situation is, I'm apparently not missing much.  The MCU market is pretty much a commodity at this point.

Not much new to add really, but I echo these sentiments:  I can use GCC for x86.  I can use it for AVR8 and Xmega.  I can use it for Cortex M.  I can use any IDE (or not) that I want for any of the above, and have no concerns over missing out on optimizations, or how many computers I can legally install the compiler on.  In many cases, there are a lot of pre-written libraries available too.  Those vendors have worked in-house, and with the OSS community, to make free, optimized tools available so I can focus my resources on the application.

Chip vendors are starting to make it as easy and inexpensive as possible to evaluate, learn, and build with their hardware.  I think that's worth noting.  For sure, Microchip isn't obligated to offer their premium compiler (compilers, which is just baffling) for free, but if they could instead recoup their development cost by charging a couple cents more per chip (or harness the OSS community to do it for them, in exchange for no more than open communication and well documented specs), then it could be much better in the long run than sticking to old business models.

Times have changed.  It may not be fair, or logical, but if you throw the hobbyests or product architects a bone, your chip is the first they'll think of to solve some problem.  The resulting product may or may not ultimately end up in high-volume production, but some will.  That has the potential to be far more lucrative than a relatively small number of $1k license fee sales.

Remove barriers anywhere you can.  That's what all the free compilers, free libraries, low-cost development / eval boards, low-cost programmers, low-cost debuggers, app notes, seminars, YouTube videos, vendor-sponsored forums, and tradeshow presences are all about.

[dannyf]

I have no idea how much this actually improves the generated code

I have XC8 1.12 and some benchmarking I have done (against  PICC9.60std and 9.65pro) suggests that the free mode is faster than the std and closer to the pro.

[dannyf]

I've looked at PICs a couple of times but there wasn't really anything compelling to draw me away from AVRs.

It is very difficult to justify using a low-end PIC (12/16/18f parts) on new designs: there are simply more superior alternatives out there.

The AVRs offer a better interrupt controller, faster speed, and more consistent peripherals. But they are more expensive as well.

The STM8 is cheaper and more capable, some of them offer a better roadmap to 32-bit chips, at a lower price point. They have however an uncertain future.

The CM0/1 chips are really attractive, particularly if you already have the code base migrated. They post a considerable threat on new designs. But the learning curve can be steep.

[WarSim]

I'm not dreaming; I see no new projects that are pic based compared to the numerous ones that are arduino based.

I would not even consider using a pic in an opensource project simply due to the fact that the tools are not free and not nearly as functional as they could/should be.

the ones using pic are the ones told to use it at school or industry.  I know of no one that starts out picking the pic anymore.  its used by pros (who have the expensive tools) but rarely by new guys starting out.

if you have info to show otherwise, bring it.  else, it seems pretty obvious if you just take a look at a place like hack-a-day (etc) and see how many pic submissions are there vs atmel.  pic is rarely even mentioned anymore and that's a fact.

I have made many PIC based projects, but I have never posted on hack-a-day.  Most likely I never would.  I use the right processor for the task.  I do not distinguish a project by the uC used.  My projects are defined by what they do not by what they use. 
All my DIY projects with PICs used the free compiler versions.  Optimizers are not required to produce excellent code.  Optimizers are just a tool to make it easier/faster.  In my opinion the only people that need optimizers are corporate users where time is money or needed to even out the various skill levels. 
Nobody should start a project with picking a uC.  The uC supplies the required functions not the other way around.  My DIY uC selection is based on package and capabilities.  It really doesn't matter who makes the uC as long as they have a free tool chain.  Even better if it is MacOS friendly. 
I have never used PICs in school.  30 years ago PIC wasn't used in schools. 
Call me a pro if you wish but I don't use Microchips expensive tools for my DIY projects.  The only reason work has the optimized licences is because government is disqualified from using the free tools. 
The only thing I see is there is a resurgence of Atmel users and they want to show off their projects.  I don't know a single PIC user that has the desire to post their projects on what I consider a vanity site. 


Sent from my iPad using Tapatalk

[andersm]

I have no idea how much this actually improves the generated code

I have XC8 1.12 and some benchmarking I have done (against  PICC9.60std and 9.65pro) suggests that the free mode is faster than the std and closer to the pro.

Congratulations, now explain how that is in any way relevant to the effect of a specific change made in XC8 version 1.32.

[dannyf]

The only thing I see is there is a resurgence of Atmel users and they want to show off their projects.

Think so too.

[SirNick]

That's probably true, but so what?  The web has always had its share of vanity.  You know this if your eyes have ever been assaulted by a personal home page with an animated Under Construction GIF.  Yeah, all these project sites are almost entirely fluff, but that's OK.  Some of those enthusiastic engineer-larva will eventually mature to something interesting.  Most will not, but such is life.  I doubt that's distinct to AVR fans, although they are perhaps a bit more accessible, therefore lowering the bar a smidge.

What this has to do with the greater scheme of things is beyond me.  I really hope it's not an attempt to bash a perfectly good architecture on the sole basis of its trendiness.  (If so, shall we also shun the 555, TL071, LM7805, BC549, and 1N4148?)

The PIC line is too quirky for my taste, but as Danny pointed out, there is good value there.  I would like to see MC step up, sort out their development hassles, make it trivial to evaluate and design with their parts, and let the hardware run at its potential best.  Even in the hands of amateurs.

[WarSim]

All my DIY projects with PICs used the free compiler versions.  Optimizers are not required to produce excellent code.  Optimizers are just a tool to make it easier/faster.  In my opinion the only people that need optimizers are corporate users where time is money or needed to even out the various skill levels.

An optimizer isn't what you seem to think it is. Without a basic optimizer your code will suck and be hard to debug at assembler level. A good one really helps when using parts with small memories too, as they can often reduce code size by 50% or more. The only alternative is trying to optimize your C code to generate better assembler, which is gong to make it suck.

Nobody should start a project with picking a uC.

That's generally what we do at work. Obviously not in isolation to anything else, but we look at the requirements for the system and decide which microcontroller best fits after sketching out the rest of the system. Since our projects can get quite large it is important to get the right peripherals and features, and avoid things that are going to make the code suck.

Sent from my iPad using Tapatalk

That's no excuse.

That is a very odd thing to say to a Systems Analyst.  The people who create the optimizers for compilers.   


Sent from my iPad using Tapatalk

[dannyf]

I did a comparison between 1.12 and 1.32, on a piece of code I have. The stats below are the total code size and execution of the main loop:

1.12 free: 2759 bytes / 5194 ticks;
1.12 pro+space: 1832 bytes / 5385 ticks;
1.12 pro+speed: 2114 bytes / 5323 ticks;

1.32 free: 2497 bytes / 7725 ticks.

[miguelvp]

All programmers take systems analysis and design, so we are all systems analysts, it's part of the curriculum.

So the people that make compilers are system analysts but not all system analysts make compilers. Also all system analysts write code unless you are on a big corporation and you are director of technology but even then you tend to write code as well, not as much but more critical stuff and/or mentor others. So unless you went to full management you still write code or at least review the code of your team.

As far as the computer titles go, system analyst as a title is about the lowest you can get. That was my title on my first job ever system analyst I.

[WarSim]

All programmers take systems analysis and design, so we are all systems analysts, it's part of the curriculum.

So the people that make compilers are system analysts but not all system analysts make compilers. Also all system analysts write code unless you are on a big corporation and you are director of technology but even then you tend to write code as well, not as much but more critical stuff and/or mentor others. So unless you went to full management you still write code or at least review the code of your team.

As far as the computer titles go, system analyst as a title is about the lowest you can get. That was my title on my first job ever system analyst I.

Very true. Only a Programer Analyst or Entry Clerk is lower.  The former works on a module and may never see how it fits onto the larger scheme.  The latter may never program at all, if they do it would likely be scripting. 



Sent from my iPad using Tapatalk

[BloodyCactus]

since were talking microchip compilers in here

upgrading to xc32 v1.32, the good old 'return 2' xclm trick no longer works... just an FYI.

The source for v1.32 has not been released yet,
http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html

changing the 1.31 download link to 32 works.
http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip

[Rufus]

changing the 1.31 download link to 32 works.
http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip

Microchip complier development is managed by loons.

The trivially easy to bypass licensing scheme got slightly harder. Paying customers as well as having the hassle of activation and/or running license servers get to wait a bit longer as every compiler invocation now generates an SHA256 hash of the 900kB licensing executable.

What I found interesting in the 1.32 source archive was a document containing this

The will allow the student edition to continue to support new devices
without requiring a re-build and underscore the philosophy that improved
functionality is only made available to paying customers (and to the
student edition in greater intervals)

Regarding .info files which decouple processor specific information from the compiler executables.

Why the hell do Microchip produce compilers at all if it isn't to support sales of their processors and here we see a 'philosophy' which requires customers to pay extra (through the annual HPA maintenance crap) if they want to use new parts. Support for new parts isn't improved functionality it is a basic requirement to use those parts and the last thing Microchip should be doing (if they want to sell) is placing financial barriers between customers and those parts.