Re: Business of Compilers

"Tom Crick" <tc@cs.bath.ac.uk> wrote in message
> 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?
>>
>> [There seems to be a lot of compiler activity in India, less here in the
>> US. I can
>> think of a few standalone compiler tech companies that have been around
>> for a while,
>> but no new ones. Perhaps people in the biz can comment. -John]
>
> I recently attended a meeting organised by HiPEAC, the European
> Network of Excellence on High Performance and Embedded Architecture
> and Compilation [http://www.hipeac.net] and they were some
> presentations from industry; the topic of the number of companies
> solely providing compiler technology was raised by a representative
> from ACE Associated Compiler Experts [http://www.ace.nl]. They
> estimated that in 2002 they were aware of c.120 companies selling
> compiler technology; today only c.70, with most having ceased trading
> or been taken over and taken in-house by bigger tech firms.
>
> And that it is only possible to make money by proving
> services/solutions/consultancy rather than by simply developing a
> toolchain.


that is one possibility.


Also Possible Is To Develop And Sell Another Program As Their Main
Product, And Maintain The Compiler As A Side-Project (Such as using it
for helping to develop their main products).


For Example, A Company Developing Consumer Electronics could have a
dedicated compiler team as well as a team dedicated to working on and
maintaining the OS kernel, ...


one could argue: why not just use Linux?...
well, a reason that comes to mind here is that it is the GPL, and that the
FSF gets notably fussy over anyone using GPL stuff in consumer electronics
(where there may be reason not to want either to release the source, or the
device may not warrent user patching...).


so, this is at least one reason to avoid dependence on GPL'ed code.


anymore, I have other reasons, which is personally why I am using the MIT
liscense for a lot of my stuff...




Well, As Well As, For Example, GCC having a few other weak points:
it is not exactly a small project;
I personally found the code confusing and ugly-looking;
getting it to build is not exactly an easy task;
...


admittedly, large size and confusing/ugly code are problems I have
noted are particularly difficult to avoid (especially in compilers),
and probably to an outside observer, my codebase would share many of
the same faults.


for example, how does one have a clean architecture?...




many of my components use internal data representations which are,
sadly, both needed in many cases, and unlikely to be provided in other
contexts.


there are very few standards as to which parts exist within a
compiler, or how data is represented, and as a result it is not very
easy to mix/match/replace compiler parts (for other reasons, I feel an
OO-based strategy is not really the answer here, although this is
generally what LLVM uses AFAICT).


personally, I guess I more believe in having specified and consistent data
representations, rather than placing all my belief in other OO or in plug-in
interfaces to keep things flexible (although they may help, they are not a
sufficient answer IMO).




things are not even all that consistent within my project, as some parts use
S-Expressions for AST's (my current BGBScript implementation), and other
parts use XML for the AST's (C, current Java & C# effort).


as well, there is no overarching spec as to the exact contents and structure
of the AST's, ...
(I am left thinking I may need to add a "srclang" attribute to the AST root
node to deal with the structural and semantic differences, say, between C
and Java AST's, ...).


similarly, the preprocessor->parser interface uses an unusual notation
(prefix line-number comments, vs "#line", ...).
a lot of my stuff uses databases and a signature system, neither of which
are externally standardized (the database is a heirarchical key/value
system, and the signature-system is a mashup of the Java ".class" signatures
and the IA-64 name-mangling, along with a lot of "custom" notation).


there is also the matter of inconsistent memory management (for performance
and reliability reasons, most compiler-related components have their own
internal memory management, and MM issues may need to be considered when
using them). (for various reasons, compiler internals and GC don't mix
well...).


my existing low-level codegen is also just terrible (the internals are
complicated and hairy, ...).




all this means that parts written, for example, for other compilers can't
easily plug into my compiler, and parts written for my compiler can't be
easily plugged into other compilers.


best I can do is try to keep the parts relatively open, such that the data
may be used in more ways, or that new parts can be written against the
pre-existing machinery.


this is sad...


I am left thinking compiler internals are likely almost invariably an ugly
mess...




in my "larger project" (outside all my compiler/VM stuff), there is still a
lot of GPL'ed code floating around, which I may need to eventually
weed-out...


admittedly, at present I lack much of anything which anyone would likely
actually want to buy (nor any particularly good ideas for what would make
sellable products...).

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