The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] History of popularity of C
@ 2020-05-21 18:28 Noel Chiappa
  2020-05-21 18:44 ` Thomas Paulsen
  2020-05-22  8:52 ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 2 replies; 17+ messages in thread
From: Noel Chiappa @ 2020-05-21 18:28 UTC (permalink / raw)
  To: coppero1237, tuhs; +Cc: jnc

    > From: Tyler Adams

    > C is so prolific and influential because it's so easy to write a C
    > compiler.

I'm not sure the implied corollary ('it's _not_ easy to write compilers for
other languages') is correct.

As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off
the shelf, and it reveals that the Algol 60 compiler discussed there (for the
KDF9), using lessons from the Algol compiler for the Electrologica X1, was
3600 words (roughly 3 instructions/word). So it was small.

Now, small is not necessarily equivalent to easy, but it was clearly not a
mountainous job. I imagine early BCPL, etc compilers were roughly similar.
The only language from that era which I can think of which was a slog,
compiler-wise, was PL/I.


I suspect the real reason for C's sucess was the nature of the language.
When I first saw it (ca. 1976), it struck me as a quantum improvement over
its contemporaries.

    Noel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-21 18:28 [TUHS] History of popularity of C Noel Chiappa
@ 2020-05-21 18:44 ` Thomas Paulsen
  2020-05-21 19:06   ` Paul Winalski
  2020-05-22  8:52 ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 1 reply; 17+ messages in thread
From: Thomas Paulsen @ 2020-05-21 18:44 UTC (permalink / raw)
  To: jnc@mercury.lcs.mit.edu (Noel Chiappa); +Cc: tuhs

>I suspect the real reason for C's sucess was the nature of the language.
it has most of the elements of structured programming as known in the 70the/80ths, and - most important - it produces small and fast performing binaries like no other high level language. Furthermore its syntax is relatively close to the system, and systems calls are easily adoptable. Thus for me it still is and ever will be the first choice. 




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-21 18:44 ` Thomas Paulsen
@ 2020-05-21 19:06   ` Paul Winalski
  2020-05-21 20:27     ` Thomas Paulsen
  0 siblings, 1 reply; 17+ messages in thread
From: Paul Winalski @ 2020-05-21 19:06 UTC (permalink / raw)
  To: Thomas Paulsen; +Cc: tuhs, jnc@mercury.lcs.mit.edu (Noel Chiappa)

On 5/21/20, Thomas Paulsen <thomas.paulsen@firemail.de> wrote:
>>I suspect the real reason for C's sucess was the nature of the language.
> it has most of the elements of structured programming as known in the
> 70the/80ths, and - most important - it produces small and fast performing
> binaries like no other high level language.

Sorry, but I can't agree with that statement (like no other high-level
language).  C is a decent language for systems programming but so are
other languages such as BLISS.  C is a terrible language if you have
to throw arrays around (which is why Fortran still rules the roost in
HPTC).

C, Pascsal, and other modern Algol-ish languages have well-behaved
grammars and were designed to be easy to lex and parse.  Fortran and
COBOL were designed before Chomsky's work on formal grammars became
well known, and as a consequence are bears to parse.  Fortran has
context-sensitive lexical analysis, for example.  But nobody knew any
better back then.

-Paul W.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-21 19:06   ` Paul Winalski
@ 2020-05-21 20:27     ` Thomas Paulsen
  0 siblings, 0 replies; 17+ messages in thread
From: Thomas Paulsen @ 2020-05-21 20:27 UTC (permalink / raw)
  To: Paul Winalski; +Cc: tuhs, jnc



>Sorry, but I can't agree with that statement (like no other high-level
>language).  C is a decent language for systems programming but so are
>other languages such as BLISS.  C is a terrible language if you have
>to throw arrays around (which is why Fortran still rules the roost in
>HPTC).

BLISS is known to a very small number of persons, thus irrelevant, and with regards to arrays, first they are rarely used in advanced programming preferring lists, maps, trees, etc.. second I never had problems with pointers.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-21 18:28 [TUHS] History of popularity of C Noel Chiappa
  2020-05-21 18:44 ` Thomas Paulsen
@ 2020-05-22  8:52 ` Tom Ivar Helbekkmo via TUHS
  2020-05-22  9:51   ` Tyler Adams
  1 sibling, 1 reply; 17+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2020-05-22  8:52 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS

Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:

> I suspect the real reason for C's sucess was the nature of the language.
> When I first saw it (ca. 1976), it struck me as a quantum improvement over
> its contemporaries.

Paul Graham expressed it like this:

"It seems to me that there have been two really clean, consistent
models of programming so far: the C model and the Lisp model. These
two seem points of high ground, with swampy lowlands between them."

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22  8:52 ` Tom Ivar Helbekkmo via TUHS
@ 2020-05-22  9:51   ` Tyler Adams
  2020-05-22 11:09     ` arnold
  2020-05-22 11:58     ` [TUHS] History of popularity of C A. P. Garcia
  0 siblings, 2 replies; 17+ messages in thread
From: Tyler Adams @ 2020-05-22  9:51 UTC (permalink / raw)
  To: Tom Ivar Helbekkmo; +Cc: The Eunuchs Hysterical Society, Noel Chiappa


[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

Awesome, looks like my theory was completely wrong. Here's what it looks
like to me, please correct me as needed.

C's popularity has 2 distinct phases.

1972-1987 Unix drove C. Writing a functional PCC for a particular
architecture was easy, but not unusually so compared to other languages at
the time.

1987- gcc made C uniquely free to compile, so people chose to write C
because it was free and already popular.

Perl also came out in 1987, and afaik that was always free, but C still
took off because there was so much room for multiple languages.

So, now Im curious about embedded systems. In my limited experience, every
"embedded system" I programmed for from 2002-2011 had C as its primary
language. After 2011, I stopped programming embedded systems, so I don't
know after that. Why was C so dominant in this space? Is it because adding
a backend to gcc was free, C was already well known, and C was sufficiently
performant?

Tyler


On Fri, May 22, 2020, 11:53 Tom Ivar Helbekkmo <tih@hamartun.priv.no> wrote:

> Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:
>
> > I suspect the real reason for C's sucess was the nature of the language.
> > When I first saw it (ca. 1976), it struck me as a quantum improvement
> over
> > its contemporaries.
>
> Paul Graham expressed it like this:
>
> "It seems to me that there have been two really clean, consistent
> models of programming so far: the C model and the Lisp model. These
> two seem points of high ground, with swampy lowlands between them."
>
> -tih
> --
> Most people who graduate with CS degrees don't understand the significance
> of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
>

[-- Attachment #2: Type: text/html, Size: 2459 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22  9:51   ` Tyler Adams
@ 2020-05-22 11:09     ` arnold
  2020-05-22 11:15       ` Tyler Adams
                         ` (2 more replies)
  2020-05-22 11:58     ` [TUHS] History of popularity of C A. P. Garcia
  1 sibling, 3 replies; 17+ messages in thread
From: arnold @ 2020-05-22 11:09 UTC (permalink / raw)
  To: tih, coppero1237; +Cc: tuhs, jnc

Tyler Adams <coppero1237@gmail.com> wrote:

> So, now Im curious about embedded systems. In my limited experience, every
> "embedded system" I programmed for from 2002-2011 had C as its primary
> language. After 2011, I stopped programming embedded systems, so I don't
> know after that. Why was C so dominant in this space?

First of all, because C is the (almost) perfect language for embedded
systems - tight code generated, language close to the metal, etc. etc.

> Is it because adding
> a backend to gcc was free, C was already well known, and C was sufficiently
> performant?

Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
in porting GCC to different processors used in embedded systems and
provided support.

Arnold

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 11:09     ` arnold
@ 2020-05-22 11:15       ` Tyler Adams
  2020-05-22 18:40         ` John Gilmore
  2020-05-22 14:59       ` Toby Thain
  2020-05-22 20:39       ` [TUHS] History of popularity of C (GCC/Cygnus) John Gilmore
  2 siblings, 1 reply; 17+ messages in thread
From: Tyler Adams @ 2020-05-22 11:15 UTC (permalink / raw)
  To: arnold; +Cc: jnc, The Eunuchs Hysterical Society


[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Doesn't C++ also generate tight code and is fairly close to the metal?
Today C++ is the high performant language for game developers and HFT shops.

But, I never found it on any of these embedded systems, it was straight C.

Tyler

On Fri, May 22, 2020, 14:09 <arnold@skeeve.com> wrote:

> Tyler Adams <coppero1237@gmail.com> wrote:
>
> > So, now Im curious about embedded systems. In my limited experience,
> every
> > "embedded system" I programmed for from 2002-2011 had C as its primary
> > language. After 2011, I stopped programming embedded systems, so I don't
> > know after that. Why was C so dominant in this space?
>
> First of all, because C is the (almost) perfect language for embedded
> systems - tight code generated, language close to the metal, etc. etc.
>
> > Is it because adding
> > a backend to gcc was free, C was already well known, and C was
> sufficiently
> > performant?
>
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1738 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22  9:51   ` Tyler Adams
  2020-05-22 11:09     ` arnold
@ 2020-05-22 11:58     ` A. P. Garcia
  1 sibling, 0 replies; 17+ messages in thread
From: A. P. Garcia @ 2020-05-22 11:58 UTC (permalink / raw)
  To: Tyler Adams; +Cc: Noel Chiappa, The Eunuchs Hysterical Society


[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Fri, May 22, 2020, 5:52 AM Tyler Adams <coppero1237@gmail.com> wrote:
<snip>

> So, now Im curious about embedded systems. In my limited experience, every
> "embedded system" I programmed for from 2002-2011 had C as its primary
> language. After 2011, I stopped programming embedded systems, so I don't
> know after that. Why was C so dominant in this space? Is it because adding
> a backend to gcc was free, C was already well known, and C was sufficiently
> performant?
>

I don't know how much gcc contributed to the success of C in the embedded
space. Microcontrollers are often programmed in assembly. They have memory
and speed constraints, much like the PDPs where C began. I think it goes
back to what Larry said about C being so close to the metal.

>
>

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 11:09     ` arnold
  2020-05-22 11:15       ` Tyler Adams
@ 2020-05-22 14:59       ` Toby Thain
  2020-05-22 20:39       ` [TUHS] History of popularity of C (GCC/Cygnus) John Gilmore
  2 siblings, 0 replies; 17+ messages in thread
From: Toby Thain @ 2020-05-22 14:59 UTC (permalink / raw)
  To: arnold, tih, coppero1237; +Cc: tuhs, jnc

On 2020-05-22 7:09 AM, arnold@skeeve.com wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
> 
>> So, now Im curious about embedded systems. In my limited experience, every
>> "embedded system" I programmed for from 2002-2011 had C as its primary
>> language. After 2011, I stopped programming embedded systems, so I don't
>> know after that. Why was C so dominant in this space?
> 
> First of all, because C is the (almost) perfect language for embedded
> systems - tight code generated, language close to the metal, etc. etc.

To my recollection, in 1985 C wasn't firstly considered an embedded
language; it was considered an applications language (so was assembly,
but we could say that was tapering off).

I believe the explosion in popularity was due to that lesson from Unix,
that you could have a single portable language for both "system" code
and applications code, with a modern looking syntax, that could be self
hosted and compiled to reasonably efficient machine code.

All those tradeoffs and definitions are very different 40 years later,
of course. (And C was far from the first or only language that met those
criteria before 1975. It just happened to take off.)

> 
>> Is it because adding
>> a backend to gcc was free, C was already well known, and C was sufficiently
>> performant?
> 
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.

Having to get a paid consultant doesn't exactly argue for the idea that
C compilers were "easy" - plus it's almost a decade after the period of
high growth. So this doesn't seem strong support for the thesis quoted
by OP.

--Toby

> 
> Arnold
> 


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 11:15       ` Tyler Adams
@ 2020-05-22 18:40         ` John Gilmore
  2020-05-22 19:01           ` Toby Thain
                             ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: John Gilmore @ 2020-05-22 18:40 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society, jnc

Tyler Adams <coppero1237@gmail.com> wrote:
> Doesn't C++ also generate tight code and is fairly close to the metal?
> Today C++ is the high performant language for game developers and HFT shops.
> 
> But, I never found it on any of these embedded systems, it was straight C.

My take on this is that programmers who understand the underlying
hardware architecture can easily intuit the code that would result from
what they write in C.  There are only a few late features (e.g. struct
parameters, longjmp) that require complex code to be generated, or
function calls to occur where no function call was written by the
programmer.

Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
generated code to do immense amounts of unexpected work.  Think of
string compares, hash table types, object initializers, or arbitrary
amounts of jumping through tables of pointers to different kinds of
objects.  Automated memory allocation.  Garbage collection.

This is both a blessing and a curse.  In C it was quite predictable how
well or badly typical sections of your code would perform.  If the
performance was bad, it was YOUR fault!  But at least YOU could fix it,
without learning to hack a compiler instead of your own application.

(I once found Berkeley SPICE code doing string compares in a triply
nested loop, just to look up the names of the signals.  In C.  Making
changes to a large state machine going into a custom chip was taking the
Sun hardware engineers multiple hours per change.  I spent weeks finding
the source code (Sun's tools group was dysfunctional; I got it from
UCB).  In half a day of profiling it and fixing it to cache the
result of the first string lookup on each signal name, four hour
rebuilds went down to under a minute.  A second day of profiling
and cacheing, just for fun, took it down to 10 seconds.)

	John

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 18:40         ` John Gilmore
@ 2020-05-22 19:01           ` Toby Thain
  2020-05-22 19:35             ` Larry McVoy
  2020-05-22 19:31           ` Larry McVoy
  2020-05-22 20:19           ` Michael Kjörling
  2 siblings, 1 reply; 17+ messages in thread
From: Toby Thain @ 2020-05-22 19:01 UTC (permalink / raw)
  To: John Gilmore, Tyler Adams; +Cc: The Eunuchs Hysterical Society, jnc

On 2020-05-22 2:40 PM, John Gilmore wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
>> Doesn't C++ also generate tight code and is fairly close to the metal?
>> Today C++ is the high performant language for game developers and HFT shops.
>>
>> But, I never found it on any of these embedded systems, it was straight C.
> 
> My take on this is that programmers who understand the underlying
> hardware architecture can easily intuit the code that would result from
> what they write in C.  There are only a few late features (e.g. struct

A short time playing with Godbolt should challenge that view :)

https://godbolt.org/


> parameters, longjmp) that require complex code to be generated, or
> function calls to occur where no function call was written by the
> programmer.
> 
> Whereas ...
> 
> 	John
> 


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 18:40         ` John Gilmore
  2020-05-22 19:01           ` Toby Thain
@ 2020-05-22 19:31           ` Larry McVoy
  2020-05-22 20:19           ` Michael Kjörling
  2 siblings, 0 replies; 17+ messages in thread
From: Larry McVoy @ 2020-05-22 19:31 UTC (permalink / raw)
  To: John Gilmore; +Cc: The Eunuchs Hysterical Society, jnc

On Fri, May 22, 2020 at 11:40:11AM -0700, John Gilmore wrote:
> Tyler Adams <coppero1237@gmail.com> wrote:
> > Doesn't C++ also generate tight code and is fairly close to the metal?
> > Today C++ is the high performant language for game developers and HFT shops.
> > 
> > But, I never found it on any of these embedded systems, it was straight C.
> 
> My take on this is that programmers who understand the underlying
> hardware architecture can easily intuit the code that would result from
> what they write in C.  There are only a few late features (e.g. struct
> parameters, longjmp) that require complex code to be generated, or
> function calls to occur where no function call was written by the
> programmer.

Amen.

> Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
> generated code to do immense amounts of unexpected work.  Think of
> string compares, hash table types, object initializers, or arbitrary
> amounts of jumping through tables of pointers to different kinds of
> objects.  Automated memory allocation.  Garbage collection.

Double amen.

> This is both a blessing and a curse.  In C it was quite predictable how
> well or badly typical sections of your code would perform.  If the
> performance was bad, it was YOUR fault!  But at least YOU could fix it,
> without learning to hack a compiler instead of your own application.

Triple amen.

> (I once found Berkeley SPICE code doing string compares in a triply
> nested loop, just to look up the names of the signals.  In C.  Making
> changes to a large state machine going into a custom chip was taking the
> Sun hardware engineers multiple hours per change.  I spent weeks finding
> the source code (Sun's tools group was dysfunctional; I got it from
> UCB).  In half a day of profiling it and fixing it to cache the
> result of the first string lookup on each signal name, four hour
> rebuilds went down to under a minute.  A second day of profiling
> and cacheing, just for fun, took it down to 10 seconds.)

Gazillion amens (I especially loved the jab at Sun's tools group, I
wrote the SCM that Sun used for Solaris initially.  They tried to get
me to join the tools group to make my stuff "official" - it worked just
fine being "unofficial".  I took a look at the people in the tools group,
no offense, but it was a big step down from working with people like srk
and gingell and shannon, not to mention that all of my peers were smart.
Tools group, just say no.)

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 19:01           ` Toby Thain
@ 2020-05-22 19:35             ` Larry McVoy
  0 siblings, 0 replies; 17+ messages in thread
From: Larry McVoy @ 2020-05-22 19:35 UTC (permalink / raw)
  To: Toby Thain; +Cc: The Eunuchs Hysterical Society, jnc

On Fri, May 22, 2020 at 03:01:40PM -0400, Toby Thain wrote:
> On 2020-05-22 2:40 PM, John Gilmore wrote:
> > Tyler Adams <coppero1237@gmail.com> wrote:
> >> Doesn't C++ also generate tight code and is fairly close to the metal?
> >> Today C++ is the high performant language for game developers and HFT shops.
> >>
> >> But, I never found it on any of these embedded systems, it was straight C.
> > 
> > My take on this is that programmers who understand the underlying
> > hardware architecture can easily intuit the code that would result from
> > what they write in C.  There are only a few late features (e.g. struct
> 
> A short time playing with Godbolt should challenge that view :)
> 
> https://godbolt.org/
> 
> 
> > parameters, longjmp) that require complex code to be generated, or
> > function calls to occur where no function call was written by the
> > programmer.

What John didn't mention, he just assumes people know and everyone is
the same, is that he is an excellent C programmer, I could fix bugs
in his code.

You can always fine someone who will make a mess of any language.
That's not the point.  

Assume that you have decent programmers, you will be able to understand
and fix their C code.  If you have really good C programmers, like
my company did, you can start to predict what the bottom half of the
function looks like by reading the top half.  We wrote very stylized C,
were not afraid of gotos when used wisely.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C
  2020-05-22 18:40         ` John Gilmore
  2020-05-22 19:01           ` Toby Thain
  2020-05-22 19:31           ` Larry McVoy
@ 2020-05-22 20:19           ` Michael Kjörling
  2 siblings, 0 replies; 17+ messages in thread
From: Michael Kjörling @ 2020-05-22 20:19 UTC (permalink / raw)
  To: tuhs

On 22 May 2020 11:40 -0700, from gnu@toad.com (John Gilmore):
> Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
> generated code to do immense amounts of unexpected work.  Think of
> string compares, hash table types, object initializers, or arbitrary
> amounts of jumping through tables of pointers to different kinds of
> objects.  Automated memory allocation.  Garbage collection.

What you wrote is pretty much my take on the subject as well.

However, part of me wants to say "let's not compare apples to
airplanes just because both start with 'a' and one can typically be
placed within the other".

C++ adds a ton of features on top of C, never mind early C, though for
the features that at least earlier C has (I'm honestly not sure about
the newer additions), C++ has very similar or downright identical
syntax compared to C.

As long as you stay with the basic C feature set, I strongly suspect
that most programmers who can follow along in the C to assembler to
machine code compilation process, can do much the same thing with C++.

It's when you start piling all the extras on top of it that things get
hairy from a code generation perspective.

Vectors? Function overloading? Exceptions? RAII? Try predicting the
execution order of destructors during exception handling for classes
with multiple inheritance where multiple inherited-from classes define
destructors. Anything else? :-)

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C (GCC/Cygnus)
  2020-05-22 11:09     ` arnold
  2020-05-22 11:15       ` Tyler Adams
  2020-05-22 14:59       ` Toby Thain
@ 2020-05-22 20:39       ` John Gilmore
  2020-05-23  4:33         ` Thomas Paulsen
  2 siblings, 1 reply; 17+ messages in thread
From: John Gilmore @ 2020-05-22 20:39 UTC (permalink / raw)
  To: arnold; +Cc: jnc, tuhs

Tyler Adams <coppero1237@gmail.com> wrote:
> > Is it because adding
> > a backend to gcc was free, C was already well known, and C was sufficiently
> > performant?

arnold@skeeve.com wrote:
> Cygnus Solutions (Hi John!) had a lot to do with this. They specialized
> in porting GCC to different processors used in embedded systems and
> provided support.

First things first.  When figuring out what happened and what became
popular, it's important to look at where money was flowing.  Economics
will tell you things about systems that you can't learn any other way.

Second, until the embedded market included 32-bit processors, gcc was
unknown in it.  32-bit was way less than 1% of the embedded market; only
in multi-thousand dollar things like laser printers (Adobe/Apple
LaserWriter) and network switches (3Com/Cisco/etc).  Cygnus ended up
with lots of those companies as support customers, because they were
sick of porting their code through a different compiler for each new
generation of hardware platforms.  But we had zero visibility into the
vast majority of the embedded market.  We went there because even our
tiny niche of it was huge, many times the size of the market for native
compilers, and with much more diversity of customers.

Early on, GCC had the slight advantage that because it was free (as in
both beer and speech) and had an email community of maintainers, many
people had started ports to different architectures.  Only a few of
those were production-quality, but they each offered at least a starting
point, and attracted interested users who might pay us to make them
real.

Cygnus was able to deliver production compilers for each new
architecture for significantly less than the other companies building
compilers for embedded systems.  I think that had more to do with our
pricing strategy than the actual cost of modifying the compiler.  Our
main competitors were half a dozen small, fat, lazy companies who
charged $10,000 PER SEAT for cross-compilers and charged the chipmaker
$1,000,000 and frequently more, to do a port to their latest chip.
Cygnus charged chipmakers $500K for a brand new architecture, and $0 per
seat, which caused us to eat our competitors' lunch over our first 3 to
5 years.  Then we hired someone who knew more about pricing, and raised
our own port price to a larger fraction of what the market would bear,
to get better margins while still winning deals.

We built the first 64-bit ports of GCC and the tools, for the SPARC when
SPARC-64 was still secret, and later for other architectures.  (Sun's
hardware diagnostics group funded our work.  They needed to be able to
compile their chip and system tests, a full year before Sun's compiler
group could deliver 64-bit compilers for customers.)

A lot of what got done to make GCC a standard, production worthy
compiler had little to do with the code generation.  For example, many
customers really wanted cross-compilers hosted on DOS and Windows, as
well as on various UNIX machines, so we ended up hiring the genius who
created djgpp, DJ Delorie, and making THAT into a commercial quality
supported product.  (We also hired the guy who made GCC run in the old
MacOS development environment (Stan Shebs) and one of the senior
developers and distributors for free Amiga applications (Fred Fish).)
We had to vastly improve the testing infrastructure for the compiler and
tools.  We designed and built DejaGnu (Rob Savoye's work), and with each
bug report, we added to a growingly serious free C and C++ compiler test
suite.  We automated enough of our build process that we could compare
the code produced by different host systems for the same target
platform.  (The "reproducible builds" teams are now trying to do that
for the whole Linux distribution code base.)  DejaGnu actually ran our
test suite on multiple target platforms with different target
architectures, downloading the binaries over serial ports and jumping to
them, and compared the tests' output so we could fix any discrepancies
that were target-dependent.  We hired full-time writers (initially
Roland Pesch, who had been a serious programmer earlier in life) to
write real manuals and other documentation.  We wrote an email-based bug
tracking system (PRMS), and the first working over-the-Internet version
control system (remote cvs).  Our customers all used different object
file formats, so we wrote new code for format independence (the BFD
library) in the assembler, linker, size, nm and ar and other tools
(e.g. we created objdump and objcopy).  Ultimately Steve Chamberlain
wrote us and GNU a brand-new linker which had the flexibility needed for
building embedded system binaries and putting code and data wherever the
hardware needed it to go.

We learned how to hire and manage remote employees, which meant we were
able to hire talented gcc and tools hackers from around the country and
the world, who jumped at the chance to turn their beloved hobby into a
full-time paying gig.  We started our own ISP in order to get ourselves
good, cheap commercial quality Internet access, and so we could teach
our remote employees how to buy and install solid 56kbit/sec Frame Relay
connections rather than flaky dialup access.

And because we didn't control the master source code for gcc, one of our
senior compiler hackers, Jim Wilson, spent a huge fraction of his time
merging our changes upstream into FSF GCC, and merging their changes
downstream into our product, keeping the ecosystem in sync.  We handled
that overhead for significant other tools by taking up the whole work of
maintenance and release engineering -- for example, I became FSF's
maintainer for gdb.  I would make an FSF GDB release two weeks before
Cygnus would make its own integrated toolchain releases.  If bug reports
didn't start streaming in within days from the free software community,
we knew we had made a solid release; and we had time to patch anything
that turned up, before our customers got it from us on cartridge tapes.

It wasn't just a compiler, it was a whole ecosystem that had to be built
or improved.  About half of our employees were software engineers, so by
the time our revenues grew from <$1M/year to $25M a year, we were
spending about $12M every year improving the free software ecosystem.
And because we avoided venture capital for six years, and shared the
stock ownership widely among the employees, when we got lucky after 10
years and were acquired by the second free software company to go public
(the first was VA Linux, the second Red Hat), all those hackers became
millionaires.  A case of doing well by doing good.

	John
	

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] History of popularity of C (GCC/Cygnus)
  2020-05-22 20:39       ` [TUHS] History of popularity of C (GCC/Cygnus) John Gilmore
@ 2020-05-23  4:33         ` Thomas Paulsen
  0 siblings, 0 replies; 17+ messages in thread
From: Thomas Paulsen @ 2020-05-23  4:33 UTC (permalink / raw)
  To: John Gilmore; +Cc: tuhs, jnc

>Early on, GCC had the slight advantage that because it was free (as in
>both beer and speech) and had an email community of maintainers
I remember that we started moving to gcc, gmake, etc,, because these tools 
performed simply spoken better than the native SNI ones.



^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, back to index

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-21 18:28 [TUHS] History of popularity of C Noel Chiappa
2020-05-21 18:44 ` Thomas Paulsen
2020-05-21 19:06   ` Paul Winalski
2020-05-21 20:27     ` Thomas Paulsen
2020-05-22  8:52 ` Tom Ivar Helbekkmo via TUHS
2020-05-22  9:51   ` Tyler Adams
2020-05-22 11:09     ` arnold
2020-05-22 11:15       ` Tyler Adams
2020-05-22 18:40         ` John Gilmore
2020-05-22 19:01           ` Toby Thain
2020-05-22 19:35             ` Larry McVoy
2020-05-22 19:31           ` Larry McVoy
2020-05-22 20:19           ` Michael Kjörling
2020-05-22 14:59       ` Toby Thain
2020-05-22 20:39       ` [TUHS] History of popularity of C (GCC/Cygnus) John Gilmore
2020-05-23  4:33         ` Thomas Paulsen
2020-05-22 11:58     ` [TUHS] History of popularity of C A. P. Garcia

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git