Just Work, Baby

I use Microsoft Windows on my laptop.  I used to use Linux.  In fact, I used to work really hard to make Linux work on my laptop, compiling kernels, fixing driver issues, downloading patches, and so forth.  I was determined.  Then, a couple of laptops ago, I had this fateful moment where I unpacked my new laptop, booted it into Windows, shut it down, got out the Linux installation DVD, and then thought -- "Wait, why do I need to do this?  Windows just works." 

I didn't develop some sudden love of Microsoft, or some sudden dislike of Linux; I just didn't feel like it was worth the trouble.  I wanted to get to work, and work meant reading email and browsing the web and that all worked fine in the operating system that had been pre-installed.  If Linux had been pre-installed, I would have used that happily.  Anyhow, this post isn't intended to contribute to the perennial Windows vs. Linux debate.  This is a post about things that just work.  Or don't.

Today, there I was using Windows.  More specifically, I was reading email in Thunderbird.  I saved a Word document (let's call it "foo.doc") that was attached to an email.  When I saved the file, it somehow ended up without an extension.  I have no idea if this was a Thunderbird oddity, or something I did when saving the document, but there it was, on my desktop with no extension.  I could double-click on it all I wanted, but Windows had no idea it was a Word document, and wasn't about to open it for me.

So, I renamed it to have a .docx extension.  Instantly, the icon changed to the Word icon, and I merrily double-clicked.  Only to find out that Word popped up an error message because apparently it wasn't a document in the new Office 2007 format.  It was actually an old-school .doc file, not a new-fangled .docx file.  So, I renamed the file again to have the .doc extension.  But, Windows didn't believe me; so convinced was it that this was a .docx file that it named it foo.doc.docx!  I had to use Google to find some setting in the Control Panel that allowed me to actually rename the extension so that I could eventually open the file.

What went wrong here? 

• Thunderbird didn't warn me I was saving the file in a way that would make it impossible to open it. 
• Windows didn't auto-detect what kind of file it was. 
• Word didn't auto-convert it when I gave it the wrong extension. 
• Windows wouldn't let me change the extension without jumping through hoops.  

The short story: it did not Just Work.

Now, I'm not picking on the folks who build Thunderbird or Windows.  I use both products every day, and happily so.

CodeSourcery's products have the same kind of problems that I described above. 

And that is what this post is really about.

Software development is hard.  CodeSourcery's tools are not going to make it easy.  To be a good software engineer you need deep insight into your target domain, solid knowledge of computer science, and the soul of an artist.  Nothing we can do can give you those things.

But, we should be able to deal with some of the annoying problems that get in your way.  We should be able to set things up so that when you connect your target board to your JTAG device and plug that into the USB port on your computer, we figure out what JTAG device you're using, what board you're using, and then show you an example program for that board.  We should be able to connect to a Linux target, detect that its Linux kernel is too old to support the debug facilities GDB needs, and tell you that.  And perhaps tell you how to get a newer kernel.

I've asked our product development team to focus on this core idea: tools that Just Work.  Our product managers and I read every support request that CodeSourcery receives.  We're paying attention to the things that people tell us don't Just Work, and we're going to fix them.  That's not to say that we're not going to add new features.  But, we're going to go for depth, not for breadth; it's far better that we have fewer features that Just Work than more features that don't.

Marketing may not be happy that I'm admitting our products aren't perfect.  Of course, there are lots of things in our products that already Just Work!  That's why people buy them.  But, they can be much, much more powerful and much, much more simpler.  That's where we're going.

Freescale: A Hardware Company Going Soft(ware)

Freescale is a company that knows how to throw a party.  Start with a luxury resort, stir in food, drink, contests, lights, music, and high production value videos showing a vision of the future in which everyone has magic see-through tablet computers that do everything from holographic ping-pong to parking your car for you -- and shazam!  I spent this past week at the Freescale Technology Forum in Orlando, Florida and I had a pretty good time -- though now I need to catch up on my sleep!

CodeSourcery works with Freescale on toolchains for  three different architectures: ARM, ColdFire, and Power.  There were exciting announcements at FTF about all three architectures, but especially about ARM and Power.  Freescale's bringing out a new line of ARM Cortex-M4 based microcontrollers called "Kinetis" and adding a 64-bit addition to the Power QorIQ line.  There will also be updated ColdFire processors called "ColdFire+".  Of course, we'll be supporting all of these processors in Sourcery G++.

We've worked with Freescale for over five years now, and it's been very striking to see how much more important software has become to Freescale.  That change is industry-wide, but Freescale is a compelling example.   Freescale is still very much a hardware company; it operates its own fab and derives most of its revenue from silicon.  Silicon design is in the corporate DNA at a company like that.  But, as the hardware becomes ever more complex, software becomes ever more important. 

Freescale executives talked about the incredible complexity of the modern automobile, where "driver infotainment" systems talk to drive-train systems, braking systems, online navigation services, and even the little microcontrollers that control the motors in the power windows.  There's a lot of software involved in making all those systems work together efficiently and reliably.  And increasing pressure to get new designs to market quickly means that tools to help build that software are also increasingly important.

Some of these tools are going to go well beyond the traditional compiler, linker, and debugger.  Or even beyond the profiler and static- and run-time analysis tool.  For example, if the driver infotainment system in your car can talk to both the internet and the drive train, you need to have high confidence that a malicious evil-doer on the internet cannot make it impossible for you to slow down.  Hypervisors, analysis tools, and audits are all going to be a part of that, of course, but I suspect that we'll need some qualitatively new tools to give ourselves confidence in that process.  The traditional 5-year automotive development cycle is going to be too long when software and hardware platforms are moving as fast as they are, and we'll need to do better.

I was also fascinated by how much more traction open-source is getting among Freescale's automotive customers.  That's not just about tools, but also about the on-device software.  It looks like there's much, much more comfort with using Linux in cars than there was even a year or two ago.  And, of course, where Linux goes, GCC (and Sourcery G++) are certain to follow.  Fun stuff!

Linaro: ARM Linux Toolchains

Linaro, a new organization focused on improving core Linux technology for ARM, was announced about two weeks ago.  Since then, I've been asked by innumerable partners whether CodeSourcery is involved with Linaro, what exactly Linaro will produce, and whether, when we all grow up, there will be ARM-powered earrings that project a 3-D image of your Facebook page directly into your brain. 

Some people take the crystal ball in CodeSourcery's logo so literally!

The short answer is that, yes, CodeSourcery is involved with Linaro.  CodeSourcery has worked with ARM, Ltd. and, in fact, most of the other founding members of Linaro for many years.  So, it should come as no surprise that CodeSourcery has a contract from Linaro for a significant amount of toolchain development, as part of the Linaro Toolchain Working Group.  The starting point for Linaro toolchain development will be CodeSourcery's Spring 2010 Sourcery G++ release.  The Toolchain Working Group will be developing toolchains based on both GCC 4.4 and GCC 4.5 for Linaro's 10.11 release.  (The Fall 2010 Sourcery G++ releases will also be based on GCC 4.5 and will of course include improvements made in the context of Linaro.)

Linaro helps to validate my previous claims that semiconductor companies increasingly recognize the importance of tools to selling silicon and the fact that, in a world based on open-source tools, they will bear the lion's share of the costs of developing those tools.  (Of course, intelligent semiconductor companies recognize that the best way to get maximum return on their investment is to work with the folks in the pointy hats!)  Our contract with Linaro will involve developing improvements to the core tools (GNU compilers, debuggers, and such), and, hopefully, to other related tools, such as QEMU.  Those improvements will be available from Linaro, in Sourcery G++, and in the upstream open-source versions of the tools.

It's clear that Linaro represents a very significant investment by ARM and its partners in Linux and related open-source technologies.  I'm proud that CodeSourcery is playing a role in Linaro, and excited to see where it leads!

GCC++

In addition to my Chief Sourcerer's hat (and, yes, I do have one, and yes, it is tall and pointy, and yes it does have moons and stars on it -- how cool is that?), I also have a GCC Release Manager hat.  (Sadly, the GCC RM hat has no physical manifestation.)  I've been wearing the (invisible) GCC RM hat for a while now; my first release was GCC 3.0 in 2001.  In 2009, I asked the GCC Steering Committee to allow me to appoint three additional co-RMs, so now there are four of us.  Together, we share responsibility for production of the Free Software Foundation's releases of GCC.

The GCC RMs have the authority to create releases, and we also have the authority to prevent a change from going into the compiler if we think it is not safe to have that change in the upcoming release.  But contrary to what some people seem to think, GCC developers do not "work for the RMs".  We can't say "GCC needs a new loop invariant dataflow assignment register optimizer graph thingy" and just sit back while everyone runs around and builds one of those.  Our formal power is mostly limited to "No, you can't make that change right now; please come back after this next release is out."

But, there's a lot more to leadership than power per se.  I try to talk to GCC's stakeholders (end-users, GCC's developers, CPU companies, OS companies, and so forth) as much as I can to figure out what's going to help make GCC most successful, and then I try to find ways to make that happen.  Last Thursday, I tried something I'd never done before; I led an online (IRC) discussion between the GCC developer community and the GCC RMs.  (You can read the transcript if you're interested.)

The most important thing that came out of that discussion was confirmation that it was time to switch the implementation of GCC itself from C to C++.  (When I first started working on GCC, it was using K&R C, which, for you youngsters, is C without prototypes.)  That decision has now been made, and the GCC developer community is working on coding guidelines governing the subset of C++ that will be used.

So, why should anyone care what language the compiler itself is written in?  What if it were Tcl, or Objective BCPL, or Prolog, or Java?  Would that make it a better compiler?  No, of course not; what actually matters is how good the code that comes out of the compiler is, how clear its error messages are, what language features it supports, and so forth.  The implementation language is, in that sense, just a detail.

But, in other ways, this is a monumental shift.  GCC is in its third decade.  That's a remarkable success, but it does mean that there are some Old Crufty Bits.  As an industry, we've learned a bit about compilers and software engineering in general since then, and it's time to bring some of that knowledge to bear.  More modern coding practices will make the development team more productive and that means a compiler that's getting better faster.

C++ is particularly important when it comes to design of a proper plug-in API.  As I wrote a few weeks back, GCC should become a platform for other tools that need to process and manipulate programs.  It should become a more modular platform that can be used as a compiler, but also as a static analysis tool, or a coding-standards enforcement tool, or a domain-specific optimization tool.  But, to do that, we need clear interfaces for plug-ins to use.  Encapsulation and object-orientation will make that vision much easier to realize.  Because C++ is (almost) a superset of C, we can make that transition gradually, without a ground-up rewrite.  So, this transition indicates the vibrancy of GCC and a step towards an exciting future.

Trends in Silicon Design: A Sourcerer Couldn't Wish for More (Part II)

Yesterday, I mentioned that CodeSourcery is working with Texas Instruments to port the GNU toolchain to the C6000 family of microprocessors.  We're excited about bringing the GNU toolchain to C6X DSPs, and the prospect of running MMU-less Linux there.  TI's OMAP processors have both a Cortex-A8 and a C6X, so we'll be able to use the GNU toolchain to target both the application processor and the DSP.  Yippee!

I also said that C6X is an example of a fundamental trend in silicon design that can only be good for those of us who like development tools.  More and more functionality is being pushed from hardware into software.  There are tons of examples of this general trend, but here are a few:

• CISC instruction sets (which had many, complex instructions) gave way to RISC instruction sets (which have fewer, simpler instructions).  RISC designs are simpler, and thus faster.  But, it became much harder to program in assembly language because the assembly code is necessarily more verbose; compilers became absolutely essential.
• Exposed pipelines (in which the hardware doesn't bother to check whether a computation is complete before you try to use the results of that computation) require that the programmer understand the number of clock cycles required for each instruction, or insert explicit synchronization instructions; more work for the compiler.
• Very Long Instruction Word (VLIW) instructions sets require that the individual instructions be "bundled" by the programmer.  Packing instructions into bundles efficiently is necessary to get performance; yet more work for the compiler.
• Multi-core systems require that programmers write applications using multiple threads of control.  In many cases, caches are not coherent; programmers must explicitly coordinate memory accesses from the various threads.
• General-purpose Graphics Processing Units (GPGPUs) provide many, many simple, parallel processing units with dedicated memory.  It's "just a software problem" to move data to and from the GPGPU and parallelize your application across zillions of hardware threads.

The general trend here is towards silicon that has many very fast, very simple function units.  The theoretical peak performance on these CPUs is incredible.  But it's increasingly difficult for mere mortals to take advantage of that performance, or to figure out why an application isn't running as fast as it should, or why it's not working, or, worst of all, why it works except when it doesn't.

The TI C6X DSPs are a good example of this trend.  These are VLIW, exposed-pipeline DSPs with some special instructions for signal-processing.  Some C6X DSPs are multi-core.  Others (as mentioned above) are even heterogeneous multi-core.  Yikes.

To program these things effectively, you definitely need compilers that can generate efficient code.  You need libraries that provide high-quality FFTs and good synchronization primitives.  You need static checking tools that help you write good code, and not just good code in general, but good code for these CPUs.  You need debuggers that can tell you what's going on, not just on one core but on all of them.  You need visual profilers to show you which CPUs are busy at what times.  You need to know what parts of your application are consuming the most power.  You need to be able to view network traffic.

There are hard problems here, and many of them don't have easy answers.  But, the Sourcerer's Quest is to discover the answers.  One by one, day by day.  Tell us what you need.

Trends in Silicon Design: A Sourcerer Couldn't Wish for More (Part I)

At the recent Embedded Systems Conference Silicon Valley, we announced that we're working with Texas Instruments to develop a port of the GNU toolchain (GCC, Binutils, GDB, etc.) to the TI C6000 family of microprocessors.  In some sense, this is nothing new: the GNU toolchain has been ported to lots of processor families (even the PDP11).  And, CodeSourcery has done lots of work on the GNU toolchain for lots of different processors.  (Our standard products include toolchains for ARM, ColdFire, IA32, MIPS, Power, SuperH -- and, coming soon, Nios II -- but of course we've done work on other architectures as well.) 

So, is this just another GNU toolchain port?  A routine activity?  An excuse for a press release?  

I bet you've already guessed my answer: no, no, and heck no.  But why not?

First, the TI C6X DSP family has been around a long time.  (It's the C6X because there were earlier C5Xs, C4Xs, C3Xs, C2Xs, and C1Xs.)  C6X is a very popular DSP.  And TI already has good tools (its Code Composer Studio product) for targeting C6X.  So, why is TI investing in building out a GNU toolchain port?

Because TI wants to run uClinux (a.k.a., MMU-less Linux) on the C6X -- and people really want to use the GNU toolchain to build the kernel and all the other parts of the system.  Even when a company invests in making a proprietary compiler compatible with GCC -- down to the command-line options -- it still may not quite "just work" when you need to build thousands of open-source packages.  And GCC is a moving target.  And GCC's performance is as good or better in many cases.  So, TI has wisely drawn the conclusion that the right way to support uClinux on C6X is to have a high-quality GNU toolchain port to C6X.

This isn't just a company saying "Hey, we have some new silicon, and GCC is the fastest way to getting a working compiler for this part."  It's a company saying "Our silicon is more valuable if it runs uClinux, and therefore we need a great GNU toolchain for it."  That's exciting in and of itself.

But, this is actually a post about trends in silicon design and why we're excited about them.   So, what's interesting about C6X silicon from our point of view?  It's an example of hardware getting faster by pushing more functionality into software.  And that additional software complexity is fun for those of us working on software tools.

More on that tomorrow!

GNU Toolchains for Symbian

What's the world's most widely used mobile phone operating system?   Apple's iPhone OS?  Google's Android?  Palm's WebOS?  Guess again.

The world's most popular mobile phone operating system is Symbian.  It's not even close, actually; Symbian had 47% of the market in 2009.  There are tons of Symbian smartphones out there, and lots more being sold all the time.

Virtually all of those smartphones have CPUs that use the ARM instruction set architecture.  So, historically, Symbian (and most applications for Symbian) have been built using ARM's proprietary compilers.  But, Symbian is now an open-source operating system -- and it doesn't really make sense to require a proprietary compiler to build an open-source OS, does it?

Thanks to sponsorship from Nokia, we've had tools (Sourcery G++ Lite Edition) that could be used to build applications for Symbian for a while now.  (Nokia calls these tools "GCCE" for reasons that nobody seems to quite remember.)  But, with those tools you still need components from ARM's libraries to build a complete application.  

We've recently been working on a project with the Symbian Foundation to provide a version of the GNU toolchain that could be used to build Symbian applications -- and the whole operating system -- without any use of ARM's tools.  Our first release includes a debug agent that you can use to debug a Symbian application with GDB and a version of QEMU that can boot Symbian, so that you can debug a Symbian application without access to hardware.  You can read more about the release in this Symbian blog post. (Don't miss the bit about the "world's leading GNU tools consulting company"!)

The Symbian Foundation is organizing the effort to make it possible to compile the operating system as a whole with the GNU tools.  There's still a long way to go on that effort, as various parts of the source code use non-standard C++ constructs, or contain assembly code written in ARM's assembler syntax.  But, they're working on it.  I think this is a very exciting project; it's the equivalent of OpenSolaris in the mobile phone world.

As noted on the Symbian blog, the tools we're providing at this point are just the basic command-line tools.  And the Symbian build process is pretty complex.  Would you like to see a simple Eclipse-based application development environment for Symbian?  Let me -- and the folks at the Symbian Foundation -- know!

GCC Frontiers (Part II): Plug-ins

As I mentioned yesterday, I had the opportunity on Friday at the 2010 Linux Foundation Collaboration Summit to muse on big-picture improvements I'd like to see in GCC.  Yesterday I wrote about how we could make a good compiler even better by focusing more on the quality of the code GCC generates.  Today I'd like to address the other topic I addressed in my talk last Friday.

GCC, like most compilers, is an infuriatingly opaque box.  You provide C (or C++, or Fortran, or Java, or Ada, or whatever) code.  It parses your code, builds up all kinds of interesting data structures about it, figures out what functions call what other functions, which variables are used where, what range of values variables have, how long it's likely to take to execute particular pieces of code, and  much, much more.  And, then, having figured all of that out, it generates (generally inscrutable) assembly code.  Does it share with you what it learned about your program?  It most certainly does not.

You should be able to get much more of this information out.  You should be able to use it for static analysis that would help you to detect errors at compile-time.  You should be able to use it to optimize your program code to improve performance in ways that the compiler cannot.  In many cases, optimizations are limited because the compiler must make worst-case assumptions that you know are false -- but there is not any way for the compiler to tell you what worst-case assumption it is making, so you can't tell it not to be so conservative.

You should also be able to put much more information into the compiler.  You have knowledge about your application that is relevant both to analysis and to optimization.  You may want to tell the compiler that if you call lock in a function, you want to be warned if you don't call unlock before returning from the function.  You might also want to tell the compiler that a call to lock followed immediately by a call to unlock can be optimized away.  Right now, you have no way to do these things.

GCC needs to stop being purely a compiler and become a toolkit that can be used for compilation -- but also for all these other applications that depend on having some parts of a compiler available.  In my talk, I said GCC needs a "plug-in API" similar to those found in Firefox or Eclipse or Apache, but another way to say this is that GCC needs to become a library, a collection of modules that can be used much more broadly. 

GCC has started to move in the direction of both greatly improved performance and towards a more modular architecture.  Nothing I've espoused here is either purely my idea or incredibly radical.  I'm not calling for a dramatic shift in priorities or mindsets.  But, it is these directions that I think will yield the greatest return on investment for those of us who care about GCC.

GCC Frontiers (Part I): Performance

On Friday, I had the honor of speaking at the 2010 Linux Foundation Collaboration Summit on the topic of big-picture improvements I'd like to see in the GNU Compiler Collection (better known as GCC). (You can download my slides.)

I think it's safe to say that GCC is used by more developers than any other compiler.  GCC is used to build virtually all GNU/Linux systems.  GCC is also used on Android, FreeBSD, NetBSD, OpenBSD, on embedded RTOS systems (including VxWorks, QNX, ThreadX, FreeRTOS), on Solaris, AIX, and HP-UX, and even on Microsoft Windows. 

And GCC is certainly not standing still.  The GCC development team (which includes most of CodeSourcery's personnel) has just released GCC 4.5.0, which features significant improvements.  (CodeSourcery expects to ship GCC 4.5.x-based products in Fall 2010.)  There is very active development around everything from link-time optimization to taking full advantage of AVX vector instructions to ARM code size to MIPS library routines.  GCC is most definitely getting better.

So, the question is how to make the world's leading compiler even more leading?

There are two things we can do that I think will be transformational changes:

• Make significant improvements to the quality of the generated code
• Make GCC not just a compiler, but a platform for analyzing and optimizing programs

Today I want to share my thoughts about the first topic -- performance.  (Check back tomorrow for my thoughts on the second topic).

I've been talking to silicon vendors about GCC since I started CodeSourcery in 1997.  In 1997, the usual reaction was "What's GCC?"  At some point, the attitude changed; the silicon vendors started to realize that a lot of people wanted to use this Linux thing, and that they needed this GCC thing to use this Linux thing, and that their competitors had better GCC things than they did, and that this was causing them to lose silicon sales.  So, they started getting very interested in having CodeSourcery improve GCC's functionality on their CPUs.

But that wasn't about performance.  It was generally about being able to say that GCC could generate reasonable code for their latest CPUs and that all the features supported on their competitor's silicon were also supported on their silicon.  In fact, in some cases, the silicon vendors explicitly indicated that their goal was to have a basic functional version of GCC as an "enabling technology", but that some other compiler (typically an in-house compiler developed by the silicon vendor) was intended to be the "performance compiler" used by "serious developers".

That has changed dramatically in the last couple of years.  The embedded silicon companies have come to recognize that so many of their users are using GCC that if GCC can't generate good code for their fancy new silicon, they might as well not have built the fancy new silicon.  If GCC generates code that only delivers 90% of the CPU's performance, well, then, users will conclude that the CPU is only 90% as good as the silicon company thinks it is.  And building CPUs is sufficiently expensive, and the market sufficiently competitive, that leaving performance on the table is not an acceptable outcome.  So, over the last couple of years, silicon companies have been asking CodeSourcery to work hard on optimization.  And other companies with a stake in GCC's performance (notably Google) have also been investing.

GCC performance can improve in many ways, some technical, and some sociological.  I believe the technical improvements will come from several sources including (a) improved infrastructure that allows the compiler to know more about the whole program (rather than just a function or a file), (b) knowing more about the performance of the compiled code at run time, (c) designing optimizations tuned just for a single CPU, rather than trying to build generic optimization infrastructure that works on all CPUs, and (d) carefully tuning each optimization for each CPU. 

The principal non-technical source of improvement will be an ever-increasing focus on performance on the part of developers and other stakeholders, including careful monitoring of the impact of changes. 

Performance is at this point the only credible justification for the existence of most competing compilers.  Many compiler vendors will claim performance superior to GCC, even if their license agreements make independent analysis of that claim impossible to prove or disprove.  CodeSourcery's analysis shows that the overall results are mixed. GCC outperforms many competing compilers on many benchmarks, but competing compilers outperform GCC in many cases as well.  When GCC becomes the unquestioned leader, these competing compilers will fade away.

Products, services, and trickery.

Our web site is designed to trick you.  It's true.  And it's time to come clean. 

Our web site is our public face.  We show you what we want to show you.  In our case, what we want to show you is our products, and, in particular, Sourcery G++, our integrated development environment for professional C and C++ developers.  We're very proud of that product.  We're bundling free and open-source tools (GCC, G++, and Eclipse) together with some important proprietary components (for JTAG debug, to simplify cross-compilation) and our technical support.  And that's not support from a call center somewhere; that's support directly from our engineering team.

But, that's the trick, see.  We're hiding the engineering team.  You look at our web site, and you think that we download the source code for the core components, build them, put them on a CD, and then stick our logo on the CD.  Then buy some Google ads, go to some tradeshows, and voila!  We've got a product.  Without doing any heavy lifting.

Actually, though, CodeSourcery is first and foremost a services company.  We'd been providing GNU toolchain services for five years before we got the idea to start building products and, after I suggested it, it took me another couple of years to convince my fellow Sourcerers that I wasn't crazy.  Or at least that the idea of building products wasn't crazy.

In our services capacity, we've built out tremendous amounts of functionality in the GNU toolchain.  ISO-conformant C and C++ parsers in the front ends?  That was CodeSourcery.  Support for ARM's Thumb-2 ISA?   That was CodeSourcery.  Multi-process debug support in GDB?  CodeSourcery.  FDPIC on SuperH?   CodeSourcery.  Native POSIX Threads Library and Thread-Local Storage for MIPS?  CodeSourcery.  ColdFire V4e?  Yup, you guessed it.  We've contributed over 10,000 changes to the official source repositories for the GNU toolchain.  And counting.

Much of this work has been funded by architecture/silicon companies (including ARM, Freescale, Intel, MIPS, Renesas, and more) who want to ensure that the GNU tools work well on their processors.  They know that you will judge their silicon in part by how well the GNU toolchain works on their processors.

So, how is that relevant to you?  After all, you're probably reading this because you got tricked into thinking that CodeSourcery is a product company.  You're probably not designing some new piece of silicon for which you desperately need a high-quality port of the GNU toolchain.  You probably just want some tools for your next embedded development project.  So, why should you care that we have a thriving services business?

Because that means that our GNU tools have the latest and greatest bits for embedded targets.  We put the work we do for services customers into our stable source base in parallel with contributing it to the official upstream repositories.  Which means that we almost always have the first release with key new functionality. 

And because we can help you use those features.  Unlike competitors who bundle the tools, but don't develop them, we can explain all the tricks and traps.  And, if you find a bug, we can fix it.

Oh, wait, are we back to products now?  This blog post is on our web site.  So, even it is designed to trick you into thinking we're a product company.  Because we are a product company.   The bit about our web site being a trick?  That was a trick.