Re: Business of Compilers

"Jeremy Bennett" <jeremy.bennett@embecosm.com> wrote in message
> On Sun, 16 May 2010 02:03:08 +0530, Seima Rao wrote:
>
>> Twenty years ago, there was buzz surrounding compilers in the ISV
>> segment.
>>
>> I am eager to know what business opportunities are available in the
>> field of compiler technology nowadays. Is it possible to run a
>> company purely by selling compiler technology? How sustainable would
>> be such an enterprise? What compiler products can possible be sold
>> these days?
>
> Hi Seima,
>
> As others have commented, the success of open source compilers has
> limited the ability to sell a traditional commercial product.
>
> Which is not to say that you can't make money. GCC is ~4 million lines
> of code, a lot of it very complex. So there is money to be made in the
> service business.




Yes, and as well there is something to be said for smaller and more
streamlined compilers, which can do a more reasonable subset of tasks,
at < 10% as much code...


granted, one can't support every architecture under the sun this way, but
for many things this is a reasonable trade-off...


admittedly, smaller code doesn't automatically mean profitability either,
but it may allow one to do some things GCC can't do...




not that it necessarily needs to be a "one or the other" tradeoff either,
for example, I have written a compiler framework which is generally intended
to be used along with another compiler (such as GCC or MSVC), since these
old-guard compilers have a proven track record of producing solidly working,
and reasonably efficient, code.


the sibling-compiler strategy does allow then giving some additional
flexibility, without necessarily having to subject oneself to lots of pain
trying to track down little bugs in a large codebase with little idea if
they are due either to a problem in the code, or a bug somewhere in the
generated code.


similarly, I see little reason to abandon proven technologies without good
reason...




> Which is what we do at Embecosm (www.embecosm.com). But we need to be
> broader than just GCC, so we support the entire GNU toolchain,
> integration with hardware models and GCC derivatives such as MILEPOST.
> All as an open source business, from which we make money selling our
> services.
>
> Our view is that, at least in the embedded space, GCC or GCC
> compatible compilers, will continue to grow in importance for two
> reasons.




yep, fair enough...


there is something to be said for both source and binary compatibility
with GCC, even if the compiler is written using different code and
potentially different technologies internally.




> First, with heterogenous multi-core chips, users are not prepared to
> support multiple compiler tool chains, and GNU is generally the only
> unified toolchain option available. Indeed processor core
> manufacturers of all sizes are coming under increasing pressure from
> IDMs to improve their GCC offering for just this reason.




fair enough.


however, I am not certain why using multiple compilers is such a problem, I
guess so long as both can interface effectively.


admittedly, I have not had to deal with the issues of interfacing multiple
ISA's on the same system, this does seem like a bit of an ugly issue
(especially, for example, if they use different endianess or word-size and
potentially operate in different address spaces).


however, with the above, I am not sure how doing all development via GCC
particularly helps here.


unless maybe one has a bunch of vendors who can't agree on matters of
calling conventions or other ABI issues, or use different object formats, or
each offer different sets of extension features?...




so, maybe you can elaborate on this?...






> Secondly, the rise of Android and other Linux based operating systems.
> These all require a compiler supporting the GNU extensions.


yeah.


a lot of headers/... end up requiring one to silently mimic a lot of
specific settings from specific compilers, such as setting _MSC_VER or
__GNUC__ to the correct value, or any number of other special defines, and
also dealing with a lot of obscure syntax (new keywords, "__declspec" and
"__attribute__" blocks, ...).


similarly, each tends to be filled with their own little ways of violating
the C standard and trying to break ones' compiler...


so, a lot is trying to deal with things such as multi-line macro invokations
absent the usual line-continuation character, or maybe a several-pages-long
string literal with embedded linebreaks, ...


one may also have to deal with several different styles of inline ASM which
the header writers just decided was a good idea to leave in there, ...




admittedly, it takes a lot more than this likely to remain source compatible
(not a particular concern FWIW, more just a matter or trying to share code
and headers with the native compilers on the systems, and fixing up problems
when they arrise).




granted, this is something which annoys me somewhat about many opensource
projects:
the blatent disregard for compiler or OS portability, or that others may not
necessarily have particular versions of some wide number of libraries, ...


it all stands in contrast to my personal belief in minimalism and modularity
when it comes to dependency issues, where every unwarrented dependency is
another potential liability...


this goes along with the GPL, which anymore I feel is not necessarily the
best way to do open source, ...




> There will still be a place for proprietary compiler technologies,
> particularly for niche processors. Companies like ACE (mentioned
> earlier) and Target Compiler Technologies have a useful line in
> compilers driven from hardware specifications. However in a mature
> market, the free and open source offerings will continue to grow in
> importance.




fair enough.




> John added a comment about there being a lot of compiler activity in
> India. You'll notice the companies I mentioned earlier are all
> European. Contributions to GCC and the GNU tool chain are still
> largely from employees of US and European companies.
>
> At the moment offerings from countries such as Indian and China seem
> to be mostly noise rather than delivery. It's one thing to offer GCC
> compiler expertise, it's another to offer an implementation that works
> reliably and is accepted.
>
> However past experience suggests that will change. It's worth noting
> that a lot of the GCC project's best internal documentation comes from
> Indian academics, and it won't be long before that expertise migrates
> fully into the commercial space.




I don't know, I can't comment much here...




hopefully it is not the idea that the GCC codebase will necessarily always
be of central importance, as that would be lame (it being, IMO, a compiler
of codebase obscurity...).


granted, as of yet I have not seen any compilers with "nice" internals, as
in nearly all I am aware of, one ends up finding some confusing and hackish
mess.


it was this originally which prompted me to write my compiler clean,
although admittedly at nearly every turn I have underestimated things
(effort involved, ...). and at best my compiler is little better...


hackishness and ugly code are seemingly inevitible it seems.


one would think that compiler writers are at least trying to keep their code
clean and organized, although externally it seems almost like all anyone is
concerned with is trying to shave off a tiny bit more time for some or
another benchmarks...




but, hell, at least I had not implemented my parser via massive nested
switch tables and gotos:


top:
...
switch(*s++)
{
        ...
        case 'f':
                switch(*s++)
                {
                        ...
                        case 'o':
                                switch(*s++)
                                {
                                        ...
                                        case 'r':
                                                ...
                                                goto top;
                                }
                }
}




I remember at least one compiler I had looked at did something like this (I
forget which one though...).




though probably not as fast, I prefer my option of reading off tokens and
using big long if/else chains...
at least it is a "little" nicer to try to look at and follow...


but, it is funny, most of my running time still goes into my function for
reading off tokens (well, along with "strcmp", which is used fairly heavily
as well...).

Return to the comp.compilers page.
Search the comp.compilers archives again.