Competing with "Free" Software

Tough Survivors

As I said in the last blog entry, independent embedded C/C++ compiler companies are becoming rare birds. Of the independent companies that support multiple platforms, besides us ImageCraft, there are Green Hills (US), IAR (SE), Cosmic (FR), Rowley (UK), and… um, I think that’s it. Since being bought up, Hiware/Metrowerks primarily target Freescale chips; Hi-Tech clearly will concentrate only on Microchip’s PIC; Keil, despite being an “ARM company,” still sell tools for the 8051, C166 etc. probably because the money is good, but who knows how long that will last?… Most  if not all compiler companies were started by compiler gearheads (who else would be crazy enough to start a compiler company?) a while ago. In fact Cosmic and ImageCraft are tangentially related through our lineage with Whitsemiths. With the different product pricing and the vast number of embedded devices, most of us in fact do not compete directly with each other per se. However, there is …

The GCC Equation 

(dun dun duuuuunnnn…..)

Different embedded compiler companies “die” for different reasons, most likely financially related, and in 2009, the GCC equation must be a factor directly or indirectly. (Click on …more… to continue)

A one paragraph summary of GCC (GNU Compiler Collection, previously known as the GNU C Compiler back in 1985 when I was arguing with Richard Stallman why it’s a bad idea and he argued why I should join in the Cause) is this: GCC is a high quality compiler collection that is free to use if you agree with its terms (the GNU Public license or GPL). The base GPL stipulates that under some conditions, you grant your users certain rights  (“Freedom”) to your code. A less restrictive LGPL license gives you more freedom on what you need to release. As each GPL release takes months of Stallman’s time to write, I’d not attempt to summarize or interpret them beyond the above, as any such attempt would be inaccurate (as surely would someone say that I already mis-characterized GCC in the above). Interested parties should visit http://fsf.org instead.

GCC is used in many embedded projects. While anyone can build their own GCC binaries, you can download them pre-built and in some cases, some commercial vendors would sell you GCC with support, or with their own IDE, or libraries etc. GPL does not restrict you from making money per se, even selling GCC if you wish (finding customers is of course a different story).

It’s tough to argue for buying a multi-thousands ARM compiler when GCC is Free. So how does one compete with Free, regardless whatever license restriction it may or may not have? Different companies have different solutions, and after looking at this problem for a while, this is what will do:

The 8-bit Solution

Despite a movement to adopt 32-bit architectures, there will continue to be a big market for the 8-bit (and 16-bit) MCUs. This is the market where GCC does not excel in due to the inherent limitations of the GCC compiler architecture. So, to be more successful in this market, we will need to take advantage of GCC’s weakness and optimizes better. For the AVR, we are already better than GCC code quality wise but competing against Free is still tough. What this means is that we will be implementing mixed pointer qualifiers (e.g. __far, __near, __huge etc.) and generate optimal code for each type of pointer access. As 8 bit MCUs typically have different address space, this will be a big win. For the AVR, this means better control of flash data, especially for the XMega (GCC doesn’t support the simple flash space well already and the XMega will definitely stretch GCC’s limit); for the Cypress PSoC1 M8C (if we were to reenter the market), this means much better code density for data access.

Some compilers implement whole program analysis to support mixed pointer usage, but we believe that the programmers can give better guidance in most cases, resulting in a more robust compiler. Embedded programmers who are concerned about code size know their stuff well.

The 32-bit Solution

For the 32-bit, we already have an ARM/Thumb compiler and the Propeller C compiler. Nothing needs to be done about them. However, it does not make sense for us to compete with the free GCC on potentially new targets such as the AVR32 and the ARM Cortex. As our resource is limited, in this space, we will leverage GCC and give commercial users a better solution by integrating GCC with our simple to use IDE and Dinkumware’s rock solid C/C++/EC++ Library. This eliminates any possible encumberment for the users from LGPL, thus providing values to our customers. This also frees up resource so that we can work on software stacks (e.g. eMOS, SD/File System, etc.) for the targets, giving our customers a complete solution. Or may be even porting to OSX or Linux etc.

We will continue to keep our pricing competitive and tools easy to use. GCC presents a challenge, but then again, each challenge presents an opportunity. Life is never boring.

// richard

13 Comments

  1. steve williams says:

    Hi Richard, I recently purchased your ICCARM7 compiler and NOICE package to use with Atmels AT91SMA7X256. I already use your ICCARV compiler all be it an older V6 copy. I discovered that I have to write my own header files and some supporting modules as ICCARM7 supports AT91SAM7S. Ok I am in the process of doing as I write this message. So my question is what does this mean for me and have I wasted my money and time only to have to do it again. Because that would mean I would definitely have to look at something like Yargarto for ARM as I could not justify any further expenditure. Don’t get wrong I like your products but need guidance on the next step.
    REgards Steve

    • imagecraft says:

      Hi Steve, this has no effect on our existing ICCARM compiler. For the ARM7, we will fill out the support by releasing more header files for common devices and add features like 64-bit double floating point support when resources is available. We have also started an eMOS port for ARM.

      Cortex is a different core. They show up as the STM32 and LPC1000 etc. Unfortunately, it does require a different code generator as there are sufficient difference in the instruction set and registers. When we support Cortex in the future, we will likely use the strategy outlined in the blog.

  2. steve williams says:

    Thanks for replying to my concerns, that certainly clears things up for me. I should have waited till today to reply to your blog as it about 11:30pm when I read the blog and it’s contents did not really sink in before I replied. The old adage engage brain before putting mouth into gear should have prevailed.
    I will have the AT91SAM7X256.H header file finished in the next few hours, I will then test it and send you the header and test files for your perusal and if you feel they are ok you can publish them if you like.
    Regards Steve

  3. Terry Painter says:

    I frequently visit this site to read your blog and the statement that piqued my interest is that you are considering porting Imagecraft’s IDEs and compilers to the Mac OSX. Count me as another person who would very much like to purchase Imagecraft’s IDEs and compilers that execute on a Mac running OSX Leopard. I favor this OS. I want to use my Mac to develop code for the TI MSP430, the ARM and the Parallax Propeller. The following statement that I have read on this website : ‘This site was created on a Macintosh’, clearly suggests that Imagecraft also favors the Mac for developing code. Please let me know if there is any chance of this happening.
    Sincerely Terry

    • imagecraft says:

      There is definitely a chance as we love Mac! The compiler proper itself can be ported to Mac OSX or Linux easily. However, the IDE is not. While it’s arguable that in fact the IDE is useless for some people, we still do need some minimal support for project management and easy device selection. We are, however, continue to explore solutions.

    • imagecraft says:

      Our current focus is looking at code::Blocks. We will see how it goes.

      Yes, we like Mac. We also have customers using our compilers on the Mac using Parallel and other VM with success.

  4. Senya says:

    Eclipse with CDT feature offers you an IDE one could possibly dream of for free. Definitely it would take ages for you to build what IBM has bin building for years, so why not focus on what you are definitely good at and what’s your competitive advantage and just bundle it with freely available IDE?
    I am considering purchase of your HCS12X compiler but definitely I’ll be using Eclipse & GNU make. Because its free and it makes transition to other compiler/microprocessor language much faster.

    • imagecraft says:

      We are definitely looking at leveraging Open Source solution. In our opinions, Eclipse is not quite there yet due to the resource requirements. I understand it runs well on most modern machines, but we have customers using netbook, older laptops, VMs etc. that make it not the best choice — yet. May be in another year or two, it would be different.

      Regardless, we will always make it possible for people who want to use Eclipse, or makefile, etc. to use our compilers.

      // richard

      • Petro says:

        If you solution limited only Windows platform mayb Visual Studio Shell will be a better choice.

        That do you think about llvm.org/ project?
        It can be a great platform for creating your own compiler, but I’m not shure how it fit into MCU architecture.

  5. C.W. says:

    Hi! I have something to do *ahem* with/at ImageCraft, and I work almost exclusively on a Mac. So, yes, we definitely do like Macs, and we have long had the idea (since the early 90′s at least!) that it would be very nice to have Mac versions of our products. :)

  6. TS says:

    Hi Christina and Richard,

    I’m running more Macs than PCs now, but there is one major drawback to run any of your cross compilers on Mac OS X: The complete toolchain. On the Mac I can use VMWare or Parallels to run Windows, but would I really?
    I’m running Imagecraft software on Windows PC because of: Atmel (AVRStudio), most hardware debuggers support only Windows as do software debuggers (NoICE), most vendors support Windows (Freescale, Atmel, Cypress, any ARM-based manufacturer). If you include in the toolchain the SDT/PCB/Simulator/FPGA software, they are all on Windows as well (as I found only partial solutions on Mac so far). I also do have lots of legacy tools on Windows.
    So what advantage will that have to offer any Imagecraft compiler on OSX?
    So in this case I vote against OS X, although I love it for much other things, especially for application software!

    // Thomas

  7. Tony Stram says:

    I have played with code::Blocks a bit. It seems to have all the basic features I need in an IDE, and looks modern. It has the ability to have plugins, so maybe that would be easier for Imagecraft to develop rather than a whole new IDE. After using code::Blocks, the layout is similar enough to Eclipse that I would not mind using it. Currently, I have benn using Eclipse/GCC for developing some projects. The reason for this is I am tired of have to learn a new IDE everytime I have to work with a different micro. To me it would be great to have a consistant look and feel in my IDE.

    I would vote for you to leverage Eclipse, but if it is too bloated for low end machines, then my second choice would be code::Blocks. As a side note, I have Eclipse running on an old laptop with a Pentium 4 1.8GHz, 512MB RAM, 60GB hard drive, and XP Pro SP3.

    I do agree with you wanting to modernizing the IDE. If leveraging an open source project will help, I am for it. Anyway, that’s just my opinion.

Leave a comment